# OSAFIS 版本与标识符

引用 OSAFIS 时，必须同时指明框架版本和所引用的元素。本文档规定 2.0.0-draft.1 的拟议发布方案、规范标识符，以及从所提供的、标记为 1.0 的文档进行迁移的方式。该来源标记记录的是正在修订的基线，并不证明此前曾公开发布。本文档集中的所有文档共用同一个框架版本。

## 版本语义

拟议的格式为 MAJOR.MINOR.PATCH，可附加预发布后缀。主版本（MAJOR）修订会改变对现有案例的解释或分类义务，例如改变某个领域的边界、删除某个属性或改变某个机制的含义。次版本（MINOR）修订会增加相互兼容的概念或说明性材料，而不改变现有含义。补丁（PATCH）修订用于更正拼写、格式或不影响上述含义的错误。如果某个看似澄清的改动改变了哪些案例符合条件，那么它就需要一次主版本变更，或者一个明确隔离的实验性扩展。

源文档使用的是 MAJOR.MINOR 格式。对 1.0 的引用仍然表示原始快照，不得被悄然改写为 1.0.0。新的三段式方案从本次拟议修订开始。后缀 draft.1 表示一份等待审查的提案。之后的草案会递增其预发布编号，并保留先前的快照。去掉草案后缀属于发布决定，需要有成文的审查；仅仅生成文件并不能授权作出这一决定。

发布清单记录版本、日期、已发布制品的文件及其加密哈希、规范定义、外部映射所依据的来源版本、已知局限以及迁移说明。哈希值能够证明字节与某个快照一致，却不能证明其中的科学主张是正确的。可编辑的源文件和供人阅读的输出应一同生成，以减少术语上的偏差。

## 规范的层标识符

| 标识符 | 2.0.0-draft.1 中的显示名称 |
| --- | --- |
| L1 | 模型与计算 |
| L2 | 软件与基础设施 |
| L3 | 数据与知识 |
| L4 | 感知与世界表示 |
| L5 | 解释与目标 |
| L6 | 记忆与状态连续性 |
| L7 | 规划与行动 |
| L8 | 人机交互 |
| L9 | 集体与系统交互 |

L 表示分析性安全领域。编号既不是依赖顺序，也不是影响等级。现有标识符保留了同一领域的沿革，但由于本次修订改变了若干边界，必须使用注明版本的定义。如果今后的工作用一个根本不同的概念取代了某个领域，应废止其标识符并分配新的标识符，而不是沿用旧的引用。

## 规范的属性标识符

| 标识符 | 显示名称 | 标识符 | 显示名称 |
| --- | --- | --- | --- |
| P01 | 机密性 | P13 | 行动完整性 |
| P02 | 完整性 | P14 | 可控性 |
| P03 | 可用性 | P15 | 规划完整性 |
| P04 | 指令完整性 | P16 | 委托完整性 |
| P05 | 上下文完整性 | P17 | 时间完整性 |
| P06 | 知识完整性 | P18 | 决策完整性 |
| P07 | 记忆完整性 | P19 | 人类决策完整性 |
| P08 | 身份完整性 | P20 | 归因完整性 |
| P09 | 目标完整性 | P21 | 信任完整性 |
| P10 | 行为完整性 | P22 | 感知完整性 |
| P11 | 语义完整性 | P23 | 世界模型完整性 |
| P12 | 能力完整性 | | |

这些是基线文档《版本与标识符》中的规范标识符，而不是其他某些源文档中使用的呈现顺序编号。当原始记录只使用了段落编号时，迁移必须核对实际的属性名称和含义。不要把源文档中的第十个标题自动转换为 P10。

在义务范围不同之处，属性之间的重叠是有意为之的。一次观测可以支持多项被违反的义务，但报告必须解释每一项断言。被违反属性的数量并不是严重性评分。今后若删除或合并属性，必须保留已废止的定义及其与替代项之间的明确关系。

## 规范的机制标识符

