文沥整个产品体系
核心本体建模
让数据的意思，全公司只有一个答案
数仓解决「数据是什么值」，本体解决「数据是什么意思」。它是概念、关系、规则的共享语义约定——口径统一有唯一定义处、归因穿透有显式关系链、业务规则有版本化沉淀处。没有语义基座，跨杠杆的统一分析与决策闭环无从谈起。
不缺数据，缺的是对数据的共同理解
消费品企业的经营会上，最常见的场景不是「没有数据」，而是同一份数据在三张表里有三个名字、一套口径有三种算法、一次归因断在半路。这三个问题的根，都在语义层缺失。
一个词，三种算法
财务、销售、市场各算各的「净收入」：折扣算不算、返利扣不扣、费用摊在哪一级——口径互不认可，经营会的前半场永远在「对数」。
差距停在总盘
知道没达成，却到不了「品类 × 渠道 × 区域」的颗粒度；「买赠促销影响了到手价，进而影响品类销量结构」这类跨域链条，在散落的表结构里根本连不起来。
规则散落在代码里
折扣上限、毛利下限、活动互斥、库存覆盖——业务规则被写死在各个功能模块的代码中，改一条要发版，改了也说不清影响面，更谈不上审计。
本体由四部分咬合而成
概念定义「有哪些东西」，关系定义「怎么关联」，规则声明「口径与约束」，实例映射把数仓里的数据行绑回业务实体——四者缺一，语义层就立不起来。
概念体系
业务的「名词表」：分类树 + 属性 + 同义词归一。经销商、门店、SKU、品类、活动、条款各自定义清楚，别名收敛到一个标准概念。
关系体系
概念之间怎么连：方向、基数、生效时间，并显式包含影响关系——「促销 → 到手价 → 价格指数 → 销量结构」这条链，是归因能穿透的前提。
规则声明
口径与约束的声明处：A/B/C/D 四类规则全部挂载在本体上，声明与执行分离——本体只声明，规则引擎统一执行。
实例映射
数仓的一行数据，对应哪个本体实例、用哪套口径解读——数仓与本体之间唯一的衔接点，覆盖率与冲突率可监控。
Core 沉淀共性，五域各自扩展
全公司共用的概念沉淀在核心本体 Core；五个杠杆域在 Core 之上扩展专属概念与关系。关键设计：域间影响关系定义在同一张图上——这是「一次买赠促销同时作用于包装、价格、品类、渠道」能被一条链解释的原因。
全公司共用的共享概念
跨域复用的基础实体与度量，一处定义、全局生效。
价格
牌价 / 到手价 · 价格带 · 价格弹性 · G2N 折扣瀑布
包装
规格 / 组合 · PPA 架构 · 每单位价格 · 规格角色
品类
品类角色 · SKU 角色 · 健康度 · 新品淘汰状态机
促销
机制 taxonomy · 活动×SKU×门店×时间 · 互斥网 · ROI 增量
渠道
渠道层级 · 利益链毛利分配 · 覆盖关系 · 串货判定
A / B / C / D：本体上挂载的四类规则
规则全部由规则引擎统一执行，业务逻辑不散落在代码里——版本化、可灰度、可回滚、可审计。四类规则各司其职：
| 类型 | 名称 | 规则引擎统一执行什么 | 消费品示例 |
|---|---|---|---|
| A | 约束校验 | 数据与业务事实必须满足的硬约束，不满足即拦截或告警 | 到手价不得高于牌价 × 折扣上限；活动必须挂至少一个 SKU |
| B | 关系推理 | 沿关系链推导隐含事实，无需人工维护派生数据 | 经销商覆盖区域 R、门店属于 R ⇒ 门店为潜在覆盖；子品类继承品类规则 |
| C | 计算瀑布 | 口径计算的分解顺序，同一度量全公司只有一种算法 | G2N：牌价 → 折扣 → 费用 → 返利 → 净收入，逐级瀑布、逐级可归因 |
| D | 决策护栏 | 优化引擎生成方案时不可越界的业务边界 | 促销预算不超品类上限；毛利下限；互斥活动不得同投；库存覆盖天数下限 |
四类规则的关系：A 校验输入合规 → B 推理补全隐含事实 → D 护栏划定优化可行域 → C 瀑布贯穿始终统一口径。规则声明在本体、执行在引擎，这是「声明与执行分离」的落点。
让本体活得下去、长得起来
建模不是一次性工程。四大能力模块支撑本体从「建起来」到「持续生长」：
本体管理
建模工作台：提案 → 评审 → 发布 → 退役全生命周期管理，谁改了什么、为什么改，全程留痕。
实例映射
数仓数据行 ↔ 本体实例的绑定与监控：覆盖率与冲突率可量化，冲突自动进入人工仲裁队列。
关系推理
继承、传递、一致性检查——沿关系链自动推导隐含事实，并校验新声明与既有关系是否冲突。
版本演进
版本化、灰度、回滚——复盘回流的技术载体。每次闭环校准都落成一个可审计的新版本。
三条原则贯穿始终
本体的价值来自克制——不试图一次建全，而保证每一次扩展都可解释、可回退、可复用。
声明与执行分离
本体声明规则（A/B/C/D 挂在哪、口径怎么算），规则引擎统一执行。业务逻辑不再散落在代码里，改规则不改代码，影响面可评估。
逻辑与物理解耦
本体是逻辑模型，与存储引擎无关——关系库起步、图数据库演进，模型不动。数仓专注「存得住查得快」，本体专注「理解一致」。
版本化闭环演进
每次复盘回流都落成可审计的新版本：验证成立的规则被强化，失败路径触发本体扩展评审。本体随业务一起长，越用越准。
本体如何驱动三个引擎
数仓出事实、本体给语义，三个引擎依次接管——这是从「理解数据」到「给出方案」的完整链路。
口径已由 C 类瀑布统一
划定可行域
跨杠杆穿透根因
max(净收入 − 成本)
结果回写数仓
⑥ 复盘回流，让本体越用越准
WELINK 六步闭环的最后一步，回流的落点之一就是本体。验证成立的规则被强化，失败路径触发本体扩展评审，全部版本化落地。
