Build against the schema. Check a sealed record yourself.

In plain terms: this page holds the specifications, test vectors and a checker that let a third party's engine produce a record against the schema, or let any reader check one, without asking Arkaya anything.

The Governance Evidence Taxonomy is the schema counterparties read. This pack is the layer beneath it: how a record is canonicalised, digested, chained and signed so that a reader who was not party to making it can check it. The Schema page explains what a record says. This page explains how one is sealed and how a reader tests the seal.

Status is stated on every file and it is literal. The specifications are in review and not yet ratified. The vector set and the conformance corpus are candidates. Nothing here is described as certified, established or recognised, because no party Arkaya does not pay yet relies on it. When that changes the status words change with it.

Retrieve from /get/v1/. Each entry carries its digest from MANIFEST.json in the profile's own form: base58-btc multibase over the multihash-prefixed SHA-256 of the bytes. Check the digest before you read the file.

• Cryptographic Profile v5. W3C Data Integrity, cryptosuite eddsa-jcs-2022, RFC 8785 canonicalisation, Ed25519. Section 8 states the proof-check procedure.
• Interface and Conformance Specification v4. The registered acceptance tests, including V-3: the check re-run with every Arkaya-operated domain blocked at DNS, which must return the same result.
• Candidate vector set v5. Seven records that must pass and fifteen that must fail, each failure with its stated reason. Forty-nine checks.
• xverify_v5.mjs. An independent checker in JavaScript, written against the specification rather than against the generator. Node 18 or later.
• generate_vectors_v5.py. The deterministic generator, so a reader can see how the vectors were produced.
• Reading-side conformance corpus, with reference_reader.py and run_fixtures.py.
• VERIFY.md, README.md, SECURITY.md.

Machine-readable index of all of the above, with digests, keys and the procedure as data: /.well-known/governance-evidence.json. A site index for agents is at /llms.txt.

You are not asked to trust that a record checks. You are asked to check it. What a proof check takes is the record, the public schema and the signer's public key, and the key travels with the record.

1. Take a record and remove its proof member. Canonicalise what remains with an RFC 8785 library. Canonical here means one thing only: the single byte form of a JSON value that RFC 8785 defines, so that two implementations hash the same bytes. SHA-256 the result. Prefix the multihash bytes 0x12 0x20, encode base58-btc, prefix z. Compare with the record digest, and with the previousDigest of the record that follows it in the chain.
2. Take the proof object, remove proofValue, canonicalise it. The signing input is SHA-256 of that, concatenated with SHA-256 from step one, in that order.
3. Decode proofValue and the key in verificationMethod. Check the Ed25519 signature over the signing input. A passing signature establishes what was sealed, not by whom; binding the key to a party is a separate question the record does not answer on its own.
4. All must pass. A record that fails says nothing about the control it describes; it is a record that cannot be relied on.

Two ready-made routes. In JavaScript: node xverify_v5.mjs vectors_v5_candidate.json runs all forty-nine checks. In Python: check_record.py runs the four steps on one record using jcs, base58 and cryptography. Nothing on either list is Arkaya's.

A specimen to start on: get-v1-specimen-record.json is vector V-01, the genesis record of the candidate chain, sealed with fixture key A. Its published digest is zQmQJtBuc2C4cwATu1LgXQkPs61Dbb6ybAVzEHREdnrw8Zx. Change one character of the body and re-run the check; it fails on the signature and the digest moves. The fixture keys are in fixture-keys.json; they are derived from fixed seeds and are never for production use.

The negative case worth running first is N-15: two strings identical on screen but different in Unicode composition produce different digests. The profile performs no normalisation, the producer fixes the form at record creation, and no reader can detect the difference afterwards. It is the divergence an implementer is most likely to introduce without noticing.

On 25 August 2026, in a clean build environment operated on Arkaya's own instruction, vector V-01 was reconstructed from the published vector set and checked with the Python route above. The canonical content matched byte for byte, the recomputed digest matched the published digest, and the Ed25519 signature checked against the key carried in the record. A copy with one word of the body altered failed on the signature, as N-01 requires.

That is what the check shows and no more. The script was written from VERIFY.md without Arkaya's code, but it covers one vector, not the suite, and it was run at Arkaya's direction, so it does not discharge the test the pack sets for itself: a second implementation, built without our code and without our help, returning the same outputs across the published set. Until a party Arkaya does not pay has done that, the honest description of every file here is registered, not recognised.

The GET schema as JSON. It exists at v4 and is hash-pinned. It is body vocabulary a reader interprets, not what an emitter validates to seal, and publishing it is a version act on the schema governance track. It follows once that act is taken.

The Evidence Record Specification, which defines the envelope an emitter emits. Also pending publication; the vectors show the envelope's shape in the meantime.

A production public key. There is none to publish. Arkaya does not sign records; the insured or its engine does, and the record states which. The only keys here are fixtures.

A key-rotation and revocation policy. How a reader years from now checks a record sealed today, after the signer's key has been rotated, is open work in the profile. The arithmetic survives, since the key travels with the record; the binding of that key to the party may not, and the profile does not yet say how that binding is preserved. It is stated as open rather than papered over.