这套公式 · 第一部分
元模型是每个团队共享的模式：节点类型、关系、属性和生命周期状态，只定义一次。它不是数据字典——字典只是罗列词汇。而这一套是经过校验的：关系只能存在于允许它的类型之间，而每个节点都带有由平台强制执行的生命周期。
452
146
223
77
分类方式
单轴目录只按领域分类，一旦同一套分类需要以同等精度覆盖车间里的一台机器、一个 AI 模型、一项法律义务和一个销售流程，它就会失效。
它位于何处——十个组织维度，每个维度负责其中元素的治理与生命周期。它从根本上是什么、做什么——十二个职能维度，即承载语义契约的通用原型。两者合在一起：452 种类型化的节点类型。
组织维度
类型
类别
战略与影响
人力资源
业务
治理与合规
数据与知识
应用
技术
实物资产
外部实体
人工智能
这个顺序既不按字母排列，也不按规模排列。它是一个组织诞生的顺序：先有意图，然后是人，然后是他们经营的业务，再是他们经营所遵循的规则，接着是知识、应用、技术、实体设施、与之往来的外部世界——最后，是读取以上全部九项的智能。
“列出治理领域中的每一个任务”，不再需要编写自定义联接。
职能轴，完整呈现
动机与约束是两极——组织在追求什么，以及它不能做什么。其他所有元素都位于两者之间。
动机
约束
行动者
任务
资源
服务
环境
事件
信息
知识
技能与功能
分组
每一种原型都带有识别它的问题、将它与相邻原型区分开的边界，以及细化它的类别——而这十二种原型通过同一套封闭的类型化关系语法相互连接。
扩展
两个听起来互不相容的主张：这套语法是封闭的，而您又可以扩展它。两者都成立，而对二者的调和，正是本页最重要的一句话。
开放的是词汇——您可以添加组织真正需要的节点类型。封闭的是语法：新类型必须被赋予十二种原型之一，并继承该原型所允许的关系。您获得的是一个新词；您无权发明新句法。
而且扩展并非随心所欲。每种类型都有四个必填槽位，第四个正是任何目录都不会问的那一个：何时不应使用它——正是这条边界，防止两个团队悄悄为同一事物创建出相互重叠的类型。
类型一经存在，就成为智能体所知的一部分。因此：
在您用过的每一个元数据系统里，增长都意味着熵增。在这里，增长意味着精确。
使用指引
每种类型都有四个必填、可翻译的槽位。它们是结构性的，因此无法跳过：
如何使用
何时使用
使用示例
何时不应使用
这与通常的做法恰恰相反。一次强制性的年度培训，最后留下的是一份流程和邮箱地址清单，要求某人为一个可能八个月后才出现的情况把它背下来——外加一张只证明出席、不证明记住的结业证书。指引远离行动的那一刻，于是行动的那一刻，恰恰是指引缺席的时候。
在这里，指引就在类型上，就在使用之处。没有人需要记住它在哪里，因为它不在别的任何地方。
而人所阅读的这四个槽位，也正是智能体用来消除歧义的内容。一个来源，两个使用者。
视角
一个规范节点
保持不变
文档工具给每个团队各自一个页面；元模型则让每个团队在同一个页面上拥有各自的视图。
这一点之所以重要，是因为另一种选择是达成一份全公司的命名共识——一个没有人愿意牵头的项目，也是大多数共享模型项目还没交付任何成果就夭折的原因。
内置能力
每种节点类型都定义了自己的责任矩阵，取自平台自带的责任类型——以及您组织新增的任何责任类型。因此，每个节点一诞生就知道由谁对它负责。没有人需要逐个节点去配置。
负责人
归其所有
数据管理员
由其管理
数据保管员
由其保管
审查人
由其审查
审批人
由其审批
发起人
由其发起
财务总监
财务由其控制
法律顾问
获得其法律咨询
风险经理
风险由其管理
数据控制者
处理由其控制
数据处理者
处理由其执行
运行负责人
由其运行
领域专家
获得其提供的专业知识
每个节点还带有由平台强制执行的生命周期状态——77 种状态，各自归属于七个族之一。族是通用的主干；状态是您所在领域的词汇。与类型本身相同的两级结构。
而一个状态归属于哪个族，本身就是一项决定：
源中缺失
已实施
已提议
过时、核验和重新流转并不是关于模型的报告——它们是模型中的位置。
承上启下
填充它的是您的组织——而有用之处在于，它并非从空白开始：它从您正在运行的系统，以及您的团队已经整理好的目录出发。