用途
Operational Ontology 是一个参考实现，旨在让“运营本体”这一概念变得可运行、可阅读、可改编。它解决了这样一个问题：当需要以业务术语一致地读取和操作来自多个系统的数据时，仅仅一个语义层（semantic layer）不足以描述整个责任范围。运营本体不仅用于读取业务，还用于运行业务——即通过共享模型执行经过业务规则检查、可审计且能写回源系统的操作。
主要能力
该模式具有四个核心属性：
- 语义对象与链接：在外部系统拥有的现有数据之上显式建模业务实体和关系。
- 动作门控写入：业务决策只能通过命名动作改变状态，所有消费者使用同一套 API。
- 动作上的业务规则：前置条件强制领域不变量（如“已发货订单不能取消”），违规产生机器可读的拒绝，已应用和已拒绝的尝试都会被审计。
- 写回记录系统：每个状态有明确的所有者，对源拥有状态的更改通过受治理的副作用传播回其所有者。
所有权在示例中有三种形式：源支持（source-backed，如 ERP 拥有 Order.status）、本体拥有（ontology-owned，如指派人和备注）、派生（derived，如查询时计算的总计）。
该实现将模型定义为普通值，包含对象类型、链接类型和动作类型。编辑描述动作对对象和链接的更改提议，审计日志记录动作执行尝试及其结果。模型也可以是数据而非类，因此可以枚举描述操作所需的信息，并在运行时检查，还能据此生成 MCP 工具。
演示中包含：通过链接和聚合跨两个系统回答业务问题；cancelOrder 拒绝已发货订单并将允许的取消写回原始 ERP；assignOrder 和 addOrderNote 存储本体拥有的状态，在源数据刷新重新索引后仍然保留；已应用和已拒绝的动作尝试出现在审计日志中。
使用方式
需要 Node.js 24 或更高版本以及 pnpm。运行演示可执行 pnpm demo。测试可通过 pnpm test 运行。仓库的 MCP 配置连接了订单示例，代理可以调用生成的工具如 search_order、traverse_customer_orders、cancel_order、read_audit_log 等。代理取消已发货订单时会收到 SHIPPED_ORDER_CANNOT_BE_CANCELLED，与人类调用者一致。业务规则位于模型中，因此提示词不必强制执行规则。
适用场景
该仓库适用于数据驱动的运营场景，例如产品召回、设备异常、患者入院请求、交易警报等。运营团队需要汇集信息，决定对谁或对什么采取行动以及依据什么证据，并随着条件变化重复这些决策和行动。演示提供了订单示例，以及召回、工厂、医院和金融等扩展示例，这些示例将集合探索与领域规则结合在模型中。此外，该模式也适用于需要为 AI 代理提供一致业务操作接口的场景。
限制
该仓库实现的是中间层，演示提供了周围的应用程序和数据集成。运行时使用同步动作执行和 SQLite 进行演示。它不包含 UI 构建器、管道框架、可扩展的索引服务或通用授权系统。写入门控是调用者进程内的 API 契约。动作可以创建本体拥有的对象或通过写回创建源支持的记录，但使用执行前指定的 ID。不支持删除、链接属性和复合键。该实现是学习资源，不是框架或 npm 依赖。发布版本可在发布说明中查看。实现注释中记录了其余限制和 API 详细信息。
