实践案例：拾光传媒本体

一个真实运行的 Operational Ontology 实例——广告变现中间平台（多上游 / 多下游 / 多站点）。
用六要素把「跑了两年的存量系统」显式化为 AI 可读、可推理、可安全行动的本体。

一、规模一览（v0.4）

二、六要素怎么落地

对象（16）——地图上的点

supplier（上游预算方） → supplier_service（接入服务） → link（链接，核心）
domain（域名资源）    → ad_unit（广告单元）        → channel（下游渠道）
downstream_user（下游客户） / traffic_site（流量站点） / vps_node（拉数节点）
project / site_template（建站） / alert_rule（告警规则） / account_manager（账号）

关键决策：domain_id 是资源属性不参与去重——一个域名可被多个链接引用。这是身份判定（Identity）在真实业务里的显式表达。

关系（14）——地图上的边

supplier 1-N supplier_service       链接 1-1 服务
link N-1 domain（资源属性，不去重）    link N-1 ad_unit
link N-1 channel（channel_id=0=未分发） ad_unit N-1 channel（间接路径）
downstream_user N-M link（授权）      alert_rule N-1 supplier（可空=全局）

核心链路：supplier → supplier_service → link——数据管线按此拆分归属。

属性（13）——现在怎么样

• 三率模型（财务核心）：deduction_rate 扣量率 / upstream_settle_rate 上游分成率 / split_rate 下游分成率
• 收入四口径：display_revenue（扣量后）/ upstream_revenue（上游分成后）/ settle_revenue（下游分成后）/ profit
• 类型体系：plain（静态值）/ time_series（流水）/ marking（标记）——快照与流水分离

动作（8）——按钮

sync（同步） deduction（扣量） write_pipeline（写管线） risk_alert（风控告警）
audit（审计） dim_expand（维度展开） build_site（建站） push_settlement（推送结算）

唯一写通道：所有写操作默认走动作——AI 不做裸写，只按定义好的动作行动。每个动作过六步流水线：参数校验 → 权限 → 业务规则 → 事务 → 副作用 → 审计。

规则（23）——凭什么做

# 计算公式（红线：不可改）
display = original x (1 - deduction/100)     # 扣量
upstream = original x upstream_settle_rate/100
settle = display x split/100
profit = upstream_revenue - settle_revenue
display_ecpm = display_revenue / impressions x 1000
# 异常判定（运营经验显性化）
IF eCPM < 阈值 AND 流量质量 < 阈值 → 建议暂停链接
IF 当日收入 = 0 且 上游有时效差异 → 不告警（数据滞后，非丢失）

权限（四层）——边界

三、决策链（Q5 闭环）

首选链：供应商异常处置

上游 API 异常 → 同步失败 → 风控规则判定 → AI 告警 + 状态快照
→ AI 生成处置建议（规则可引）→ 人审批 → 动作执行（暂停/重试）→ 审计留痕

OMA 五维自检：Q1 地图 ✅（16对象）→ Q2 按钮 ✅（8动作）→ Q3 依据 ✅（23规则）→ Q4 边界 ✅（四层）→ Q5 闭环 🟡（AI 建议到位，审批流建设中）。

四、从存量系统改出来（不是新建）

• 系统已跑两年，代码 / 数据库 / 经验全在——本体是改造存量，不是推倒重来
• 文档体系（系统全景 / 数据管线 / 坑点库）= 未结构化的本体，做的只是显式化 + 机器化
• 经验沉淀 = 实战回填：每次异常处置把隐性规则补进本体（git 版本化 + 变更纪律）

一句话：拾光传媒本体证明——Operational Ontology 不是理论口号，是把 AI 从「会告警的聊天助手」推向「权限内推动动作的协作方」的工程路径。