arXiv CSopen access

Beyond Object Validation: Relational Conformance in Multi-Artifact Agent Releases

PREPRINT, JULY 2026

1

Beyond Object Validation: Relational Conformance in Multi-Artifact Agent Releases Tengjiao Liu Founder & Researcher, psi.run, [email protected] Abstract—Agent systems validate inputs, tool calls, and generated objects. The final package often escapes the same scrutiny. In one DRSS release, the ledger supported 60 points and a failed certificate; the report announced a 100-point Gold Path. Every local gate was green. The package contradicted itself. We study that failure alongside Schema Docs, where similar faults became product contracts, and Brand Shuttle GEO, where evidence is turned into repair work. The result is a candidate Schema-SIP Relational Conformance profile (SIP-RC). It models a release as a graph: claims point to evidence, decisions carry bounded authority, derived artifacts retain their execution conditions and lineage, and published bytes must match the package that was checked. Hard failures cannot be averaged away, and a validator recomputes critical decisions on a separate path. The paper establishes the failure class and shows that several mechanisms are practical. Whether the full profile performs better than existing checks remains an open experiment.

arXiv:2607.14155v1 [cs.SE] 14 Jul 2026

Index Terms—agent-generated deliverables; relational conformance; release validation; artifact graphs; schema interoperability; provenance; claim verification; document exchange

✦

1

I NTRODUCTION

In July 2026, a DRSS development batch passed every automated, schema, and documentation gate. The release still contained a failed certificate under a Gold Path header, and a consumer report still carried manufacturing language. The consistency audit missed both. That batch did not test SIPRC; it exposed the problem SIP-RC is meant to address. The problem appears when an agent produces a package rather than one object. A research release joins evidence, findings, scores, certificates, and reports. A document exchange adds rendered views, assets, disclosure decisions, and hashes. A diagnostic product adds work orders and later review. Each part may satisfy its own schema while the package violates the relations that make it credible. Schema Docs provides the working counterpoint. The local-first product handles Markdown, text, PDF, DOCX, PPTX, XLSX, and CSV. Real files exposed delayed spreadsheet headers, display-font semantics, Office formulas, unreachable assets, stale caches, mixed human/AI views, and unsafe outbound context. Those failures now live in executable contracts and regression tests. Brand Shuttle GEO asks whether the same vocabulary survives outside research and document exchange. It maps public signals to a diagnosis, prioritized gaps, repair work, assets, and later review. We use it as an illustration, not as an independent validation. Comparable boundary failures occur outside this research program. The PyTorch Foundation documented a nightly build that resolved a malicious torchtriton package from PyPI instead of the project index [39]. EchoLeak showed how a crafted email could cross Microsoft 365 Copilot’s trust boundaries and drive data exfiltration [40]. Neither incident was analyzed with SIP-RC, but both confirm that package resolution and outbound disclosure can

fail even when attention remains fixed on individual components. The prior Schema Sandbox paper introduced a ninelayer constraint architecture, an L0–L3 classification, workspace partitions, and an early Schema Interoperability Protocol [1]. The present paper changes the unit of analysis from a sandbox or protocol object to the released multiartifact deliverable. Evidence local check: PASS Certificate local check: PASS Report local check: PASS Assets local check: PASS

Release graph

NON-CONFORMANT RELEASE score/status claim/evidence canonical/rendered asset/path approval/bytes

Manifest local check: PASS

Fig. 1. Local validity does not imply release conformance. The failure lies in relations among artifacts, not necessarily inside any one artifact.

1.1

From execution to release boundaries

Earlier work in this research program treated persistence as a boundary problem, separated proposal from validation roles, and retained verified failures as constraints [24]–[29]. Schema Sandbox applied that line of thought to execution layers and workspace partitions [1]. DRSS exposed the missing boundary: a controlled run could still publish mutually inconsistent artifacts. Those prior studies explain the design lineage of SIP-RC; because they share an author and research program, they do not establish generality. We ask three research questions:

PREPRINT, JULY 2026

- RQ1: Why did per-object validity and green local tests fail to guarantee deliverable conformance in the studied systems? - RQ2: Which agent-specific relation and release obligations can be derived across the negative, successful, and transfer cases? - RQ3: Relative to schema-only, sharedgenerator, and provenance-only baselines, what detection, false-block, authoring, and runtime costs does SIP-RC impose? The case analysis answers RQ1 and proposes an answer to RQ2. RQ3 remains future work. The profile covers claim support, authority, execution conditions, lineage, rendered artifacts, completeness, and publication—requirements derived from the incident record. Its guarantees stop at declared invariants. Section 7 describes the experiment still needed to test it. Our working claim is: > A multi-artifact deliverable should be accepted only after its release relations have been checked on a path separate from the generator’s own acceptance logic.

2

R ELATED W ORK AND S COPE

2.1

Objects and graphs

