Written for engineers implementing agent payment flows who want to check their code against fixed, recorded values. The AINumbers kernels publish golden test vectors as JSON fixtures in the public repository: each vector records the inputs a node accepts, the exact output a recorded run produced, and a hash over both. Take the inputs, run them through your own implementation, compare the output, recompute the hash. This page explains what the vectors are, lists the nodes that publish them, and walks through the comparison step by step. For the replay workflow against exported Policy Mandates, see the mandate regression replayer.
A test vector is one recorded case: a fixed input and the exact output the kernel returned for it. The vectors live as fixture files in the public repository under chaingraph/kernels/fixtures/, one file per node: chaingraph/kernels/fixtures/. Each file holds a vectors array, and every vector carries five fields:
name, a stable identifier for the case; note, a short provenance comment; policy_parameters, the exact caller-supplied inputs the node accepts; output_payload, the exact output the recorded run produced; and golden_hash, a SHA-256 digest over both of those objects.
The digest comes from chaingraph/kernels/_hash.mjs, the single canonicalization the project uses for every execution hash: RFC 8785 (JSON Canonicalization Scheme) over the object {policy_parameters, output_payload}, hashed with SHA-256 and rendered as lowercase hex. There is exactly one canonicalization. Two implementations that produce the same output but canonicalize differently will produce different hashes, so the hash is also a check on canonicalization.
Nine agent-payment and agent-identity nodes publish conformance fixtures. The vector counts below were read from each fixture file at repository commit d6f955621; the standards basis column quotes each node's standards_basis field from chaingraph.json verbatim, and one node declares no such field, marked not stated. The protocols each node implements are named in its description.
| Node | Fixture file | Vectors | What it computes | Standards basis |
|---|---|---|---|---|
| x402 EIP-712 Digest Recomputerart-590-x402-eip712-digest-recomputer | art-590-x402-eip712-digest-recomputer.fixtures.json | 5 | Recomputes the EIP-712 typed-data digest for an EIP-3009 TransferWithAuthorization struct, the authorization primitive under the x402 rail. | not_applicable |
| x402 Signer Recovery Verifierart-591-x402-signer-recovery-verifier | art-591-x402-signer-recovery-verifier.fixtures.json | 7 | Recovers the ECDSA signer address from a supplied EIP-712 digest and an (r, s, v) or (r, s, yParity) signature. | not_applicable |
| x402 Domain Nonce Window Checkerart-592-x402-domain-nonce-window-checker | art-592-x402-domain-nonce-window-checker.fixtures.json | 8 | Checks an EIP-3009 authorization's domain fields and replay window against caller-supplied expectations. | not_applicable |
| AP2 CartMandate Hashchain Builderart-595-ap2-cartmandate-hashchain-builder | art-595-ap2-cartmandate-hashchain-builder.fixtures.json | 4 | Builds an AP2 CartMandate verifiable credential skeleton whose subject carries a deterministic hash chain over ordered cart lines. | not_applicable |
| AP2 x402 Cart Correlationart-596-ap2-x402-cart-correlation | art-596-ap2-x402-cart-correlation.fixtures.json | 6 | Correlates a built AP2 CartMandate against x402 spend evidence: cart totals, merchant identity, and amount agreement. | not_applicable |
| x402 Permit2 Evidence Recomputerart-699-x402-permit2-evidence-recomputer | art-699-x402-permit2-evidence-recomputer.fixtures.json | 26 | Recomputes the Permit2 typed-data digest a payer wallet signs for an x402 payment, across the exact and upto schemes. | implements_standard |
| Mandate Authorization Gateart-703-mandate-authorization-gate | art-703-mandate-authorization-gate.fixtures.json | 17 | Gates a proposed payment against a mandate, budget, and rail state, in authorize and verify modes. | not_applicable |
| Agent OBO Mandate Validatorart-151-agent-obo-mandate-validator | art-151-agent-obo-mandate-validator.fixtures.json | 3 | Validates an agent on-behalf-of mandate: represented subject, bounded scope array, intent string, and validity window. | not stated |
| KYA x402 Scope Verifierart-565-kya-x402-scope-verifier | art-565-kya-x402-scope-verifier.fixtures.json | 3 | Cross-checks a KYA credential's declared scope against an x402 PaymentPayload: spend cap, network and asset allowlists, and payee. | not_applicable |
Node pages are on this site; fixture files are in the public repository, where the recorded values live. Nothing on this page transmits data anywhere: the files sit in a git repository and your comparison runs entirely in your own environment.
policy_parameters object verbatim, with every field and value exactly as recorded.output_payload field by field: field names, value types, and value formats all count. A field-by-field comparison is stricter than a parsed-equality check and is the one that detects representation drift.{policy_parameters, output_payload} with the RFC 8785 rule that chaingraph/kernels/_hash.mjs implements, hash the canonical bytes with SHA-256, and compare to golden_hash. If your output matched and your hash differs, your canonicalization differs. The simplest way to rule that out is to import _hash.mjs rather than reimplement the canonicalization.Step 4 is deliberately narrow: the hash covers exactly the two recorded objects and nothing else, so a match on both steps pins your implementation's output and your canonicalization at the same time.
A match is a reproducibility result. It means your implementation, given the vector's policy_parameters, returned output equal to the recorded output_payload field for field, and that a hash computed the project's way over those two objects equals golden_hash. A match also tells you your canonicalization agrees with _hash.mjs.
A match carries no conformance claim about any standard, protocol draft, or regulation, and it says nothing about behaviour on inputs the vectors do not cover. The vectors cover the cases they cover: their number and subject are in the table above. Publication of the vectors expresses no opinion about any implementation, and no relationship between any implementation and this site follows from a match.
If your output differs from output_payload on inputs you copied verbatim, or your recomputed hash differs from golden_hash while your output matches, check your canonicalization against _hash.mjs first. If the recorded values themselves look wrong, open an issue on the repository's public issue tracker with the vector name and fixture file, your output, and your computed hash. A suspected error in a recorded vector is handled like any other repository defect: it gets checked against the kernel and fixed in the fixtures if it is wrong.