MILPA 要求 — 0.1 版¶

状态：自 MILPA 0.1（2026 年 9 月 28 日；编辑修订 0.1.1）起生效。请先阅读规范性用语，并查阅版本历史。

MILPA 关注的是：知识存放在哪里、由谁对其负责、来自何处，以及它具有怎样的权威。以下要求与技术无关：不规定编程语言、文件格式或具体的目录树。取决于项目类型的内容归入应用配置。

MILPA-R-001 — 规范性陈述的权威与来源¶

字段	内容
类别	与技术无关的要求 · 源自 MILPA-P-01
状态	`accepted` — MILPA 0.1（2026 年 9 月 28 日）
问题	某段文字仅因位于“权威”文件夹、带有 `status: canon`，或被某个 SDK 重复，就被当作规则，而实际上无人对其作过决定。
适用范围	一切被当作某种方法或项目的规则、要求、原则或决定而提出的陈述。
责任人	方法负责人（对于领域规则，则为项目负责人）。
适用条件	发布、引用或强制执行某项规范性陈述时。
可验证的表述	每项规范性陈述必须标明：来源（路径或 URL）、修订版本或 SHA-256、状态（`draft`、`proposed`、`accepted`、`deprecated`、`historical`）以及人类负责人。若没有写明版本与日期的人工决定记录，陈述不得被呈现为 `accepted`。来源的位置、文件名和标签不得被用作权威的证明。
预期证据	各页面的元数据；含日期、责任人和修订版本的决定记录；带哈希值的来源清单。
例外	对 `accepted`，无例外。不含规则的指引性页面，如声明自身不具规范性，可以省略负责人。
残余风险	正确的记录并不保证规则本身是好的；它只说明知道是谁、从何处批准了该规则。

MILPA-R-002 — 事实、推断与假设相互分离¶

字段	内容
类别	与技术无关的要求 · 源自 MILPA-P-02
状态	`accepted` — MILPA 0.1（2026 年 9 月 28 日）
问题	智能体或人在概括项目状态时，把已核实的内容与臆测的内容混在一起；这份概括随后又被当作事实重复使用。
适用范围	由 AI 产出或辅助产出的、描述某个项目或某个来源的报告、审计、状态摘要和提案。
责任人	签署或交付报告的人（该委托任务的负责人）。
适用条件	当该报告将用于作出决定、发布或变更某项规则时。
可验证的表述	报告必须区分（1）注明了来源的事实，（2）推断，以及（3）假设或不确定之处。未经确认的数字、版本或状态必须标记为不确定。报告不得把未来的结构或能力描述为已经存在。
预期证据	包含这三个部分的报告；每项事实均有可核实的路径或 URL。
例外	不用于作决定的工作笔记。
残余风险	标签可能被错误地分配；人工审查仍然必要。它无法发现引用有误的事实内部所包含的虚构。
外部参考	NIST AI 600-1，Confabulation 与 Information Integrity 风险。

MILPA-R-003 — 同名的分类彼此不得换算¶

字段	内容
类别	与技术无关的要求 · 源自 MILPA-P-01
状态	`accepted` — MILPA 0.1（2026 年 9 月 28 日）
问题	多个等级体系都被称为“级别”，并共用一些名称（Canon、Evidencia/Evidence、Referencia/Reference），但顺序和含义各不相同；把其中一个换算成另一个，会凭空制造权威或确定性。
适用范围	MILPA、ASILO、它们的应用配置和实现所使用的分类体系。
责任人	方法负责人；维护者在映射枚举时负责。
适用条件	定义、记录或实现某种分类时。
可验证的表述	每个分类体系必须有自己的名称、用途和取值定义。没有经过接受的对应表，一个取值不得被转换为另一个体系中的取值。
预期证据	收录每个体系的术语表；已接受的对应表，或不存在对应表的说明。
例外	在尚无已接受的对应关系时，无例外。
残余风险	它不能消除阅读时的混淆；只能阻止这种混淆被正式化。

MILPA-R-004 — 项目身份清单¶

字段	内容
类别	与技术无关的要求（文件格式属于应用配置） · 源自 MILPA-P-04
状态	`accepted` — MILPA 0.1（2026 年 9 月 28 日）
问题	为了弄清谁负责、涵盖什么、什么受限，人或智能体必须遍历文件夹并自行推断；推断出的结果可能是错的。
适用范围	智能体在其上运行的、或声明应用 MILPA 的每个项目或节点。
责任人	项目负责人。
适用条件	当项目声明应用 MILPA，或允许智能体在其上运行时。
可验证的表述	项目必须在其根目录发布一份机器可读的清单，至少包含：标识符、节点角色、人类负责人、范围、所声明的应用配置、父节点（或无）以及受限区域。如果清单记录层级深度，该字段不得与某种权威或确定性等级使用相同的名称（例如 `level`）。清单之间的继承不在 0.1 版的范围之内：已声明的继承不得被呈现为已生效。
预期证据	带版本的清单；模式（schema）验证；关于如何解析（或不解析）继承的记录。
例外	没有智能体、且不在 MILPA 之内的项目。
残余风险	清单可能过时；它本身并不能阻止他人读取受限区域。