JSON Schema and constrained generation can keep an object well formed [2], [11], [12]. They cannot make its values correct [17], much less reconcile it with another file. Data-quality systems already check cross-field consistency [16], and SHACL validates graph constraints [3], including planned and recursive forms [18], [19]. SIP-RC builds on that foundation with terms drawn from agent releases: evidence, decision authority, execution conditions, rendered views, hard gates, and publication state. 2.2

Provenance, binding, and claims

PROV-O records derivation and responsibility [4]. in-toto binds supply-chain steps to attestations [5], while C2PA binds manifests and assertions to assets [6]. SPDX and CycloneDX inventory software or system components [35], [36]. Pramān.a comes closest to the present problem because it defines replayable, typed claim attestations [7]. All of these records can appear in a SIP-RC graph. The release decision still has to ask whether the evidence, verdicts, views, approvals, and final bytes agree.

2

records. The name needs one qualification: “SIP” already denotes the IETF Session Initiation Protocol [15]. We therefore use Schema-SIP for the family and SIP-RC for this release profile. 2.5

3

R ELATIONAL C ONFORMANCE M ODEL

The model says one thing precisely: a release is a graph, and validation looks for contradictions in that graph. 3.1

Runtime controls and release controls

MemGPT organizes persistent context [13]. AgentSpec, SkillGuard, AC4A, ChainCaps, AIRGuard, and Agentproof govern runtime rules, permissions, composed authority, or workflow properties [8], [9], [20]–[23]. NeMo Guardrails and Guardrails AI check interaction stages or individual outputs [37], [38]. Those systems govern a run. SIP-RC checks the package left behind by the run. 2.4

Interoperability boundary

The Model Context Protocol connects hosts, clients, servers, tools, resources, prompts, and negotiated capabilities [10]. A SIP-RC manifest can travel through MCP or another transport and can carry SHACL, provenance, or attestation

Typed artifact graph

A release contains files, views, approvals, and policies connected by relations such as “supports,” “renders,” and “authorized by.” We write that graph as:

G = (V, E, τV , τE , ν, A), where: - V is a finite set of artifact nodes; - E ⊆ V ×V represents directed semantic relations; - τV : V → TV maps nodes to an extensible type vocabulary that includes evidence, criterion, finding, recommendation, certificate, report, asset, rendered view, approval, policy, manifest, and package; - τE : E → TE maps edges to an extensible relation vocabulary that includes supports, corroborates, evaluated_by, summarizes, renders, references, derived_from, authorized_by, accepted_by, and published_as; ν(v) identifies the immutable version and cryptographic hash of node v ; - A ⊆ V is the authoritative node set from which release decisions must be recomputed. Nodes may be mandatory, optional, unknown, blocked, or excluded from a partial release. A derived node may have multiple versions, but the release graph selects one immutable version for every included authoritative or rendered artifact. 3.2

2.3

Comparative boundary

Table 1. Where SIP-RC sits among adjacent mechanisms. The approaches reviewed here do not, by themselves, decide whether one agent release is fit to leave the system. SIP-RC groups release-specific rules—authority, hard gates, view agreement, typed approval, and publication state—on the same artifact graph.

Object and release conformance

Each node vi has a local contract Ci validating object-level schema compliance. Each required relation or subgraph has a predicate Rj enforcing relational consistency. A predicate may span several edges—for example, recomputing one certificate from many findings—and one edge may participate in several predicates. The predicate count k therefore need not equal |E|. Global release conformance is defined as: 

|V |



ReleaseConform(G) = 

^

Ci (vi ) ∧ 

i=1



k ^



Rj (G)

j=1

∧ Publishable(G), where k is the number of required relation or subgraph predicates declared by the active profile.

PREPRINT, JULY 2026

3

TABLE 1 Where SIP-RC sits among adjacent mechanisms. Approach

Primary strength

Gap motivating SIP-RC’s additional layer

SIP-RC contribution

JSON Schema / structured output SHACL / TravSHACL W3C PROV / in-toto

Per-object structure and types General and efficiently planned graph constraints Provenance, derivation, supply-chain attestation Claims, assertions, manifests, signatures, asset binding Component inventory and software/system supplychain relations Typed, replayable consequential-claim verification Interaction-stage and individual-output validation Runtime rules and static/temporal workflow verification Skill permissions and finegrained resource access Composition-safe capability flow and action-time authority Tool/resource connection and capability negotiation

Cross-object agreement and rendered-package acceptance Agent-specific decision authority, execution strength, and publication lifecycle Business and epistemic release invariants

Typed artifact relations and release predicates Agent release vocabulary and conformance profile Release-gating semantics over provenance-bearing artifacts Claim/operator/decision and completeness consistency

C2PA SPDX / CycloneDX Pramān.a NeMo Guardrails / Guardrails AI AgentSpec / Agentproof SkillGuard / AC4A ChainCaps AIRGuard MCP

/