| 标识符 | 显示名称 |
| --- | --- |
| M01 | 技术操纵 |
| M02 | 数据操纵 |
| M03 | 环境操纵 |
| M04 | 感知操纵 |
| M05 | 语义操纵 |
| M06 | 上下文操纵 |
| M07 | 行为操纵 |
| M08 | 记忆操纵 |
| M09 | 身份操纵 |
| M10 | 目标操纵 |
| M11 | 能力操纵 |
| M12 | 人类操纵 |

机制术语包含相互重叠的描述项和不同的抽象层次。机制必须指向一项已被证实或明确假设的干预，而不只是复述结果。对于意外失效，没有机制是合理的。在分配标识符之前，未能表示的机制以文字形式连同扩展提案一起记录。M00 以及其他临时编造的代码，不得冒充规范条目。

## 规范的横向维度

| 标识符 | 显示名称 |
| --- | --- |
| D1 | 身份、信任与授权 |
| D2 | 治理与问责 |
| D3 | 供应链与来源 |
| D4 | 隐私与人身安全 |
| D5 | 生命周期与变更管理 |
| D6 | 可观测性、日志与可审计性 |
| D7 | 韧性与恢复 |

D 标识符专门保留给这些维度，不得用于标记另一套九领域图示。维度是一种审查视角，可以适用于许多领域和属性，而不是要求每当它相关时就再指定一项违反。

## 从基线层模型迁移

| 标识符 | 基线名称 | 必要的重新分类检查 |
| --- | --- | --- |
| L1 | 模型与计算基础（Model & Computational Foundation） | 把模型制品和计算与 L2 中的托管软件及运行时实现区分开 |
| L2 | 应用与基础设施（Application & Infrastructure） | 纳入传统软件契约，并核实模型执行缺陷所在的位置 |
| L3 | 数据与知识（Data & Knowledge） | 把信息资源与保留的运行状态、以及被提升为指令权限的情形区分开 |
| L4 | 环境与感知（Environment & Perception） | 按功能应用观测和世界表示，包括数字环境；仅仅是文本格式并不使其不适用 |
| L5 | 语义与行为（Semantic & Behavioral） | 依据实际的解释契约或目标契约，或依据负有责任的相邻领域，对宽泛的行为标签重新分类 |
| L6 | 记忆与持久状态（Memory & Persistent State） | 规定保留、归属、关联、更新和时间连续性，而不是存储技术 |
| L7 | 智能体与行动（Agent & Action） | 无论系统是否被称为智能体，都纳入规划和物理驱动 |
| L8 | 人与人工智能交互（Human-AI Interaction） | 识别关于交互、理解、授权或干预的契约，而不仅仅是对人的后果 |
| L9 | 系统与社会（Systemic & Societal） | 要求具备集体交互机制和契约；仅有广泛影响时，将其归入后果范围 |

原先隐含的、按后果范围逐级扩大的排序已被撤销。不得根据 L 编号推断现有的严重性估计。图中的边现在具有明确的类型，只有实际的委托边才表示被委托的权限。群体或回路可以是集体失效的位置。当与系统实际情况相符时，共享组件只表示一次。一项发现可以保留多个因果领域分配，而不必选定一个人为的主要领域。

P22 和 P23 保留了其在观测和世界表示方面的沿革，修订后的功能范围记录在《安全属性》中。原先因使用数字观测而被排除的案例需要重新审查。宽泛的 P10“行为完整性”标签，需要有一项具体的、兜底性的行为义务，且该义务无法由更具体的属性更好地表达；只有当时间轨迹构成该义务的一部分时，才需要时间轨迹。P09“目标完整性”、P15“规划完整性”和 P18“决策完整性”必须分别依据受保护的目标、计划和单项决策加以区分。M03 和 M04 保留了基线对物理环境的侧重；数字感知失效并不自动归入这两个机制中的任何一个。这些细化并不能成为不阅读证据就修改旧记录的理由。

## 证据描述项与记录状态

E0–E6 是描述项代码，其标签和定义在《评估方法》中规定。它们保留了基线中的证据问题，但不再构成强制性的累进阶梯。不得把旧有的“最高等级”取值自动展开为若干得到支持的较低方面。应依据底层制品重新评估每一个方面。描述项是否得到支持，与评估结果以及登记库中的审查状态相互独立。