MILPA-R-005 — 保留名称与已声明的词汇表¶

字段	内容
类别	与技术无关的要求（具体列表属于应用配置） · 源自 MILPA-P-03
状态	`accepted` — MILPA 0.1（2026 年 9 月 28 日）
问题	同名的文件夹在不同项目中含义不同，或者每个团队各自发明保留字。
适用范围	具有方法论含义的文件夹名称和文件名称。
责任人	方法负责人（词汇表）；项目负责人（使用）。
适用条件	声明应用 MILPA 的项目。
可验证的表述	项目必须声明其使用的保留名称词汇表及其版本。保留名称不得被赋予其他含义。新的保留名称必须通过有记录的变更加入词汇表，而不是通过本地使用。
预期证据	带版本的词汇表；来自清单的引用；对项目中名称的检查。
例外	领域名称（产品、垂直行业）不属于保留词汇表。
残余风险	这一约定无法避免命名正确的文件夹中出现不正确的内容。

MILPA-R-006 — 不变核心与已声明的应用配置¶

字段	内容
类别	与技术无关的要求 · 源自 MILPA-P-03
状态	`accepted` — MILPA 0.1（2026 年 9 月 28 日）
问题	把某一特定类型（例如产品档案）的文件夹树强加给所有项目，或者任由各项目自行发明结构而不加说明。
适用范围	应用 MILPA 的项目的文件与文件夹结构。
责任人	项目负责人；对于核心，则为方法负责人。
适用条件	声明应用 MILPA 的项目。
可验证的表述	项目必须包含不变核心，并且必须在清单中声明其应用配置。0.1 版的不变核心包含七项功能，每项都有可识别的位置：（1）清单（MILPA-R-004）；（2）面向读者的入口；（3）来源与关联的登记（MILPA-R-007）；（4）面向智能体的说明（如有智能体运行）；（5）文档索引；（6）决定记录；（7）存放非权威临时材料的独立位置。具体的文件名属于应用配置。不得根据结构推断应用配置。本方法不得把仅属于某一应用配置的文件夹要求为通用要求。如果没有任何已接受的应用配置合适，项目应当声明这一点并提出一个新的配置，而不是勉强套用最接近的那个。
预期证据	带应用配置的清单；对核心及应用配置路径的检查；没有应用配置的项目的记录。
例外	处于过渡期的项目可以声明一个带日期的目标应用配置，并须经负责人接受。
残余风险	文件夹存在，并不意味着其内容正确。

MILPA-R-007 — 项目之间已声明的关联¶

字段	内容
类别	与技术无关的要求 · 源自 MILPA-P-05
状态	`accepted` — MILPA 0.1（2026 年 9 月 28 日）
问题	两个项目仅因共用名称、文件夹或品牌就被当作已经集成；或者规划层面与实现层面彼此脱节，双方却都不知道。
适用范围	项目之间、规划与实现之间、方法与软件之间的关系。
责任人	关联两端的负责人。
适用条件	当一个项目使用另一个项目、派生自它或为其编写文档时。
可验证的表述	每项关联必须在两端都作出声明，内容包括：提供方、使用方、契约与版本、跨越边界的数据、负责人、状态和证据。对于已发布的版本，本地路径不得是唯一的关联机制。
预期证据	两个仓库中的关联条目（例如 `SOURCE.md`）；已固定的版本。
例外	标明为探索性、且未发布的关联。
残余风险	声明契约并不能证明兼容；使用方还需要进行测试。

MILPA-R-008 — 矛盾在解决之前保持可见¶

字段	内容
类别	与技术无关的要求 · 源自 MILPA-P-06
状态	`accepted` — MILPA 0.1（2026 年 9 月 28 日）
问题	通过悄悄选取较新的文字来“清理”矛盾，结果丢失了变更的原因。
适用范围	ASILO 和 MILPA 的来源、要求与决定。
责任人	发现矛盾的人负责登记；方法负责人负责解决。
适用条件	当两个来源或两项要求的说法互不相容时。
可验证的表述	矛盾必须登记，并包含双方来源、修订版本或哈希值、相冲突的语句及其后果。解决矛盾时，不得删除来源信息和历史文本；解决方案必须引用相应的决定。
预期证据	方法的矛盾登记册；与之关联的决定。
例外	无。
残余风险	一份冗长且未解决的登记册会阻碍接受；需要定期审查。