Whether evidence and decision operators support an agent recommendation Epistemic claims, decision authority, rendered views, and publication states Multi-file report/certificate/view/tier agreement Frozen multi-artifact release agreement

Cross-output, cross-version release obligations

Final multi-artifact product consistency

Artifact-centered release checks

Relation integrity of final conclusions and packages

Relational release profile

Post-execution agreement

Release-time authority and publication checks

report/certificate/view/package

Domain acceptance and release invariants

The DRSS counterexample establishes only the nonimplication: ^ Ci (vi ) = 1 ̸⇒ ReleaseConform(G) = 1. i

3.2.1 Minimal DRSS example The central D1 incident can be represented without the full case vocabulary: ledger(60) -eval(policy)-> dec(fail) dec(fail) -summarized---> cert(fail, 60) cert -rendered-----> report(Gold, 100)

All four nodes pass their local schemas. Recomputing from ledger + policy-v3 returns fail, 60, so the report relation emits SIP_RC_ARTIFACT_CONTRADICTION. The validator blocks the report and its package. It may still release the ledger and failed certificate as a newly manifested partial graph if the audience is allowed to receive a failure record. 3.3

References BOMs while governing acceptance-relevant agent artifacts Package-level release conformance

Complementary release obligations

Their order is not assumed to be total: a profile declares which pairs are comparable and may add domain-specific scopes. An authority scope is the product σ = (d, b) ∈ SD × SB , ordered component-wise:

σ1 ⪯ σ2 ⇐⇒ d1 ⪯D d2 ∧ b1 ⪯B b2 . A claim or approval c at scope σc can authorize an action a only when the action lies within the authority carried by that claim or approval:

Authorized(c, a) ⇐⇒ σa ⪯ σc .

D = (SD , ⪯D ),

An aggregation or escalation operator may create a new authority token at a greater scope only when the profile declares the operator, its inputs, its approver role, and the hash-bound output. Without that new token, a criterion-level pass cannot authorize a project commitment, and approval of one artifact cannot authorize publication of an entire release. A violation is reasoning- or releasescope escalation, analogous to privilege escalation inside the deliverable graph. The model complements fine-grained access control [20], skill permissions [9], and monotonic capability attenuation [21] without replacing their actiontime enforcement.

B = (SB , ⪯B ).

3.4

Two-dimensional authority-scope orders

One fixed chain cannot represent every domain’s decision reach or publication extent. A profile therefore declares two finite partial orders:

For the cases in this paper, SD contains observation, criterion, option, and project scopes; SB contains field, object, artifact, bundle, release, and public-publication scopes.

Execution risk and assurance

Execution conditions mix two different questions. Risk records where and how the run acted; assurance records how well its result can be replayed:

PREPRINT, JULY 2026

4

risk(m) = (e, µ), assurance(m) = ρ, where e is externality (local, pinned_remote, open_remote), µ is mutability (read_only, bounded_write, arbitrary_write), and ρ is replayability (none, trace_only, deterministic_replay). Each profile declares the relevant comparisons. Ordinary derivation follows two rules:

Generic schema, parsing, or canonicalization libraries may be shared when they do not compute the decision and their versions remain explicit. A separately authored implementation, another language, or an external operator provides progressively stronger evidence and must be reported as such. 3.7

Publication state machine

The legal release states are:

risk(mup ) ⪯ risk(mdown ), assurance(mdown ) ⪯ assurance(mup ).

building → validated → frozen

A downstream artifact must not under-report inherited risk or over-report assurance. Keeping the two orders separate avoids suggesting that greater replayability somehow cancels an external call or write. An explicitly declared transform may strengthen replayability—for example, by adding a complete trace or deterministic fixture—but it cannot erase external calls or writes that already occurred. Its output must bind the transform version, inputs, retained trace, and validator result. Silent promotion, including relabeling fixture evidence as live or claiming deterministic replay without retained support, triggers SIP_RC_MODE_PROMOTION. Example. Suppose a finding depends on (pinned_remote, read_only, trace_only) evidence. A locally rendered report still inherits the pinned_remote exposure in its release envelope; local rendering does not erase the remote observation. The report cannot claim deterministic_replay unless an explicit transform retained sufficient fixtures and proved that stronger assurance. Conversely, a downstream step that performs an arbitrary write must declare that increased mutability even when all upstream artifacts were read-only.

Only published is externally consumable. Mutation after frozen invalidates the candidate and returns it to building. A blocking violation found at or after validated does the same and invalidates endorsements, hash-mismatched approvals, and derived signatures. Publishing through a temporary directory followed by atomic rename prevents a receiver from observing a partial package.

3.5

Non-compensatory gates

A high score cannot hide a hard failure. If evidence is missing, a signature is invalid, or the package hash is wrong, the release fails even when every optional quality measure looks strong. Let gk (G) ∈ {0, 1} represent those hard gates, q(G) the quality score, and θ its threshold: ! ^ Accept(G) = gk (G) ∧ (q(G) ≥ θ). k