| 维度 | 问题 | 允许的表示方式 |
| --- | --- | --- |
| 契约结果 | 在本次测试中，规定的义务是否得到满足？ | 已声明的判据，以及“通过”“未通过”或“无法确定”的结果和观测证据 |
| 评估结果 | 就该主张而言，证据确立了什么？ | supported、refuted、inconclusive、quality_issue、hazard_only 或 out_of_scope |
| 证据方面 | 存在何种类型的支持，范围如何？ | 每个 E 代码对应 supported、unsupported、not_tested、inconclusive 或 not_applicable |
| 分类确定性 | 该案例与术语体系的契合程度有多可靠？ | 有理由的分配，并保留模糊、复合或未能表示的案例 |
| 映射审查 | 外部关系经过了怎样的审查？ | proposed、reviewed、disputed 或 not_assessed |
| 登记库审查 | 作出了什么行政决定？ | submitted、under_review、accepted、rejected、withdrawn 或 superseded |

这些维度彼此之间不能相互换算。一条在语法上有效的记录，在科学上可能缺乏支持。说明性记录没有实际的登记库决定，其未执行的测试也不能被描述为观测到的失效。

## 迁移程序

1. 保留原始记录及其所引用的确切框架快照。如果其版本未知，应记录这种不确定性，而不是猜测。
2. 同时依据标识符和源文档中的含义识别每一个被引用的元素。明确解决名称与章节编号之间的不一致。
3. 根据证据重建入口、失效的契约、传播和后果。按照新的边界规则重新审视 L4、L5、L8 和 L9。
4. 记录保留的分配、变更的分配、未决的案例以及每项变更的理由。重命名可以是机械性的；涉及范围的决定则需要审查。
5. 创建一个链接到前一版本的新记录修订版本。保留其观测日期、证据限制以及原始评估结果。
6. 对受该变更影响的任何派生摘要、网站文本、概况适用性或对照表重新进行评估。迁移后的标签并不提供新的实验证据。

## 记录标识符与修订

拟议的登记库前缀为 OSAFIS，即所提供文档集中的项目标签。登记库条目使用 OSAFIS-YYYY-NNNN 格式，其中年份为提交年份，序号在该年份内分配。这是一项拟议的本地约定，而不是某个公认的漏洞管理机构的命名空间。绝不可臆造公开的编号分配，或暗示其与 CVE 标识符等价。演示案例使用 EX 标识符，例如 EX01，并置于登记库命名空间之外。

条目标识符在审查、否决、更正、撤回和取代的过程中始终保持不变。每一次实质性变更都会使 entry_revision 递增。引用应包括条目标识符、条目修订号、框架版本以及检索日期或不可变快照。重复条目链接到被保留的记录，任何一个标识符都不得被回收再用。受限证据的可访问性可以改变，但应保留一份不暴露敏感内容的公开历史。

组件、边、契约、测试和制品的标识符仅在一次评估内部有效，除非明确记录了外部命名空间。例如，某个案例中的契约标识符 C1 并不会创建一个新的全局 OSAFIS 属性。模式版本管理机器表示，与框架含义相互独立。使用方必须拒绝不受支持的模式版本，而不是悄然按照另一个版本来解释字段。

## 变更控制与发布决定

变更提案应说明其动机、受影响的定义、边界案例、对兼容性的影响以及现有证据。记录应包括作者和审查人员的角色、利益冲突、不同意见以及最终处理结果。拟议的流程角色不得被说成是已任命的独立审查人员。在声称发布一个受开放治理的公开版本之前，所有者必须建立实际的治理机制并确定发布许可。本文档既不选择法律许可，也不授予认证权力。

下一个稳定版本需要具备一致的制品、经过审查的迁移、明确的科学局限，以及与其主张相称的证据。如果该版本只提出一套术语，实验可以尚未完成，但这一状态必须清晰可见。如果该版本声称已证明分类的可靠性或控制措施的有效性，就必须附上支持性研究及其局限。标识符使主张可以追溯；它们并不能验证主张。