OpenChainGraph: Browser-Native, Hash-Anchored Provenance for Verifiable Agent-Callable Decisions

1 · Introduction

Two developments over roughly the last eighteen months changed what software can ask of other software. The first is the Model Context Protocol (MCP)^[9], which gave AI agents a standard way to discover and invoke external tools. An MCP host turns a language model from a text generator into an orchestrator that calls third-party capabilities and consumes their results. The second is a cluster of agentic-payment and cross-vendor trust standards, including AP2^[11], A2A, x402, and signed-agent-request conventions^[10], which made it concrete for one organization's agent to act on the output produced by another organization's tool. Put together, these create a requirement that did not previously have a clean answer: when an agent consumes a tool's result and acts on it, both sides want that result to behave as verifiable evidence rather than as an unaccountable assertion.

The requirement is sharpest in regulated finance, where supervisors increasingly expect demonstrable and reproducible controls instead of after-the-fact attestation. The expectation is codified, not merely cultural: BCBS 239 requires banks to aggregate risk data accurately and trace reported figures to their sources^[38], the EU's Digital Operational Resilience Act requires financial entities to evidence their ICT controls rather than assert them^[40], and the EU AI Act's record-keeping article obliges high-risk systems to keep automatically recorded logs of their operation^[39]. It is not confined there. Any decision a downstream party relies on, whether a credit eligibility check, a sanctions screen, a reserve-adequacy calculation, or a scientific estimate, benefits from an artifact that lets a third party re-establish, independently, that a stated output follows from stated inputs.

1.1 · Why the usual answers are unsatisfying here

Three established approaches to trusted output each carry a cost that OCG is built to avoid.

Signature-based trust proves who produced a result. It does not prove that the result is correct, and it transfers a key-custody burden onto the producer and a key-distribution burden onto the verifier. A signed wrong answer is still a wrong answer, now with attribution.

Hardware trusted execution environments (TEEs) attest that a given program ran inside an enclave. The guarantee is real but it rests on a hardware root of trust and on a vendor attestation service, and that root has been breached repeatedly across successive microarchitectural and side-channel disclosures. A standard that depends on enclave integrity inherits every future enclave break.

On-chain verification publishes a proof or a commitment to a blockchain. This buys public auditability at the cost of gas fees, latency, and, in the common case where inputs or proofs are posted publicly, a loss of confidentiality.

OCG starts instead from the cheapest primitive that still gives a useful guarantee, namely deterministic recomputation, and treats every stronger guarantee as an opt-in layer placed on top rather than as a precondition.

1.2 · Contributions

This paper makes seven contributions. It describes a compact artifact model that binds decision inputs and outputs under one canonical hash and chains across vendors by citation (Sections 3 and 5). It argues, from a requirements matrix over the adjacent standards, that no existing system nor a practical combination of them covers this target (Section 2.6). It states a determinism discipline that lets the same kernel run and verify in a browser, on a server, and in continuous integration with byte-identical results (Section 4). It gives a formal statement of the base-layer guarantee, with an explicit reduction to hash collision resistance (Section 5.5). It defines a strength-of-verifiable ladder that adds authenticated attestation, a zkVM compute-integrity proof, and independent timestamp evidence as additive, backward-compatible layers (Section 6). It defines conditional chain execution whose routing decisions are themselves hash-bound and replayable (Section 5.6). It presents an agent interaction model in which discovery, planning, invocation, and verification all run over MCP (Section 8). And it reports a cross-domain deployment of more than 830 tools across three sites (Table 4), with measured verification and proving costs (Section 11). Section 12 states the limits without softening them.

2 · Background and Related Work

OpenChainGraph is a synthesis of borrowed parts rather than a new primitive. Each ingredient already exists in an adjacent field. What is new is the combination and the target. We name the influences plainly, because honest positioning is more useful to an implementer than a novelty claim.

2.1 · Software-supply-chain provenance

in-toto^[1] and SLSA^[2] established the pattern OCG borrows most directly: a hash-anchored, recompute-to-verify provenance record for produced artifacts, paired with a version-independent buildType vocabulary that names the algorithm rather than a particular tool version. The supply-chain setting cares about which source and which builder produced a binary. OCG transplants the same idea into a different setting, where the produced thing is a financial or analytical decision, and where production and verification both happen client-side. The buildType idiom carries over unchanged, and OCG reuses it to name its hashing algorithm. Two adjacent lessons from the same ecosystem carry over as well. The Update Framework showed that update systems should survive key compromise by design rather than by custody discipline^[31], and Sigstore showed how far adoption improves when signing friction is engineered away^[35]. OCG takes the more radical step its narrower setting allows: the base layer removes keys from the trust path altogether.

2.2 · Data provenance and lineage

The W3C PROV data model^[3] describes the provenance of data in terms of entities, activities, and agents. As the Trusted Compute Units authors note^[14], PROV concentrates on data and not on the computations that produced it. OpenLineage^[13] records dataset movement through pipelines for observability. OCG uses PROV vocabulary in its provenance envelope and then adds the part PROV leaves out: a hash that binds the output to the inputs as a function, so a node records both what flowed and that the output is reproducible from the recorded inputs.

2.3 · Catalogs, semantics, and credentials

OCG expresses its discovery catalog as a W3C DCAT version 3 dataset^[4], which makes the catalog crawlable by data portals and reporting platforms. For payment-shaped payloads it offers an optional ISO 20022 semantic crosswalk^[5], and for regulatory filing it offers an XBRL export keyed to published taxonomies^[19]. Any artifact can be re-expressed as a W3C Verifiable Credential version 2.0^[6], and signing keys can be named with decentralized identifiers^[18]. These are interoperability surfaces. None of them is the trust mechanism, and none of them enters the hash.

2.4 · Verifiable computation and zkVMs

Verifiable computation has a deep literature of its own. Walfish and Blumberg survey the road from theoretical possibility to near practicality^[36], with Pinocchio usually credited as the first nearly practical general-purpose system^[37]; modern zkVMs are the industrialized descendants of that line. The closest academic neighbor to OCG is Trusted Compute Units (TCU)^[14], which frames chained verifiable computation as a technology-agnostic abstraction over heterogeneous backends. TCU combines hardware TEEs and zero-knowledge virtual machines and anchors a workflow to a blockchain registry, demonstrating end-to-end integrity across organizations through federated-learning use cases. OCG shares the goal of chaining verifiable computation across organizational boundaries, and it adopts the zkVM half of TCU's toolkit, but it diverges on three deliberate points. It is software and cryptographic only, with no TEE and no hardware enclave. It is off-chain, with the registry realized as a published catalog rather than a blockchain. And its base layer needs no proving at all, because deterministic recomputation already gives a useful integrity guarantee at zero proving cost. Where a verifier wants more, OCG turns to zkVMs such as RISC Zero^[15] and SP1^[16], both of which can emit a Groth16 SNARK^[17] for cheap downstream verification, and it declines the TEE leg on purpose (Section 6.5). Content-provenance efforts such as C2PA^[12] solve an analogous problem for media through signed manifests over assets, which is a different object than a recomputable decision.

Agent-receipt formats have independently converged on much of OCG's cryptographic stack, JCS canonicalization, SHA-256, Ed25519, previous-hash chaining, in at least two public designs, which is convergent-field evidence rather than a priority claim in either direction. Microsoft's proposal-stage compliance receipts^[50] add bilateral pre- and post-execution seals, a temporal-order mechanism OCG does not currently claim. The agent-receipts VC 2.0 profile^[51] defines a signed AgentReceipt credential that OCG's Section 7 export can address directly, modulo a proof-suite delta between its Ed25519Signature2020 and OCG's eddsa-jcs-2022. The standard's §XMAP-1 annex gives the field-level mapping for both.

2.5 · Theoretical lineage