The conjunction makes the rule explicit: quality matters only after every mandatory gate passes. 3.6

Separate-path decision recomputation

The generator does not grade its own work. It proposes dˆ; a separately versioned validator reads the canonical ledger L ⊆ A and policy P , computes d∗ , and compares the two:

d∗ = fvalidator (L, P ),

dˆ = d∗ .

“Separate” means a distinct execution path, not automatically an independent implementation, author, or organization. The validator does not call the generator’s acceptancerelevant helpers, decision templates, or scoring heuristics.

→ verified → published.

3.8

Evidence identity and corroboration

Evidence deduplication and corroboration are different relations. Two observations with the same source identity and content hash resolve to one canonical snapshot; repeated ingestion does not create more support. Independently produced sources remain distinct evidence nodes linked by a corroboration relation. Collapsing both cases compromises source independence, whereas preserving every repeated snapshot inflates apparent support. 3.9

Conditional conformance guarantee

Let F be the declared fault set encoded by mandatory SIPRC predicates. Assume that (i) for every fault f ∈ F , the manifest declares every artifact and relation instance on which the predicate for f is defined—that is, the manifest vocabulary and instance graph subsume the faults the validator claims to detect; (ii) the validator correctly implements those predicates; (iii) signature and hash primitives behave as specified; and (iv) the published bytes equal the verified bytes: > If ReleaseConform(G) = true, no correctly modeled and correctly implemented fault in F is present in the published graph. This target is conditional on the model and implementation. It offers no protection against undeclared faults, a bad domain method, or a bug shared by generator and validator.

4

S TUDY M ETHOD

4.1

Design and case roles

We reconstructed three systems from repositories, artifacts, tests, and development records. Each system plays a different role: The three systems share an author, a research program, and parts of their architecture. They are contrasting cases, not independent replications.

PREPRINT, JULY 2026

4.2

Evidence and grading

We examined repository code, manifests, schemas, generated artifacts, batch records, and development histories, and reran available local checks on 13 July 2026. Antigravity supplied a separately written account; we checked it against the files and use it only as internal triangulation. - E1: fresh local re-execution or directly inspectable current artifact; - E2: development log with observable failure and repair evidence; - E3: current implementation or specification supporting a mechanism claim; - E4: design intent or historical account not currently reproduced. The Batch 16 DRSS document is a pending acceptance specification, not a completion report. It is used to identify observed defects and prescribed gates, never as proof that those gates passed. The replication package containing all E1 execution logs, conformance vectors, and local schemas is included in the open-source repository. 4.3

Evidence coverage

Raw test totals appear once because the suites exercise different risks and are not comparable coverage scores. Table 2. Evidence available in the three cases. The last two columns matter more than the totals: none of the three systems has yet been replicated by an outside organization. 4.4

Analysis

For each included incident we reconstructed: input or precondition, expected relation, observed artifacts, local checks, relation failure, implementation status, candidate SIP-RC rule, and release action. Multiple assertions caused by one root failure were treated as one incident. Historical failure, injected fault, required repair, and completed repair were distinguished.

5

C ROSS -C ASE E VIDENCE

5.1

DRSS: central negative case

DRSS evolved through repeated attempts to create an institutional research pipeline. The full batch chronology is retained as internal supplementary evidence; the main paper uses three standardized incidents. 5.1.1

Incident D1 — Certificate/report contradiction

5.1.2

Incident D2 — Operator inversion

5.1.3

Incident D3 — Decision-scope escalation

Two additional observations support, but do not complete, the protocol design. A package with zero completed dossiers and four gaps received a 100-point professionalreport tier, motivating non-compensatory gates. A report changed after its manifest recorded bytes and hashes, motivating a freeze–verify–atomic-publish transaction. Both appear in a pending acceptance specification; their prescribed fixes are not counted as completed DRSS results.

5

5.1.4

5.1.1 How the DRSS failures accumulated

No single schema rule caused the DRSS release to fail. The damage accumulated in seven layers. Criteria, findings, metrics, and certificates were connected by array positions and substring matches instead of stable identifiers. Several components then summarized the same facts, leaving the package with more than one source of truth. The next two layers concerned verification itself. Generator and validator shared helpers and domain assumptions, allowing the same error to appear on both sides of the check. Function-level tests then confirmed those shared paths without opening the final report and manifest as a single release. Passing tests were genuine, but their unit of observation was too small. Three operational failures completed the pattern. Domain-specific compiler text, including battery units such as GWh, leaked into unrelated reports. Fixture, cached, and live evidence lacked explicit execution-mode labels. Specifications changed without version or hash bindings, leaving runtime rules and validators to diverge silently. Taken together, these seven layers explain why adding another object schema would not have repaired the release process; the checked object had to become the frozen artifact graph.

