OSAFIS 研究愿景
OSAFIS 提出一种用于分析智能系统安全失效的通用表示方法。其目的在于，把失效的安全契约与所涉及的组件或关系、影响机制、支撑该发现的证据，以及在已声明系统边界内产生的后果联系起来。研究人员可以用这一表示方法比较不同的发现；工程人员可以用它确定控制措施和评估义务。但无论哪种用途，都不能证明该表示方法是完备的，也不能证明某个系统是安全的。
当前规范版本为 2.0.0-draft.1。它定义了一种研究方法和一套候选术语。分类的可靠性、评估的实用性以及覆盖范围，仍有待独立检验。OSAFIS 并不声称已被认可为标准，不声称拥有认证系统的权力，不声称已有运行中的公共登记库，也不声称已在业界得到广泛采用。
要解决的问题
智能系统不只是其学习得到的模型。一次部署可能同时包含应用代码、训练数据与检索数据、观测、保留的状态、工具访问、人工审批，以及与其他系统共享的依赖。系统的安全既取决于每个组件的完整性，也取决于这些功能之间的契约。有效的凭据可能允许执行用户从未请求过的操作；检索到的文档可以提供有用的证据，却无权改变任务；准确的观测中也可能含有系统不得当作指令处理的文本。
要作出这些区分，就需要说明权限与预期用途。传统的访问控制、软件安全和运营风险管理仍是这一说明的组成部分。现有的人工智能安全工作已经提供了术语、威胁知识和缓解指南。OSAFIS 的研究机会在于检验：一种一致的、以契约为中心的表示方法，能否让这些资源与特定系统之间的关系更易于分析。
本提案聚焦于可识别的失效和站得住脚的证据。一段看似合理的攻击描述，并不能证明系统允许这种攻击；一个出人意料的输出，本身也不能证明存在安全漏洞；在某一配置中得到证实的失效，并不能说明它在各类产品中普遍存在。每一项陈述都应保留赋予其意义的假设和观测。
适用范围与目标用户
预期范围涵盖学习型模型与符号模型、语言与多模态应用、检索系统、自适应服务、使用工具的智能体、具身系统以及相互交互的部署。是否适用取决于被评估系统中实际存在的功能。数字智能体可以在没有物理传感器的情况下观测并估计环境状态；预测服务可能完全没有持久的任务记忆；一个以“自主”为卖点的系统，仍可能包含决定其实际权限的人工审批边界。
安全研究人员需要稳定的概念、示例和可证伪的分类规则。系统构建者需要带有可观测验收标准、并有明确责任人的安全契约。评估人员需要一套能够区分“观测所得”与“推断所得”的证据包。领域专家需要一种方法，使测试契合实际的危害、用户和运行约束。受影响的人群则需要在评估对其作出判断时，其利益和提出异议的途径能够得到体现。
当失效涉及已声明的安全契约，或与智能系统存在实质性关联时，本框架也可以描述与人身安全相关的失效，包括意外失效。它不能替代特定领域的安全评估、临床研究、法律分析，也不能替代对社会危害的一般性论述。与智能系统没有实质关联的纯粹人类组织问题，不在本范围之内。对于边界不清的案例，在评估边界得到论证之前，应明确保留为未决状态。
拟议的表示方法
九个暂定的分析领域描述了安全责任，分别是：L1 模型与计算、L2 软件与基础设施、L3 数据与知识、L4 感知与世界表示、L5 解释与目标、L6 记忆与状态连续性、L7 规划与行动、L8 人机交互，以及 L9 集体与系统交互。编号仅用于标识，并不表示执行顺序、智能程度递增、严重程度或后果范围的扩大。
二十三个属性标识符描述了可能适用于多个领域的义务。十二个机制标识符为对抗性影响提供了相互重叠的描述项。七个横向维度提示审视身份与权限、治理、来源、隐私与人身安全、变更管理、可观测性以及恢复。这些数量只反映当前的术语体系，其最优性尚未得到证明。
另有一张图用于记录实际的组件、人员和共享资源，以及带类型的关系。一个组件可以实现多个领域。当多个智能体确实依赖同一个制品时，共同使用的模型应表示为一个共享组件，而不是虚构出若干相互独立的副本。观测、信息交换和状态同步并不会自动传递权限。集体契约可以涉及一个群体或一个反馈回路，而无需归结为某一条有缺陷的两两连接。
发现需要区分入口点、失效的契约、参与的领域、传播过程和影响。下游领域不会仅仅因为攻击到达了它就自动被视为存在漏洞。影响范围广本身并不构成 L9 发现。评估人员可以认定多个因果失效，也可以让分类保持不确定，而不必强行指定一个人为的主要层。
研究原则
定义应当服务于决策。每个领域都必须指明受保护的功能或关系，并说明它与相邻领域有何不同。每个属性都必须规定一项可以具体化为可测试契约的义务。像“完整性”或“信任”这样的属性名称，若没有对象、授权变更规则、相关假设和可观测的违反情形，便是不充分的。
证据应当保持可追溯。报告应保留配置、版本、输入来源、测试边界、结果、相反证据以及对复现的限制。开放并不要求公开私密数据或危险的载荷。对于受限证据，应声明其访问流程，并清楚说明这对独立验证的影响。
主张应当保持适度。分类覆盖率、攻击检测、缓解效果和残余风险是彼此独立的问题。一个框架可以描述它无法自动检测的失效；一项控制措施可以阻止某个已测试的场景，却不能消除更广泛的一类问题；一项实证研究可以支持一个有限的结论，却不能证明未来不会发生失效。
修订应当可供审查。分歧本身就是证据，反映出边界不清、因果解释相互竞争或威胁假设各不相同。相关流程应保留这些信息。领域范围的变更需要迁移记录，而不是对旧发现进行悄然的重新解释。外部映射应保留其来源版本，并区分概念上的关联与等价性主张。
交付物及其职责
《基础概念》定义分析单元以及整套文档共用的术语。《安全层》定义九个领域及其边界规则。《安全属性》定义用于构建安全契约的义务。《威胁模型》记录谁能在何种知识与访问条件下影响什么。《攻击分类法》描述机制术语及其局限。
《评估方法》规定如何界定评估范围、开展测试、解释结果并撰写报告。《系统概况》将通用方法应用于候选的系统类别，而不臆造适用于整个行业的阈值。《漏洞登记库》规定证据记录和拟议的审查流程。《与现有框架的关系》记录注明来源的映射。《版本与标识符》管理引用与迁移。《未来》界定研究问题和触发修订的条件。本《愿景》文档则阐明项目的目的，以及项目准备提出的主张。
《示例案例》作为未执行的教学案例随规范一同提供。机器可读的定义和记录校验有助于保持文档的一致性，但它们既不是攻击扫描器，也不能证明漏洞存在。网站和演示文稿传达的是同样的内容，绝不应暗示超出底层证据所能支持的成熟度。
下一版本所需的证据
应在一个已声明的案例集合上评估该架构，这一集合需涵盖不同的功能、生命周期阶段和后果范围。开发集可以帮助澄清定义；另设一个留出集，由独立审查人员依据冻结的定义进行分类，可用于检验这些澄清能否推广。报告应包括不确定性、分歧、模糊案例、未能表示的案例，以及得出有用分类所需的工作量。
比较研究应检验具体的问题，例如：审查人员能否更一致地识别出缺失的行动授权检查，或者能否更准确地追溯共享资源失效。比较应基于可比的信息和任务条件，而不应以竞争方案的文档中是否恰好使用了 OSAFIS 的层名称来评分。
评估的实用性需要单独检验。各团队应考察该方法能否产生可复现的契约和控制措施，在保留经授权功能的同时解决所观测到的失效。他们还应跟踪未成功的缓解尝试以及新引入的失效模式。面向人的研究需要适当的参与者保护措施；可能产生物理后果或不可逆后果的测试，则需要安全的测试环境和明确的运行授权。
治理与发布
在把登记库说成是受独立治理的之前，项目需要有明确的维护者、成文的审查流程、利益冲突处理机制以及申诉途径。拟设的角色并不等于已任命的审查人员；拟议的发布许可也不等于已采用的许可。在所有者作出这些决定之前，相关材料应只描述面向开放参考资源的预期方向，既不授予未明确的权利，也不声称获得机构背书。
所谓成功，是指独立用户能够应用、质疑并改进这一表示方法，并且基于它的评估能够在特定情境中支持更好的安全决策。要确立这一结果，需要的证据远不止完成这些文档。本规范将各项承诺和检验明确写出，以便项目去争取这些证据。