OCG's mechanisms are recombinations of well-established results, and naming that lineage is part of candid positioning. The base-layer idea, that a record's integrity can rest on a hash linking it to its inputs and to prior records, descends from the hash-linked digital timestamping of Haber and Stornetta^[21] and from Merkle's hash-tree authentication of large data sets^[22]. A ChainGraph is, in effect, a hash-linked provenance structure over decisions rather than over documents or coins. Certificate Transparency turned the same hash-linked construction into operational infrastructure at web scale^[32], and the IETF's SCITT effort is now generalizing transparent, append-only registration to arbitrary supply-chain statements^[29]; Section 2.6 returns to why neither substitutes for OCG's object. The cryptographic hash itself is SHA-256 as standardized in FIPS 180-4^[26], and the canonical preimage is restricted to the interoperable JSON subset of RFC 7493^[27] so that serialization is unambiguous. This is also the sense in which an OCG deployment treats its receipts as the canonical record. The append-only sequence of hash-anchored artifacts is the source of truth, and any convenient cached state is a derived view that a reader can always recompute from the artifacts themselves, the state-is-derived, log-is-canonical framing that Certificate Transparency's successor specification^[47] and the data-systems literature^[48] make precise.

The optional compute-integrity layer draws on the zero-knowledge proof tradition that began with Goldwasser, Micali, and Rackoff^[23] and that modern zkVMs realize through transparent, scalable proof systems such as STARKs^[24]. The idea of composing such proofs across a workflow, so that a verifier checks a final result without re-running the whole pipeline, is the proof-carrying data model of Chiesa and Tromer^[25], which Section 6.7 returns to. The mainstreaming of provenance as a baseline control, which made the supply-chain analogy in Section 2.1 timely, tracks frameworks such as the NIST Secure Software Development Framework^[28].

2.6 · Why a new standard: the requirements matrix

A reasonable reader should ask the skeptical question directly: the field has provenance standards already, so why another one? The straightforward way to answer is to state the requirements OCG's setting imposes and score the adjacent standards against them, including the unflattering cells.

The setting of Section 1 imposes seven requirements. R1, recomputable derivation: a verifier can re-derive the output from the recorded inputs and match a content hash, so integrity rests on reproduction rather than on attestation. R2, cross-vendor chaining by content address: an artifact cites prior artifacts, including another organization's, by hash, and the citations verify. R3, browser-native production and verification: both ends run in a commodity browser with no backend service in the trust path. R4, agent-callable: the capability is invocable over a standard agent protocol and returns the verifiable artifact in the same round trip. R5, keyless and ledgerless base: the base integrity claim requires no signing key, no transparency service, and no blockchain. R6, additive strength: stronger attestations attach without changing the artifact's identity or breaking its schema. R7, executable conformance: the standard's normative rules are machine-checked, so conformance is decidable.

Each "no" above is a reasonable design choice for that standard's own object: signed statements for SCITT, media assets for C2PA, movement observability for OpenLineage. The matrix is not a criticism of any row. It shows that the intersection OCG occupies was empty.

The stronger form of the skeptical question is whether a combination would suffice, since standards compose. Take the best available stack: express the decision as an in-toto attestation, wrap it as a Verifiable Credential, and register it with a SCITT transparency service. That composition yields a signed, transparently logged, semantically interoperable statement, and it still fails the requirements that define the setting. Nothing in it recomputes the decision (R1), every layer adds a key or a service to the trust path (R3, R5), and no layer exposes the capability to an agent as a callable that returns the evidence (R4). The gap is not glue code. The missing piece is the object itself: a decision rendered as a pure function whose output a stranger re-derives locally. That object is OCG's contribution, and everything around it, the envelope vocabulary, the catalog format, the credential view, the signature suite, is deliberately borrowed from the rows of the matrix.

The converse scoping also holds. A deployment that already lives inside a PKI, does not need recomputation, and wants transparency of issuance is better served by C2PA or SCITT than by OCG, and Section 7 exists so that such systems can consume OCG artifacts rather than compete with them.

2.7 · Convergent validation from recent work

Two papers published after OCG's single-guest compute-integrity layer and hash-chained artifact model were already shipping arrive independently at the same requirements, which is worth recording as corroboration rather than as a source. Balan, Learney, and Wood survey cryptographic verifiability across the full AI lifecycle and name, as an open gap in the field, that zero-knowledge proofs of training and zero-knowledge proofs of inference typically run on different, often bespoke proof systems that are not directly compatible, for instance because quantization is handled differently between the two^[49]. OCG's compute-integrity layer (Section 6.3) does not bridge that gap so much as sidestep it by construction: every proven node, whatever stage of a decision it represents, runs through the same universal RISC Zero guest with the kernel's own logic passed in as data, so there is no separate training-time arithmetization to reconcile against an inference-time one. The same paper frames a verifiable pipeline as a chain of stages, each taking commitments from the prior stage as input, verifying them, and emitting its own proof linked to what came before, which is recognizably the incrementally-verifiable-computation shape of Section 6.7's proof-carrying-data frame and of the chain.parent_hashes citations that Section 5 already ships; OCG gets that composition from cheap hash citation at the base layer rather than from proving it at every hop. Castillo, Heiss, Werner, and Tai's Trusted Compute Units, already OCG's closest academic neighbor in Section 2.4, is related pipeline-verification work in the same convergent direction, chaining verifiable computation across organizational boundaries with its own technology-agnostic abstraction over zkVMs and TEEs^[14]. Neither paper was a design input; both are cited here because a field arriving independently at the same requirements is stronger evidence for those requirements than either paper alone.

3 · The OpenChainGraph Model

An OCG artifact is a JSON document with a fixed envelope. The integrity anchor is a single field, execution_hash, defined as a WebCrypto SHA-256 over the canonical serialization of exactly one pair of members, policy_parameters and output_payload, and nothing else. The remaining envelope fields are metadata that travel with the artifact but stay outside the hash.