5.2 Schema Docs: successful general-purpose interoperability Schema Docs implements a local-first workflow across Markdown, TXT, PDF, DOCX, PPTX, XLSX, and CSV: scoped ingest -> quality and fidelity diagnosis -> canonical representation -> human / AI / diagnostic views -> local selection and masking -> Send Gate -> exchange package and hashes -> receiver-side verification -> optional audited write-back

Passing paths include conversion, package construction, content hashes, receiver/trust reports, timeline events, AI context, and a fourteen-step external editing scenario. Historical incidents are used here to explain how the successful contracts were discovered. 5.2.1 ing

Incident S1 — Stored value versus displayed mean-

5.2.2 Incident S2 — Asset existence versus receiver reachability 5.2.3 ness

Incident S3 — Input identity versus derivation fresh-

Schema Docs also makes disclosure a product state. Local masking replaces detected secrets, email addresses, IP addresses, phone numbers, and configured PII classes with typed placeholders. A Send Gate returns allow, review_required, or block, with reasons and next actions. Local SQL filtering can reduce CSV/XLSX context before Markdown handoff. Credential-like content stops at review_required; the product will not send it from that state. The mechanism is limited, but it is visible and testable.

PREPRINT, JULY 2026

6

TABLE 2 Evidence available in the three cases. Case

Object checks

Cross-artifact checks

Render/package checks

Separate-path

External

DRSS

Historical Batch 13 reported 417/417 passing

Consistency audit existed but missed both contradictions

No; generator path certified itself

No

Schema Docs

267 passed, 0 failed, 1 skipped (268 total)

Missing for the decisive score/status and audience contradictions Implemented for canonical/view, hash, cache, disclosure, and receiver relations

Implemented across exchange packaging and a fourteen-step external-editing scenario

Implemented for selected checks; not a second product implementation

Brand GEO

116 passed, 0 failed, 2 skipped (118 total)

Implemented for selected evidence-mode and score-toaction contracts

Bilingual report and asset paths exercised; two livenetwork paths excluded

Focused only

Receiverside and desktop checks; no external replication No

Shuttle

5.2.4 5.2.1 What the product case establishes The product now enforces four rules that began as unrelated bugs: stored value must agree with displayed meaning; assets must resolve for the receiver; cached output must name the extractor that produced it; and send approval must bind the reviewed bytes. The rules still live in different parts of the codebase. SIP-RC proposes a common declaration for them. 5.3

Brand Shuttle GEO: illustrative transfer case

GEO maps a bounded set of public evidence to a diagnosis, prioritized gaps, repair work, assets, and recurring review. It lets us test the vocabulary on an evidence-to-action product. It cannot establish generality. 5.3.1 Incident G1 — Degraded execution mode 5.3.2 Mechanism G2 — Evidence-to-action closure 5.3.3 5.3.1 From diagnosis to bounded action GEO ends with named deliverables rather than open-ended advice. Diagnostic scores produce repair work, update intervals, and localized assets. The input and output contracts can be public even when prompts, crawlers, and scoring heuristics remain private. That separation is useful for review, but GEO is still an internal case. 5.4

Cross-case synthesis

Across the cases, the same seven relations recur. Schema Docs implements several of them in a working product; GEO exercises a smaller subset.

6

C ANDIDATE SIP-RC P ROFILE

6.1

Scope and normative language

SIP-RC is a candidate profile, not a standard. Its conformance requirements have not yet passed comparative evaluation. The profile applies to releases with at least two artifacts or views that affect acceptance. MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY follow BCP 14. SIP-RC extends rather than replaces SIP-Core and SIPSecure: SIP-Core: object contracts + structured rejections

mechanisms

↓ SIP-Secure: signatures + capabilities + evidence ↓ SIP-RC: cross-artifact relations + release gates

A SIP-RC implementation inherits the mandatory requirements of the lower profiles. Deployment and marketplace metadata may be defined by separate profiles, but they are outside this paper’s release-conformance contribution. SIP-RC does not require RDF. A conforming implementation MUST provide: 1. a typed artifact graph or equivalent relation model; 2. per-object schemas; 3. required relation predicates; 4. an immutable release manifest; 5. a validator report with stable violation codes; 6. a publication state and release verdict. JSON Schema MAY validate objects. SHACL MAY validate an RDF/JSON-LD graph. A restricted Datalog or SIPRC invariant DSL MAY express domain rules. Interoperability depends on shared semantics and test vectors, not on one mandatory rule engine. 6.2

Required modules

6.3

Version and extension envelope

protocol: "schema-sip" version: "1.2-draft" profile: "sip-rc" status: "candidate" namespace: "https://schema-sip.example/ns/rc/1.2" extensions: - id: "org.example.domain-claims" version: "2.0.0"

Unknown mandatory extensions MUST cause rejection. Unknown optional extensions MAY be preserved without enforcement if the release manifest declares that they do not affect authoritative decisions. 6.4

Minimal relation declarations

claim_contract: semantic_scope: [observation, criterion, option, project] publication_scope: [field, object, artifact, bundle, release, public_publication] scope_order: "profile-declared partial orders" deny_implicit_scope_escalation: true require: [evidence, operator, execution_mode] execution_mode: risk:

