The emerging agent economy lets autonomous software discover and invoke third-party tools across organizational boundaries. When those tools make consequential decisions, such as a compliance verdict, a capital calculation, or a payment authorization, the consumer needs to know not only what was returned but that the result follows from stated inputs by a stated procedure, and to re-establish that fact later without trusting the producer. Existing provenance systems address adjacent problems. Software-supply-chain frameworks attest builds. Data-lineage systems track movement. Verifiable-credential systems bind claims to keys. None of them targets recomputable decision artifacts that are produced and verified inside a commodity web browser and are callable by an AI agent over a standard protocol.
We present OpenChainGraph (OCG), an open standard for deterministic, hash-anchored decision artifacts. An OCG artifact commits its policy inputs and output payload under a single canonical execution hash, computed with WebCrypto SHA-256 over an RFC 8785 canonical serialization. Any party that re-runs the producing kernel with the recorded inputs recomputes the identical hash, which establishes integrity without a signature, a key, or a trusted third party. Artifacts cite one another by hash to form a provenance graph that recomputes end to end across vendors, and every node is exposed as a Model Context Protocol tool so that agents can plan and execute a chain. OCG layers progressively stronger guarantees as an opt-in ladder: recompute-to-verify at the base, a W3C Data Integrity signature above it, and, new in version 0.6, a zero-knowledge virtual machine compute-integrity proof that a verifier checks without re-execution and, when desired, without seeing the inputs. The standard is enforced by construction. Each normative rule is bound to an executable conformance gate, and a rule with no wired gate is, by definition, not part of the standard. We state the base-layer guarantee formally, as a reduction to hash collision resistance, argue from a requirements matrix that no existing provenance standard, nor a practical combination of them, targets this setting, and measure the cost of every rung of the verification ladder on the deployed suite. We report a cross-domain deployment of 659 browser-native tools across three independent sites, covering finance, education and career analytics, and observational astrophysics, all sharing one envelope, one hash rule, and one live agent endpoint. We are candid about the limits. Recompute-to-verify proves derivation, not input truth or human action; it requires inputs in the clear unless the zkVM layer is used; and the design composes public parts rather than introducing a new cryptographic primitive.
Keywords: verifiable computation; decision provenance; content-addressed artifacts; JSON canonicalization; zero-knowledge virtual machines; Model Context Protocol; agentic AI; RegTech; conformance-by-construction
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.
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.
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 and, new in version 0.6, a zkVM compute-integrity proof as additive, backward-compatible layers (Section 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 659 tools across three sites, with measured verification and proving costs (Section 11). Section 12 states the limits without softening them.
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.
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.
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.
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.
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.
| Ingredient | Prior art | How OCG differs |
|---|---|---|
| Hash-anchored, recompute-to-verify provenance | in-toto, SLSA[1][2] | Applied to decision artifacts, produced and verified in-browser |
| Computation provenance vocabulary | W3C PROV[3] | PROV envelope plus a binding hash over inputs and output |
| Chained verifiable computation framework | Trusted Compute Units[14] | Software only (no TEE), off-chain, recompute base layer |
| Signed cross-vendor receipts and mandates | AP2[11] | Computation-trust first; the key signature is optional |
| Lineage graph | OpenLineage[13] | Recomputable decision receipts, not movement observability |
OCG's mechanisms are recombinations of well-established results, and naming that lineage is part of honest 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.
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.6 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].
A reasonable reader should ask the skeptical question directly: the field has provenance standards already, so why another one? The honest 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.
| Requirement | in-toto / SLSA[1][2] | VC 2.0[6] | C2PA[12] | SCITT[29] | TCU[14] | OpenLineage[13] | OCG |
|---|---|---|---|---|---|---|---|
| R1 · Recomputable derivation | partial | no | no | no | partial | no | yes |
| R2 · Chaining by content address | partial | no | yes | partial | yes | no | yes |
| R3 · Browser-native produce + verify | no | partial | partial | no | no | no | yes |
| R4 · Agent-callable, artifact returned | no | no | no | no | no | no | yes |
| R5 · Keyless, ledgerless base | no | no | no | no | no | vacuous | yes |
| R6 · Additive strength | yes | partial | partial | yes | partial | no | yes |
| R7 · Executable conformance | partial | partial | partial | no | no | no | yes |
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.
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 }
}
execution_hash from the worked example in Section 3.3.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.
Several plausible-looking shortcuts produce hashes that look canonical but are not, and OCG forbids them by lint gate rather than by convention.
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.sha256: defeats the integrity claim while preserving its appearance.output_payload breaks recomputation for anyone who hashes what was actually stored.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.
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
art-04 with the same policy_parameters reproduces the same output_payload and therefore the same hash; the deployed verifier confirms the match.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.
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.
| Identifier | Answers | Current | Changes when |
|---|---|---|---|
spec_version (catalog) | which OCG release is this | 0.6.0 | every release |
chaingraph_version (artifact) | which schema to parse it with | 0.4.0 | only a breaking envelope change |
@context URL | which JSON-LD[41] vocabulary applies | v0.3 | only on a vocabulary change |
payloadType version | which signing-envelope shell | 0.2 | only on a DSSE shell 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).
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.
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.
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.
Producing and verifying in a commodity browser removes a backend from the trust story. There is no server to operate, no data egress, and no server-side state. The verifier's trust assumption shrinks to two clauses: SHA-256 is collision resistant, and my own browser executed the math. That is a smaller assumption than trusting the producer's infrastructure, and it is what makes the zero-egress, zero-PII posture credible rather than aspirational.
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.
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.
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.
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.
Recompute-to-verify has two honest 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.
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 honestly 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; the transcendental-math nodes of Section 6.3 mark exactly where that discharge currently falls short.
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.
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.
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.
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.
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 of roughly two hundred bytes 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.
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.
Version 0.6 moved this layer from defined to deployed. At the time of writing, 190 of the 191 deterministic compute nodes in the AINumbers suite 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 receipts were produced off-line from a single universal guest program, so one image identifier covers every node and each kernel's source is passed in as data, generated on one consumer graphics card over a few hours with the prover's development mode disabled, so the proofs are real rather than mocked. The remainder is stated rather than hidden. A few nodes whose results depend on transcendental math, where the last bits differ between the browser engine and the guest, are marked in the catalog as compute-proof-deferred with a reason, rather than given a receipt that would attest a number the live surface does not show. Closing them needs a single deterministic math implementation shared by both runtimes, which is tracked as future work in Section 13.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The discipline is not abstract. It 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.
Because the schema and the gates are the source of truth, conformance is a decidable property rather than a matter of interpretation. An implementation conforms if and only if it validates against the published schema and passes every gate. The prose in this paper explains; the gates decide.
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.
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.
policy_parameters so the hash anchors it.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.
| Mechanism | Proves | Hides inputs | No re-exec | Root of trust |
|---|---|---|---|---|
| OCG L1, execution hash | Derivation integrity | no | no | math (SHA-256) |
| OCG L2, signature[7] | plus named-key attestation | no | no | math plus key custody |
| OCG L3, zkVM proof[15][16] | plus correct execution | optional | yes | math (ZKP) |
| TEE attestation | Code ran in enclave | yes | yes | hardware plus vendor |
| On-chain ZKP[14] | Correct execution | often public | yes | chain consensus plus gas |
OCG runs in production, and its claims are reproducible from public catalogs. The reference suite, AINumbers.co, exposes 487 browser-native tools, of which 204 are OCG nodes wired into 228 chains, backed by 208 shared deterministic kernels and a live MCP endpoint that registers 228 agent-callable tools 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.
| Site | Domain | Tools | OCG specifics |
|---|---|---|---|
| AINumbers.co | Finance, RegTech | 487 | 204 nodes, 228 chains, 208 kernels, live MCP |
| ApexLogics.org | Education, career | 146 | Same envelope and hash rule, own MCP catalog |
| OmegaCentauri.me | Astrophysics | 26 | Peer-reviewed and speculative registers, Bayesian evidence ledger |
| Total | 3 independent domains | 659 | One standard, three vocabularies |
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.
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 honesty 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.
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 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.
| Quantity | Layer | Measured |
|---|---|---|
| Artifact size | L1 | a few kilobytes of JSON for a typical node |
| Native kernel execution | L1 | sub-millisecond for a typical kernel |
| Recompute-and-hash verification | L1 | milliseconds in a browser: one kernel re-run, one JCS pass, one SHA-256; the post-deploy sweep re-verifies every live node on every release |
| Signature generation and verification | L2 | milliseconds (Ed25519 via WebCrypto) |
| Receipt size | L3 | Groth16 seal over BN254, roughly 200 bytes, constant in the size of the computation, plus the public-output journal |
| Receipt verification | L3 | milliseconds, via the shipped zero-dependency pairing-check verifier, with no prover-vendor runtime |
| Guest execution | L3 | 4.5 to 7 million RISC-V cycles for the worked examples, under one universal guest image whose single identifier covers every node |
| Proving, single receipt | L3 | roughly four to twelve minutes, hardware-dependent |
| Proving, full fleet | L3 | 184 receipts in about five and a half hours on one consumer GPU (RTX 3080), under two minutes per receipt amortized |
The asymmetry in the table is the design working as intended. Proving a receipt costs minutes, once, off-line, which is roughly six orders of magnitude above the sub-millisecond native execution and consistent with published zkVM characterizations[14][36]. Verifying that receipt costs milliseconds, every time, forever, against about 200 bytes of evidence. 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.
A standard that lists only strengths is not credible. OCG does not do everything, and it should not be sold as if it does.
Two directions are concrete. The first continues the compute-integrity layer now that it is broadly deployed. The proving pipeline is wired and the self-contained pairing-check verifier is shipped, so the open items are narrower. The first is to close the last transcendental-math nodes, which need one deterministic math implementation shared by the browser engine and the guest so their results agree bit-for-bit. The second is to exercise the input-hiding mode of Section 6.4 on a real high-value node rather than only specifying it. The third is to enable server-side did:web signing for stable institutional issuers.
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 separate catalog of these concept clusters and the OCG primitives each one uses[20]. 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.
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 and zkVM compute-integrity 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 659 tools. 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, honest, 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.
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.