{
  "@context": "https://ainumbers.co/chaingraph/context/v0.3/context.jsonld",
  "chaingraph_version": "0.4.0",
  "mandate_type": "compliance_mandate",
  "tool_id": "art-04-agent-identity-attestation-checker",
  "tool_version": "1.0.0",
  "generated_at": "2026-06-27T12:00:00Z",
  "buildType": "https://ainumbers.co/chaingraph/context/v0.2#WebCryptoSHA256",
  "execution_hash": "63e5ab2beeec9efeb1e77c3da265eb049160a271fa98096ce8bebf2dbb838677",
  "chain": { "parent_hashes": [], "parent_tool_ids": [], "chain_depth": 0 },
  "policy_parameters": { // half of the hash preimage: every decision input lives here },
  "output_payload":    { // half of the hash preimage: the decision itself },
  "audit_signature":   { // optional attestations: §16 proof, §17 build_identity, §18 compute_proof }
}

3.1 · Canonicalization is the contract

Two implementations agree on a hash only if they serialize the preimage the same way down to the byte. OCG fixes this with the JSON Canonicalization Scheme (JCS, RFC 8785)^[8]: object keys are sorted by Unicode code point, arrays keep their order, numbers use the ECMAScript number-to-string production, strings use minimal escaping, and insignificant whitespace is removed. A single shared canonicalizer, used by both the browser tool and the server compute path, produces these bytes, and the hash is the SHA-256 (the Secure Hash Standard, FIPS 180-4^[26]) of that byte string rendered as lowercase hexadecimal.

Canonicalization carries a subtle correctness condition. JCS is only well defined over the interoperable JSON subset (I-JSON, RFC 7493^[27]), so a value that cannot round-trip, such as a non-finite number or an integer beyond the safe range of an IEEE-754 double, would canonicalize ambiguously. OCG rejects such values at hash time rather than emitting an unstable hash. The reference canonicalizer asserts the I-JSON property over the preimage and raises an error on any violation, which converts a silent reproducibility bug into a loud failure at the point of production.

Forbidden constructions

Several plausible-looking shortcuts produce hashes that look canonical but are not, and OCG forbids them by lint gate rather than by convention.

• Array-replacer key sorting, such as passing Object.keys(x).sort() as the replacer argument to a stringify call, sorts only the top level and leaves nested objects in insertion order. It is a frequent and quiet source of cross-implementation drift.
• Substituting a non-cryptographic digest, such as a 32-bit string hash, for SHA-256 and labeling the result sha256: defeats the integrity claim while preserving its appearance.
• Hashing a reduced or pretty-printed object that differs from the stored output_payload breaks recomputation for anyone who hashes what was actually stored.
• Embedding the hash inside the object that is hashed creates a self-reference that cannot be reproduced.

3.2 · The preimage and only the preimage

Folding every decision input into policy_parameters is a strict discipline. If a kernel reads a value that is not in the preimage, a verifier who has only the recorded inputs cannot reproduce the output. The rule is therefore that the kernel is a pure function of policy_parameters and writes its entire result to output_payload. Everything else in the envelope, including the timestamp, the context URL, the version tag, and any later attestation, sits outside the preimage so that adding or changing it never disturbs the hash.

3.3 · A worked example

The following artifact was produced by the deployed agent-identity attestation kernel (node art-04) and is reproduced here verbatim, including its real hash. The kernel checks an agent credential against a set of Know-Your-Agent rules and returns a pass, warn, and fail tally.

// policy_parameters (the full preimage input)
{
  "credential": {
    "credential_type": "AgentCredential", "agent_id": "agent-7f3a",
    "issuer": "did:key:z6MkExampleIssuer",
    "issued_at": 1750000000, "expires_at": 1781536000,
    "scopes": ["read:account", "initiate:payment"], "signature": "ed25519:zSig"
  },
  "validate_at_unix": 1751000000
}

// output_payload (the decision)
{
  "overall_status": "warn", "pass": 5, "fail": 0, "warn": 3,
  "checks": [ {"code":"KYA-T01","status":"pass"}, /* ... */ {"code":"KYA-EU1","status":"warn"} ],
  "root_agent_id": "agent-7f3a", "scopes": ["read:account", "initiate:payment"]
}

// execution_hash = SHA-256( JCS({ policy_parameters, output_payload }) )
63e5ab2beeec9efeb1e77c3da265eb049160a271fa98096ce8bebf2dbb838677

To verify this artifact, a third party canonicalizes the two preimage members, takes the SHA-256, and compares against the stored value. To verify it more strongly, that party re-runs the kernel itself with the recorded policy_parameters, obtains the same output_payload, and then hashes. The second path is what distinguishes OCG from a plain checksum: the hash is reproducible because the computation is reproducible, so the artifact certifies a derivation and not merely an unchanged blob.

3.4 · Versioning model

One point of friction deserves a direct explanation, because an artifact carries several version numbers and none of them is the headline "v0.6." OCG uses layered version identifiers, each answering a different question, and deliberately decouples them. This follows the in-toto and SLSA convention, where a predicate's type URI resolves to the latest minor version and does not change for additive updates; the consumer-facing identifier moves only on a breaking change.

The signing-envelope shell named in the last row is DSSE, the envelope format the in-toto ecosystem converged on^[30], reused rather than reinvented.

The unifying rule: every additive layer (the verifiable-credential view of Section 7, and the proof, kernel-identity, and compute-integrity attestations of Section 6) is hash-excluded and lives under audit_signature, so it never moves chaingraph_version. A v0.6 artifact therefore still validates under the frozen v0.4 schema. Read chaingraph_version as the schema version ("parse me with this"), and spec_version as the standard release. The bare field name chaingraph_version is the one we would change, to a self-describing format_version or type URI in the in-toto style, on the next breaking envelope revision; it cannot be renamed additively because the envelope root is closed (additionalProperties:false).

4 · Determinism and Compute Binding

Recompute-to-verify is only as good as the determinism of the kernel. OCG's reference implementation enforces determinism through a deployment discipline rather than trusting authors to be careful. Each tool is a single self-contained HTML page that computes in the browser with no network calls after load, no persistent storage of any kind, and no personally identifiable data. The decision logic is a pure kernel, a function from inputs to output, with no clock, no source of randomness, and no input or output side effect on the hash path.

4.1 · One kernel, three runtimes

The same kernel module is shared, byte for byte, between the browser page and a server-side compute path, a property OCG calls compute binding. An agent that prefers a single round trip can call the server path and receive a complete, hash-anchored artifact without ever opening the page, and the result is identical to what the page would have produced because the code and the canonicalizer are the same module imported in two runtimes. WebCrypto provides SHA-256 in browsers, in the Cloudflare Workers runtime, and in Node, so the canonicalizer runs unchanged in all three, including the continuous-integration environment that gates releases.

The discipline is reproducible-builds thinking^[33] moved one level up. Where reproducible builds demand bit-for-bit identical binaries from the same source, OCG demands bit-for-bit identical decisions from the same inputs, and it inherits the same core lesson: reproducibility is not a property one asserts about code, it is a property one engineers into the toolchain and then tests for continuously.

4.2 · The kernel contract

A server-computable node ships a kernel that exports three things: a pure compute function, an async buildArtifact that wraps the output in the envelope and computes the hash, and a small metadata record. Two properties are checked mechanically. Every node that declares a server compute capability must ship a registered kernel, and a missing kernel fails the build rather than degrading to a browser-only fallback. Every kernel must return a finite, I-JSON-valid result even on empty input, which a dedicated gate verifies by invoking each kernel with an empty object and rejecting any non-finite value. The second check exists because an unguarded division or logarithm that yields infinity or not-a-number would break canonicalization and, with it, reproducibility.

5 · Chaining and Cross-Vendor Verification

A single artifact certifies one decision. Real workflows compose decisions, often across organizational boundaries, and OCG composes artifacts the same way it secures them, by hash.

5.1 · Edges are citations

A consuming stage records, in its chain object, the execution_hash of each parent it depends on, the parents' tool identifiers, and a depth value set to one more than the greatest parent depth. A root artifact has an empty parent list and depth zero. The edges of the resulting directed acyclic graph are cryptographic citations rather than editorial references: a set of hashes that either reproduce or do not.

5.2 · The verification algorithm

To verify a chain rooted at a final artifact, a consumer walks the graph from that artifact toward its roots. For each artifact it confirms two things: that recomputing the SHA-256 over the artifact's own preimage reproduces its execution_hash, and that every value listed in parent_hashes equals the execution_hash of an artifact it has obtained and checked. The walk succeeds only if every node reproduces and every cited parent hash resolves. Because a child's stored parent hash is the parent's own computed hash, any modification anywhere upstream changes a hash and breaks the citation that points at it, so tampering is detected at the first altered node regardless of how deep it sits.

5.3 · Why this works across vendors

Nothing in the procedure requires the verifier to trust, or even contact, the organizations that produced the upstream artifacts. The artifacts are self-certifying: each carries its inputs, its output, and a hash that a verifier reproduces locally. A bank consuming a counterparty's screening artifact, which in turn cited a data vendor's enrichment artifact, can reconstruct and re-verify the full provenance from the artifacts alone. The base layer's one cost, which Section 5.4 and Section 6 address, is that this reconstruction requires re-execution and requires the inputs to be present.

5.4 · The cost the base layer pays

Recompute-to-verify has two real weaknesses at the base layer. Verifying a deep chain means re-running every stage, with no shortcut, and re-running a stage means holding its inputs in the clear. Both are acceptable for many workflows and unacceptable for some, which is precisely why OCG offers stronger layers above the base rather than forcing every user onto one mechanism. The compute-integrity proof of Section 6.4 removes both weaknesses at once, at the price of off-line proving.

5.5 · A formal statement of the guarantee

The claims of Sections 3 and 5 can be stated precisely, and stating them makes the trust reduction explicit. Fix H = SHA-256^[26] and let C be the JCS canonicalization function^[8] restricted to I-JSON values^[27]. On that domain C is injective: it assigns every value exactly one byte string, and distinct values receive distinct byte strings. This injectivity is precisely the property the I-JSON guard of Section 3.1 protects, since a non-finite number or an unsafe integer would break it. A kernel K is a deterministic, total function from an input document to an output document, both I-JSON. An artifact with members p (the recorded policy_parameters), o (the recorded output_payload), and h (the recorded execution_hash) is conformantly produced when o = K(p) and h = H(C({p, o})).

Three checks operate on such an artifact. The integrity check recomputes H(C({p, o})) from the stored members and compares it with h. The derivation check additionally re-runs the kernel and confirms K(p) = o before hashing. The chain check applies the derivation check to an artifact and, recursively, to every artifact its chain.parent_hashes cites, confirming at each edge that the stored citation equals the cited artifact's own recomputed hash.

Claim 1 (tamper evidence). An adversary who alters p, o, or both while keeping h fixed, and whose altered artifact still passes the integrity check, has found a SHA-256 collision. The argument is a direct reduction. Write the altered pair as (p′, o′) ≠ (p, o). By injectivity of C, the byte strings C({p′, o′}) and C({p, o}) differ, yet passing the check means both digest to the same h. That is a collision for H. Under the standard assumption that finding SHA-256 collisions is computationally infeasible, any such alteration is detected.

Claim 2 (chain propagation). In a chain that passes the chain check, altering any upstream artifact is detected at the first altered node. The adversary has two moves at that node and both fail. Recomputing the altered node's hash necessarily changes its value, so the downstream child's stored citation no longer matches and the edge check fails. Keeping the old hash on altered members is Claim 1 at that node. Induction over depth extends the argument to a chain of any length, which is the formal content of the sentence in Section 5.2 that tampering is detected regardless of how deep it sits.

The formalism also says plainly what it does not say, matching Section 10. The derivation check establishes o = K(p) for the kernel K the verifier chose to run; it does not establish which program the producer actually executed, which is the gap Sections 6.2 and 6.3 address. It says nothing about whether p is true. And the totality and determinism of K are assumptions, discharged operationally by the Section 4 discipline and its gates rather than proven.

5.6 · Conditional execution and decision gates

Chains as described so far run every step in order, which fits a report but not a decision procedure. Real decision workflows branch: a qualified-mortgage points-and-fees test that fails should stop the pipeline rather than proceed to a pricing step, and a parametric insurance trigger that fires should route to a payout calculation rather than to a rejection notice. Version 0.8 adds decision gates for exactly this shape. A chain step may carry a gate: a small routing object holding an RFC 6901 pointer into that step's own output, an ordered list of comparator rules drawn from a closed operator set (equality, inequality, ordered comparison, membership, presence), and a mandatory default target. Rules evaluate first-match, targets may only point forward in the chain, and the required default makes routing a total function. Together these three constraints guarantee, by construction, that every gated chain terminates and that an agent can run it end to end with no human intervention and no undefined state. The design deliberately excludes loops, backward jumps, and general expression languages; the closed comparator set follows the lesson of decision-model standards such as OMG DMN, whose single-hit table policies are the deterministic core of a much larger language^[45], and of deployed rule subsets that achieved cross-platform determinism by specifying less, not more.

The integrity question is what distinguishes this from ordinary workflow branching: a verifier must be able to establish not only that each step is authentic but which path ran and why. Gated chains therefore extend the composite artifact with three members. A route plan digest commits the full chain definition, including every gate, under the same canonicalizer as everything else, so the decision policy that could have run is itself hash-bound. A decisions list records, for each evaluated gate, the pointer, the observed value, the matched rule, and the chosen target. A path list records the ordered steps that actually executed, with skipped steps marked as skipped by gate, which is distinct from failed. Because the decisions list is a pure function of the recorded step outputs and the recorded gates, a verifier replays the routing locally: re-evaluating every gate over the stored outputs must reproduce the stored decisions exactly, and any divergence is tamper evidence in the same sense as a hash mismatch. All three members enter the composite hash preimage only when a chain declares at least one gate, so every pre-existing linear chain's composite hash is unchanged, a property the conformance suite enforces with frozen golden hashes across the full deployed chain set.

6 · The Strength-of-Verifiable Ladder

No single mechanism serves every verifier. One party wants cheap, anonymous, keyless integrity. Another wants a named party to vouch for an artifact. A third wants a succinct proof that also hides the inputs. OCG offers all three as additive, opt-in attestations, each living under the audit_signature object and each excluded from the hash. Adding an attestation never changes the execution_hash, and an artifact that carries no attestation is still fully conformant.

6.1 · Layer 2, the Data Integrity signature

Proof binding attaches a proof object at audit_signature.proof using the eddsa-jcs-2022 cryptosuite, an Ed25519 signature over a JCS-canonicalized document, in the standard W3C Data Integrity pipeline. The secured document is the full artifact with the proof object removed, so a signature is never part of its own input. Generation hashes the canonical proof options and the canonical document separately, concatenates the two digests, and signs the concatenation; verification reverses the steps. The canonicalizer is the same one used for the execution hash, so there is no second serialization path and the forbidden constructions of Section 3.1 stay forbidden here as well. Because the execution hash sits inside the secured document, a whole-artifact signature transitively secures the Section 4 anchor. The verification method is a decentralized identifier: a did:key for ephemeral, fully client-side signing, where a private key must never be shipped in page or storage, or a did:web for a stable institutional issuer whose key lives in a hardware security module and signs on the server compute path.

6.2 · Layer between L2 and L3, kernel identity

The execution hash proves that the output follows from the inputs by some logic, but it does not pin which logic ran. Kernel identity binding closes that gap as a published claim. The artifact records, at audit_signature.build_identity, the SHA-256 digest of the exact kernel source that produced it, computed over line-normalized source bytes by the same shared digest helper, and a node publishes that digest in its catalog entry. A verifier cross-checks three values: the digest in the artifact, the digest published in the catalog, and the digest recomputed from the deployed source. We are explicit about the strength of this claim. It is advisory. It lets a verifier confirm which source the publisher states ran, but a dishonest server could record a digest different from the code it actually executed. Cryptographic proof that the named program produced the output is the job of the next layer.

6.3 · Layer 3, the compute-integrity proof

Compute-integrity proof, new in version 0.6, turns the Section 4 hash from re-execute-to-verify into a succinct proof of correct execution. A node may attach, at audit_signature.compute_proof, a zkVM receipt with a small fixed shape: a type tag, a system identifier such as risc0 or sp1, a receipt format, an image identifier that names the exact guest program (a RISC Zero ImageID or an SP1 verifying key), the proof bytes, and a journal of public outputs. The journal's committed output must equal the artifact's output_payload, which is what binds the proof to this particular artifact rather than to some other run of the same program.

Verification, with the cryptography delegated

A verifier has two paths and chooses between them. It can recompute per Section 4 when the inputs are public, or it can verify the receipt against the image identifier, which works even when the inputs are withheld. The cryptographic seal check is delegated to the named system's own vetted verifier, in the same way that Section 4 delegates SHA-256 and Section 6.1 delegates Ed25519 to WebCrypto. OCG specifies the binding and does not reimplement a proof system. Its conformance gate checks that the receipt is well formed, that its image identifier matches the one the node publishes, that the journal binds the output, that no new execution hash is minted, and that the version tag is unchanged. The recommended receipt format is a Groth16 SNARK over the BN254 curve, a constant-size proof (256 bytes in every deployed receipt) that verifies in milliseconds, because both RISC Zero and SP1 can produce it and it has become the practical interoperability point across zkVMs. A self-contained pairing-check verifier for that format is recommended so that a verifier is not dependent at run time on the prover's vendor, and OCG ships one: a zero-dependency BN254 pairing check that reconstructs the receipt's claim digest from the image identifier and the journal and tests it against the published verifying key, with a conformance gate that proves it accepts a real receipt and rejects a tampered seal or a mismatched journal.

One element of fully independent verification was until recently documented as pending rather than asserted, and how it was settled is worth recording precisely. The claim digest a receipt binds covers the journal as the byte string the guest committed, so recomputing that digest from a published receipt requires a byte-serialization contract for the journal over and above its JSON value. The question could not be settled from the bulk of the corpus: in all but one of the 313 published fixture receipts (counted 2026-09-02) every journal object is already key-sorted, so the RFC 8785 canonical serialization and plain insertion order coincide byte for byte and cannot be told apart. The single receipt whose journal carries unsorted keys was therefore the deciding test, and that test has now run (2026-09-01, in the external verifier program): the receipt verifies end to end under the RFC 8785 canonical derivation and fails under insertion order, so the byte contract the guests actually implement is canonical order, established empirically without reading the guest source. The corresponding specification clause is drafted against that result and remains pending until it lands through the standard's own gate suite; until it does, the contract is a documented finding rather than normative text. An earlier internal draft had stated the same canonical-order conclusion from the coinciding evidence alone; that claim was caught in review, downgraded to exactly what the experiment then discriminated, and the deciding receipt was queued and run, which is the review ladder of Section 9 applied to the standard's own documentation, twice.

Proving runs off-line

zkVM proving needs a Rust toolchain and substantial compute, and the proving cost runs orders of magnitude above native execution^[14]. OCG therefore states a hard constraint: proving must not be claimed to run in the browser tool, in the Cloudflare Workers compute path, or in continuous integration. A receipt is produced off-line and attached, and the live surfaces only verify.

Adoption

Version 0.6 moved this layer from defined to deployed, and coverage has grown with every release since. Receipts are attached kernel by kernel as each is proven off-line, and a downward-only ratchet tracks how many eligible live nodes still lack one, a count that can only fall, never rise, as later waves prove more kernels; the current figure is always available by running the tracking script rather than by reading a number fixed in this paper (scripts/check-compute-proof-coverage.mjs). At present 659 of 661 live nodes in the AINumbers suite (99 percent, all three figures derived sentinels) carry a real Groth16-BN254 receipt, each accepted by the shipped pairing-check verifier and each carrying a journal that is byte-identical to the output the live tool returns; the remainder stay deferred for stated reasons and are tracked by that same ratchet. Most proven nodes were proven off-line from a single universal guest program whose one image identifier covers the large majority of them, with each kernel's source passed in as data. Four cases carry their own guest image for a stated reason, and no others do: a Monte-Carlo value-at-risk kernel and a content-identification kernel each needed a native guest to fit a heavy workload into the local proving budget, an agent-identity kernel predates the universal guest, and a group of private-input nodes uses an extended guest that also hides its inputs. All were generated on one consumer graphics card with the prover's development mode disabled, so the proofs are real rather than mocked. The transcendental-math gap reported in earlier drafts has since been closed: the affected kernels now inline a shared deterministic math implementation, so the browser engine and the guest agree bit for bit, and those nodes carry receipts like any other. The content-identification pipeline that earlier drafts recorded as deferred, whose hashing workload interprets to over a billion guest cycles, has since been proven on its own native guest, moving the ratchet's deferred count down by one; the ratchet does not reach a fixed end state, because each new wave of kernels can add newly eligible, not-yet-proven nodes even as older deferrals clear. Proving capacity has also been demonstrated well past the typical kernel's budget: the heaviest single receipt in the fleet, for a DID log-verification kernel, ran to 9,922 proof segments under cooperative checkpointing, was suspended at a segment boundary while the proving machine slept, resumed from its checkpoint under a guard that refuses to continue if the kernel digest has moved since the checkpoint was taken, and completed to a verified Groth16 receipt in roughly four and three-quarter hours of total proving time.

6.4 · Confidentiality

The receipt enables a mode the base layer cannot reach. When a receipt is used to withhold inputs, policy_parameters may carry commitments or hashes in place of cleartext, the journal exposes only the public result, and the proof attests that some private input consistent with those commitments produced that result. In this mode the Section 4 recompute path is unavailable to a third party, because the third party does not hold the inputs, and the receipt becomes the sole verification path. A tool offering this mode must say so to the consumer. Like signing, attaching a receipt links a run to a published program identity, so the layer defaults off and is never applied automatically.

6.5 · Why not TEEs

TCU combines TEEs and zkVMs. OCG adopts the zkVM leg and declines the TEE leg deliberately. A hardware enclave relocates the root of trust into silicon and a vendor attestation service, and that root has a long record of being broken by side-channel and microarchitectural attacks. A zkVM keeps the trust in mathematics and in open verifiers, which is consistent with the rest of the design. The three layers compose. A compute-integrity receipt can itself be covered by a Data Integrity signature over the whole artifact. None of the three mints a new execution hash or changes the version tag, all of them ride under the tolerant audit_signature object, and an artifact carrying none of them is byte-identical to a pre-version-0.6 artifact and validates under the same frozen schema.

6.6 · Anchor bindings: the time dimension

Every rung so far answers what was computed. None answers when. Version 0.7 added anchor bindings for that question: an artifact may carry, under a hash-excluded anchor_bindings array, portable evidence that its execution hash existed by a point in time. The primary binding type is an RFC 3161 timestamp token^[43] obtained from an independent time-stamping authority, stored verbatim together with the full signer certificate chain so that verification needs no network access and no cooperation from the authority. A second type carries an OpenTimestamps proof^[44], which commits the hash to the Bitcoin block-header chain and therefore has no certificate to expire. The standard recommends bindings from more than one independent authority, and the reference verifier validates a token at its issuance time rather than at the current time, which is the property that lets a binding remain checkable decades after the authority's signing certificate has rotated.

Timestamping every artifact individually does not scale past an authority's request policies, and version 0.8 addressed throughput the same way transparency logs do^[32]. A batch of execution hashes is assembled into an RFC 6962 style hash tree, the single root is anchored once, and each artifact carries the root's binding together with a compact inclusion proof: its leaf, index, audit path, and tree size. A verifier recomputes the root from the leaf and the path and requires it to equal the anchored value, so one timestamp covers an unbounded batch while each artifact remains independently checkable. The reference deployment operates this as a public evidence surface with its own agent endpoint, offering hash anchoring, batch anchoring, binding verification, and passkey-based signature envelopes that pair a WebAuthn assertion with a timestamp token in the ETSI JAdES format^[46]. Timestamp evidence composes with the rest of the ladder: a receipt proves the computation, a signature names a party, and a binding fixes the moment, and a workflow that needs contemporaneous documentation, such as a hedge-effectiveness test that must provably have run at designation date, uses all three together.

6.7 · Proof-carrying data: the formal frame

The base layer and the compute-integrity layer are two points on one spectrum the literature calls proof-carrying data^[25]. In that model each node in a computation passes along, together with its output, evidence that the output was produced correctly from valid inputs, and a downstream party verifies the final evidence without re-executing the history. OCG's base layer is a degenerate instance of the model: the evidence is the recorded inputs plus the execution hash, and verification is re-execution, which is cheap to produce but linear to check and needs the inputs in the clear. The compute-integrity layer is the full instance: the evidence is a succinct zero-knowledge proof^[23], realized in current zkVMs through transparent proof systems^[24], and verification is sublinear and input-hiding. Framing the layers this way clarifies the design. OCG does not choose between recomputation and proof; it places them on one ladder and lets a deployer pick the rung that matches a workflow's cost and confidentiality needs.

7 · Export Profiles and Semantic Interoperability

A verifiable artifact is useful only if the systems around it can read it. OCG defines export profiles, which are generated renderings produced after the execution hash and excluded from the preimage. An export is a view of the artifact, not a second source of truth. A single read-only export tool emits XLSX, CSV, PDF, an XBRL document keyed to a regulator taxonomy, and a Verifiable Credential. Each export embeds the canonical hash and a link back to the JSON, none of them mints a new hash, and each is deterministic, so the same artifact renders byte-identical bytes every time. Verification always routes back to the canonical artifact.

7.1 · XBRL without invented concepts

The XBRL profile maps payload fields to published taxonomy elements on a per-regime basis, with pilots for the European Banking Authority own-funds and liquidity templates, and it never fabricates a taxonomy concept. Where no regulator taxonomy exists for a quantity, the profile uses an explicit extension element rather than pretending a standard concept applies. The intent is that a filing produced from an OCG artifact can be checked against the regulator's own taxonomy, not merely against OCG's claims about it.

7.2 · The credential view

The Verifiable Credential profile re-expresses an artifact as a W3C Verifiable Credential version 2.0 document. It maps the envelope to credential fields and carries a hash anchor that restates the canonical execution hash, so a credential consumer can route back to the canonical JSON and re-verify. The profile is available on every node, because a lossless structural re-expression always exists, and it deliberately mints no securing proof of its own. A deployer who needs a secured credential adds an enveloping proof downstream, and the proof binding of Section 6.1 provides exactly that mechanism over the canonical artifact.

7.3 · The catalog as an orchestration recipe

The discovery catalog is a DCAT version 3 dataset, which makes it crawlable by data portals and reporting platforms. Beyond cataloging, the catalog carries the edges an agent needs to plan. Each node declares what it consumes and what it feeds, and those edges are the machine-readable map an agent reads before it calls anything, so it can assemble a full chain in advance rather than discovering dependencies by trial. Payment-shaped nodes additionally carry an ISO 20022 crosswalk for amounts, parties, and agents, and every node declares its profile conformance with the W3C Profiles vocabulary^[42], asserting only what it truthfully conforms to so that a non-payment node carries no payment profile. None of these surfaces enters the preimage, so a verifier written for the base envelope computes identical hashes regardless of which overlays are present.

7.4 · Payment-mandate mapping

One export deserves a specific note because the standard around it moved. The Agent Payments Protocol^[11] transferred to the FIDO Alliance in May 2026, which makes an interoperability question routine for any payment-shaped artifact: is this mandate AP2-compatible? OCG answers it the way it answers every other interoperability question, by mapping rather than by custody. The standard's mandate structure carries a documented field-level correspondence to the AP2 verifiable-credential mandate, so a payment artifact can be re-expressed against AP2's vocabulary and checked for structural conformance without OCG taking custody of a payment, holding a credential, or entering a settlement path. The correspondence is a view in the sense of this section's opening, and like every other export it mints no new hash and adds no party to the trust model. One naming boundary is kept deliberately sharp in the reference deployment: the client-side export schema its tool pages offer is called the Policy Mandate, an internal AINumbers format, and it is not AP2's mandate vocabulary; the mapping above is how a payment-shaped artifact is expressed against AP2, and the two schemas are never conflated on the surfaces that carry both.

7.5 · The Evidence Envelope: signed receipts for events OCG does not compute

Most of the evidence a regulated workflow generates originates in systems the standard does not operate: a ledger engine posting journal entries, a policy engine evaluating a rule, a payments service pre-flighting a transfer, a reconciliation run. Version 0.8.13's ecosystem layer adds the Evidence Envelope (schema ainumbers.evidence.v0.1, ratified August 2026), a signed receipt format for exactly these events. A receipt records its event class, with policy decisions, reconciliations, payment pre-flights, journal verifications, and refusals all first-class types, the source adapter that observed the event, and algorithm-prefixed digest fields (sha256: strings) over the input, the policy, the execution, and the output. A previousReceiptHash chains each receipt to its predecessor, so a per-issuer receipt sequence is itself tamper-evident, and an optional result_status makes a receipt of a denial a distinct, first-class object rather than an error page.

The signing pipeline reuses the discipline of Section 3 rather than inventing a second one. Everything except a single unprotected slot travels inside the signed payload. Signing removes the signatures and unprotected members, canonicalizes the remainder with the same RFC 8785 canonicalization the artifact envelope uses, hashes it, and signs the 32-byte digest with Ed25519, named EdDSA after the JOSE convention and keyed by a did:key in kid. Digest preimages are domain-separated by context tags, so a digest minted for one field cannot be replayed as another. Two transparency-log surfaces are preimage members: an optional log_url, which binds which log must be able to prove inclusion, and an optional committed-fields root, an RFC 6962-style Merkle tree over salted leaf digests that supports selective disclosure. Timestamp-log inclusion proofs and witness countersignatures live in the unprotected slot, so post-issuance anchoring never disturbs the signed bytes or the chain.

The envelope's vocabulary is adopted, with citations, from published peer formats, and its divergences are stated rather than hidden. Field names follow the Acta receipt vocabulary (policy_digest, issued_at, issuer_id, previousReceiptHash), the typed links[] relation vocabulary is seeded from the EP-AEG registry, and the digest tags follow the domain-separation pattern of the APS payments drafts. Three divergences are normative: receipt chaining digests cover the signatures and exclude the unprotected slot, where Acta pins the signature inside, because mutable countersignatures must never break a successor; signature values are base64url rather than hex, for JSON-native size; and timestamp authority follows the Sello design^[52], with a verifier preferring the transparency log's integrated time over the self-asserted issued_at, which is a backdating defense rather than a formality.

The posture behind the envelope is verify-their-format. Where a peer format is published, the response is to build verifiers and adapters of the published text rather than to negotiate one, and no alignment decision waits on anyone's reply: the ratified text records that every decision was self-resolved from the published drafts, with outreach retired unsent. The catalog behind this posture collapses to three action lanes, build from published specs, build verifiers of published formats, and watch, because a lane that assumed counterparties would respond was a lane that could silently gate nothing else.

8 · The Agent Interaction Model

OCG is built for two readers at once, a human at a page and an agent at a protocol. The human face of a capability is a tool, a single self-contained page. The machine face of the same capability is a node, an entry in the catalog with a stable identifier, an MCP tool name, an input schema, and the promise to emit a hash-anchored artifact. The two are the same computation behind two interfaces, and they share the same kernel.

8.1 · Discover, plan, call, verify

An agent works the catalog in four steps. It discovers nodes by reading the DCAT catalog, which lists every node, its inputs, and its consumes and feeds edges. It plans a chain by following those edges, ordering the nodes so that each one's inputs are available before it runs. It calls each node over MCP, passing inputs and receiving a complete artifact, including the execution hash, in a single round trip through the server compute path. It verifies by recomputing the hash, or by checking an attached attestation, before it acts on the result or passes it downstream.

8.2 · One round trip to a verifiable result

Compute binding is what makes step three cheap for an agent. Because the kernel runs server-side as well as in the page, the agent does not need to drive a browser or scrape a result; it calls the MCP tool, the server executes the same kernel, and the response is the artifact the page would have produced. The export tool is exposed the same way, as a single read-only call that takes a full artifact and a format and returns the rendered bytes, so an agent can obtain a filing-ready document without leaving the protocol.

The machine face also answers the inverse question. A verify_receipt meta-tool takes any Evidence Envelope receipt and verifies it offline: it recomputes the canonical digest, checks every algorithm-prefixed digest field, verifies the Ed25519 signature against the issuer's did:key, and walks the previousReceiptHash chain, returning a structured verdict rather than prose. A counterparty's receipt is therefore checkable with no trust in the sender and no custom code, over the same protocol the agent already speaks, and a receipt of a refusal verifies exactly like a receipt of an execution.

8.3 · A note on vocabulary

There is one collision worth flagging for MCP-native readers. In MCP, the callable thing is itself called a tool. OCG re-layers that word, using tool for the human page and node for the agent surface. The distinction is deliberate, because the two faces differ in real ways, but it is bespoke, and a reader who lives in MCP's vocabulary should keep it in mind.

8.4 · The page itself as an agent surface

MCP reaches an agent that speaks the protocol from outside the page. A newer, complementary surface reaches the agent that is already in the user's browser. Following the WebMCP draft of the W3C Web Machine Learning Community Group, a tool page can register its own compute entry function as an in-page tool: the page calls document.modelContext, with a navigator.modelContext fallback for earlier builds, publishes an input schema synthesized from the same form fields the human sees, delegates execution to the same function the form's submit uses, and marks the tool read-only. The registration is feature-detected, so a browser without the API renders a byte-identical page. 106 pages carry registrations (a derived sentinel counting the registration calls themselves, so the figure tracks each tranche as it lands); the first three were a qualified-mortgage points-and-fees test, a Regulation Z threshold lookup, and a certified-payroll recompute. Each registered name is the node's existing MCP tool name, so the uniqueness the catalog already enforces carries over to the in-page namespace unchanged. For scale on the protocol side, the live MCP endpoint currently registers 718 server-side compute tools alongside the catalog-search and workflow utilities.

8.5 · The human handoff

The interaction model above serves the agent. The person the agent works for needs a fourth surface, because an artifact that arrives as raw JSON in a conversation is evidence only in principle. The reference deployment closes this loop with a link: chain and export responses include an address whose URL fragment carries the complete artifact, compressed and encoded, small enough that a typical artifact fits in a shareable link. Opening the link loads a statically hosted verification console that stores records only in the reader's own browser, recomputes the execution hash, checks any signature, replays every gate decision against the recorded outputs, and surfaces timestamp evidence, with nothing transmitted to any server. Because the fragment never leaves the browser and the console holds no accounts and no storage of its own, the handoff adds no party to the trust model: the artifact remains the database, and the console is only a reading device. The same console accepts pasted or dropped artifacts from any conformant producer, including the sister deployments of Section 11, so a counterparty handed a receipt can check it without installing anything or trusting the sender's infrastructure.

9 · Conformance by Construction

A standard that exists only as prose drifts away from its implementation. OCG's central methodological claim is that conformance is defined by an executable gate suite and not by prose. The normative specification carries a matrix in which every normative rule names at least one gate, an on-disk script that checks it. A meta-gate parses that matrix and fails if any rule lacks a wired gate, so a contributor cannot add a requirement to the standard without also wiring the automation that enforces it. Stated plainly, a rule with no live gate is not part of the standard.

9.1 · What the gates cover

The suite spans the canonicalization lints of Section 3.1, schema validation of the envelope and the catalog node object, an offline test that confirms a kernel's buildArtifact reproduces its own hash, a single-version-of-record check that every public surface declares the same standard version, catalog and surface parity checks that every node has a page and every count agrees, a uniqueness check on MCP tool names, chain-integrity validation, and, for the version-0.6 attestation layers, sign-and-verify round trips, tamper detection, determinism, and backward-compatibility checks. A subset runs after deployment against the live endpoint. A sweep re-verifies that every deployed node still recomputes a valid hash, and a smoke test performs a real protocol handshake, because a green build does not prove that a live endpoint answers.

9.2 · The incident that motivated it

The discipline is the institutional response to a real failure, in which a canonicalization rule was documented but had no end-to-end gate that exercised it on the deployed surface, and several implementations drifted to incompatible hashes before anyone noticed. The remediation consolidated all hashing onto one shared canonicalizer, added the forbidden-construction lint, and, most importantly, added the meta-rule that a normative requirement without a gate is rejected at review time. A related class of failure, the documented-but-not-executed gate, is guarded the same way: a unit test can exist in the tree yet never run, so the release pipeline now invokes each attestation gate explicitly, and during the preparation of this paper one such gate was found to be present but unwired and was connected to the pipeline.

A second incident hardened the proof layer by the same method. An August 2026 sweep found a set of nodes whose compute-integrity receipts were cryptographically valid yet vacuous: the guest had committed an empty output object, the coverage gate accepted any non-null object as a journal, and the checker therefore shared the exact defect of the thing it checked. The response was a gate that does not classify but re-executes: it runs each proven kernel from the bytes on disk, inside the same sandboxed engine the guest is pinned to, over the node's published conformance vectors, and requires the recomputed output to canonicalize byte-for-byte to the receipt's committed journal (scripts/check-recompute-equality.mjs). Receipts that fail to reproduce are quarantined by name in a committed register that records an observed cause for every entry and is permitted only to shrink: no node is ever excluded by a rule, only by name, and if a quarantined receipt starts reproducing the build fails until its entry is deleted, so the register cannot outlive the defect it records. Re-proving a node retires its entry in the same push that attaches the replacement receipt, and the heaviest such re-prove is the checkpointed receipt of Section 6.3; the register still holds the entries whose replacements have not yet been produced, each with its recorded cause, and that residue is stated here rather than rounded away.

10 · Threat Model and Trust

The property the base layer defends is integrity of derivation. Given an artifact, a verifier can establish that the recorded output is what the recorded kernel produces from the recorded inputs. Stating the adversary makes the boundary precise.

10.1 · Adversary and defenses

Consider an adversary who can present an artifact and can tamper with any field in it, who can stand up a server that returns artifacts, and who may have stolen a signing key. The base layer detects any modification of inputs, output, or chain edges, because each of those changes the hash or breaks a cited parent hash. It does so without trusting the producer, because the verifier reproduces the hash locally. What the base layer does not defend follows just as precisely. It does not prove the inputs are true, so an adversary who feeds false but well-formed inputs gets a faithfully hashed false conclusion. It does not prove which kernel ran, which is the gap kernel identity addresses as a published claim and the compute-integrity proof addresses cryptographically. It does not prove a human acted on the result. And it provides no confidentiality at the base layer, because reproduction requires the inputs.

10.2 · Specific attacks

• Input or output tampering. Detected at L1. Any altered preimage member changes the hash, and any altered upstream artifact breaks the child's parent-hash citation.
• Kernel substitution. A server that runs different code than it claims is not caught by L1 alone. Kernel identity (Section 6.2) surfaces it as a digest mismatch when the source is checkable, and the compute-integrity proof (Section 6.3) rules it out cryptographically by binding the image identifier of the program that actually ran.
• Replay and substitution of a valid artifact. The artifact is bound to its inputs and to its parents, so reusing it in a context with different inputs fails the parent-hash and journal checks. Binding an artifact to a wall-clock or a nonce, where that matters, is done by folding the value into policy_parameters so the hash anchors it.
• Key compromise at L2. A stolen signing key lets an adversary forge attestations, which is the standard key-custody risk the signature layer inherits. It does not let the adversary forge a correct derivation, because L1 still requires the output to reproduce from the inputs. This is the reason the signature is an addition to, not a replacement for, the hash.

10.3 · Privacy posture

The default posture is anonymous. Inputs stay client-side and contain no personally identifiable data, and a base artifact names no one. Each attestation trades some of that anonymity for a stronger claim. A signature links a run to a key, and a compute-integrity proof links it to a published program identity. Both are therefore default-off, and a tool that offers them must surface the trade so a user chooses it knowingly rather than inheriting it silently.

10.4 · The five guarantees, named

The layers of Sections 4 through 6 can be read as five plain guarantees an artifact offers a downstream party, which the reference deployment names with the initials SWORN. An artifact is Signed when it carries the optional Data Integrity proof of Section 6.1, Warranted when a kernel-identity or compute-integrity attestation (Sections 6.2 and 6.3) binds it to a named program, Ordered when its chain edges and gate decisions (Sections 5.1 and 5.6) fix the sequence that ran, Replayable when the base execution hash lets anyone recompute it (Section 4), and Named-humans when a passkey signature envelope (Section 6.6) ties a moment to a real signer. The five are a reading aid for guarantees this paper already defines, not a new mechanism, and they are meaningful only in combination: no single initial is a standalone claim, and an artifact asserts only the guarantees whose layers it actually carries. The category the combination describes is verifiable work infrastructure.

The framing also marks a boundary against an adjacent class of system. Durable-execution engines such as Temporal, Restate, DBOS, and Cloudflare Workflows persist every step of a workflow so it can resume after a failure, but as of mid-2026 those persisted steps are unsigned operational state rather than portable evidence. Durable execution remembers; SWORN proves. The two compose cleanly, with durability living under the receipt layer rather than beside it, which is the direction the reference deployment takes when it runs a chain on a durable-execution substrate.

11 · Deployment and Evaluation

OCG runs in production, and its claims are reproducible from public catalogs. The reference suite, AINumbers.co, exposes 590 browser-native tool pages and registers 661 OCG nodes wired into 368 chains, 64 of them gated, backed by shared deterministic kernels and a live MCP endpoint that registers the nodes alongside interactive widgets, prompts, and utilities. The same standard, the same envelope, the same hash rule, and the same canonicalizer are deployed without modification on two sister sites in unrelated fields, and since this draft's first revision both sisters have completed the climb from envelope-only conformance to the full ladder, including real compute-integrity receipts of their own.

11.1 · Domain generality is the result

The cross-domain spread is the substantive finding. A finance compliance verdict, an education-financing return estimate, and an astrophysical mass constraint share nothing in their domain vocabularies, yet each emits the same hash-anchored, recomputable, agent-callable artifact. The standard is therefore not tuned to finance; finance is simply where it was first built out in depth.

11.2 · An adversarial case for over-claiming

The astrophysics deployment is worth dwelling on because it stresses the design against the temptation to overstate. Its tools separate a peer-reviewed register, meaning citable published science, from a speculative register, meaning engineering extrapolation beyond established results, and they label every tool accordingly. Its flagship evidence ledger aggregates competing lines of evidence for and against an intermediate-mass black hole in Omega Centauri using a Bayesian log-odds account, and it deliberately preserves an unresolved tension between two published mass bounds rather than collapsing them into one convenient number. A provenance standard ought to make that kind of epistemic candor easy to express, and the same hash-anchored artifact that records a compliance decision records "here is the evidence, here is the weighting, here is the result, recompute it yourself" equally well.

11.3 · Operational gates

Every deployment is gated. The full conformance suite runs before publication, and after each deploy a sweep re-verifies that each live node recomputes a valid hash and a smoke test confirms that the agent endpoint completes a real handshake. The suite also enforces a single version of record across every public surface, so the version a human reads on the specification page, the version a machine reads from the schema, and the version the catalog declares cannot drift apart silently. The same gates are mirrored shift-left: a local preflight runs every hard gate in the pipeline's order before a push leaves the machine, 224 gate entries at this revision, wired into a committed pre-push hook so a red tree does not reach the pipeline at all; among them are editorial gates that hold the reader-facing prose of every public page to the same ratchet discipline as the code.

11.4 · Measured costs

The ladder's economics can be stated from measurement rather than estimate, because every rung is exercised on the deployed suite. The numbers below come from the production pipeline that generated the live receipts, with the prover's development mode disabled, so none of them is a mock.

The asymmetry in the table is the design working as intended. Proving a receipt costs minutes, once, off-line, which is around five orders of magnitude above the milliseconds-scale execute-and-verify cost and consistent with published zkVM characterizations^[14][36]. Verifying that receipt costs milliseconds, every time, forever, against a 256-byte seal. The base layer inverts the trade: production is free and verification bears the re-execution cost, which for these kernels is also milliseconds. A deployer chooses the rung whose cost profile matches the workflow, which is the entire argument of Section 6.

11.5 · Decision receipts in regulated workflows

The most recent build program is the sharpest test of the standard's premise, because it targets workflows where a third party has a legal reason to check the math. The suite now covers straight-through decision procedures across United States mortgage compliance, including an actuarial annual percentage rate engine under Regulation Z Appendix J and the disclosure-tolerance and qualified-mortgage tests that consume it; fair-lending and adverse-action screening; consumer remittance disclosure arithmetic under Regulation E; record-keeping structures aligned to the EU AI Act's logging article^[39]; cross-border payment prevalidation for the ISO 20022 migration; parametric insurance trigger adjudication; corporate treasury procedures including hedge-effectiveness documentation; and compensation-integrity checks. Each cluster follows one pattern. Regulatory thresholds that change by rulemaking, such as the annually adjusted qualified-mortgage fee tiers, ship as version-pinned fixture tables that carry their source citations, so the audit question of which year's figures a decision used is answered by the artifact rather than by the operator's memory. The procedures that branch, such as a fail-fast points-and-fees test or a trigger evaluation that routes to a payout branch, run as gated chains under Section 5.6, so the branch taken is part of the evidence. And the receipts that need a provable moment, such as a hedge-effectiveness test whose accounting treatment depends on contemporaneous documentation, attach the timestamp bindings of Section 6.6.

The same program supplied a test of the verification culture rather than the machinery. A 2026 audit pass that compared each node's narrative against the primary record found the Regulation Z threshold nodes citing six Federal Register locators that were all wrong, one of them resolving to a different agency's unrelated notice, alongside figures that were correct in most cells and stale in others. The correction was retrieved from the primary sources, pinned cell by cell in a reviewed specification, applied mechanically with an explicit instruction that a disagreeing implementer must stop and report rather than substitute a figure, and re-proved. Two lasting disciplines came out of it. Figures that a rulemaking updates are now recorded as dated observations, naming the source and the date the value was read, rather than as timeless constants. And the silent-fallback shape is now detected mechanically: a year-keyed table lookup that quietly answers an out-of-range year from a default row is linted and ratcheted toward zero across the kernel fleet (scripts/check-year-fallback-parity.mjs), because a wrong answer that looks retrieved is worse than an error.

11.6 · Cross-vendor depth, upgraded

The first revision of this paper could claim only that three sites shared an envelope and a hash rule. The claim is now stronger in kind. Both sister deployments completed the full migration to the 0.8.0 release: frozen-envelope artifacts, the canonical hash, the conformance gate suite in their own release pipelines, kernel-identity stamps, gated chains, and real Groth16 receipts produced on the same universal guest, seventeen of them on the education suite and a proven flagship set on the astrophysics suite, whose evidence-ledger receipt attests the same Bayesian computation its browser page performs, byte for byte. The education suite also now hosts a cross-industry showcase implementing exemplar nodes from the standard's industry concept catalog^[20] outside finance and science. A verifier holding artifacts from all three vendors checks them with one procedure and, where receipts are present, one pairing-check verifier, which is the cross-vendor promise of Section 5 demonstrated at every rung of the ladder rather than only at the base.

11.7 · Mechanical verification of the contract layer

The conformance suite of Section 9 checks the standard's rules against each artifact. A second, separately tracked ladder checks the contracts between composed steps, and it now returns real numbers rather than a promise. The checker (scripts/check-chain-l2-contracts.mjs) runs against the live catalog on every push and evaluates three contract classes per workflow: gate contracts, meaning a conditional step's routing rule reads a field whose producer publishes a decidable domain (the Section 5.6 guarantee, checked rather than assumed); shared-input coherence, meaning steps fed from the same input use it consistently; and provenance threading, meaning parent citations carry what the composition declares.

The checker's current figures are printed here as derived count sentinels, regenerated from the checker itself on every release and policed by the count-drift gate, so this paragraph cannot silently outlive the numbers it quotes. Gate contracts: 74 gate rules in scope, decided 3 pass, 2 fail, 69 indeterminate. Shared-input coherence: 17 chains pass, 2 fail, 86 indeterminate, over 180 shared input fields examined estate-wide. Provenance threading is not applicable to any workflow today, because the field-map model it would check has no instances in the deployed estate. Most gate rules are indeterminate at this writing: each indeterminate verdict carries a recorded reason, most waiting on a producer manifest that declares the domain a gate reads, and the checker derives the authoring worklist that would decide them. The failures are stated as failures; an earlier revision of this paragraph shipped hand-typed figures from a stale tree that reported zero failures where the record showed two, which is exactly the defect the sentinels now make impossible.

The boundary of the claim is stated by the checker itself and repeated here. This is a check of declared assume-guarantee composition only: no kernel is executed in the process, and it is not a claim of formal verification, which for these workflows remains future work. The dataflow note matters just as much: the deployed workflows are provenance-linked bundles of independently parameterised kernels rather than data pipelines, each step's inputs coming from the recorded input set or a fixture rather than from the previous step's output payload, so the checker validates the couplings that exist and not a producer-to-consumer field map. An indeterminate verdict is a distinct state in this reporting: it is never folded into a pass and never displayed as one.

12 · Limitations

A standard that lists only strengths is not credible. OCG does not do everything, and it should not be sold as if it does.

13 · Future Work

Three directions are concrete. The first continues the compute-integrity layer. The transcendental-math item reported in earlier drafts is done: a shared deterministic math implementation now serves both the browser engine and the guest, and the affected nodes carry receipts. The remaining items are to exercise the input-hiding mode of Section 6.4 on a real high-value node rather than only specifying it, and to enable server-side did:web signing for stable institutional issuers. The second direction extends decision gates. The 0.8 comparator set is deliberately minimal, and the natural next steps are a strictly specified expression subset in the tradition of deployed rule languages that achieved cross-platform determinism, and decision tables as first-class, hash-pinned artifacts, so that a rating grid or a regulatory threshold table is content-addressed the same way a kernel is. The third direction extends anchor bindings with stateless renewal in the style of evidence-record syntax, so a binding whose authority chain nears expiry can be re-anchored without any service holding state.

The second direction is likely to interest a broader audience, namely applications outside finance. The same primitive, a recomputable, hash-anchored, chainable artifact, generalizes well beyond compliance. Candidate areas include reproducibility ledgers for scientific results, where a published figure cites the artifact that produced it, a direction the ACM's artifact-review and badging program already rewards^[34]; provenance for physical supply chains and trade documents, where each handoff is a node; content authenticity for AI-generated media, where a disclosure is an artifact rather than a watermark; and replayable state for games and generative art, where a seed and its derivation are the artifact. We maintain a catalog of these concept clusters and the OCG primitives each one uses^[20], and the education-suite showcase of Section 11.6 has begun implementing exemplars from it as live nodes. Each is an opportunity to test whether browser-native, recompute-to-verify provenance fits where heavier verifiable-computation stacks have been too costly to adopt.

14 · Conclusion

OpenChainGraph takes a well-understood pattern, hash-anchored recompute-to-verify provenance, and applies it to a problem the agent economy has only recently made urgent: decisions that one party produces and another, sometimes an autonomous agent, has to trust independently. The base layer asks for the smallest plausible trust assumption, deterministic recomputation in the verifier's own browser, and adds named-key attestation, zkVM compute-integrity, independent timestamp evidence, and hash-bound conditional execution as opt-in, additive, backward-compatible layers, never a hardware enclave and never a blockchain. It is enforced by an executable conformance suite rather than by prose, and it is deployed across three unrelated fields and more than 830 tools (Table 4), with real compute-integrity receipts on all three. It is not a new cryptographic primitive, it does not prove that inputs are true, and it says both of those things plainly. What it offers is a small, candid, browser-native unit of verifiable decision provenance that an agent can discover, call, and check, and that a third party can re-establish without trusting anyone.

Acknowledgment of AI Assistance

In the interest of transparency: drafting, citation verification, derivation checking, and figure preparation were performed with substantial assistance from a large language model (Claude, Anthropic), under the author's direction. The author reviewed and takes full responsibility for all claims, derivations, and references.