PREPRINT, JULY 2026 externality: [local, pinned_remote, open_remote] mutability: [read_only, bounded_write, arbitrary_write] assurance: replayability: [none, trace_only, deterministic_replay] prohibit_understated_exposure: true prohibit_overstated_replayability: true artifact_consistency: authoritative_nodes: [criterion_ledger, final_decision] invariants: - "certificate.decision == recompute(criterion_ledger, policy).decision" - "report.score == certificate.score" - "completed_dossiers >= delivery_tier.minimum_completed" - "all(package.asset_refs).resolve" publication: freeze_before_hash: true verify_registered_bytes: true mode: atomic_directory_rename lineage_closure: evidence_identity: duplicate_key: [source_identity, content_hash] preserve_independent_corroboration: true

6.5

Canonicalization, signatures, and content binding

A SIP-RC manifest MUST state its canonicalization and digest algorithms. A minimal implementation MAY use JSON Canonicalization Scheme and Ed25519, as in the local prototype. Production profiles SHOULD reuse established content-binding and provenance conventions where applicable, including C2PA collection bindings or equivalent signed asset lists. The signature MUST cover the manifest fields that determine authority, policy, relations, versions, and registered artifacts. Revocation MUST distinguish a historically valid release from a release that never conformed. A changed registered artifact invalidates the release; it cannot be patched without rebuilding and re-verifying the manifest. 6.6

Validation and publication algorithm

handshake and verify profile -> validate object schemas -> validate semantic and operator bindings -> close claim evidence and lineage -> recompute decisions on a separate path -> validate scope and completeness gates -> render candidate views -> validate view, asset, and package relations -> freeze registered files -> hash, sign, and read-only re-verify -> publish atomically or reject

An accepted package MUST be byte-identical to the verified package. A validator MUST emit stable codes, affected nodes/edges, expected and observed values, and permitted remediation. On a blocking violation, it MUST continue evaluating all independent predicates so the release receives one consolidated diagnostic result, except where the failure makes a later predicate semantically undefined or unsafe to execute. 6.7

Typed human approval

“Human in the loop” is not one interchangeable mechanism. Formula-fidelity review, outbound-send authorization, visible-UI confirmation, and receiver acceptance approve different risks and artifacts. A required approval MUST bind the decision type, approver role, immutable artifact version, hash, and time. Approval of one artifact or

7

risk MUST NOT be reused as approval of another unless an explicit policy permits that delegation. human_approval: artifact_ref: "report-v3" decision_type: "fidelity_review" authority_scope: semantic: "observation" publication: "artifact" approver_role: "domain_reviewer" artifact_hash: "sha256:..." timestamp: "2026-07-13T14:00:00Z" decision: "approve"

This requirement connects directly to Schema Docs, where Send Gate approval, formula review, desktop-visible verification, and receiver acceptance are separate release gates. 6.8

Partial release

A release graph MAY declare independently releasable subgraphs. If a node is blocked, every authoritative or rendered descendant MUST also be blocked unless a declared cut removes the dependency and the remaining subgraph is revalidated. Partial release requires a new manifest and hashes. A blocked claim MUST NOT remain visible through a summary, certificate, cached view, or asset caption. 6.9

Constraint relaxation TABLE 3 Classification of constraint relaxation behaviors. Class

Examples

Allowed response

Security-rigid

signature, file/network/tool scope, lease evidence, operator, mode honesty tool order, provider route, budget layout, serialization, wording

block or authorized human decision

Epistemicrigid Procedureadaptive Expressionsoft

collect evidence, mark unknown, or block replan bounds

within

rigid

transform or visibly degrade

The geo_hello_sandbox prototype verifies typed fallback suggestions for soft formatting and rigid file-scope rejection. It does not by itself prove a complete audited retry lifecycle. For example, a renderer MAY change Markdown layout under an Expression-soft rule, but it may not rewrite a failed certificate as passed. A provider outage MAY trigger Procedure-adaptive rerouting within an approved network scope, but it may not downgrade a live-evidence-required claim to cached evidence without marking the claim unknown or blocked. A human risk exception may authorize a specifically hash-bound release where policy permits; it may not silently relax signature integrity or evidence truthfulness. 6.10

Representative relational error codes

A validator MUST use stable error identifiers shared by conformance vectors and incident-corpus labels. The main profile retains representative release-blocking codes; the complete taxonomy is provided in the V15 Supplement.

PREPRINT, JULY 2026

8

TABLE 4 Representative relational error codes. Code

Meaning

Operator and status disagree SIP_RC_CLAIM_UNSUPPORTED Claim lacks evidence or operator SIP_RC_MODE_PROMOTION Silent strength promotion SIP_RC_SCOPE_ESCALATION Lower-scope authorizes higherscope SIP_RC_POST_FREEZE_MUTATION Registered bytes changed after freeze SIP_RC_ASSET_UNREACHABLE Reference does not resolve in package

