Verify it yourself.

Settles: Whether a receipt proves the action that ran was the action authorized.

Real receipts produced by executing against the protected receiver, not constructed for the file. ES256 over the compact form, raw 64-byte R||S, Base64Url. Each names the SHA-256 of the previous one, so a deleted receipt is as detectable as an altered one. One vector is a receipt whose amount was edited after signing; a verifier that reads the decoded payload without checking the signature accepts it, which is the mistake the file exists to catch.

Settles: What a protected resource must refuse, stated as inputs and expected outcomes.

Published before the resource existed, so the cases could not be written to match an implementation. Forged and altered grants, expired and paused authority, replays, mismatched parameters, alternate routes.

Settles: Whether a grant is genuine, current, and covers these exact parameters.

Signature material and canonical forms for the single-use grants issued by evaluation. ECDSA here is randomised, so signatures are not reproducible: verify, never re-sign to compare.

Settles: Whether two implementations hash the same action to the same value.

Canonicalisation vectors, including the ones that catch the errors this repository has already made. Predicate order does not change the hash; decimal scale does, because 13800.00 and 13800 are the same number and different strings, and a grant issued for one is not redeemable with the other.

Settles: What may cross the privacy boundary, and what may never.

Closed at every version: no additional properties, no free-text field of any name, no generic map. A requirement that appears to need one is a requirement for a new registered predicate type with exactly one deterministic evaluator.

Settles: Whether these files are enough to build against without reading the implementation.

Written from the conformance document and the vectors alone. It imports nothing from the platform, links no SDK and calls no service; its only dependency is node:crypto. Run it against the receipts above, or against your own. It trusts the signature rather than the file: a vector file edited to claim the tampered receipt should verify still fails. It does not make anyone an independent third party - the same people wrote the receipts and the verifier - but if it could not verify them, these files would be inadequate.

Settles: What 2AYE signs, with which algorithm, and which formats are frozen rather than exemplary.

Fourteen formats in five representations, with three timestamp conventions, three absent conventions and two algorithms. That is not presented as a design: each entry carries a compatibility status, and LEGACY_COMPATIBLE means the bytes must stay stable and a new format must not copy them. Published rather than tidied, because the alternative to admitting this is a cleanup that invalidates signatures somebody already relied on. No format may exist in runtime code without an entry; a build gate sweeps the source and fails otherwise.

Settles: What a new signed format must look like for five languages to agree on its bytes.

One representation for new authority objects, explicitly not applied retroactively. It forbids any dependence on serializer defaults, native number formatting, locale, machine timezone, map iteration order or platform newlines - each of which has a named failure behind it. The grant signature once carried a six-character escape where every other language emits one character, and no non-.NET verifier could reproduce it; that is the rule's first clause.

Settles: Whether an implementation agrees on the bytes, and whether it refuses what it should.

Three worked objects with digests, 85 scalar cases and 20 negative vectors across twelve categories: field order, decimal scale, timestamp reformatting, Unicode, collection order, casing, framing, unknown fields, absent semantics and domain separation. Cryptographic portability means proving inequality as well as equality, so the negatives include bytes that are valid for a different object rather than merely malformed - which is the case a parse error does not protect you from.

Settles: Whether the rules are complete enough to build from, and whether rejection means refusal.

Written from the specification alone with node:crypto and no platform code. It reproduces every accepted vector, refuses every rejected one, and checks that absent and empty do not collapse into each other - the single most security-relevant inequality in the document, because an implementation that merges them either widens a contract somebody locked or narrows every contract signed before a field existed.

Settles: Whether an approval, a contract signature or an attestation can be checked without our code.

The exact bytes a device, provider or executor signs, per family, with each one's raw input and digest. Inputs are untrimmed and in the caller's casing on purpose: an implementation has to apply the normalisation rules rather than receive values already normalised. Field order, hash casing and timestamp format differ per family here, and the vectors pin each as it is rather than as a uniform rule would have it.

Settles: Whether the statement specification is complete enough to build from.

Rebuilds every vector from its input in another language, with node:crypto and no platform code. It found nothing new, which is the point of running it; what it did settle is that one field cannot be published honestly - the capability statement's cost is a decimal, and the vector has to declare it as a string because JSON.parse turns 12.50 into 12.5 before any implementation sees it.

Settles: What the signed bytes are, and where they are irregular.

Eight versioned signed formats, specified by transcribing the implementations rather than by inferring the pattern. The last section is the four irregularities that transcription found, including one statement family whose fields are not sorted like the other six and one legacy shape that carries no domain separator at all. They are recorded rather than fixed: each alters bytes that existing signatures were made over.

Settles: What an implementation must do to be conformant, in normative language.

The MUST and SHOULD rules for admitting a grant and emitting a receipt, including the verification rule that matters most: verify over the compact form exactly as received, never over a reserialized payload.