Foundry · 本体数据平台
把散落的数据表变成"能查、能改、能治理"的业务对象（Object / Link / Action），是全矩阵的语义层地基。本页用场景故事带你认识它擅长什么、怎么调整、边界在哪里。
能 / 不能速览
- 数据接入 + 元数据导入，把表建模成本体对象（Object）
- 对象查询 / 语义检索 / OOL，按业务语言取数
- Action 唯一写路径：RBAC + 乐观锁 + 幂等 + 审计，安全写回
- 版本治理：draft → review → merged，快照 + diff + 影响分析
- 指标语义层、管道构建、数据血缘与质量
- 对象查询是轻量 OOL：单对象、≤3 层深、禁点号，复杂 join 不支持
- 跨数据源管道暂不做（单数据源 SQL 步骤）
- HTTP / API 类 Action 回写未实现，仅 SQL 类
- 版本管理是"浓缩版"，不是真正全局分支
适用角色
- 数据工程师：核心使用者，负责数据源、本体建模、管道与版本合入。
- 业务分析师：对象查询 / 语义检索自助取数，消费统一指标口径。
- 业务决策者：通过仪表盘与指标消费洞察，审批受保护的变更。
- 平台管理员：权限（RBAC / RLS）、审计、系统健康。
核心能力（能做什么）
本体论引擎
Object / Link / Action 三要素：对象定义属性与约束，链接表达关系（1:N / N:N），动作提供唯一写路径。
对象查询三件套
SemanticSearch（找口径）+ OOL（单对象遍历过滤）+ 对象查询（页面精确过滤），覆盖从"不知道该去哪查"到"精确定位"。
Action 写路径
VALIDATE / RUN / VALIDATE_AND_EXECUTE 四模式执行，乐观锁防并发冲突，幂等防重放，强制审计。
版本治理
草稿 + 快照 + 变更 diff + 审批策略，合入前做影响分析，历史版本可回溯可回滚。
指标语义层
entity / dimension / measure / metric 四层，把 total_gmv、aov 等口径集中管理，消灭"口径对不上"。
管道 + 血缘 + 质量
SQL 步骤声明式管道（含 write_mode），四级血缘（源 → 管道 → 对象 → 指标 → 报表），质量规则拦截问题数据。
做得好的场景
- 10 分钟建模型：数据工程师从接数据源到对象可查询，分钟级完成，替代数天排期。
- 业务自助取数：分析师用业务语言查数，口径统一，不再等临时报表。
- 受控数据变更：改状态 / 改字段走唯一写路径，冲突有 409、重复有幂等、过程有审计。
- 核心对象演进：版本快照 + 影响分析，改核心对象不心惊胆战。
限制与不足
- 查询深度受限：OOL 单对象、≤3 层深、禁点号；跨源复杂 join 不支持。
- 占位 / 未实装项：order_to_product 是占位链接；语义检索向量增强默认关闭；HTTP / API 类回写未实现。
- 版本非真分支：浓缩版（快照 + diff + 审批），复杂多人并行能力有限。
- 演示数据会重置：demo 数据源每次启动重建，源表改动重启还原（编辑态 / 审计保留）。
主题列表
常见问题
Foundry 和 AIP 是什么关系？
AIP 负责"自然语言查数"，Foundry 是它的语义层地基：AIP 的查询准确率来自 Foundry 的对象与指标口径。数据工程师把数据建模成对象，分析师和 AI 都消费同一套语义。
不会 SQL 能用 Foundry 吗？
能。对象查询、语义检索、指标查询都是页面操作，按业务语言选对象、加过滤即可；SQL 只出现在管道构建等数据工程场景，分析师不需要碰。
数据写回安全吗？
安全。所有写操作必须走 Action：参数 Schema 校验、逐动作 RBAC、对象 / 记录级写权限、乐观锁防冲突、幂等防重放、强制审计，还保存修改前状态快照。
怎么体验？
启动 Foundry 后端（18081），用 admin / admin1 登录。演示数据自动就绪：foundry_demo_warehouse 数据源、customer / order / product 对象、update_order_status 动作、total_gmv / aov 指标。建议先看"入门：从数据到本体"。