SIP_RC_OPERATOR_MISMATCH

6.11

Default action Block affected claim and descendants Block claim; revalidate partial graph Block affected artifact Block action; preserve bounded implication Invalidate and rebuild package Block package or affected subgraph

Threat boundary

SIP-RC is an information, decision, and artifact-release boundary. It does not contain arbitrary malicious code, prevent kernel exploits, isolate system calls, repair an overprivileged host credential, or recover a compromised operating system. High-risk capabilities still require a subprocess, container, gVisor, microVM, hardware, or equivalent execution boundary. Runtime controls govern what may happen; SIP-RC governs whether the resulting package may be published. The Supplement carries the detailed threat table and the guidance on evidence minimization, patents, and trade secrets [30]–[34].

7 I MPLEMENTATION S TATUS AND E VALUATION P LAN The current evidence stops at implementation feasibility. DRSS supplies observed failures. The seven invariants were derived from those failures and the two other development histories. Schema Docs implements several of them and protects them with regression tests. The profile as a whole has not been compared with the baselines below. The next study begins by freezing the profile and building a corpus of 40–60 root causes. Internal incidents are split before evaluation: no more than 60% may shape the vocabulary, up to 20% may support validator development, and at least 20% remain blind. One root cause counts once even when it triggers many assertions. A fourth system, maintained outside psi.run and chosen after the freeze, provides the external transfer test. Two validators will read the same public profile and vectors without sharing decision code. Validator A works over canonical JSON or CBOR. Validator B lifts the graph into SHACL and a rule layer. That separation is architectural; the study will report authorship and organizational control separately. The principal comparisons are object-schema validation, generic graph validation, provenance/content binding, shared-generator consistency, runtime controls, and the full candidate profile. Ablations remove one path at a

time: separate-path recomputation, risk/assurance propagation, rendered-artifact checks, scope enforcement, mandatory gates, or atomic publication verification. Primary outcomes are relational-fault recall, false blocks, escape rates, validator–human agreement, validation latency, and contract-authoring cost. The analysis will emphasize paired incident-level outcomes, effect sizes, and confidence intervals; null results will not be treated as equivalence. The corpus schema, baseline definitions, ablation matrix, statistical plan, reproducibility inventory, and confidentiality fields are specified in the Supplement. Until those results exist, performance, false-block rate, and cross-implementation interoperability remain unanswered.

8

D ISCUSSION

The cases did not call for a larger schema. They changed the object under review. The object is now the release: its derivation, rendered views, approvals, and final bytes. 8.1

Why Schema Docs is the principal success case

Schema Docs changed what failure means inside the product. A conversion can lose fidelity, require review, or stop. Those states follow the document through formulas, assets, masking, audience views, packaging, receiver checks, and external editing. The regression suite matters because it preserves failures found in real files, not because its total is large. A skipped environment-dependent test stays skipped, and an unverified desktop fixture stays blocked. Loss is acceptable when the product names it; silent success is not. 8.2

Decision scope as an authority boundary

Security models normally govern identities, tools, files, and networks. DRSS shows that authority also exists inside a reasoning product. A criterion-level observation can overreach into a project-level action without invoking an unauthorized tool. Decision-scope enforcement treats implication as a capability: lower-scope claims may influence higherscope decisions only through declared operators. 8.3

Provenance is necessary but not a release decision

PROV-O, in-toto, and C2PA offer mature representations and bindings that SIP-RC should reuse. A perfectly traceable contradiction remains a contradiction. SIP-RC adds the policy that certain provenance-bearing relations are releaseblocking and identifies agent-specific predicates for claim, decision, view, tier, and publication agreement. 8.4

Refutability rather than omniscience

SIP-RC cannot decide unrestricted factual truth. It can expose the basis on which a package asks to be trusted. An auditor can then point to ineligible evidence, an inverted operator, an overreaching claim, promoted execution conditions, a missing dossier, or bytes changed after review. This makes release relations auditable within the broader governance, technical-control, and deployment context described by NIST AI RMF [14].

PREPRINT, JULY 2026

9

9

L IMITATIONS

10

9.1

Common-source bias

DRSS passed every local gate and still shipped a package whose ledger, certificate, report, and audience claims disagreed. Schema Docs shows the opposite trajectory: failures found in real documents became contracts over content, views, assets, caches, approvals, and receiver checks. GEO shows that some of the same relations appear when evidence leads to work rather than a report. SIP-RC gives those relations a form that a validator can test: support, authority, execution risk and assurance, lineage, cross-artifact agreement, hard completeness gates, and freeze–verify–publish integrity. That is the contribution reported here. The comparative question now belongs to the corpus, the two validators, the blind hold-out, and the external system.

All three systems originate from one research program. Antigravity provides a separate development account but not an external replication. The proposed vocabulary may reflect local terminology and architecture. 9.2

