How receipt conformance works

Conformance is a statement about a format, and it is deliberately narrow: a stated input and output pair hashes to the stated execution_hash under the formula below. That is the whole claim. It does not say a kernel's business logic is correct. It says nothing about a proof attached at compute_proof or audit_signature.proof, and it makes no claim about AINumbers' live service. Those are separate, larger questions with their own evidence surfaces.

The corpus and the verifier behind this page were extracted from the normative specification so that a party with no interest in AINumbers code can check the receipt format independently. Every vector in the corpus is a real pair produced by a real, shipped decision kernel, named in the manifest's source field. None are hand-invented.

Every OpenChainGraph receipt carries an execution_hash, and the hash has exactly one definition:

Only the receipt's own policy_parameters and output_payload enter the hash. Canonicalization recursively sorts every object's keys by Unicode code point, keeps array order unchanged, and serializes with minimal whitespace; for the practical JSON subset the vectors use (finite numbers, no integers past 2⁵³) this reproduces RFC 8785 output exactly. The SHA-256 runs over the UTF-8 bytes of that canonical string, rendered as lowercase hex.

Any implementation in any language that sorts keys, serializes to minimal-whitespace JSON, and runs SHA-256 over the UTF-8 bytes will reproduce the same execution_hash for the same input pair. On 2026-09-21 the corpus was cross-checked between two independent implementations: the site's JavaScript canonicalizer and verify.py's Python canonicalizer reproduce identical canonical hashes on every vector, including a float-heavy one where a naive Python float rendering would disagree with ECMAScript.

One entry from vectors/manifest.json, verbatim as of September 2026. A conforming implementation reproduces the final hash from the two files and nothing else.

The two canonical hashes exist so a new implementation can agree on canonicalization before touching hashing: if your canonicalizer disagrees at check 3, your hasher is not yet implicated.

git clone https://github.com/PostOakLabs/ainumbers
cd ainumbers
python3 ocg-conformance/verify.py            # 9/9 vectors, exit 0
python3 ocg-conformance/verify.py --quiet    # summary line only

Provenance is a separate, complementary check: node ocg-conformance/derive-vector.mjs <id> --check re-runs the named kernel on its recorded input and proves the committed pair against the result. The manifest was last regenerated on 2026-09-22, when the art-09 and art-34 vectors were re-derived after a kernel field-name fix had left them stale.

A party that is not AINumbers submits its own kernel's conformance vector as one pull request that touches a single new directory, ocg-conformance/third-party/<your-slug>/: a submitter.json (display name, contact URL, verified GitHub identity, a reverse-DNS namespace derived from it), a manifest.json carrying the same four hash fields the house corpus uses, and the input/output pair itself. Reverse-DNS naming means two submitters can name a kernel identically without colliding. Both schemas ship in the kit, together with example-submitter/, a hand-authored worked example under GitHub's octocat demo account that round-trips end to end.

Every submission carries a machine-readable conformance witness and a trust disclaimer pinned by JSON Schema as a const, so it cannot be paraphrased or dropped:

Validate before you open the pull request: node ocg-conformance/third-party/validate-submission.mjs your-slug checks both schemas, the namespace binding, and every vector's hashes, recomputed through the same canonicalizer the estate's kernels use. Submissions are reviewed as ordinary pull requests today; the auto-check workflow and the generated roster row for submissions are specified in the kit's README as follow-up rows and have not been built yet, which is also why each shipped witness carries status: pending.

The conformance roster keeps the dated list of implementations and their gate-suite results, run and quoted rather than asserted. The house corpus currently stands at nine vectors, all passing; the roster records AINumbers' own §15 gate-suite results against the same specification.