Retrospective collection

The histories were not preregistered. Some incidents are reconstructed from development logs and acceptance tasks. Implementation status is therefore explicit, and pending tasks are not counted as completed repairs. 9.3

Unequal maturity and test semantics

Schema Docs and GEO have freshly executed current suites. DRSS supplies a historical artifact counterexample. The suites test different risks, so Table 2 reports coverage categories rather than treating totals as comparable evidence. 9.4

Manifest and ontology quality

SIP-RC can only enforce declared semantics. An incomplete or strategically permissive manifest may validate a non-conformant real-world method. ChainCaps similarly identifies manifest quality as a deployment bottleneck [21]. Human review, negative vectors, schema governance, and cross-system reuse tests are necessary to distinguish profile quality from validator correctness. 9.5

Validator fallibility and monoculture

A validator may implement the declared invariant incorrectly. A local canonicalization prototype previously accepted an unpaired Unicode surrogate until a focused test exposed the bug. If generator and validator share the same assumptions, apparent conformance may reproduce a common error. Cross-language or differently modeled implementations, adversarial vectors, and human adjudication are required. 9.6

Evaluation status and generalization

The current study is classified as a design and experience contribution. The evaluation protocol is intended for preregistration; once run, it will test whether the observed mechanisms generalize to a broader incident class and whether SIP-RC provides detection advantages over the specified baselines at acceptable validation and authoring cost. 9.7

C ONCLUSION

Formal scope

The conditional conformance guarantee depends on a declared fault set and correct validator implementation. It is a target, not a theorem, and makes no claim about open-world truth, scientific validity of the domain method, or absence of undeclared failures.

R EFERENCES [1]

T. Liu, “Schema Sandbox: A Nine-Layer Architecture and Interoperability Contract for Constrained Agent Execution,” psi.run, 2026. doi:10.5281/zenodo.20775072. [2] JSON Schema, “JSON Schema: A Media Type for Describing JSON Documents,” Draft 2020-12, 2022. [3] W3C, “Shapes Constraint Language (SHACL),” W3C Recommendation, 20 July 2017. [4] T. Lebo, S. Sahoo, and D. McGuinness, eds., “PROV-O: The PROV Ontology,” W3C Recommendation, 30 April 2013. [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. [7] R. K. Kadaboina, “Pramān.a: A Protocol-Layer Treatment of Claim Verification in Autonomous Agent Networks,” arXiv:2605.20312, 2026. 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. 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. doi:10.48550/arXiv.2606.03024. [10] Model Context Protocol, “Specification,” Revision 2025-11-25, accessed 14 July 2026. [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. [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 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.

PREPRINT, JULY 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. 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. doi:10.48550/arXiv.2603.20356. [24] T. Liu, “Agent Concretization: An Evolutionary Framework for Persistent Agent Personas in Latent Space,” psi.run and Zenodo, 2026. doi:10.5281/zenodo.20681708. [25] T. Liu, “Agent Concretization: Informational Boundaries and Persistent Agent IP,” psi.run, 2026. doi:10.5281/zenodo.20741399. [26] T. Liu, “Harvesting Unexpectedness: A Double-Threshold Filter for AI-Generated Discoveries,” psi.run, 2026. doi:10.5281/zenodo.20776925. [27] T. Liu, “Lamarckian Scars: Inheritable Runtime Constraints for Persistent LLM Agents,” psi.run, 2026. 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. doi:10.48550/arXiv.2607.11226. [29] T. Liu, “Schema Accommodation via Algorithmic Compaction: Boundary-Preserving Skill Patches for Persistent LLM Agents,” published research paper, 2026. [30] European Patent Office, “Article 55 — Non-prejudicial disclosures,” European Patent Convention, 2020 edition. [31] United States Patent and Trademark Office, “Provisional Application for Patent,” USPTO guidance. [32] World Intellectual Property Organization, “Trade Secrets,” WIPO guidance. [33] European Commission, “Data protection explained,” EC GDPR guidance. [34] E. McCallister, T_Grance, and K_Scarfone, Guide to Protecting the Confidentiality of Personally Identifiable Information (PII), NIST SP 800-122, 2010. [35] SPDX Project, “SPDX Specification,” Version 3.0.1. [36] OWASP Foundation, “CycloneDX Bill of Materials Specification (ECMA-424).” [37] NVIDIA, “NeMo Guardrails: Guardrail Types,” documentation. [38] Guardrails AI, “Guardrails AI Documentation,” structured-data generation and validation. [39] PyTorch Foundation, “Compromised PyTorch-nightly dependency chain between December 25th and December 30th, 2022,” PyTorch Blog, Dec. 31, 2022. [40] P. Reddy and A. S. Gujral, “EchoLeak: The First Real-World ZeroClick Prompt Injection Exploit in a Production LLM System,” arXiv:2509.10540, 2025. doi:10.48550/arXiv.2509.10540.

10