@ziffer-io/types 0.1.0

package/dist/generated_wire.d.ts

@@ -0,0 +1,4466 @@
+import type { FidelityClass, Reversibility, Risk, SuiteId, TenantId, Tier, WebauthnAlg } from './generated.js';
+/**
+ * The two acts an acknowledgement can be. Closed enum: the reference refuses
+ * any other value at ACK-1 by name, before the signature is checked, because
+ * a third value would be an act with no defined consequence and the release
+ * path would have to guess at it.
+ * Generated from acknowledgement.schema.json#/$defs/ack_decision.
+ */
+export type AcknowledgementDecision = 'CONFIRM' | 'REPUDIATE';
+/**
+ * What an Attestation Object may declare as its suite: a machine suite
+ * (`SuiteId`, the set CR-4's floor is registered in) or a human key type
+ * (`WebauthnAlg`, HM-4's two, which CR-8 puts outside that floor). The two
+ * are declared once each, in the SIGNED root, and pointed at from here.
+ *
+ * WHY A UNION AND NOT A THIRD LIST. A single enum naming all five values is
+ * the obvious way to write this field and it is the defect this repository
+ * publishes corrections for. The names would then exist in three places:
+ * CR-4 compares an object's suite against `min_suite`, which is drawn from
+ * `signature.schema.json`, and HM-3 compares it against a `webauthn`
+ * registry entry's `alg`, which is drawn from `attesters.schema.json`. A
+ * comparison between a copy and its original passes on a vocabulary nobody
+ * checked -- `decision_receipt.alg` records the same argument for `SuiteId`
+ * alone, and CR-8's restriction is exactly what forbids the cheaper fix of
+ * widening `SuiteId` to five values: `webauthn-es256` and `webauthn-ed25519`
+ * MUST NOT appear as a bundle, receipt or door suite, and every other holder
+ * of `SuiteId` is one of those three positions.
+ *
+ * WHY THE GENERATOR ACCEPTS IT. `tools/codegen.py` reads a `oneOf` as a
+ * union it must be able to DECIDE, and refuses one it would have to resolve
+ * by trying branches until something fits. A tagged union of objects proves
+ * its discriminator from the schema; this one is proved a different way and
+ * the proof is just as mechanical: the branches are named enums and the
+ * generator halts unless their value sets are pairwise DISJOINT, so exactly
+ * one branch can match any given string and the decode is by value rather
+ * than by order. Adding a value to either declaration that already exists in
+ * the other turns the generator red rather than emitting a type whose
+ * meaning depends on branch order.
+ *
+ * BOTH BRANCHES CROSS ROOTS, AND ONLY A NAMED SCALAR MAY (ACP-78 M1). The
+ * signed side owns the vocabulary and the wire carries it, the same
+ * direction as `SuiteId`, `Tier` and `FidelityClass`. This type is
+ * nevertheless declared HERE rather than in the bundle root, because the
+ * union is a fact about a MESSAGE: no signed table holds a value that may be
+ * either, and a registry entry's `alg` is always exactly one of the two.
+ * Generated from attestation_object.schema.json#/$defs/attestation_alg.
+ *
+ * The two branches are declared once each, elsewhere, and the generator
+ * proved their value sets disjoint before emitting this union, so narrowing
+ * it by value is total: a string belongs to at most one branch.
+ */
+export type AttestationAlg = SuiteId | WebauthnAlg;
+/**
+ * AU-9's seven event classes, in pipeline order: a door refusing a
+ * submission (F1.1), a Decision passing or failing §9.3 (F6.1), a receipt
+ * refused at the Executor with the offending receipt attached (EX-3), a
+ * floor-HIGH action held (DR-1), an irreversible below-HIGH action's notice
+ * committed before execution (DR-13), a held action released or refused
+ * (DR-7/9/10, counted under DR-12), and what the target reported (EX-2).
+ * Generated from audit_record.schema.json#/$defs/event_class.
+ */
+export type AuditEventClass = 'ingress_refused' | 'decision' | 'verification_failed' | 'hold' | 'notice' | 'release' | 'execution';
+/**
+ * EX-2's four execution outcomes, plus `refused` for a `release` record
+ * whose DR-* check failed closed. Which values a class admits is §11.1's
+ * table, enforced by the consumer under AU-9; the enum is the union so one
+ * type serves both records.
+ * Generated from audit_record.schema.json#/$defs/outcome.
+ */
+export type AuditOutcome = 'executed' | 'failed' | 'not_attempted' | 'indeterminate' | 'refused';
+/**
+ * A byte string carried as text under WE-4: the ASCII `"b64:"` followed by
+ * RFC 4648 §4 base64, WITH padding. The URL-safe alphabet (RFC 4648 §5) and
+ * unpadded encodings are different values and MUST be rejected rather than
+ * normalized.
+ *
+ * The prefix is part of the value, not a label on it. §11.2 pins `sha256:`
+ * to the character and records why it had to -- an implementer who fed
+ * forward raw digest bytes built a different chain while following the text
+ * -- and WE-4 exists because the same hole was open on every `b64:` value
+ * through v1.3.17, where the string appeared only inside §9.2's diagnostic
+ * JSON and no clause said whether the prefix was part of what gets hashed
+ * and signed. Two spellings of one byte string are two values, and at a
+ * verifier the mismatch is indistinguishable from a forgery.
+ *
+ * This type carries no length bound: WE-4 governs the encoding, and the size
+ * of any particular value is the business of the clause that defines it.
+ * Generated from signing_request.schema.json#/$defs/b64_bytes.
+ *
+ * The schema constrains this to `^b64:(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$`, which is NOT enforced here.
+ */
+export type Base64Bytes = string;
+/**
+ * The three outcomes of the section 8.4 grading fold: ALLOW executes, ATTEST
+ * routes to a human quorum, DENY refuses.
+ *
+ * NOT ORDERED. These are outcomes, not a severity scale, and a derived
+ * comparison over them would invite `>= ALLOW`-shaped code that has no
+ * meaning. P-4 makes DENY the default for no matching rule, unknown
+ * capability, unclassified resource or unavailable Context Store, each with
+ * its own reason code -- so DENY is where the fold lands when it knows
+ * nothing, not the far end of a ranking.
+ *
+ * EO-1: HIGH MUST NOT be auto-allowed by any configuration; there is no flag
+ * that makes step 11 emit ALLOW for HIGH.
+ * Generated from decision_receipt.schema.json#/$defs/decision_outcome.
+ */
+export type DecisionOutcome = 'ALLOW' | 'ATTEST' | 'DENY';
+/**
+ * The two doors of deferred release. `presentation` is the Attestation
+ * Presentation Service (the approval path); `notification` is DR-2's
+ * independent path. DELIBERATELY NOT ORDERED: neither outranks the other,
+ * and the two-compromise argument needs both.
+ * Generated from notification.schema.json#/$defs/door_role.
+ */
+export type DoorRole = 'presentation' | 'notification';
+/**
+ * A 128-bit nonce: `"b64:"` followed by RFC 4648 §4 base64 WITH padding,
+ * carried, hashed and signed as that string (WE-4). The size is AT-1 for the
+ * attestation nonce and L-17 for the receipt nonce.
+ *
+ * THE PATTERN IS TWO RULES, AND THEY REFUSE UNDER DIFFERENT NAMES. `b64:`
+ * plus the RFC 4648 §4 alphabet with padding is WE-4, the wire type; the
+ * twenty-four characters are the 128 bits. A verifier folding them into one
+ * check answers `WE-4` for a 64-bit nonce, which is a perfectly well-formed
+ * `b64:` value — the wrong clause name, and the cross-language differential
+ * compares names. `reference/src/acp_executor.py` and
+ * `crates/acp-decision/src/quorum.rs` both apply the type rule first and the
+ * size rule second, in that order, because an object wrong in both ways must
+ * stop at the same rule everywhere.
+ *
+ * WHY THE PREFIX IS PART OF THE VALUE. `attestation_id` is SHA-256 over the
+ * canonical CBOR of the Attestation Object (AT-8a), so an issuer carrying
+ * `b64:AAAA…` and a verifier carrying `AAAA…` derive TWO IDS FOR ONE OBJECT
+ * and claim TWO LEDGER SLOTS — one human approval, spent twice. That is Z4
+ * and T-14 reopening through a type nobody had written down, reached with no
+ * optional field and therefore untouched by AT-8b, which closes the field
+ * set one layer above this. §11.2 pins `sha256:` to the character for the
+ * same reason and records what happened without it: an implementer who fed
+ * forward raw digest bytes built a different chain while following the text.
+ *
+ * HISTORY, KEPT BECAUSE IT IS THE ARGUMENT. When this schema was first
+ * written the prefix was pinned HERE and nowhere else — `b64:` occurred
+ * exactly twice in ZIFFER-SPEC-001, both times inside §9.2's diagnostic
+ * JSON, and no clause said whether it was part of the value. Writing the
+ * schema is what surfaced that (ACP-87); it is now fixed at the root as WE-4
+ * in v1.3.18, so this pattern restates the specification rather than
+ * exceeding it. A type that exists only in a schema is a type the
+ * specification does not have, and a second implementation written from the
+ * document alone would never have seen it.
+ *
+ * The three definitions of this type — here, the Python reference and the
+ * Rust verifier — DID diverge, and no gate noticed: this pattern pinned
+ * twenty-four characters from its first day while the reference accepted any
+ * length, and no fixture ever fed a wrong-length nonce.
+ * `tools/nonce-type-vectors.json` is now the one corpus all three are
+ * evaluated against, and `tools/check-nonce-type.py` resolves this `$def`
+ * rather than one field's inline pattern, so the corpus is evaluated against
+ * the type every nonce field shares.
+ *
+ * IT IS ONE TYPE AND IT LIVES HERE. ACP-78 M1 found FIVE definitions of it
+ * inside `spec/schemas/wire/` alone — an inline pattern on this object's
+ * `att_nonce` and on `PendingRelease.receipt_nonce`, and named copies in the
+ * audit record and the ledger claim — with the sentence above, saying the
+ * definitions must move together, sitting inside two of them. `$ref` it; do
+ * not restate it.
+ * Generated from attestation_object.schema.json#/$defs/nonce128.
+ *
+ * The schema constrains this to `^b64:[A-Za-z0-9+/]{22}==$`, which is NOT enforced here.
+ */
+export type Nonce128 = string;
+/**
+ * A party identity: the operator an action is attributed to, and the same
+ * value DR-9 compares an acknowledger against.
+ *
+ * NO CLAUSE TYPES THIS AND THAT IS THE POINT OF SAYING SO HERE.
+ * ZIFFER-SPEC-001 carries `operator`, attester identities and notification
+ * recipients as bare strings everywhere and states no syntax, no length and
+ * no namespace for any of them. The bound is DERIVED, not restated: an
+ * operator must resolve in the bundle's attester registry for AT-2
+ * approver-distinctness and DR-9 to be decidable, and
+ * `spec/schemas/bundle/attesters.schema.json` bounds that registry's keys at
+ * 1..128 — itself a schema-level choice with no clause behind it. So this is
+ * a schema constraint the specification does not make, in the ACP-87 shape:
+ * a type that exists only in a schema is a type the specification does not
+ * have.
+ *
+ * IT IS DECLARED ONCE BECAUSE IT WAS DECLARED FIVE TIMES. ACP-78 M1 found
+ * this value written inline in five places across this root with TWO
+ * different bounds — 128 here, in `ContextRead.capability_grant`, in the
+ * receipt and in the pending-release record, and 2,048 in the audit record,
+ * where its author derived the bound from L-04 instead. Two lengths for one
+ * identity means a party who is nameable in an audit record and unnameable
+ * in the receipt that produced it.
+ * Generated from attestation_object.schema.json#/$defs/operator_id.
+ */
+export type OperatorId = string;
+/**
+ * EL-2's value domain: an integer or a string, and nothing else. A rule's
+ * environment binds each `params` entry to one of these; a value of any
+ * other JSON type -- a non-integer number, a boolean, null, an array, an
+ * object -- MUST refuse the whole Proposal (EL-2, closes the v1.3.17
+ * `22`/`22.0` defect). The integer is bounded by the width the deployment
+ * declares under AC-1a; the generated types carry `i64`, and a value above
+ * it is out of the domain rather than merely large.
+ * Generated from proposal.schema.json#/$defs/param_value.
+ *
+ * EL-2's domain and nothing else. A value of any other type refuses the
+ * Proposal; it is never coerced into one of these two.
+ */
+export type ParamValue = number | string;
+/**
+ * An instant on the wire: EXACTLY `YYYY-MM-DDTHH:MM:SSZ`, to one second. No
+ * offset, no fractional part, no lowercase `z`. Every temporal value in this
+ * root carries this type except the acknowledgement's, which ACK-6 declares
+ * numeric.
+ *
+ * WHY THE SPELLING IS PINNED AND NOT LEFT TO RFC 3339 AS WRITTEN. RFC 3339
+ * accepts `2026-08-09T14:02:11Z`, `2026-08-09t14:02:11z`,
+ * `2026-08-09T16:02:11+02:00` and `2026-08-09T14:02:11.000Z` as four
+ * renderings of ONE instant. Each is a distinct string, and these values go
+ * inside canonical CBOR and are hashed: the receipt's `issued_at` sits in
+ * the signed body, the attestation object's `expires_at` sits in the
+ * preimage of `attestation_id` (AT-1, AT-8a), and `occurred_at` sits in the
+ * AU-1 chain preimage. Four spellings of one instant are four ids for one
+ * object and four chain hashes for one history -- Z4 and T-14 reopening
+ * through a type nobody had written down, which is precisely what `nonce128`
+ * above records happening to `b64:`. Canonicalization cannot fix it: the
+ * ambiguity is in the VALUE, not the encoding. So the offset MUST be `Z`,
+ * the letters MUST be upper case, there MUST be no fractional part, and a
+ * verifier MUST REJECT any other rendering rather than normalizing it --
+ * normalizing here would make this verifier accept every spelling and hand
+ * the divergence to the next implementation, which is the reasoning
+ * `nonce128` gives for refusing a stripped `b64:` prefix.
+ *
+ * WHY IT IS A STRING AND NOT AN EPOCH NUMBER. AT-8a forbids a float in a
+ * canonical structure because a float is not deterministically encoded, and
+ * `canon()` enforces that at the TOP level only -- a nested float serialises
+ * happily in both languages. The one structure in this root whose times are
+ * numbers is the acknowledgement, and the reference put `1787598182.1470501`
+ * into it on every production path (`crates/acp-core/src/generated_wire.rs`
+ * records the observation beside `AcknowledgementObject.issued_at`). A
+ * string of this shape has exactly one encoding.
+ *
+ * HISTORY, KEPT BECAUSE IT IS THE ARGUMENT. Through v1.3.27 this type was
+ * written out on `audit_record.occurred_at` and NOWHERE ELSE; the other six
+ * temporal fields carried a bare `{"type": "string", "format": "date-time"}`
+ * with no pinned spelling, and BOTH implementations read all seven as POSIX
+ * numbers. So an Attestation Object that satisfied the schema was refused at
+ * `9.3-7b-iii` by both verifiers, and an object both verifiers accepted did
+ * not validate -- no client building from the schema could satisfy a
+ * floor-HIGH quorum. The cross-language differential could not see it,
+ * because the two implementations agreed with each other and disagreed with
+ * the document: the eighth lesson in `dossier/05-TEST-EVIDENCE.md`, one
+ * artifact over. Nothing validates a fixture against these schemas (ACP-52),
+ * so nothing else could either. Filed as ACP-167 by the first executable
+ * consumer to build a floor-HIGH fixture from the schema rather than from
+ * the reference, and closed in v1.3.28 by moving the IMPLEMENTATIONS --
+ * because AT-1, section 9.2's rendered receipt and seven schemas all said
+ * RFC 3339, and only the code said otherwise. `anchor.schema.json` had
+ * already written the fix down: "a divergence to close in one place, not
+ * two".
+ *
+ * THE PARSER ALREADY EXISTED, ONE ROOT OVER, AND THIS TYPE IS ITS GRAMMAR
+ * WRITTEN DOWN. PB-1 has to decide when a bundle stops being valid, so
+ * `bundle/manifest.schema.json` carries `expires_at` as RFC 3339 and both
+ * implementations parse it strictly: `Timestamp::parse` in Rust and
+ * `Timestamp.parse` in the reference, refusing offsets, fractional seconds
+ * and lowercase `z` in the same words, checking the day against the actual
+ * length of the month, and refusing a leap second because `datetime` does.
+ * They are already differential partners. This $def is that grammar, so the
+ * wire root gets ONE more reference to an existing type rather than a second
+ * parser -- a second parser for one format being the two-definitions defect
+ * this repository has published three corrections for. THE FRACTIONAL PART
+ * IS WHY THIS PARAGRAPH IS HERE: `occurred_at`'s pattern through v1.3.27
+ * permitted `(\.\d{1,9})?`, so `...:11Z` and `...:11.0Z` were two spellings
+ * of one instant inside the AU-1 chain preimage -- the exact hazard four
+ * paragraphs up, in the one field that had a pattern at all. v1.3.28 narrows
+ * it to the parsers' grammar. Nothing emitted a fractional second, because
+ * both implementations were emitting numbers.
+ *
+ * IT IS ONE TYPE AND IT LIVES HERE, for the reason `nonce128` states one
+ * $def above.
+ * Generated from attestation_object.schema.json#/$defs/rfc3339_instant.
+ *
+ * The schema constrains this to `^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z$`, which is NOT enforced here.
+ */
+export type Rfc3339Instant = string;
+/**
+ * The identifier half of SR-1's content address, carried on every Proposal
+ * by SR-5 and on the receipt that decided it by §9.2.
+ *
+ * ONE DECLARATION, AND WHY IT IS NOT SHARED WITH `task_type`. Before ACP-78
+ * M1 this pattern was written out three times in this root: here, on the
+ * receipt, and on the payload's `task_type`, which is a DIFFERENT value that
+ * happens to share a character class. The first two are one type and are now
+ * one declaration. The third is deliberately left as its own inline pattern,
+ * because V-11 requires `task_type` to `agree with` `schema_id` and does not
+ * say what agreement is -- string identity, or a registry lookup. Giving
+ * both fields one type would answer V-11 by writing a schema, which is the
+ * move this root exists to refuse. Two types with the same pattern are two
+ * types; one type with two declarations is the defect.
+ *
+ * THE PATTERN IS §6.3's, CHARACTER FOR CHARACTER, AND THE REFERENCE DOES NOT
+ * SATISFY IT: `reference/suites/conformance.py` builds `schema_id: "fw.v1"`
+ * and `.` is outside the class. It is kept as written, because widening a
+ * schema's own pattern to admit the fixture that violates it proves only
+ * that the instrument is adjustable. Whether a pattern stated inside a
+ * NORMATIVE EXAMPLE binds an implementation at all is unresolved and
+ * reported rather than assumed.
+ * Generated from proposal.schema.json#/$defs/schema_id.
+ *
+ * The schema constrains this to `^[a-z0-9_-]{1,32}$`, which is NOT enforced here.
+ */
+export type SchemaId = string;
+/**
+ * The version half of SR-1's content address (SR-5), declared once here and
+ * `$ref`d by the receipt, which carries the same triple. It is the axis SR-3
+ * decides change direction over: a change is NARROWING only where the new
+ * admissible set is a provable subset of the old in EVERY dimension of the
+ * bounded lattice -- character class, length bound, enum set, numeric range
+ * -- and anything not provably narrowing in every dimension is widening and
+ * takes the distinct-reviewer path. v1.2.0 left `narrowing` undefined, which
+ * let a net-widening change self-classify as narrowing and bypass review.
+ *
+ * The pattern is §6.3's and carries the same unresolved question as
+ * `schema_id`: it is stated inside a section titled `Reference Schemas
+ * (Normative Examples)`, and whether an example binds is not settled
+ * anywhere.
+ * Generated from proposal.schema.json#/$defs/schema_version.
+ *
+ * The schema constrains this to `^\d+\.\d+\.\d+$`, which is NOT enforced here.
+ */
+export type SchemaVersion = string;
+/**
+ * `"sha256:"` followed by a lowercase-hex SHA-256 digest — 71 characters.
+ * The type is pinned rather than left to the implementer because §11.2
+ * records an implementer who fed forward raw digest bytes and built a
+ * different chain while following the text.
+ * Generated from attestation_object.schema.json#/$defs/sha256.
+ *
+ * The schema constrains this to `^sha256:[0-9a-f]{64}$`, which is NOT enforced here.
+ */
+export type Sha256Hash = string;
+/**
+ * A signed acknowledgement of a floor-HIGH action being held for release.
+ * Carried on legs F5.4 and F5.5 of the leg register (ZIFFER-DEPLOY-001 Annex
+ * A): F5.4 is the DR-9 positive acknowledgement that releases an
+ * IRREVERSIBLE action, F5.5 is the DR-4 repudiation that vetoes one. It is
+ * the same artifact on both, discriminated by `decision`.
+ *
+ * THE DISCLOSURE THAT GOVERNS EVERY LINE BELOW: ACK-1 THROUGH ACK-6 ARE NOT
+ * CLAUSES OF ZIFFER-SPEC-001. The string `ACK-` does not occur in that
+ * document at all. They are reference-level rules, written for v1.3.12 in
+ * `reference/src/acp_ack.py` to close T-31, and the two places that already
+ * say so in as many words are the leg register (`DR-9, ACK-1..6
+ * (reference-level)`) and `spec/schemas/bundle/attesters.schema.json`
+ * (`ACK-4 (reference-level ... not a spec clause)`). ZIFFER-SPEC-001 states
+ * the OBLIGATIONS this object discharges -- DR-9 requires positive
+ * acknowledgement from at least one notified party who is not the operator,
+ * DR-4 admits repudiation from any notified party, DR-5 admits it only from
+ * a notified party and forbids the repudiation path from depending on the
+ * approval chain -- and states NOTHING about the artifact that carries them:
+ * no field list, no canonicalization, no validity bound, no identity type,
+ * no nonce type. Every field below therefore cites the reference-level ACK-*
+ * rule that put it there together with the ZIFFER-SPEC-001 clause it serves.
+ * A second implementation written from ZIFFER-SPEC-001 alone would not
+ * produce this object and would still be conformant with the document. That
+ * is the same hole ACP-87 was filed for one layer down, and it is wider
+ * here: there the type of one field was unstated, here the whole artifact
+ * is.
+ *
+ * ONE ARTIFACT OR TWO, AND WHY THIS SCHEMA IS ONE. The leg register makes
+ * them two rows with DIFFERENT clause sets -- F5.4 carries `DR-9, ACK-1..6`,
+ * F5.5 carries only `DR-4, DR-5` and names no ACK-* rule at all. The
+ * reference makes them ONE object: there is exactly one closed field set,
+ * and `confirm()` and `repudiate()` run the identical `_verify_ack` and
+ * differ only in which value of `decision` they will accept afterwards. Read
+ * literally, the register says a repudiation must satisfy DR-4 and DR-5 and
+ * nothing else -- which is the v1.3.11 bare-name form (T-31) still standing
+ * on the veto leg, unsigned, while the confirmation leg was fixed. It does
+ * not stand in the code. The register and the reference disagree, the
+ * disagreement is recorded rather than silently resolved (that is the ACP-57
+ * shape), and this schema follows the code because the code is what runs.
+ *
+ * WHY THE FIELD SET IS CLOSED. ACK-1: an acknowledgement is an object with a
+ * closed schema -- exactly these fields, no optional ones, no extension
+ * point. An object carrying an unknown field or omitting a declared one MUST
+ * be rejected, never normalized and never defaulted. That is why
+ * `additionalProperties` is false at both levels and why `required` lists
+ * every property, and it is why `x-acp-absent` appears here only on the
+ * signature map: an absent-value rule on a field of a closed object would be
+ * a defect rather than a control. The reason is Z4, stated for the
+ * Attestation Object and applying unchanged here because this object is on
+ * the same binding path: given ANY optional field, the object
+ * present-as-null and the object with the field omitted are each valid
+ * canonical encodings, hash to TWO DISTINCT ids, and therefore claim TWO
+ * ledger slots. One acknowledgement, spent twice; ACK-5's single use
+ * defeated without forging anything. Canonicalization cannot fix it, because
+ * the ambiguity is in the field set rather than the encoding.
+ *
+ * ENCODING, AND THE CLAUSE THAT IS MISSING. ACK-1 says the object is
+ * `canonically encoded` and NO clause anywhere says WHICH canonicalization.
+ * ZIFFER-SPEC-001 pins the other two: RFC 8785 (JCS) for the Proposal,
+ * canonical CBOR (RFC 8949 4.2) for the receipt and the Attestation Object
+ * (WE-1, WE-2, AT-8a). AT-8a's whole rationale is that object hashing moved
+ * onto the binding path, so any encoder disagreement between issuer and
+ * verifier becomes a freshness and single-use defect. This object is on that
+ * same path by construction: its id is a hash over its canonical encoding
+ * and the Consumption Ledger consumes that id (ACK-5). Two encoders means
+ * two ids for one acknowledgement, so a re-encoded acknowledgement claims a
+ * fresh slot and replays -- Y1b reopening in the machinery a later fix
+ * introduced, which is the RES-8/9/10 recurrence pattern this repository has
+ * now published five times. The rule AT-8a states for the Attestation Object
+ * is the rule this object needs and does not have. Filed, not invented here.
+ *
+ * WHAT IS NOT A FIELD. The acknowledgement id. ACK-5 recomputes it as a hash
+ * over the canonical object and consumes it in the ledger; it is never
+ * transmitted and never read from the message. That is Y1b's lesson applied
+ * before it could be rediscovered, and a schema property for it would invite
+ * exactly the read that was closed as Y1. There is likewise no field naming
+ * the pending action other than `proposal_hash`, no field asserting that the
+ * acknowledger was notified (that is the Executor's own record, tested under
+ * DR-5), and no field carrying the reversibility class (RV-3: recomputed
+ * from the signed bundle, never read from a message).
+ *
+ * SUITE 12 CLASSIFICATION. Every field here is class T at the SCHEMA layer,
+ * because a schema constrains shape and shape is not authority. What lifts
+ * them is stated on each property and enforced elsewhere: `acknowledger`
+ * becomes B once the signature over the canonical object verifies against
+ * the key the SIGNED BUNDLE registers for that name (ACK-2/ACK-4, and row 27
+ * of the classification table records that it was T through v1.3.11 -- that
+ * was T-31); `proposal_hash` becomes B against the Executor's own recomputed
+ * hash (ACK-3); `policy_bundle_hash` and `bundle_epoch` are compared against
+ * the bundle the Executor already holds and are never used to SELECT a
+ * bundle.
+ *
+ * WHAT THIS SCHEMA DOES NOT CONSTRAIN, STATED BEFORE ANYTHING IT DOES. (1)
+ * ORDER. The reference consumes the ledger slot inside `_verify_ack`, BEFORE
+ * the `decision`, DR-5 membership and DR-9 non-operator tests run -- so
+ * submitting a captured, validly signed REPUDIATE object to the confirmation
+ * endpoint burns its id, the genuine repudiation is then refused as a replay
+ * (CL-3), and a REVERSIBLE unsampled floor-HIGH action releases on silence
+ * under DR-7 with its veto suppressed. Executed, not reasoned about:
+ * `confirm(REPUDIATE)` refuses at ACK-1, `repudiate` then refuses at CL-3,
+ * `release` then succeeds. DR-5 exists to stop a veto being suppressed by
+ * the approval chain, and no shape constraint can express this. (2) The
+ * ACK-6 window LENGTH bound, and that the acknowledgement falls inside the
+ * hold window it is acknowledging. (3) CR-3's requirement that the signature
+ * key set exactly match the declared suite, and CR-4's containment against
+ * the bundle floor -- both are decided against the signed bundle, which a
+ * schema cannot see. (4) DR-3 delivery and DR-8 deliverability. (5) Whether
+ * any human read anything: A-8 is untouched, and acknowledgement remains an
+ * input to the model rather than evidence of comprehension.
+ * Generated from acknowledgement.schema.json.
+ */
+export interface Acknowledgement {
+    /**
+     * The signed object. Carried in its own member rather than flattened beside
+     * the signature because the id and the signature are both taken over THIS
+     * map alone (ACK-2, ACK-5): flattening would put the signature inside the
+     * bytes it signs. The reference refuses an acknowledgement with no `obj` at
+     * ACK-1 by name, because the v1.3.11 form that this member's absence
+     * identifies is a bare string -- T-31, an identity anyone could type.
+     */
+    readonly obj: AcknowledgementObject;
+    /**
+     * CR-2: a signature under a suite is a MAP from primitive name to signature
+     * value, one entry per primitive of the suite named in `obj.alg`. A bare
+     * scalar signature MUST NOT be accepted under any suite, not even a
+     * single-primitive one -- format leniency is a downgrade in disguise, and
+     * the reference refuses a non-map before it looks at any value.
+     *
+     * OPEN MAP, DELIBERATELY. The suite registry lives in the SIGNED BUNDLE
+     * (CR-1) and CR-7 makes migration forward-only, requiring a deployment to
+     * verify structures signed under a HIGHER suite than its floor. A closed
+     * `{classical, pq}` object here would hard-code one suite into the wire
+     * format and make CR-7 unimplementable; it would also be a second registry
+     * of primitive names beside the bundle's, which is the two-definitions
+     * defect.
+     *
+     * CR-3 IS CONJUNCTIVE AND IS NOT EXPRESSIBLE HERE. Verification succeeds
+     * only if EVERY primitive of the declared suite verifies and the supplied
+     * set EXACTLY matches it -- no missing entries and no extra ones, an
+     * accepted extra primitive being an undeclared code path chosen by the party
+     * under verification. Whether this map's key set matches depends on
+     * `obj.alg` resolved against the bundle, so it is checked in code and not
+     * here.
+     *
+     * THE VALUE TYPE IS NOT PINNED BY ANY CLAUSE, AND THE TWO IMPLEMENTATIONS OF
+     * IT DISAGREE. WE-4 pins `b64:` plus padded RFC 4648 4 base64 for `any
+     * signature or byte string carried as text`, while
+     * `reference/src/acp_executor.py` hex-encodes every signature value with the
+     * comment that signatures travel through JSON and raw bytes do not, and
+     * `spec/schemas/bundle/attesters.schema.json` carries public keys as bare
+     * base64 with no prefix at all. Three encodings of one concept in one
+     * repository. A pattern is therefore NOT asserted here, because asserting
+     * one would decide a normative question by writing a schema -- exactly what
+     * ACP-87 was filed rather than done.
+     *
+     * ABSENT-ENTRY RULE, carried as documentation and NOT enforced by this type,
+     * because this is a message and not signed policy. An entry absent from this
+     * table is a REFUSAL under CR-3, never a default value: a primitive named by
+     * the declared suite and absent from this map is a hybrid signature verified
+     * on fewer primitives than it claims, which is the OR composition CR-3
+     * forbids: a hybrid verifier that accepts when EITHER half checks out is
+     * weaker than its weaker member, so an attacker who breaks one primitive is
+     * unconstrained by the other. Refuse, never treat a missing primitive as
+     * satisfied and never verify the subset that is present.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: values minLength 1.
+     */
+    readonly sig: Readonly<Record<string, string>>;
+}
+/**
+ * The lenient projection of Acknowledgement: every field optional, every enum
+ * degraded to `string`. What a verifier parses. Never make a decision on
+ * one — the fail-safe lookups live on the strict type only.
+ */
+export interface RawAcknowledgement {
+    readonly obj?: RawAcknowledgementObject;
+    readonly sig?: Readonly<Record<string, string>>;
+}
+/**
+ * The signed acknowledgement object -- the bytes the signature covers and
+ * the bytes the id is derived from. ACK-1's closed field set, exactly
+ * `ACK1_FIELDS` in `reference/src/acp_ack.py`, in the order that file
+ * declares them. Adding a field here is a BREAKING change, never an additive
+ * one, for the Z4 reason on the root: a field set with an optional member
+ * gives one object two ids and two ledger slots.
+ * Generated from acknowledgement.schema.json#/$defs/acknowledgement_object.
+ */
+export interface AcknowledgementObject {
+    /**
+     * THE BINDING, and the reason the object exists rather than a name. ACK-3:
+     * this MUST equal the hash the Executor recomputed for the action it is
+     * about to release; an acknowledgement of a different action is not an
+     * acknowledgement of this one. Without it a captured acknowledgement for a
+     * routine action is replayed onto a dangerous one, which is Y1 one layer up
+     * -- there a genuine quorum raised for P1 verified against an
+     * attacker-chosen P2.
+     *
+     * The Executor compares against ITS OWN recomputed hash, never against a
+     * hash the same message supplied: a transmitted identifier is a name for a
+     * binding, not evidence of one (RES-8).
+     */
+    readonly proposalHash: Sha256Hash;
+    /**
+     * The signed bundle the acknowledger was acting under. ACK-3 requires it to
+     * equal the hash of the bundle the Executor holds, so an acknowledgement
+     * raised under a superseded policy cannot release an action graded under the
+     * current one. It selects nothing: the Executor already has its bundle and
+     * this value is compared to it, because a hash that chose which policy to
+     * load would let the acknowledging party choose the policy that judges them.
+     */
+    readonly policyBundleHash: Sha256Hash;
+    /**
+     * Epoch of that bundle, compared for equality by ACK-3 alongside the hash.
+     * Carried as well as the hash because the two fail differently and a reader
+     * should see which: a hash mismatch means a different bundle, an epoch
+     * mismatch means a different version of the policy basis. Epoch MONOTONICITY
+     * is not a property of this field -- it is enforced at the KMS against a
+     * durable high-water mark (RAD-3), never from a value a message carries.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minimum 0.
+     */
+    readonly bundleEpoch: number;
+    /**
+     * The identity acknowledging, INSIDE the signature. ACK-4 is the whole of
+     * T-31's lesson: the identity used for the DR-9 non-operator test and the
+     * DR-5 notified-membership test is taken FROM THE SIGNED BYTES, never from
+     * the call that delivered the object. Through v1.3.11 it was a bare string
+     * checked only for set membership and inequality with the operator -- the
+     * release gate held no key material at all, and an irreversible action
+     * released with `human_verified` true and zero signatures verified.
+     *
+     * ACK-2 makes the name resolvable rather than authoritative: it selects a
+     * key from the attester registry inside the SIGNED bundle, and an identity
+     * with no registered key cannot acknowledge anything. The signature
+     * establishes who signed; this field only says which enrolled key to check
+     * it against. It does not authorise anyone to name themselves.
+     *
+     * BOUNDED AT 128 BECAUSE THE REGISTRY IT MUST RESOLVE IN IS.
+     * `spec/schemas/bundle/attesters.schema.json` bounds its `propertyNames` at
+     * 1..128, so a longer value cannot name an enrolled attester and the same
+     * bound belongs on both sides of the lookup. It is also the bound
+     * `AttestationObject.operator` carries, which matters because DR-9 compares
+     * this value to that one: two bounds on one identity space would make a name
+     * that is a valid acknowledger and an invalid operator, and the non-operator
+     * test compares them.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minLength 1, maxLength 128.
+     */
+    readonly acknowledger: string;
+    /**
+     * Which of the two acts this object is: CONFIRM is the DR-9 positive
+     * acknowledgement that permits an IRREVERSIBLE floor-HIGH action to release;
+     * REPUDIATE is the DR-4 veto that blocks release with a critical alert and
+     * requires a fresh quorum rather than a replay.
+     *
+     * HOISTED INTO $defs rather than written inline for the reason
+     * `attester_role` gives in the bundle schemas: an inline enum has no name,
+     * and a generator inventing one invents a name that drifts.
+     *
+     * DELIBERATELY NOT ORDERED. A repudiation does not outrank a confirmation on
+     * some scale; they are different acts with different consequences, and
+     * DR-4's precedence -- a repudiated action fails closed at release however
+     * many confirmations it also collected -- is enforced in the release step
+     * against `repudiated_by`, not by comparing two enum members.
+     *
+     * THIS FIELD IS INSIDE THE SIGNATURE, AND THAT IS THE POINT. It is the
+     * discriminator between the two legs, so an attacker who could rewrite it
+     * would turn a veto into an approval. Being an ACK-1 field it is
+     * signature-covered, exactly as CR-5 requires of `alg` and AT-1 of
+     * `operator` after Y4. A verifier MUST still check it against the endpoint
+     * that received the object: a valid REPUDIATE object is not a confirmation
+     * merely because it was posted to the confirmation path.
+     */
+    readonly decision: AcknowledgementDecision;
+    /**
+     * Freshness material, so that two acknowledgements of the same action under
+     * the same bundle by the same party are distinct objects with distinct ids.
+     * ACK-5 consumes the derived id in the ledger, so this is what stops a
+     * second honest acknowledgement colliding with the first.
+     *
+     * ITS TYPE AND ITS ENTROPY ARE UNSTATED, AND THE REFERENCE MAKES IT
+     * PREDICTABLE. AT-1 requires a 128-bit FRESH nonce for the Attestation
+     * Object and WE-4 pins that value's wire type; no clause says anything about
+     * this one, and `make_ack` builds it as the acknowledger's own name joined
+     * to a millisecond timestamp (observed: `ack-op_1121-1787598182147`). It is
+     * therefore neither random nor unique -- two acknowledgements by one party
+     * in one millisecond collide -- and, because every other field of the object
+     * is already known to the operator, the derived ledger id is guessable to
+     * within the timestamp resolution. The ledger id is the single-use key, so a
+     * guessed id can be claimed before the honest acknowledgement arrives, and
+     * the honest one is then refused as a replay.
+     *
+     * `minLength: 1` and nothing more, deliberately. A zero-length nonce
+     * contributes no freshness at all, which is a shape claim a schema may make;
+     * a length or an alphabet would be this schema inventing the normative rule
+     * that is missing, and inventing it here is how a type comes to exist in a
+     * schema and nowhere else -- the defect the sibling wire schema records
+     * against its own `att_nonce`.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minLength 1.
+     */
+    readonly ackNonce: string;
+    /**
+     * When the acknowledgement was raised, in seconds since the Unix epoch.
+     * ACK-6 requires `issued_at <= now <= expires_at` at the consumer, evaluated
+     * against NTS-disciplined wall time within the L-20 skew allowance (leg F9.1
+     * carries that dependency).
+     *
+     * THIS IS THE ONE STRUCTURE IN THE WIRE FORMAT WHOSE TIMES ARE NUMBERS, AND
+     * THE REFERENCE PUTS FLOATS IN IT. Section 9.2's receipt and AT-1's
+     * `expires_at` are RFC 3339 strings; only the acknowledgement is numeric,
+     * and `make_ack` defaults to `time.time()`, so a float reaches the canonical
+     * bytes on every production path. AT-8a forbids a float in a canonical
+     * structure because a float is not deterministically encoded, and `canon()`
+     * enforces that only at the top level -- a nested float is serialised,
+     * observed as `{"ack_nonce":...,"issued_at":1787598182.1470501,...}`. Two
+     * runtimes formatting that value differently derive two ids for one
+     * acknowledgement, which is precisely the encoding split AT-8a exists to
+     * prevent and precisely the ledger-slot defect Y1b closed.
+     *
+     * `integer` is pinned here because it is the only one of the three encodings
+     * present in this repository -- float, integer, RFC 3339 -- that AT-8a
+     * permits. Which of the remaining two the acknowledgement SHOULD carry is a
+     * normative question ZIFFER-SPEC-001 does not answer, and pinning the
+     * narrower of what exists is not the same as answering it.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minimum 0.
+     */
+    readonly issuedAt: number;
+    /**
+     * When the acknowledgement stops being valid, in seconds since the Unix
+     * epoch, on the same clock and with the same float caveat as `issued_at`.
+     *
+     * THE WINDOW LENGTH IS ENFORCED BY THE CONSUMER, NOT READ FROM THE MESSAGE.
+     * ACK-6 requires `expires_at - issued_at` to be bounded, and that bound is
+     * checked by the Executor -- the Y2 lesson, where receipt validity LENGTH
+     * was checked nowhere and lived only in the value the signing party wrote,
+     * permitting long-lived pre-positioned receipts. A schema cannot express a
+     * relation between two fields, so this constraint is stated and not
+     * asserted.
+     *
+     * THE BOUND ITSELF HAS NO CLAUSE. The reference uses 120 seconds and its
+     * comment says the figure mirrors L-14 -- but L-14 is the ALLOW receipt
+     * validity ceiling, a limit on a different artifact with a different
+     * lifetime, and the section 13 limits table has no row for an
+     * acknowledgement window. A borrowed number is not a normative bound;
+     * recorded rather than restated as one.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minimum 0.
+     */
+    readonly expiresAt: number;
+    /**
+     * The signature suite `sig` is under. CR-1: every signed structure MUST
+     * carry an explicit `alg` naming a suite REGISTERED IN THE SIGNED BUNDLE,
+     * and an unregistered or unknown suite MUST fail closed. CR-5: it is
+     * signature-covered, so an issuer cannot rewrite the suite without
+     * invalidating the object -- an acknowledger cannot downgrade its own suite.
+     *
+     * NO ENUM, DELIBERATELY. The suite set is a bundle property, so an enum here
+     * would be a second registry of suite names beside the signed one, and two
+     * definitions of one object is the defect this repository is built around.
+     * It would also break CR-7, which makes migration forward-only and requires
+     * a deployment to verify structures signed under a suite HIGHER than its
+     * floor: a suite the schema had not been updated to list would be refused at
+     * the wrong layer, for the wrong reason, with the wrong clause name.
+     *
+     * CR-4 IS CONTAINMENT AND IS DECIDED AGAINST THE BUNDLE. The floor is
+     * satisfied when the named suite's primitive set CONTAINS every primitive of
+     * the bundle floor's suite -- not by rank. The rank table this replaced was
+     * a total order over sets that are not comparable, and it let a deployment
+     * whose signed floor said hash-based post-quantum silently accept a lattice
+     * one: not a stronger suite accepted, a DIFFERENT hardness assumption
+     * substituted, with the floor check reporting satisfaction. The reference
+     * checks the floor BEFORE verifying the signature, so a below-floor
+     * acknowledgement refuses at CR-4 rather than at ACK-2.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minLength 1.
+     */
+    readonly alg: string;
+}
+/**
+ * The lenient projection of AcknowledgementObject: every field optional, every enum
+ * degraded to `string`. What a verifier parses. Never make a decision on
+ * one — the fail-safe lookups live on the strict type only.
+ */
+export interface RawAcknowledgementObject {
+    readonly proposalHash?: string;
+    readonly policyBundleHash?: string;
+    readonly bundleEpoch?: number;
+    readonly acknowledger?: string;
+    readonly decision?: string;
+    readonly ackNonce?: string;
+    readonly issuedAt?: number;
+    readonly expiresAt?: number;
+    readonly alg?: string;
+}
+/**
+ * The external commitment to one per-tenant audit chain head: what an
+ * anchoring party receives under AU-3, and what a verifier running outside
+ * the production trust domain compares its own recomputation against under
+ * AU-4. Carried on leg F6.4 of the leg register (ZIFFER-DEPLOY-001 Annex A);
+ * leg F6.3 carries the `chain_hash` this object commits to.
+ *
+ * WHY THE OBJECT EXISTS AT ALL. AU-3 says it in one line: an unanchored
+ * in-database chain is tamper-DECORATED, not tamper-EVIDENT. The chain lives
+ * inside the production trust domain and a compromised audit writer can
+ * rewrite it; what such a writer cannot rewrite is an anchor already
+ * published. Everything below serves one comparison - recompute the head
+ * from the records under AU-1, then check it against what was anchored. AU-4
+ * makes a head that fails to extend a previously anchored head a critical
+ * integrity alert, and AU-7 makes coverage by an anchor a precondition of
+ * releasing a floor-HIGH action rather than a report written afterwards.
+ *
+ * NOTHING BELOW IS EVIDENCE ON ITS OWN (RES-8 / RES-9 / RES-10). Every field
+ * here is a value the publisher sends. The guarantee comes from two things
+ * outside this object: the store is append-only and sits outside the
+ * production trust domain (AU-4, ZIFFER-DEPLOY-001 DP-11), and the anchor is
+ * verifiable by any party holding the anchor public keys (AU-3a). A verifier
+ * that read a head from the chain it is auditing, or accepted an anchor
+ * because the audited party said it existed, has taken a derived security
+ * value from the party under verification - the class this architecture has
+ * hit five times, C2 -> X1 -> Y1 -> Z3 -> W1, each time inside machinery the
+ * previous fix introduced.
+ *
+ * WHY THE FIELD SET IS CLOSED, AND WHY THAT IS A SECURITY PROPERTY. Every
+ * field is REQUIRED and `additionalProperties` is false. An anchor is a
+ * signed structure (CR-1), so an optional field gives one semantic anchor
+ * two canonical encodings, two signed preimages and two values - the Z4
+ * defect that AT-8b closes for the Attestation Object one schema over. Here
+ * the consequence is worse than a duplicate id, because it lands on an
+ * honest party: a publisher that omits the field and a verifier that encodes
+ * it as absent-present compute different bytes, the signature fails, and
+ * AU-4 raises a critical integrity alert with no attacker anywhere. That is
+ * exactly what the AU-1 correction records happening to this subsystem
+ * already, from a formula rather than a field.
+ *
+ * WHAT THIS SCHEMA DOES NOT MODEL, STATED SO THE FILE IS NOT READ WIDER THAN
+ * IT IS.
+ * (1) The signature envelope. CR-2 makes a signature a map from primitive to
+ * signature value and CR-3 requires the supplied set to match the declared
+ * suite exactly. That map is keyed by the primitive names whose one home is
+ * `spec/schemas/bundle/signature.schema.json`, in the other schema root. A
+ * `$ref` crossing roots resolves now (ACP-78 M1, for a named scalar), so
+ * what still blocks the envelope is the OPEN MAP and not the reference: the
+ * generator's only rule for one is `x-acp-absent`, which states what the
+ * SIGNED POLICY says when a lookup misses, and a message carries no
+ * authority to answer that -- in the wire root such a rule is now carried as
+ * documentation and no accessor is generated from it. So the envelope is
+ * disclosed as absent rather than invented in a shape the specification
+ * never gave it. This follows the precedent of the sibling Attestation
+ * Object schema, which models the AT-1 body and not the surrounding `kind` /
+ * `attester` / `sig`.
+ * (2) AU-3's mechanism and its evidence. AU-3 permits a public transparency
+ * log with inclusion proofs, a threshold signature from at least 3
+ * independent parties, or RFC 3161 timestamping. Those three have
+ * incompatible evidence shapes - a Merkle inclusion proof, a set of party
+ * signatures, a CMS TimeStampToken - and no clause says which the anchor
+ * carries, how a verifier learns which was used, or which of the anchor
+ * public keys AU-3a means. An outside auditor cannot verify this object from
+ * its fields alone, and saying so is more useful than inventing a
+ * discriminator.
+ * (3) Ordering and rate. AU-3's <= 10 min interval (L-19) and its
+ * at-every-bundle-activation rule are properties of a SEQUENCE of anchors;
+ * AU-4's extension check is a relation between two of them; AU-7's
+ * anchor-before-release is an ordering between an anchor and an execution.
+ * None is a property of one object and none is expressible here. They are
+ * per-implementation obligations (`spec/vectors/OBLIGATIONS.md`), and
+ * `reference/suites/audit_suite.py` is where the reference discharges them.
+ * (4) AU-5 retention (>= 24 months or per regulation), AU-6 outage
+ * behaviour, and §11.3's eight reconciliation checks. All are about what a
+ * deployment does with anchors, never about what one is.
+ *
+ * ENCODING, AND A GAP. §11.2 fixes `canonical()` for §11 as the single
+ * canonicaliser AT-8a requires - canonical CBOR, RFC 8949 §4.2 - and
+ * requires chain values to be carried, stored, anchored and fed forward as
+ * the 71-character `sha256:` string. That is the only canonicaliser §11
+ * names, so it is the reading this schema is written against. But no clause
+ * states the anchor's own signed preimage: whether the signature covers this
+ * whole object, the `chain_hash` alone, or a mechanism-specific structure.
+ * AU-3a cannot hold until it is pinned, for the reason AU-1 already records
+ * - two implementations signing different bytes each refuse the other's
+ * anchor, and at the verifier a refusal is indistinguishable from tampering.
+ * JSON here is diagnostic form, never an accepted input.
+ * Generated from anchor.schema.json.
+ */
+export interface Anchor {
+    /**
+     * The tenant whose chain this anchor commits to. AU-1 makes chains
+     * per-tenant and AU-2 makes `(tenant_id, seq)` unique and gapless, so a head
+     * with no tenant names no chain: a verifier holding anchors from many
+     * tenants cannot tell which recomputation to compare against, and AU-4's
+     * extension check has no predecessor to look for.
+     *
+     * It is a NAME for something already inside the chain, not a second source
+     * of it. AU-8 derives genesis from a tenant-creation record over
+     * `{tenant_id, created_at, bundle_epoch, schema_version}`, so the tenant is
+     * committed from `chain_hash_0` onward and a verifier that trusted this
+     * field over the chain would be trusting the publisher about which chain it
+     * published.
+     *
+     * The specification pins no form for a tenant identifier - §9.2 renders one
+     * as `ten_04qf` in diagnostic JSON and no clause types it. The only stated
+     * bound is L-04 (max string field length 2,048 chars, no exceptions), so it
+     * is applied here rather than inventing a narrower one. That L-04's
+     * enforcement point is the Input/Output Schema registry and is being read as
+     * a general wire bound is an assumption; it is recorded rather than made
+     * quietly.
+     */
+    readonly tenantId: TenantId;
+    /**
+     * The sequence number of the record whose head is anchored. AU-2 makes
+     * `(tenant_id, seq)` unique and gapless per tenant, and gaplessness is what
+     * makes deletion detectable at all - a sequence with holes has no missing
+     * record, only a shorter one.
+     *
+     * Zero is the genesis anchor. AU-8 requires it to be published IMMEDIATELY
+     * on tenant creation rather than on AU-3's <= 10 min schedule, because
+     * without an anchored genesis the destruction of an entire tenant chain is
+     * detectable only after the first scheduled anchor, and a chain destroyed
+     * inside that window leaves no evidence it ever existed.
+     *
+     * An anchor at `seq` commits transitively to every record from 0 to `seq`,
+     * because AU-1 chains each head over the previous one. That is derived from
+     * the chain construction rather than promised by this field, and it is what
+     * §11.3(g) relies on when it asks for an anchor COVERING a floor-HIGH
+     * execution record.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minimum 0.
+     */
+    readonly seq: number;
+    /**
+     * The anchored head: `chain_hash_seq` as AU-1 constructs it, `H({prev,
+     * record})` over the canonical encoding of a two-key map whose key names are
+     * part of the preimage. Carried as the 71-character string §11.2 pins, never
+     * as the 32 raw digest bytes - that type is pinned in the specification
+     * because an implementer who fed forward raw bytes built a different chain
+     * while following the text.
+     *
+     * A NAME FOR A BINDING, NOT EVIDENCE OF ONE. The verifier's job under AU-4
+     * is to recompute the head from the records and compare, so this value is
+     * one half of a comparison whose other half the verifier computes itself. It
+     * is trustworthy only to the degree that the store holding it is append-only
+     * and outside the production trust domain; the field carries no authority of
+     * its own.
+     *
+     * THE AU-1 CORRECTION IS WHY THAT SENTENCE IS WORTH WRITING. Through v1.3.13
+     * the clause read `SHA-256(chain_hash_{n-1} || canonical(record_n))`, a
+     * concatenation, while the reference hashed the canonical encoding of the
+     * two-key map. Different preimage, different chain from record 1 onward. The
+     * damage was not that an implementer failed to match: an honest third party
+     * implementing the clause literally recomputes a different head on an
+     * untampered chain, so AU-3a's independent verifiability did not hold, and
+     * AU-4 routed an honest verifier into this system's own critical-alert
+     * channel with no attacker present. The clause moved and the implementations
+     * did not, and the reasoning was published rather than taken silently.
+     */
+    readonly chainHash: Sha256Hash;
+    /**
+     * When the anchor was published. §11.3(g) requires every floor-HIGH
+     * execution record to be matched to an anchor DATED AT OR BEFORE release,
+     * and AU-7 makes that ordering a release precondition rather than a report,
+     * so the comparison needs a date and this is it.
+     *
+     * WHO STAMPS IT IS THE WHOLE QUESTION, AND NO CLAUSE ANSWERS IT. If the
+     * anchoring party stamps it, the field is an external attestation of time
+     * and AU-7 means what it says. If the publisher stamps it, the party under
+     * verification dates its own alibi: a compromised audit writer backdates the
+     * anchor it has just published, and §11.3(g) - one of the mechanisms by
+     * which several disclosed residuals are said to be DETECTED rather than
+     * prevented - compares two numbers written by the same hand. Detection that
+     * can be erased is not detection, in AU-7's own words, and a timestamp the
+     * audited party chooses is erasure with an extra step. The Python reference
+     * is the second reading: `AnchorService.publish(tenant, seq, head, now)` in
+     * `reference/src/acp_audit.py` takes `now` from its caller, and the caller
+     * is `AuditChain.anchor_now`, inside the production trust domain. Recorded
+     * and filed; a schema cannot settle it.
+     *
+     * THE TYPE IS NOT THE SPECIFICATION'S EITHER. No clause types an anchor
+     * timestamp. RFC 3339 is used because §9.2's `issued_at` and `expires_at`
+     * are RFC 3339 instants and §12.5 disciplines every receipt-issuing and
+     * receipt-verifying clock with NTS inside the L-20 skew allowance, so a
+     * second time format in the one subsystem whose value is retrospective would
+     * be a second encoding of one thing. The reference stores a POSIX float, so
+     * the two disagree today; that is a divergence to close in one place, not
+     * two.
+     */
+    readonly anchoredAt: Rfc3339Instant;
+    /**
+     * The signature suite the anchor was signed under. CR-1 names the audit
+     * anchor explicitly among the structures that MUST carry an explicit `alg`
+     * identifying a suite registered in the signed bundle, and an unregistered
+     * or unknown suite MUST fail closed.
+     *
+     * IT IS IN THE BODY BECAUSE OF WHAT HAPPENS WHEN IT IS NOT. PB-8 records the
+     * reasoning for the bundle SIGNATURE file and it transfers unchanged: the
+     * declared suite must be inside what the signature covers, or an attacker
+     * relabels a hybrid structure as classical, the verifier obligingly requires
+     * one primitive, and CR-3's conjunctive guarantee is decorative at the point
+     * it is loaded. An anchor is the structure a downgrade is worth most against
+     * - receipts live 120 s (L-14) and attestations 60 min (AT-1), while the
+     * audit chain's non-repudiation value is retrospective and measured in
+     * years, which is why §1 tells deployments to prioritise post-quantum
+     * signing on anchoring and bundle signing over receipt signing.
+     *
+     * THE SUITE-NAME TYPE HAS ONE HOME AND IT IS NOT THIS FILE. The enumerated
+     * names are `SuiteId` at
+     * `spec/schemas/bundle/signature.schema.json#/$defs/suite_id`, in the other
+     * schema root, alongside the primitive names CR-2's signature map is keyed
+     * by. Declaring the enum a second time here would be two definitions of one
+     * object - the defect that generator exists to prevent, committed in a file
+     * that cites it. Where a type shared by both roots lives is now decided
+     * (ACP-78 M1): a named SCALAR is `$ref`d across roots and imported rather
+     * than redeclared, which is what the Decision Receipt's `alg` does. This
+     * field deliberately does NOT do that, and the reason is the conflict
+     * recorded below rather than a missing mechanism: AU-3 requires an EXTERNAL
+     * anchoring mechanism while CR-1/CR-4 require the deployment's registered
+     * floor, no public transparency log or timestamping authority signs under
+     * either registered suite, and typing this field as `SuiteId` would decide
+     * that conflict by writing a schema. So the constraint is stated and the
+     * type is pointed at rather than made in passing in a schema about anchors.
+     *
+     * CR-4 IS SATISFIED BY CONTAINMENT, NEVER BY RANK, and the floor is read
+     * from the signed bundle rather than from this field. A verifier that
+     * ordered suites would place hybrid above `slhdsa128s` and serve a lattice
+     * signature to a deployment that chose hash-based precisely to rest on no
+     * lattice assumption. CR-6 SHOULD-recommends SLH-DSA for audit anchoring,
+     * and `slhdsa128s` is declared and not implemented in either implementation
+     * (ZIFFER-DEPLOY-001 DP-27), so a deployment following CR-6 to the letter
+     * cannot run today. That tension is the specification's and is named here
+     * rather than resolved by a schema.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minLength 1, maxLength 2048.
+     */
+    readonly alg: string;
+}
+/**
+ * The lenient projection of Anchor: every field optional, every enum
+ * degraded to `string`. What a verifier parses. Never make a decision on
+ * one — the fail-safe lookups live on the strict type only.
+ */
+export interface RawAnchor {
+    readonly tenantId?: string;
+    readonly seq?: number;
+    readonly chainHash?: string;
+    readonly anchoredAt?: string;
+    readonly alg?: string;
+}
+/**
+ * One receipt per attestation (CL-3, T-14). A second receipt bearing the
+ * same attester signatures and a fresh nonce is rejected at §9.3 step 7
+ * because the id is already consumed.
+ *
+ * THE OBLIGATION THIS CLAIM DEPENDS ON IS NOT AT THE LEDGER. §9.3 step 7b(v)
+ * requires the Executor to RECOMPUTE `attestation_id :=
+ * SHA-256(canonical(obj))` per AT-1 and to claim the recomputed value, never
+ * an id read from the receipt -- that is Y1b, and the Attestation Object
+ * schema carries no `attestation_id` property for the same reason. The
+ * ledger cannot tell a recomputed id from a transmitted one; both arrive
+ * here as the same 71 characters. So this field is class T AT THE LEDGER and
+ * the control lives entirely at the Executor. Recording that here is the
+ * point: a reader who takes ledger consumption as the whole of the T-14
+ * defence has the same misreading v1.3.2 shipped, where CL-3 guaranteed one
+ * receipt per attestation and never asked whether it was the RIGHT receipt.
+ * Generated from ledger_claim.schema.json#/$defs/attestation_id_claim.
+ */
+export interface AttestationIdClaim {
+    readonly tenantId: TenantId;
+    readonly artifactClass: 'attestation_id';
+    /**
+     * The recomputed `attestation_id` (AT-1): SHA-256 over the canonical CBOR
+     * encoding of the whole Attestation Object (AT-8a). Carried with its
+     * `sha256:` prefix per §11.2, which pins the type to the character and
+     * records why it had to -- an implementer who fed forward raw digest bytes
+     * built a different chain while following the text. Here the same slip is
+     * worse than a different chain: a prefixed issuer and an unprefixed verifier
+     * derive two ids for one object and claim two ledger slots, which is Z4 and
+     * T-14 reopening with no optional field anywhere in reach.
+     */
+    readonly identifier: Sha256Hash;
+}
+/**
+ * The lenient projection of AttestationIdClaim: every field optional, every enum
+ * degraded to `string`. What a verifier parses. Never make a decision on
+ * one — the fail-safe lookups live on the strict type only.
+ */
+export interface RawAttestationIdClaim {
+    readonly tenantId?: string;
+    readonly artifactClass?: string;
+    readonly identifier?: string;
+}
+/**
+ * A signed human act bound to a `proposal_hash`. Carried on leg F4.4 of the
+ * leg register (ZIFFER-DEPLOY-001 Annex A). F4.3 named the signing act
+ * inside the approval domain, which crosses no domain boundary and is
+ * therefore not a leg (DP-83); ACP-86 retired the id rather than reusing it,
+ * and AT-1 and AT-8a are cited on F4.4, where the object arrives.
+ *
+ * WHY THIS SCHEMA IS CLOSED, AND WHY THAT IS THE SECURITY PROPERTY RATHER
+ * THAN A STYLE CHOICE. AT-8b: every AT-1 field is REQUIRED; there are no
+ * optional fields, no defaultable fields, and no extension points. An object
+ * carrying an unknown field, or omitting any AT-1 field, MUST be rejected —
+ * never normalized, never defaulted. That is why `additionalProperties` is
+ * false and why `required` lists every property, and it is the one place in
+ * this repository where an absent-value rule would be a DEFECT rather than a
+ * control: `x-acp-absent` deliberately appears nowhere below.
+ *
+ * The reason is Z4. AT-8a pinned the canonicalizer but not the field set.
+ * Given ANY optional field, an object present-as-null and the same object
+ * with the field omitted are EACH valid canonical CBOR, hash to TWO DISTINCT
+ * ids, and therefore claim TWO ledger slots — one attestation, consumed
+ * twice. T-14 attestation amplification reopens through the very mechanism
+ * Y1b closed. Canonicalization cannot fix it: the ambiguity is in the field
+ * set, not the encoding. Mechanized as `Z4_OptionalFieldYieldsTwoIds`.
+ *
+ * CONSEQUENCE FOR ANYONE EDITING THIS FILE: adding a field here is a
+ * BREAKING change requiring a `receipt_version` increment, never an additive
+ * one (AT-8b). A future revision that adds an optional field to be helpful
+ * reopens T-14.
+ *
+ * ENCODING. The wire form is canonical CBOR, RFC 8949 §4.2 (AT-8a) — the
+ * same canonicalization as the receipt (WE-1/WE-2). JCS (RFC 8785) MUST NOT
+ * be used for this object; JCS is the Proposal's rule and mixing them is the
+ * encoding split at the point it does the most damage. JSON here is the
+ * diagnostic form the schema is written against, never an accepted input. An
+ * object whose RECEIVED encoding is not the canonical one MUST be rejected
+ * and MUST NOT be re-serialized and accepted.
+ *
+ * WHAT IS NOT A FIELD. `attestation_id` is DERIVED, not carried: it is
+ * SHA-256 over the canonical CBOR encoding of this object (AT-1, AT-8a) and
+ * the Executor recomputes it (§9.3 step 7b(v)). Transmitting it for trust is
+ * what v1.3.2 did, and under one compromised KMS a receipt bearing a genuine
+ * quorum raised for proposal P1 verified against an attacker-chosen P2 — Y1.
+ * A schema that gave `attestation_id` a property would invite exactly that
+ * read, so it has none.
+ *
+ * SUITE 12 CLASSIFICATION. Every field below is class T at the schema layer
+ * — this document constrains SHAPE, and shape is not authority. The
+ * Executor's obligations are elsewhere and are not restated here
+ * (DP-3/DP-84): `proposal_hash` is bound (9.3-3), floor-only risk is
+ * RECOMPUTED and never read from here (TR-8), and `required_count` is
+ * subject to AT-9's two disjoint rules described on that property.
+ * Generated from attestation_object.schema.json.
+ */
+export interface AttestationObject {
+    /**
+     * The suite this attestation was raised under. CR-1: every signed structure
+     * carries an explicit `alg` naming a suite registered in the signed bundle,
+     * and an unregistered or unknown name fails closed rather than being
+     * resolved to a known one.
+     *
+     * IT IS AN AT-1 FIELD, WHICH IS WHY IT IS HERE AND NOT BESIDE THE SIGNATURE.
+     * CR-5 makes `alg` signature-covered, so it sits inside the canonical CBOR
+     * whose SHA-256 is `attestation_id` (AT-8a). An issuer who could relabel the
+     * suite without changing the object would hand a verifier a hybrid entry to
+     * check as a classical one, and CR-3's conjunctive rule would be decorative
+     * at the point it is applied. PB-8 records the same reasoning for the bundle
+     * signature file and anchor.schema.json restates it for the anchor; this is
+     * the third artifact it governs and the one where the field set is closed by
+     * AT-8b, so a verifier reading `alg` from anywhere else would be reading a
+     * field the object may not carry.
+     *
+     * WHAT THE VERIFIER DOES WITH IT IS NOT ONE RULE BUT TWO, AND THE SCHEMA
+     * CANNOT PICK. For a `hybrid` registry entry the name is a machine suite and
+     * CR-4 compares it against the bundle's registered floor by CONTAINMENT of
+     * primitives, never by rank. For a `webauthn` entry it is one of HM-4's two
+     * key types, CR-8 puts a human leg outside that floor entirely, and HM-3
+     * requires it to EQUAL the registry entry's `alg`, refusing a mismatch
+     * before a byte of the assertion is examined. Which rule applies is decided
+     * by the registry, which this object does not name, so the shape layer
+     * admits both vocabularies and narrows nothing. See `attestation_alg` below
+     * for why that is a union of two declarations and not a third list.
+     *
+     * ADDED IN v1.3.31 (ACP-299), AS A CORRECTION AND NOT A FEATURE. This schema
+     * had no `alg` property through v1.3.30 while CR-5 called it an AT-1 field,
+     * `reference/src/acp_executor.py` listed it in `AT1_FIELDS` and
+     * `crates/acp-decision/src/quorum.rs` listed it in `AT1_FIELDS` and
+     * re-parsed it to pick the suite. The field set is CLOSED in both directions
+     * (AT-8b), so an object built from this file was refused by both verifiers
+     * for missing a field, and an object either verifier accepted carried a
+     * field this file called additional. The cross-language differential could
+     * not see it, because the two implementations agreed with each other and
+     * disagreed with the document -- the eighth lesson in
+     * `dossier/05-TEST-EVIDENCE.md`, and exactly the shape ACP-167 had one field
+     * over. `tools/check-attestation-object.py` is the executable consumer that
+     * would have caught it and now does.
+     */
+    readonly alg: AttestationAlg;
+    /**
+     * The canonical Proposal this attester signed. The binding the whole object
+     * exists to carry: the Executor verifies the executed proposal hashes to
+     * this value (9.3-3) rather than trusting that it does.
+     */
+    readonly proposalHash: Sha256Hash;
+    /**
+     * The signed bundle in force when the attestation was raised.
+     */
+    readonly policyBundleHash: Sha256Hash;
+    /**
+     * Epoch of that bundle. Monotonicity is enforced at the KMS against a
+     * durable high-water mark (RAD-3), never from this value.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minimum 0.
+     */
+    readonly bundleEpoch: number;
+    /**
+     * The Context read the Decision was computed over (§8.8 `snapshot_hash()`).
+     */
+    readonly contextSnapshotHash: Sha256Hash;
+    /**
+     * FLOOR-ONLY risk, not effective risk. AT-3 requires the attester to have
+     * been shown floor tiers and the bundle `rule_id`s that raised the risk, NOT
+     * Context-asserted values — that separation is what closes A-8's display
+     * path. The Executor recomputes this from the signed bundle and the
+     * canonical Proposal (TR-8); a disagreement with the value here is a
+     * critical alert, because it means the signing substrate emitted a Decision
+     * the bundle does not support.
+     */
+    readonly floorOnlyRisk: Risk;
+    /**
+     * Attester roles the rule demanded. `uniqueItems` because a repeated role is
+     * a second spelling of one requirement, and two spellings of one thing is
+     * the defect this repository is built around.
+     *
+     * THE ARRAY MAY BE EMPTY, AND EMPTY HAS A MEANING: the rule demanded a
+     * quorum and named no role, so any enrolled attester of the right kind
+     * satisfies it. AT-8b keeps the FIELD required — an absent `required_roles`
+     * is still a refusal, because an absent field and an empty array would be
+     * two encodings of one object (Z4) — but nothing sets a lower bound on its
+     * length.
+     *
+     * `minItems: 1` STOOD HERE THROUGH v1.3.31 AND WAS REMOVED IN v1.3.32
+     * (ACP-308). It was a schema-level choice with no clause behind it — the
+     * shape `operator_id` already records about its own length bound — and it
+     * made the common case invalid: `tools/check-attestation-object.py` found on
+     * its first run that the simulation builds a floor-HIGH object with
+     * `required_roles: []` for every action whose rule names no role, which is
+     * four of its five floor-HIGH actions. Neither verifier reads this field for
+     * the quorum DECISION: the threshold is `quorum_k` from the signed bundle
+     * (AT-9, PB-6, class R) and role membership is resolved against the
+     * registry, so an empty list withholds nothing a verifier needed. Stating
+     * the bound in AT-1 instead was the alternative, and it was rejected because
+     * it would force every floor-HIGH rule an operator writes to invent a role
+     * name for a requirement it does not have — a policy-authoring obligation
+     * this document never asked for, imposed by a validator rather than by a
+     * clause.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: uniqueItems; items minLength 1, maxLength 128.
+     */
+    readonly requiredRoles: readonly string[];
+    /**
+     * The threshold the attester was shown and signed.
+     *
+     * AT-9 places TWO requirements on this field and NEITHER SUBSTITUTES FOR THE
+     * OTHER. (1) It MUST NOT be an input to the quorum decision, in whole or in
+     * part, INCLUDING where every entry agrees on it: the threshold is taken
+     * from the signed bundle's `quorum_k` (PB-6) and is class R — recomputed.
+     * `required_count` is signed by the attester, and the attester is exactly
+     * the party under verification, so reading the threshold from it asks the
+     * adversary how large a quorum to demand. (2) It MUST nonetheless equal
+     * `quorum_k`, and a mismatch MUST fail closed with a critical alert —
+     * because it is part of what the attester was SHOWN (AT-3), so a mismatch
+     * means the humans approved under a policy the engine did not apply.
+     *
+     * An implementation that keeps only (1) satisfies INV-1-HIGH while silently
+     * executing actions no attester agreed to. This clause exists because its
+     * absence was exploited — see the v1.3.15 alert in §1(a).
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minimum 1.
+     */
+    readonly requiredCount: number;
+    /**
+     * The operator the action is attributed to. Carried HERE, inside the
+     * signature, so approver-distinctness (AT-2) and the §9.3 step-9 capability
+     * recheck key on a signature-covered value rather than a receipt-body claim.
+     * The receipt's top-level `operator` is diagnostic only. Mechanized as
+     * `Y4_OperatorTamperDetected`.
+     */
+    readonly operator: OperatorId;
+    /**
+     * A fresh 128-bit attestation nonce (AT-1), making the derived
+     * `attestation_id` unique per attestation. Single use is enforced by ledger
+     * consumption of that id (AT-5, CL-3), not by assertion — v1.2.0 stated
+     * single-use as a property with no enforcing mechanism, which permitted
+     * attestation amplification (T-14).
+     */
+    readonly attNonce: Nonce128;
+    /**
+     * RFC 3339 instant, at most 60 minutes after issuance (AT-1). Expired
+     * attestations are void and partial quorum at expiry is void (AT-5).
+     * Evaluated against NTS-disciplined wall time within the L-20 skew
+     * allowance, never against a monotonic clock — leg F9.1 carries that
+     * dependency and DP-52 states the distinction.
+     */
+    readonly expiresAt: Rfc3339Instant;
+}
+/**
+ * The lenient projection of AttestationObject: every field optional, every enum
+ * degraded to `string`. What a verifier parses. Never make a decision on
+ * one — the fail-safe lookups live on the strict type only.
+ */
+export interface RawAttestationObject {
+    readonly alg?: string;
+    readonly proposalHash?: string;
+    readonly policyBundleHash?: string;
+    readonly bundleEpoch?: number;
+    readonly contextSnapshotHash?: string;
+    readonly floorOnlyRisk?: string;
+    readonly requiredRoles?: readonly string[];
+    readonly requiredCount?: number;
+    readonly operator?: string;
+    readonly attNonce?: string;
+    readonly expiresAt?: string;
+}
+/**
+ * VOCABULARY PINNED BY AU-9 (v1.3.27). `event_class` is one of seven values
+ * declared in `$defs/event_class`; every record carries `event_class`,
+ * `tenant_id`, `seq` and `occurred_at`; and each class carries EXACTLY the
+ * further fields §11.1's table names for it -- a `decision` record the
+ * twenty members this schema had always required, an `ingress_refused`
+ * record the four a door can know, an `execution` record the EX-2 `outcome`
+ * this schema had no place for. Every field below `seq` is therefore
+ * optional AT THE SCHEMA LAYER and required BY CLASS, and the consumer
+ * refuses a record whose set is not its class's before hashing it (AU-9),
+ * because JSON Schema cannot say `required when event_class is X` in a form
+ * this repository's generator has a rule for, and a consumer that hashed
+ * first and checked second would have chained a record it then refused.
+ * Until v1.3.27 this file was §11.1's decision record only: a door could not
+ * build one, nothing recorded what RAN, and the timestamp's key name and the
+ * class's value domain were both unpinned inside the AU-1 preimage -- so two
+ * conformant implementations wrote different chain hashes for identical
+ * histories (ACP-153, items 16-18; found by the first audit service).
+ *
+ * The record of one pipeline event. Carried on leg F6.1 of the leg register
+ * (ZIFFER-DEPLOY-001 Annex A), Executor to Audit subsystem, cited there
+ * against AU-2. It is `record_n` -- the object AU-1 places inside the chain
+ * preimage -- and nothing else.
+ *
+ * WHY THIS IS A HASHED ARTIFACT AND NOT A LOG LINE. AU-1 (REVISED in
+ * v1.3.15): `chain_hash_n = H({"prev": chain_hash_{n-1}, "record":
+ * record_n})`, where §11.2 defines `H(x)` as the ASCII string `"sha256:"`
+ * followed by the lowercase-hex SHA-256 of `canonical(x)`, and `canonical()`
+ * is the single canonicaliser of AT-8a -- canonical CBOR, RFC 8949 §4.2. The
+ * record therefore sits INSIDE a hash preimage, so its field set and its key
+ * names are load-bearing in exactly the way AT-8b's are one artifact over.
+ * AU-1 says as much about its own two keys: *the key names are part of the
+ * preimage*. Two encodings of one event are two chain hashes, and from that
+ * link onward two honest parties hold two different chains.
+ *
+ * WHAT THAT COSTS WHEN IT GOES WRONG, WHICH IS NOT A LOST COMPARISON. AU-3a
+ * requires every anchor to be independently verifiable by any party holding
+ * the anchor public keys, and AU-4 makes a head that fails to extend a
+ * previously anchored head a CRITICAL INTEGRITY ALERT. So an encoding
+ * ambiguity in this object routes an honest third-party verifier into this
+ * system's own critical-alert channel with no attacker present. That is
+ * ACP-57 -- the correction recorded in §1 and at AU-1, where the clause
+ * specified a concatenation and `reference/src/acp_audit.py` had always
+ * hashed a two-key map, so AU-3a did not hold as written. ACP-57 was a
+ * defect in the clause immediately ABOVE this object. This schema is the
+ * field set the same defect would live in, one layer down.
+ *
+ * WHY THE FIELD SET IS CLOSED, AND WHERE THAT CLOSURE EXCEEDS WHAT §11.1
+ * STATES. Every property below is REQUIRED and `additionalProperties` is
+ * false, because an optional field admits two canonical encodings of one
+ * event -- present-as-null and omitted -- which is Z4 read at the chain
+ * layer: not two ledger slots this time, but two chains, and the divergence
+ * surfaces as AU-4's critical alert against an honest party. AT-8b closes
+ * exactly this for the Attestation Object and L-26 records it as a limit; no
+ * clause closes it here.
+ *
+ * AND THE SPECIFICATION DOES NOT SUPPORT THE CLOSED READING. §11.1 requires
+ * *all relevant hashes*, and the word RELEVANT is the whole problem: it
+ * makes the field set vary by event class, the document enumerates neither
+ * the event classes nor which hashes are relevant to each, and it defines no
+ * representation for an absent value. A conditional field set is Z4; a
+ * closed one demands values a producer cannot always have (`raw_input_hash`
+ * at the Executor is the clean case -- see that property). This schema takes
+ * the closed reading because it is the only encoding-safe one, and records
+ * the gap rather than resolving it by invention. Until §11.1 pins either a
+ * per-event-class field set or an absent encoding, no schema for this object
+ * can be both closed and conformant.
+ *
+ * §11.1 IS ALSO NOT THE WHOLE RECORD ON ITS OWN TERMS. SR-5 adds the
+ * `(schema_id, schema_version, schema_hash)` triple and the fidelity class
+ * to every audit record; B-2 requires every model-call record to assert that
+ * provider-side tool features were disabled; EX-3 requires a
+ * verification-failure record to carry the offending receipt; DR-11/L-29
+ * require the confirmation-sampling draw to be recorded in audit; DR-12/L-30
+ * require the unacknowledged-release counter to be. Five clauses add record
+ * content that §11.1 does not list. The SR-5 triple is below because it is
+ * stated of every audit record; the other four are event-class-specific and
+ * are named here rather than guessed at.
+ *
+ * WHAT IS NOT A FIELD. `chain_hash` and `previous_hash` are AU-2's STORAGE
+ * constraints on the row the receiver writes, not content of the record the
+ * sender sends: the receiver computes them per AU-1 after this object
+ * arrives (F6.1 carries the record, F6.2 carries the `chain_hash`). A record
+ * carrying its own chain hash would be self-referential, and a record
+ * carrying its own `previous_hash` would let the audited party name its own
+ * link -- the audited party supplying the evidence of its own position,
+ * RES-8 with the writer as the source. AU-8's tenant-creation record is
+ * likewise not this object: it is a four-key map `{tenant_id, created_at,
+ * bundle_epoch, schema_version}`, anchored immediately on tenant creation,
+ * and modelling it here would put two objects in one schema. The anchor
+ * (AU-3) is a third artifact on legs F6.3/F6.4. `audit_id` is absent because
+ * §11.1 does not list it, even though §9.2's receipt carries one and R-1
+ * returns one to a rejected caller.
+ *
+ * WHAT THIS SCHEMA DOES NOT CONSTRAIN, STATED SO THE CLAIM IS NOT READ WIDER
+ * THAN IT IS. Every ordering property is invisible here. AU-7
+ * anchor-before-release, AU-2's UNIQUE and GAPLESS `(tenant_id, seq)` and
+ * its SERIALIZABLE or single-writer-per-tenant discipline, AU-6's outage
+ * behaviour, AC-5's count-at-release, and all eight §11.3 reconciliation
+ * checks are properties of a SEQUENCE of records and of the writer's
+ * discipline. No instance check can see one of them: a schema-valid record
+ * says nothing about whether it was anchored before its action was released.
+ * They are per-implementation obligations (`spec/vectors/OBLIGATIONS.md`)
+ * exercised in `reference/suites/audit_suite.py`, and a conformance claim
+ * resting on this schema is a claim about shape only.
+ *
+ * SUITE 12 CLASSIFICATION. Every field below is class T at the schema layer,
+ * and no consumer may promote any of them. An audit record is testimony
+ * produced INSIDE the production trust domain -- the domain §11.3 places
+ * under suspicion when it puts reconciliation in the anchor-verifier's
+ * domain (AU-4) -- so a control input read from here would be the RES-8
+ * defect with the audited party as the source. §9.2's authority note already
+ * says `risk_level_effective`, `risk_level_floor_only` and `fidelity` are
+ * diagnostic and audit fields only, and TR-8 requires the Executor to
+ * recompute floor-only risk from the signed bundle and the canonical
+ * Proposal. Reconciliation checks this record against ANCHORS and the
+ * CONSUMPTION LEDGER, never against itself.
+ *
+ * ENCODING. Canonical CBOR, RFC 8949 §4.2, via §11.2's `H` and AT-8a's
+ * single canonicaliser. The JSON here is the diagnostic form the schema is
+ * written against, never an accepted input.
+ *
+ * NO `x-acp-absent` APPEARS BELOW, DELIBERATELY. No clause declares a
+ * fail-safe default for a missing audit-record field. Inventing one would
+ * let an unparseable record be silently completed and chained, which is the
+ * opposite of what a tamper-evidence chain is for: P-4's default-DENY is
+ * about policy evaluation and does not reach record parsing.
+ * Generated from audit_record.schema.json.
+ */
+export interface AuditRecord {
+    /**
+     * The class of pipeline event this record is of (§11.1, first item). It is
+     * what makes §11.1's *all relevant hashes* even readable -- relevance is
+     * relevance TO AN EVENT CLASS -- so it is the field the rest of the record's
+     * conditionality would hang from.
+     *
+     * THE VALUE DOMAIN IS AU-9's (v1.3.27): `ingress_refused`, `decision`,
+     * `verification_failed`, `hold`, `notice`, `release`, `execution` -- one per
+     * pipeline event the flow register puts a record on (F1.1, F6.1, DR-1,
+     * DR-13, DR-7/9/10/12, EX-2, EX-3). Through v1.3.26 no clause enumerated it,
+     * and this repository held three vocabularies for one field: the reference's
+     * `type` with `hold`/`release`, an AU-1 suite case's `event`, and §11.1's
+     * words. The consequence was not cosmetic: AU-1 hashes this record, so
+     * different strings for one event were different chain hashes for identical
+     * histories, and AU-3a's independent verifier could recompute neither. The
+     * reference now writes THIS key with THESE values, and AU-9 makes a value
+     * outside the set a refusal rather than a fourth vocabulary.
+     */
+    readonly eventClass: AuditEventClass;
+    /**
+     * The tenant whose chain this record extends. §11.1 lists *tenant*; AU-1
+     * makes chains PER-TENANT, AU-2 keys uniqueness and gaplessness on
+     * `(tenant_id, seq)`, and AU-8 puts `tenant_id` in the genesis preimage, so
+     * the identifier is the specification's own and not a name coined here.
+     *
+     * IT NAMES A CHAIN AND DOES NOT SELECT ONE (RES-8). A receiver that resolves
+     * WHICH chain to append to from this field has let the writer choose its own
+     * history; D-1 gives every tenant dedicated per-tenant executor credentials
+     * and schemas precisely so the authenticated connection is what answers.
+     * Carried anyway, because it is inside the AU-1 preimage: a record whose
+     * tenant is implicit at write time and explicit at verification time is one
+     * event with two encodings, and the chain would not survive that.
+     */
+    readonly tenantId: TenantId;
+    /**
+     * The session the event occurred in (§11.1, third item). The specification
+     * uses the bare word `session` in exactly one other place that types it at
+     * all -- §8.5's accumulator `group_by` lists `["operator","session"]` -- so
+     * the key name here is that word and no other. It is load-bearing beyond
+     * forensics: §4.2 scopes cross-session persistence OUT of the accumulator
+     * model (*fresh session credentials reset session-scoped accumulators*),
+     * which makes the session boundary an attacker-visible reset, and the audit
+     * record is the only place a reconciler can see how an operator's activity
+     * was partitioned across sessions.
+     *
+     * `maxLength` is L-04. No format is pinned because no clause pins one.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minLength 1, maxLength 2048.
+     */
+    readonly session?: string;
+    /**
+     * The operator the event is attributed to (§11.1, fourth item; §8.5 groups
+     * accumulators by the same key). It is the principal AT-2
+     * approver-distinctness and DR-9 acknowledgement are stated about, and the
+     * principal AC-5's deny-effect accumulators can lock out -- which is why W1
+     * mattered: counters inflated by Decisions that never executed are a
+     * targeted lockout of a legitimate operator.
+     *
+     * THIS IS A RECORD OF AN ATTRIBUTION, NOT THE ATTRIBUTION ITSELF. The
+     * authoritative operator identity for approver-distinctness and the §9.3
+     * step-9 capability recheck is `attestations[].obj.operator`, which is
+     * signature-covered (Y4); §9.2 says in as many words that the receipt's
+     * top-level `operator` is diagnostic only. An audit record is one level
+     * further from the signature than that receipt field, so nothing may key a
+     * control decision on this value.
+     */
+    readonly operator?: OperatorId;
+    /**
+     * The fidelity class of the adapter the event descends from. Required twice
+     * over: §11.1 lists it in the record, and SR-5 states that every Atom,
+     * Proposal, Decision and audit record carries the `(schema_id,
+     * schema_version, schema_hash)` triple AND the fidelity class.
+     *
+     * WHY IT IS AUDITED AT ALL. FC-1 makes the class the difference between
+     * injection being grammatically impossible (F-HIGH) and containment resting
+     * entirely on capability limits, confirmation and receipts (F-LOW), and FC-2
+     * lets policy condition on it. A receipt asserting `fidelity: "F-HIGH"` for
+     * a Proposal from an F-LOW-bound adapter MUST fail closed with a critical
+     * alert (§14 suite 3), which is possible only because the true class is
+     * recorded somewhere the adapter binding can be reconciled against. The key
+     * name is §9.2's receipt field name `fidelity`; §11.1's phrase is *fidelity
+     * class*.
+     */
+    readonly fidelity?: FidelityClass;
+    /**
+     * First member of SR-5's triple, which every audit record carries. The
+     * triple is what lets a replayed Decision be re-derived against the schema
+     * that actually admitted the input: §11.3(e) re-derives sampled Decisions by
+     * replay and calls a mismatch critical, and SR-6 retires schemas after 180
+     * days, so a record naming only a version would become unresolvable. Same
+     * key name as §9.2's receipt field.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minLength 1, maxLength 2048.
+     */
+    readonly schemaId?: string;
+    /**
+     * Second member of SR-5's triple. Carried beside `schema_hash` rather than
+     * instead of it because a version is a NAME for a schema and the hash is the
+     * evidence of which bytes were used -- SR-3's narrowing rules move the
+     * admissible set between versions, so a replay that trusted the version
+     * alone would re-derive against a different grammar than the one that ran.
+     * No format is pinned; no clause pins one.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minLength 1, maxLength 2048.
+     */
+    readonly schemaVersion?: string;
+    /**
+     * Third member of SR-5's triple, and the only member of it that is evidence
+     * rather than a label. §8.4 step 1 admits a Proposal only against a
+     * `(schema_id, version, hash)` valid in the bundle, so this is the value
+     * that ties the recorded event to bundle-attested bytes.
+     */
+    readonly schemaHash?: Sha256Hash;
+    /**
+     * The hash of the external input the event descends from (§11.1, first of
+     * the enumerated hashes).
+     *
+     * THIS FIELD IS WHERE §11.1 AND LEG F6.1 CONTRADICT EACH OTHER, AND THE
+     * CONTRADICTION IS RECORDED RATHER THAN SMOOTHED. `raw_input_hash` occurs
+     * exactly ONCE in ZIFFER-SPEC-001 -- in §11.1's own sentence -- and no
+     * clause says what it covers, at which point of §5.1's flow it is taken, or
+     * under which canonicalisation. For an F-LOW adapter the raw input is free
+     * text, so *canonical* has no meaning for it at all. Worse for this leg: the
+     * Executor never sees the raw input (§5.1 puts the Ingress Adapter and the
+     * validators upstream of the Policy Engine, and D-2 gives the model path no
+     * route to the Executor segment), and neither §9.2's receipt nor the
+     * canonical Proposal carries the value -- so an Executor writing an F6.1
+     * record can only forward a number it was handed, class T with no verifier
+     * anywhere on the path, or omit it and split the encoding (Z4 at the chain
+     * layer). The specification supports neither. Kept in the schema because
+     * §11.1 states it unconditionally, and flagged because writing the field
+     * down is what made the contradiction visible.
+     */
+    readonly rawInputHash?: Sha256Hash;
+    /**
+     * The canonical Proposal (B-1a) the event is about (§11.1). It is the join
+     * key for most of §11.3: (a) matches execution records to receipts, and
+     * DS-6f pins one immutable `proposal_hash -> origin_nonce` binding per
+     * Proposal in the Consumption Ledger with INDEFINITE retention, which the
+     * reconciler reads from the ledger and never from a record like this one.
+     * Canonicalisation for the Proposal is JCS (RFC 8785) per WE-1/WE-2, not the
+     * CBOR that encodes this record -- the two canonicalisers coexist by
+     * artifact, and mixing them is the encoding split AT-8a exists to prevent.
+     */
+    readonly proposalHash?: Sha256Hash;
+    /**
+     * The signed bundle in force for the event (§11.1). Recorded so a Decision
+     * can be re-derived (§11.3(e)) against the exact policy that produced it:
+     * PB-1 expires bundles and §8.2 rules move, so a record naming only an epoch
+     * would be replayable only while that bundle survived.
+     */
+    readonly policyBundleHash?: Sha256Hash;
+    /**
+     * The epoch of that bundle (§11.1). §11.3(d) reconciles every signing event
+     * against a `bundle_epoch` greater than or equal to all prior epochs, which
+     * is the rollback detection, and L-24 makes the epoch a strictly increasing
+     * integer that is never reused.
+     *
+     * DETECTION HERE, ENFORCEMENT ELSEWHERE (RES-8). Monotonicity is enforced at
+     * the KMS against a durable high-water mark (RAD-3) with indefinite
+     * retention in the ledger (CL-4), never from an audited value: an epoch read
+     * back from the chain the production domain writes would let a compromised
+     * writer lower its own high-water mark. `minimum: 0` is the type's floor,
+     * matching AU-8's genesis record, which carries an epoch before any signing
+     * event exists.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minimum 0.
+     */
+    readonly bundleEpoch?: number;
+    /**
+     * The Context read the Decision was computed over (§11.1; §8.8
+     * `snapshot_hash()`). Recorded because the Context Store is adversarial in
+     * this threat model -- §8.3.2 leaves it able to raise tier or withhold
+     * capability facts -- so re-deriving a sampled Decision (§11.3(e)) requires
+     * knowing which snapshot was read, and INV-1-MEDIUM's disclosed residual is
+     * only investigable against a pinned snapshot.
+     */
+    readonly contextSnapshotHash?: Sha256Hash;
+    /**
+     * The nonce of the Decision Receipt the event is about (§11.1, *receipt
+     * nonce*; the receipt's own field name in §9.2 is `nonce`, and §11.1 does
+     * not say which spelling belongs in the record).
+     *
+     * WHY IT IS IN THE RECORD. It is the identity a receipt is consumed under:
+     * CL-2/CL-3 consume receipt nonces once against the linearizable ledger,
+     * §9.3 step 6 claims it atomically, and DS-6a makes the FIRST receipt's
+     * nonce the `origin_nonce` half of `action_id = (proposal_hash,
+     * origin_nonce)`. §11.3(a) reconciles every execution record against exactly
+     * one valid receipt, and orphan executions are critical -- that check needs
+     * this value in the record.
+     *
+     * AND IT IS THE FIELD THAT MAKES THE CLOSED READING UNSATISFIABLE. A
+     * pattern-constrained string has no empty encoding, so an event class with
+     * no receipt -- an ingress rejection under R-3, a model call under B-2 --
+     * cannot produce a schema-valid record without one, and no clause supplies
+     * an absent form. `attestation_ids` escapes the same problem only because an
+     * empty ARRAY is a single well-defined canonical encoding while an absent
+     * field is two readings. Size is L-17's 128 bits; type is WE-4.
+     */
+    readonly receiptNonce?: Nonce128;
+    /**
+     * The `attestation_id`s of the Attestation Objects the event consumed
+     * (§11.1, *attestation IDs*). Each is SHA-256 over the canonical CBOR
+     * encoding of the whole object (AT-1, AT-8a), RECOMPUTED by the Executor at
+     * §9.3 step 7b(v) and never taken as transmitted -- transmitting the id for
+     * trust is what v1.3.2 did and what Y1 broke. So the values here are a
+     * record of a recomputation, which is the only kind of derived value an
+     * audit record may honestly carry.
+     *
+     * WHY IT MATTERS THAT THEY ARE RECORDED. §11.3(c) reconciles every
+     * `attestation_id` against exactly one receipt and at most one execution --
+     * the check whose absence permitted T-14, attestation amplification. A
+     * reconciler running outside the production domain (AU-4) can only perform
+     * it against records that name the ids.
+     *
+     * THESE ARE NOT `attestation_digests`. Under receipt version 3 (§8.6b, AB-1)
+     * the receipt commits to entry digests taken over the whole entry -- object,
+     * `kind`, `attester` and `sig` together -- while an `attestation_id` is over
+     * the object alone. Two different values over overlapping bytes; recording
+     * the wrong one makes §11.3(c) silently compare nothing.
+     *
+     * AN EMPTY ARRAY IS THE CORRECT ENCODING FOR AN EVENT THAT CONSUMED NO
+     * ATTESTATION, and it is deliberately not modelled as an absent field: `[]`
+     * has one canonical CBOR encoding, an omitted key has two readings, and two
+     * readings is the chain divergence this schema exists to prevent.
+     * `uniqueItems` because one attestation appearing twice in one record is one
+     * approval counted twice, which is T-14 in miniature.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minItems 0, uniqueItems.
+     */
+    readonly attestationIds?: readonly Sha256Hash[];
+    /**
+     * The floor-only risk the Policy Engine computed (§11.1, *floor-only and
+     * effective risk*; the key name is §9.2's receipt field). Floor-only means
+     * derived from the SIGNED BUNDLE's tier floors and rules, with no
+     * Context-asserted raise folded in -- §8.3.2's separation, which is what
+     * keeps a compromised Context Store from suppressing escalation (TR-4,
+     * `FloorDominance`).
+     *
+     * DIAGNOSTIC AND AUDIT ONLY, IN THE SPECIFICATION'S OWN WORDS. §9.2's
+     * authority note classifies this field non-authoritative in the receipt, and
+     * TR-8 requires the Executor to RECOMPUTE it from the signed bundle and the
+     * canonical Proposal; a transmitted value disagreeing with the recomputation
+     * is a critical alert at §9.3 step 7a. That history is why the note exists:
+     * v1.3.0 keyed the Executor's quorum requirement on the receipt's value, so
+     * one compromised KMS could sign a floor-T3 action as `LOW` with no
+     * attestations and defeat INV-1-HIGH. A value one hop further from the
+     * signature must not be treated any better.
+     */
+    readonly riskLevelFloorOnly?: Risk;
+    /**
+     * The effective risk -- floor composed with Context-asserted raises and
+     * accumulator effects (§8.4, §8.5) -- recorded beside the floor-only value
+     * because §11.1 requires BOTH. Recording only one loses the ability to
+     * reconstruct why an action attested: the pair is the evidence of which side
+     * raised it, and a raise that appears in the effective value and not the
+     * floor is a Context Store claim rather than a bundle rule. Diagnostic and
+     * audit only, per §9.2's authority note.
+     */
+    readonly riskLevelEffective?: Risk;
+    /**
+     * The disposition the Policy Engine reached (§8.4 step 11; §5.1's flow
+     * renders the engine's output as `ALLOW/ATTEST/DENY`; §9.2's receipt field
+     * carries the same name).
+     *
+     * THIS IS THE ONLY MEMBER OF §11.1'S *Decision fields* THIS SCHEMA PINS, AND
+     * THE REST IS AN OPEN QUESTION RATHER THAN AN OMISSION. §11.1 says *Decision
+     * fields* and enumerates none. §9.2's receipt body carries a dozen
+     * candidates -- `rule_id`, `receipt_version`, `issued_at`, `expires_at`,
+     * `idempotency_key` among them -- and guessing which of them §11.1 meant
+     * would be this schema legislating where the specification is silent, which
+     * is how a second definition of one object gets created. Only the
+     * disposition itself is taken, because it is the one field both §8.4 and
+     * §9.2 name as THE Decision.
+     *
+     * `DENY` is included on P-4's authority as much as step 11's: no matching
+     * rule, unknown capability, unclassified resource or unavailable Context
+     * Store each resolve to DENY with a distinct reason code, and R-3 requires
+     * every rejection to produce an audit record -- so a record that could not
+     * express a refusal would leave the entire fail-closed path unauditable.
+     */
+    readonly decision?: DecisionOutcome;
+    /**
+     * The monotonic sequence number of this record within its tenant's chain
+     * (§11.1, last item). AU-2 makes `(tenant_id, seq)` UNIQUE and GAPLESS, with
+     * inserts appending under SERIALIZABLE or single-writer-per-tenant
+     * discipline.
+     *
+     * WHY THE MINIMUM IS 1 AND NOT 0. AU-8 defines `chain_hash_0` over the
+     * tenant-creation record, and AU-1 pairs `chain_hash_n` with `record_n`, so
+     * index 0 is genesis and the first pipeline event is n = 1. The
+     * tenant-creation record is a different object (see this schema's
+     * description) and never appears here.
+     *
+     * IT NAMES A POSITION AND IS NOT EVIDENCE OF ONE (RES-8). Gaplessness and
+     * uniqueness are properties the WRITER enforces under AU-2's own discipline;
+     * a receiver that appends at the sequence number its sender chose has let
+     * the sender place its own link, and a chain whose positions are supplied by
+     * the party under audit is not tamper-evident. The value is carried because
+     * §11.1 puts it in the record and AU-1 hashes the record -- but the receiver
+     * assigns and verifies it.
+     *
+     * RESOLVED IN v1.3.28 (ACP-164): WRITER PROPOSES, RECEIVER VERIFIES. The
+     * finding this paragraph used to record was that the reference refused a
+     * writer-supplied `seq` and stamped its own, while this schema makes the
+     * field REQUIRED -- so the generated `AuditRecord`, which types `seq` as a
+     * required integer, could not express a message the reference would accept,
+     * and no F6.1 vector could satisfy both. The resolution is the
+     * compare-and-retry shape ziffer's audit service already shipped for three
+     * concurrent writers per chain: the writer names the position it believes is
+     * next, and `AuditChain.append` refuses a mismatch under AU-2 with the
+     * EXPECTED position in the refusal, which is the whole retry protocol. The
+     * receiver still decides -- it never appends AT the writer's number, it
+     * refuses unless that number is the one it was about to assign -- so the
+     * RES-8 paragraph above survives unchanged: naming the right position gains
+     * a writer nothing, and naming any other gains it a refusal. The preimage is
+     * the record as written, `seq` included.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minimum 1.
+     */
+    readonly seq: number;
+    /**
+     * RFC 3339 instant at which the event occurred, in the rendering §9.2 uses
+     * for `issued_at` and `expires_at`.
+     *
+     * THE CLAUSE THAT REQUIRES IT IS NOT §11.1, AND THAT IS THE POINT. §11.1's
+     * record content lists NO timestamp. §11.3(g) nonetheless reconciles every
+     * floor-HIGH execution record against *an anchor covering it, dated at or
+     * before release* -- a comparison the reconciler makes from outside the
+     * production trust domain (AU-4), where the record and the anchor are the
+     * only two things it can read. Without a time in the record the AU-7
+     * enforcement check has nothing to compare the anchor's date against, and
+     * AU-7 is what closed W3, the pre-anchor rewrite gap.
+     * `reference/src/acp_audit.py` carries the value under the key `at` and
+     * `reconcile()` compares `a["at"] > r["at"]` exactly as described.
+     *
+     * THE KEY NAME IS `occurred_at`, PINNED BY AU-9 (v1.3.27). The reference
+     * carried this value under `at`, and the anchor's date under `at` beside it;
+     * both are renamed to the names the wire schemas already used (`occurred_at`
+     * here, `anchored_at` in anchor.schema.json), because an unpinned key name
+     * for a required value inside the AU-1 preimage was a chain divergence
+     * waiting to happen.
+     *
+     * EVALUATED AGAINST NTS-DISCIPLINED WALL TIME within the L-20 skew allowance
+     * (§12.5, leg F9.1), never a monotonic clock: an anchor and a record are
+     * dated by different processes, and only wall time is comparable across
+     * them.
+     */
+    readonly occurredAt: Rfc3339Instant;
+    /**
+     * What happened, on the records AU-9 puts it on: an `execution` record
+     * carries EX-2's `executed`, `failed`, `not_attempted` or `indeterminate`
+     * (§9.5 -- `indeterminate` is what DS-3's reconciliation is keyed on, and it
+     * is a value here because a chain that cannot say an outcome was unknown
+     * cannot answer §11.3 (f)); a `release` record carries `executed` or
+     * `refused` (DR-7, DR-9, DR-10). Absent on every other class. Through
+     * v1.3.26 nothing in the record said what ran, so §11.3 (a) orphan
+     * executions, (f) indeterminate outcomes and (h) released executions could
+     * not be answered from a chain written in this vocabulary (ACP-153, item
+     * 17).
+     */
+    readonly outcome?: AuditOutcome;
+    /**
+     * On a `notice` record: who the signed bundle's `notice_targets.json` names
+     * for the action class (DR-13), as committed BEFORE execution. At least one,
+     * because DR-13 refuses to execute where the bundle names none -- a notice
+     * with no addressee is not a detection channel -- and a record that could
+     * carry an empty set would be that refusal written down as success.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minItems 1, maxItems 100.
+     */
+    readonly recipients?: readonly OperatorId[];
+    /**
+     * On a `release` record: the notified parties whose acknowledgements the
+     * Executor verified (ACK-1..6) before releasing. EMPTY for a silent release,
+     * and DR-12's per-tenant counter is the count of `release` records whose set
+     * is empty -- recorded in audit, as the clause requires, by being derivable
+     * from it rather than by a counter field a writer could set.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: maxItems 100.
+     */
+    readonly acknowledgedBy?: readonly OperatorId[];
+    /**
+     * On an `ingress_refused` or `verification_failed` record: the clause id the
+     * refusal fired under -- `B-6`, `V-1`, `9.3-7b(ii)` -- in the spelling
+     * `tools/clauses.py` indexes. It is the join key between a chain and the
+     * specification: an auditor reading `verification_failed` records grouped by
+     * clause is reading the threat table's countermeasures firing, which is what
+     * EX-3 puts the record there for.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: pattern `^[A-Za-z0-9.]{1,12}-[0-9]{1,3}[a-z]?(\([a-z-]{1,8}\))?$`,
+     * minLength 1, maxLength 32.
+     */
+    readonly clause?: string;
+    /**
+     * On an `execution` record: the target system's correlation identifier for
+     * the invocation (EX-2's `target correlation IDs`), so an `indeterminate`
+     * outcome can be resolved against the target's own record of what it did
+     * (DS-3). Opaque here; its meaning is the target's.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minLength 1, maxLength 256.
+     */
+    readonly correlationId?: string;
+}
+/**
+ * The lenient projection of AuditRecord: every field optional, every enum
+ * degraded to `string`. What a verifier parses. Never make a decision on
+ * one — the fail-safe lookups live on the strict type only.
+ */
+export interface RawAuditRecord {
+    readonly eventClass?: string;
+    readonly tenantId?: string;
+    readonly session?: string;
+    readonly operator?: string;
+    readonly fidelity?: string;
+    readonly schemaId?: string;
+    readonly schemaVersion?: string;
+    readonly schemaHash?: string;
+    readonly rawInputHash?: string;
+    readonly proposalHash?: string;
+    readonly policyBundleHash?: string;
+    readonly bundleEpoch?: number;
+    readonly contextSnapshotHash?: string;
+    readonly receiptNonce?: string;
+    readonly attestationIds?: readonly string[];
+    readonly riskLevelFloorOnly?: string;
+    readonly riskLevelEffective?: string;
+    readonly decision?: string;
+    readonly seq?: number;
+    readonly occurredAt?: string;
+    readonly outcome?: string;
+    readonly recipients?: readonly string[];
+    readonly acknowledgedBy?: readonly string[];
+    readonly clause?: string;
+    readonly correlationId?: string;
+}
+/**
+ * The bundle-epoch high-water mark consulted by RAD-3 (CL-3, T-15).
+ * Retention is INDEFINITE (CL-4): an expiring epoch mark reopens rollback,
+ * because a genuine but superseded and more permissive bundle becomes
+ * acceptable again the moment the mark that refused it is forgotten.
+ *
+ * THIS CLASS DOES NOT BEHAVE LIKE THE OTHER THREE, AND THE SPECIFICATION
+ * CALLS IT A CONSUMPTION ANYWAY. CL-3 lists bundle epochs under "Consumed
+ * identifier classes", but an epoch high-water mark is not consumed: many
+ * receipts legitimately reference the same epoch, and a ledger that treated
+ * this as at-most-once would refuse the second receipt issued under one
+ * bundle. CL-4 says as much by giving the mark indefinite retention while
+ * nonces and attestation ids expire. CL-3's own text does that disclosure
+ * for the fourth class -- "Unlike the three classes above this is a
+ * *binding*, not a consumption" -- and does not do it for this one. The
+ * divergence is recorded with this schema rather than resolved here, because
+ * deciding it is a normative act.
+ * Generated from ledger_claim.schema.json#/$defs/bundle_epoch_claim.
+ */
+export interface BundleEpochClaim {
+    readonly tenantId: TenantId;
+    readonly artifactClass: 'bundle_epoch';
+    /**
+     * The `bundle_epoch` of the receipt under verification (§9.2). An integer,
+     * not a digest, which is why the four classes cannot share one object:
+     * `identifier` is a string in the other three branches and there is no
+     * encoding of this value that is simultaneously both. Monotonicity is a
+     * LEDGER property compared against the durable mark, never a property of
+     * this value -- a claim asserting it is the highest epoch ever seen would be
+     * the claimant setting its own bar, which is what RAD-3 replaced the v1.2.0
+     * history window to prevent.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minimum 0.
+     */
+    readonly identifier: number;
+}
+/**
+ * The lenient projection of BundleEpochClaim: every field optional, every enum
+ * degraded to `string`. What a verifier parses. Never make a decision on
+ * one — the fail-safe lookups live on the strict type only.
+ */
+export interface RawBundleEpochClaim {
+    readonly tenantId?: string;
+    readonly artifactClass?: string;
+    readonly identifier?: number;
+}
+/**
+ * One asserted answer of `has_capability(operator, capability, resource)`
+ * (section 8.8). All three arguments are carried because all three identify
+ * the fact: an entry naming fewer of them answers a question nobody asked,
+ * and at section 9.3 step 9 the question is specific -- capability of THIS
+ * operator on THIS target. The reference implementation is the
+ * counterexample and it is worth keeping in view: `acp_executor.py` keys
+ * capabilities by the joined string `f"{task_type}:{target}"`, so a
+ * capability name containing a colon aliases a different (capability,
+ * resource) pair, and the three-argument interface section 8.8 declares has
+ * no three-argument representation anywhere in the reference.
+ * Generated from context_read.schema.json#/$defs/capability_grant.
+ */
+export interface CapabilityGrant {
+    /**
+     * The principal the capability is asserted for. This is the SAME value the
+     * Attestation Object carries as `operator` and the same one section 9.3 step
+     * 7b(iii-a) hands to step 9, so the bound is copied from
+     * `attestation_object.schema.json` rather than chosen: if the two disagreed,
+     * an operator an attestation can name would be an operator this read cannot
+     * answer for, and step 9 could not run. Neither bound is stated by the
+     * specification -- see the note on `resource`.
+     */
+    readonly operator: OperatorId;
+    /**
+     * The capability asserted. Section 8.8 names this argument and nothing
+     * anywhere declares its identifier space, its syntax or its relation to a
+     * rule's required capabilities at evaluation-order step 4; the bound is the
+     * neighbouring one rather than a fourth invention.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minLength 1, maxLength 256.
+     */
+    readonly capability: string;
+    /**
+     * The resource the capability is asserted over -- the same identifier space
+     * `floors.json` and `tier_raises` are keyed by, so the bound is copied from
+     * `floors.schema.json`. THE SPECIFICATION BOUNDS NO IDENTIFIER LENGTH
+     * ANYWHERE except L-04's 2,048-character maximum string field, whose
+     * enforcement point is 'Schema' and whose scope (a Proposal's fields, or
+     * every string on every wire) it does not state. Three schemas in this
+     * repository already pin three different bounds. Copying a neighbour's is
+     * the least bad of the available moves and is not a reading of the document.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minLength 1, maxLength 256.
+     */
+    readonly resource: string;
+}
+/**
+ * The lenient projection of CapabilityGrant: every field optional, every enum
+ * degraded to `string`. What a verifier parses. Never make a decision on
+ * one — the fail-safe lookups live on the strict type only.
+ */
+export interface RawCapabilityGrant {
+    readonly operator?: string;
+    readonly capability?: string;
+    readonly resource?: string;
+}
+/**
+ * One snapshot-consistent read of the Context Store, carried on legs F3.1
+ * (Context Store -> Policy Engine) and F3.5 (Context Store -> Executor) of
+ * the flow-leg register (ZIFFER-DEPLOY-001 Annex A). Section 8.7 requires
+ * that Context reads be snapshot-consistent, which is why ONE read is ONE
+ * object carrying every fact read under ONE `snapshot_hash`, rather than a
+ * separate response per function of the section 8.8 interface. Split into
+ * per-function responses, a Policy Engine can answer capability at
+ * evaluation-order step 4 from one snapshot and tier at step 7 from another,
+ * and the consistency section 8.7 requires holds of neither.
+ *
+ * THE RULE THIS OBJECT EXISTS TO CARRY, AND THE ONE A CONSUMER MUST NOT GET
+ * WRONG: A CONTEXT READ RAISES, AND CAN NEVER LOWER. TR-1 puts a resource's
+ * floor tier in the signed bundle (`floors.json`), read-only to the runtime
+ * under PB-4. TR-2 lets the Context Store serve a RAISE and nothing else.
+ * TR-3 composes them at the consumer: `effective_tier(r) = max(floor(r),
+ * raise(r))`, absent raise = T0, and evaluation order step 7 states the same
+ * composition. Because risk functions only escalate (RK-3), TR-4 is then a
+ * theorem rather than a hope: a compromised Context Store can drive
+ * effective tier UP, producing more attestation, which is safe, and can
+ * never drive it below the signed floor. It is mechanized as
+ * `FloorDominance` (Annex B, theorem 2, SMT-discharged over the 4x4 lattice
+ * and killed by mutation M1), and section 4.3 classes the Context Store on
+ * exactly that basis -- 'Trusted for RAISES only. Cannot lower effective
+ * tier.'
+ *
+ * WHAT BREAKS IF A CONSUMER TREATS THIS OBJECT AS ABLE TO LOWER. The whole
+ * of v1.2.0's most serious defect returns, and section 8.3.2 opens by naming
+ * it: tier data in two mutually exclusive places, so RK-5's two-person
+ * control over floor changes protects a copy that does not feed evaluation.
+ * That is C2, and its attack is T-16, tier suppression -- falsify a
+ * resource's tier downward and the escalation trigger never fires, so a
+ * floor-T3 action grades LOW, takes step 11's ALLOW branch, and executes
+ * with no quorum. INV-1-HIGH is stated over floor-only risk (TR-5) precisely
+ * so that no single runtime component can forge it downward; a consumer that
+ * took an effective tier, or a floor, from this object would move the value
+ * back under the control of the component section 10's invariant table says
+ * must not have it. Annex B's proof would still discharge, and it would be a
+ * proof about a composition the implementation no longer performs. Note also
+ * which direction is cheap: TR-9 makes lowering a floor an offline-key
+ * deploy under RK-5 while raising stays fast through this object, and that
+ * asymmetry is the design.
+ *
+ * WHAT IS NOT A FIELD, EACH ABSENT ON PURPOSE. (1) A FLOOR TIER, and (2) AN
+ * EFFECTIVE TIER. The floor is TR-1's, comes from the signed bundle the
+ * consumer already holds, and a second copy of it here is C2 restated at the
+ * wire; the effective tier is TR-3's `max`, which the consumer computes, and
+ * a transmitted one is a derived security value accepted from the party
+ * under verification (TR-8's rule, RES-8's wording). (3) A `granted: false`
+ * capability answer -- see `capability_grants`. (4) THE PROVIDER CLASS. CP-1
+ * declares provider selection per tenant IN THE SIGNED BUNDLE, and CP-3
+ * requires evaluation logic to be identical across providers; a provider
+ * class carried here is both a value read from the party being verified and
+ * a field a consumer could branch on, and CP-3 forbids the branch. (5) A
+ * TENANT IDENTIFIER. DP-43 puts tenant separation for the Context Store at
+ * the CREDENTIAL boundary -- a credential scoped to one tenant must not be
+ * able to read another tenant's rows -- so tenancy is a property of the
+ * connection rather than a claim in the payload. A claimed `tenant_id` would
+ * be self-asserted scope from the store, which is the same shape again. The
+ * residual is real and is disclosed rather than closed: nothing in the
+ * payload lets a consumer detect a store that answered with another tenant's
+ * facts, and DP-78 already records that this repository reads no credential
+ * domain and can audit no such boundary. (6) A SIGNATURE. WE-1 makes
+ * COSE_Sign1 the receipt's carrier and AT-8a pins the Attestation Object's
+ * encoding; no clause states a signature over a Context read. Section 4.3
+ * authenticates this leg at the transport (mTLS REQUIRED between components)
+ * and accepts the store as trusted-for-raises-only, which is coherent only
+ * because a compromised store fails safe in both available directions.
+ * Section 8.7.1's 'Context Store signing key SHOULD be in an offline HSM' is
+ * INFORMATIVE and names no bytes it signs, so a `signature` property here
+ * would invent an envelope the specification does not have.
+ *
+ * WHY THE FIELD SET IS CLOSED, AND WHY THAT CLAIM IS WEAKER HERE THAN IT IS
+ * FOR THE ATTESTATION OBJECT. `additionalProperties` is false and every
+ * property is required. NO CLAUSE STATES THIS RULE. AT-8b closes the
+ * Attestation Object's field set and calls the closure the security property
+ * itself; there is no AT-8b for a Context read. Closure is adopted because
+ * it is the fail-safe direction -- an unknown key is refused rather than
+ * ignored, a missing key is refused rather than defaulted -- and because of
+ * Z4: any optional field gives one read two valid encodings, and the receipt
+ * carries `context_snapshot_hash` (AT-1, section 9.2) as a name for exactly
+ * this object, so two encodings of one snapshot are two names for it. That
+ * argument is CONDITIONAL on a preimage the specification does not define
+ * (see `snapshot_hash`), which is why it is recorded as a gap rather than
+ * presented as a reading. The consequence of an optional field here is
+ * therefore not Z4's amplification but DIVERGENCE: one consumer refuses the
+ * unknown key, another ignores it, and at a verifier a divergence is
+ * indistinguishable from a compromise.
+ *
+ * ENCODING IS NOT PINNED BY ANY CLAUSE, AND THAT IS A HOLE RATHER THAN A
+ * CHOICE. Section 9.2 pins JCS (RFC 8785) for the Proposal and canonical
+ * CBOR (RFC 8949 section 4.2) for the receipt and the Attestation Object
+ * (WE-1, WE-2, AT-8a). Nothing pins a canonicalization for the Context read,
+ * and section 8.8 gives `snapshot_hash()` a return type and never a
+ * preimage. So the one artifact in this register whose digest is carried
+ * inside a signed receipt is the one artifact with no stated canonical form.
+ * The JSON below is written as diagnostic form, in the same sense WE-3 gives
+ * that phrase for receipts, and it is NOT an assertion that JSON is the wire
+ * form; no clause says what the wire form is.
+ *
+ * SUITE 12 CLASSIFICATION. Every field below is class T at the schema layer,
+ * because this document constrains SHAPE and shape is not authority. Two of
+ * them are T at the SYSTEM layer as well, with residuals the specification
+ * already discloses rather than residuals this file is introducing.
+ * Capability facts: section 8.7's note and section 10's invariant table
+ * state that a compromised Context Store can withhold a capability (DENY,
+ * safe), raise a tier (more attestation, safe), or FALSIFY A GRANT AT
+ * MEDIUM, which is INV-1-MEDIUM's disclosed residual -- INV-1-HIGH survives
+ * because floor-HIGH already required a quorum and step 9 is a revocation
+ * recheck closing the issuance-to-execution window (T-10), not the
+ * authorization itself. `snapshot_hash`: TR-10's rule is that a transmitted
+ * identifier is a NAME for a binding and not EVIDENCE of one, and this
+ * identifier is not merely unverified but unverifiable, because no clause
+ * says what it covers.
+ *
+ * WHAT THIS SCHEMA DOES NOT CONSTRAIN, listed so that shape validity is
+ * never read as conformance. (a) SNAPSHOT CONSISTENCY (section 8.7) is a
+ * property of how the facts were read, not of the object; a store that
+ * assembles a `ContextRead` from three different snapshots and stamps one
+ * hash on it is shape-valid here. (b) THE FRESHNESS BOUND. CP-2 resolves
+ * stale freshness to DENY and L-18 caps revocation staleness at 5 minutes,
+ * but the contract that applies is the one section 8.8's provider table
+ * gives for the bundle-declared provider class (CP-1), so the bound is
+ * evaluated by the consumer against the signed bundle and never parsed here
+ * -- see `freshness_seconds`. (c) THAT THE READ IS LIVE. Step 9 requires the
+ * Executor to RE-QUERY at execution time; a cached `ContextRead` replayed
+ * inside its freshness window is indistinguishable from a fresh one at this
+ * layer, and that is the whole of T-10. (d) THAT THE ANSWERS MATCH THE
+ * QUESTIONS. The specification defines no query message, so nothing binds
+ * this response to the read that was requested. (e) ORDERING, of
+ * `capability_grants` or of anything else.
+ *
+ * NOTHING IN THIS REPOSITORY PRODUCES OR CONSUMES THIS OBJECT, AND SAYING SO
+ * IS THE POINT. The Python reference models Context as an in-process dict of
+ * operator -> set of `"task_type:target"` strings (`acp_executor.py`,
+ * `Executor.context`), read once at step 9. It implements none of section
+ * 8.8's four functions: there is no `snapshot_hash()`, no `freshness()`, and
+ * `tier_raise` appears nowhere in `reference/` or `crates/` -- both
+ * evaluators bind `resource.effective_tier` to the FLOOR (TR-5's floor-only
+ * computation), so TR-3's `max` has no implementation anywhere and the raise
+ * half of the floor/raise model is proof and prose only.
+ * `context_snapshot_hash` appears in every fixture as the literal string
+ * `"sha256:ctx"`, which does not even match the `sha256` type this file
+ * references. ACP-52 already records that nothing validates a fixture
+ * against these schemas; DP-57 records that the fail-closed response to an
+ * unreachable or stale Context Store is a normative MUST with NOTHING in
+ * this repository that goes red when it is violated. Per DP-86 a component
+ * gets a register row whether or not anyone built it, and by the same
+ * argument it gets a schema.
+ * Generated from context_read.schema.json.
+ */
+export interface ContextRead {
+    /**
+     * The identifier of the snapshot every fact in this object was read from
+     * (section 8.8, `snapshot_hash() -> sha256`). It is what the Decision
+     * carries forward as `context_snapshot_hash` in the receipt (section 9.2)
+     * and inside every Attestation Object (AT-1), so the value a human
+     * attester's device shows and signs over is this one.
+     *
+     * IT IS A NAME FOR A BINDING, NOT EVIDENCE OF ONE (TR-10; RES-8 is the
+     * dossier's wording of the same rule). Worse than the usual case: it is not
+     * merely unverified, it is UNVERIFIABLE. Section 8.8 declares the return
+     * type and no clause anywhere says WHAT BYTES the digest covers or under
+     * which canonicalization, so no consumer can recompute it, no two
+     * implementations can be shown to agree on it, and a store is free to emit a
+     * constant. The consequence is that the receipt's `context_snapshot_hash` --
+     * a field carried through the signed body and through the attested object,
+     * the field that is supposed to say WHICH Context the Decision was computed
+     * over -- discharges nothing today. Section 9.3's checklist has no step that
+     * reads it, which is consistent: there is nothing to check it against.
+     *
+     * This is a normative gap found by writing the schema rather than by reading
+     * the text, which is the same way AT-1's `b64:` nonce type was found to be
+     * unstated (ACP-87, closed at the root as WE-4 in v1.3.18). It is recorded
+     * here and NOT closed here: pinning a preimage in a schema would make this
+     * file the definition of a type the specification does not have, and a
+     * second implementation written from the document alone would never see it.
+     */
+    readonly snapshotHash: Sha256Hash;
+    /**
+     * The age of the last authoritative update behind this read, in whole
+     * seconds (section 8.8, `freshness() -> age of last authoritative update`).
+     * CP-2 makes it a control input rather than telemetry: all providers MUST
+     * honour P-4, and stale freshness resolves to DENY with a distinct reason
+     * code -- unknown is never LOW. What the bound IS depends on the provider
+     * class the signed bundle declares for the tenant (CP-1) and on section
+     * 8.8's provider table: a static signed entitlement bundle has staleness
+     * near zero, workload attestation is per-request, and live directory sync
+     * must be within L-18's 5 minutes for revocations or the sync is broken and
+     * the deployment fails closed.
+     *
+     * THERE IS NO MAXIMUM HERE, DELIBERATELY. Encoding L-18 as a schema bound
+     * would turn a control decision into a parse error: the consumer must DENY
+     * with P-4's distinct reason code, and a malformed-message rejection loses
+     * the reason code, loses the audit record of a Decision that was refused for
+     * staleness, and applies the live-sync bound to providers section 8.8 gives
+     * a different contract. `minimum` is 0 because an age cannot be negative and
+     * a value outside the domain MUST refuse rather than take the permissive
+     * branch -- EL-2 states that reading for the evaluation environment and P-4
+     * states it generally; a negative age read as 'very fresh' is the permissive
+     * branch arriving through a type error.
+     *
+     * THE NAME AND THE UNIT ARE THIS FILE'S, NOT THE SPECIFICATION'S, AND BOTH
+     * ARE GAPS. Section 8.8 names the function `freshness()` and its return 'age
+     * of last authoritative update'; it fixes no unit, no wire type and no name,
+     * so `_seconds` is carried in the field name because a bare duration with
+     * its unit in a comment is a unit nobody reads.
+     *
+     * AND THE RES-8 OBJECTION, STATED RATHER THAN SILENTLY FIXED. An AGE is
+     * computed by the Context Store, on the Context Store's clock, and the
+     * staleness decision that fires CP-2's DENY is then keyed on a derived value
+     * supplied by the party being read -- TR-8's shape exactly. Carrying the
+     * INSTANT of the last authoritative update instead would let the consumer
+     * derive the age against its own NTS-disciplined clock within the L-20 skew
+     * allowance, which is what section 12.5 and leg F9.1 exist to make
+     * available, and would move this row from 'derived value accepted as
+     * transmitted' to 'raw fact plus consumer-computed derivation'. This file
+     * models the return type section 8.8 states. Changing it is a text change,
+     * and making it silently inside a schema is how a register acquires a claim
+     * nobody decided (the ACP-86 shape).
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minimum 0.
+     */
+    readonly freshnessSeconds: number;
+    /**
+     * The capability facts this snapshot asserts: one entry per (operator,
+     * capability, resource) triple that `has_capability` answered TRUE for
+     * (section 8.8). Consumed at evaluation-order step 4 (operator holds every
+     * required capability, else DENY) and again at section 9.3 step 9, where for
+     * recomputed floor-HIGH the Executor re-queries capability of the operator
+     * established in step 7b(iii-a) -- taken from the verified Attestation
+     * Object, never from the receipt body -- and fails closed if it has been
+     * revoked.
+     *
+     * THERE IS NO BOOLEAN, AND ABSENCE IS THE ANSWER. `has_capability` returns a
+     * bool, but under P-4 and CP-2 the two false-ish outcomes are ONE outcome:
+     * an unknown operator, an unknown resource and a capability the store simply
+     * declined to assert all resolve to DENY. Representing them differently
+     * would give one outcome two encodings while no decision anywhere depends on
+     * the difference -- two spellings of one thing, which is the defect class
+     * this repository is built around, and here it would also split the snapshot
+     * digest.
+     *
+     * `uniqueItems` because a repeated grant is a second spelling of one fact.
+     * Note that a grant's identity is the WHOLE TRIPLE, which is why
+     * `x-acp-keyed-by` is deliberately absent: a lookup keyed by `operator`
+     * alone answers 'granted' for the wrong capability on the wrong resource,
+     * and a generator that emitted one would be building the vulnerability. That
+     * used to cost a check that would not run: `tools/codegen.py` read an
+     * array's `x-acp-absent` only alongside `x-acp-keyed-by`, so the fail-safe
+     * declared below was dropped in silence -- a rule written down that reached
+     * nothing, with every gate green. It was declared anyway, because the schema
+     * is the normative artifact and the rule belongs in it, and the gap was
+     * disclosed rather than worked around by mis-keying the lookup. ACP-78 M1
+     * closed it from the generator's side: an array carrying an absent rule with
+     * no key now HALTS in the root that emits accessors, and in this root the
+     * rule is carried into the generated field's documentation. No multi-field
+     * key was invented, because the key is the decision and inventing it here
+     * would be building the vulnerability.
+     *
+     * No `maxItems`. L-05 bounds list length at ingress, on a request; a Context
+     * read is not a request, and a store whose honest answer exceeds an invented
+     * cap would have to truncate, which silently converts grants into DENYs.
+     *
+     * ABSENT-ENTRY RULE, carried as documentation and NOT enforced by this type,
+     * because this is a message and not signed policy. An entry absent from this
+     * table is a REFUSAL under P-4, CP-2, never a default value: a triple absent
+     * from this list is a capability the snapshot does not assert, and P-4's
+     * default is DENY: no matching rule, unknown capability, unclassified
+     * resource and unavailable Context Store each refuse, with a distinct reason
+     * code. CP-2 binds every provider class to that rule. An accessor that
+     * returns a bare Option here is one unwrap away from treating 'the store
+     * said nothing' as 'the store said yes', which at section 9.3 step 9 is a
+     * revoked operator executing a floor-HIGH action. NO ACCESSOR IS GENERATED
+     * FOR THIS LIST AND THE RULE IS CARRIED AS DOCUMENTATION (the wire root's
+     * `absent_emits` is `doc`), so the sentence above describes what a CONSUMER
+     * must do rather than what a generated lookup does for it. Two things forced
+     * that. A grant's identity is the whole triple `(operator, capability,
+     * resource)` -- section 8.8's `has_capability` takes all three -- and
+     * `x-acp-keyed-by` names ONE field, so a generated lookup keyed by any
+     * single one of them answers 'granted' for the wrong resource, which is
+     * building the vulnerability rather than typing it. And ACP-78 M1 found that
+     * an array's `x-acp-absent` was read only ALONGSIDE `x-acp-keyed-by`:
+     * declared without a key it was dropped in silence, which is the failure the
+     * generator's keyword audit refuses one level up. That is now a HALT in the
+     * root that emits accessors.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: uniqueItems.
+     */
+    readonly capabilityGrants: readonly CapabilityGrant[];
+    /**
+     * Resource identifier -> RAISE tier (section 8.8, `tier_raise(resource) ->
+     * T0..T3`; TR-2). A RAISE and nothing else: the consumer holds the floor
+     * from the signed bundle (TR-1) and computes `effective_tier(r) =
+     * max(floor(r), raise(r))` itself (TR-3, evaluation order step 7). Absent
+     * raise is T0, so an unclassified resource is governed entirely by its floor
+     * -- which under RK-1 is T3 when `floors.json` does not name it. The two
+     * defaults compose in the safe direction on purpose: absent floor is the
+     * HIGHEST tier, absent raise is the LOWEST, because the floor is the value a
+     * compromised runtime must not be able to lower and the raise is the value
+     * it must not be able to invent downward.
+     *
+     * The key space is `floors.json`'s key space and the bound is copied from
+     * `floors.schema.json` for that reason: TR-3's `max` is taken over the two
+     * maps keyed by the same resource identifier, so a resource nameable in one
+     * map and unnameable in the other has no defined effective tier. It is an
+     * open map for the same reason floors is -- resources are
+     * deployment-specific -- and the VALUES are closed.
+     *
+     * A T0 ENTRY AND AN ABSENT ENTRY MEAN THE SAME THING, AND THE SPECIFICATION
+     * PERMITS BOTH. TR-2 gives the return type as T0..T3 and TR-3 makes
+     * `max(floor, T0) = floor`, so an explicit T0 is a second encoding of 'no
+     * raise'. The enum is not narrowed to T1..T3 here because narrowing the
+     * stated range would be this file exceeding the document; the consequence is
+     * recorded instead, and it is Z4-shaped -- two encodings of one snapshot are
+     * two `snapshot_hash` values for it, in whatever preimage a future clause
+     * defines.
+     *
+     * ABSENT-ENTRY RULE, carried as documentation and NOT enforced by this type,
+     * because this is a message and not signed policy. An entry absent from this
+     * table reads as `T0` under TR-3: TR-3 states it in as many words: absent
+     * raise = T0. This is the one place in this file where the LOWEST value is
+     * the fail-safe one, and the reason is that the raise is not the tier -- the
+     * floor is, it comes from the signed bundle, and RK-1 already defaults an
+     * unnamed resource to T3. A lookup that refused here, or that defaulted
+     * upward, would let a silent Context Store escalate every resource it has
+     * never heard of and hand a compromised store a denial of service against
+     * the attestation queue that AQ-1 to AQ-3 exist to protect. THIS OBJECT
+     * SETTLED A TENSION INSIDE THE GENERATOR AND THE ANSWER IS WORTH READING
+     * WITH THE RULE. `tools/codegen.py` HALTED on a map with no absent rule --
+     * every table a caller can miss needs its absent case stated in the schema
+     * -- while its wire-root header note said no fail-safe accessor should be
+     * emitted in that root at all, because an absent rule on a wire field would
+     * be a default supplied by the party under verification. This is the only
+     * MESSAGE in the register that is a LOOKUP TABLE, so it is the case neither
+     * was written for. ACP-78 M1 resolved it per root: the wire root declares
+     * `absent_emits="doc"`, the rule below is CARRIED into the generated field's
+     * documentation, and NO accessor is emitted. The deciding argument is one
+     * root over: `floors.schema.json` already generates the accessor that
+     * answers T3 on a miss (RK-1, P-4), and a second generated accessor
+     * answering T0 on a miss over a TRANSMITTED map would put the permissive
+     * answer behind an API shaped like a control, one import away from the
+     * signed one. The rule stated here is TR-3's and is right; where it has
+     * effect is in the consumer's `max(floor, raise)`, against a floor that came
+     * from the signed bundle.
+     */
+    readonly tierRaises: Readonly<Record<string, Tier>>;
+}
+/**
+ * The lenient projection of ContextRead: every field optional, every enum
+ * degraded to `string`. What a verifier parses. Never make a decision on
+ * one — the fail-safe lookups live on the strict type only.
+ */
+export interface RawContextRead {
+    readonly snapshotHash?: string;
+    readonly freshnessSeconds?: number;
+    readonly capabilityGrants?: readonly RawCapabilityGrant[];
+    readonly tierRaises?: Readonly<Record<string, string>>;
+}
+/**
+ * The SIGNED BODY of a Decision Receipt under receipt version 3, carried on
+ * leg F3.3 of the flow-leg register (ZIFFER-DEPLOY-001 Annex A, Policy
+ * Engine -> Executor; the row read KMS -> Executor until ACP-110, and the
+ * KMS cannot be that sender: B-1a puts the canonical Proposal beside the
+ * receipt on this leg and the KMS never holds it, so the signed receipt
+ * returns to the Policy Engine on F3.2's response). The Executor trusts a
+ * signature, not a channel (9.1): B-4 forbids it accepting any instruction
+ * from any other source, so this object is the only thing in the system that
+ * can cause an external effect.
+ *
+ * WHERE THE EDGE OF THIS OBJECT IS. Two clauses fix it. WE-2: the COSE
+ * payload is the canonical encoding of the receipt structure. AB-5: the
+ * bytes covered by the receipt signature are the canonical encoding of the
+ * receipt body WITHOUT the attestation entries. Every property below is
+ * inside the signature and nothing else is, which is also what makes AB-6
+ * measurable -- the 4,096-byte bound is on THIS object's canonical encoding,
+ * and it is the whole reason version 3 exists.
+ *
+ * WHAT IS NOT A FIELD, EACH ABSENT ON PURPOSE.
+ * (1) The SIGNATURE. WE-1 makes COSE_Sign1 the carrier, so the signature is
+ * the envelope around this payload, never a member of it. The Python
+ * reference carries a sibling `sig` key and excludes it from the signed body
+ * by name (`SIGNED_EXCLUDE`), a stand-in for a COSE envelope it does not yet
+ * emit and which its own CRYPTO DISCLOSURE names as a gap. Giving `sig` a
+ * property here would make that stand-in look normative.
+ * (2) The ATTESTATION ENTRIES. AB-1: the entries MUST travel alongside the
+ * receipt and MUST NOT appear in the signed body; they are bound solely by
+ * `attestation_digests` below. Note what the specification does not say --
+ * it names no envelope structure, no field name and no ordering for that
+ * beside-channel. `attestations` is the reference implementation's choice of
+ * name, not the document's.
+ * (3) `reversibility`. RV-2 is explicit: reversibility lives only in the
+ * signed bundle and there is 'no receipt field of record'. RV-3 recomputes
+ * it, because a receipt-asserted REVERSIBLE would suppress DR-9's
+ * acknowledgement exactly as v1.3.0's forged floor-only risk suppressed
+ * attestation (X1). The reference nevertheless reads a `reversibility` key
+ * when one is present; under this closed field set such a receipt is
+ * malformed, and that disagreement is recorded rather than reconciled.
+ * (4) `attestation_id` and `action_id`. Both are DERIVED: the first is
+ * SHA-256 over the canonical Attestation Object (AT-1, AT-8a) and the
+ * Executor recomputes it (9.3 step 7b(v)); the second is the pair
+ * (proposal_hash, origin_nonce) pinned by the ledger (DS-6a, DS-6f). A
+ * transmitted identifier is a name for a binding, not evidence of one
+ * (RES-9), and a schema that gave either a property would invite exactly
+ * that read.
+ *
+ * WHY THE FIELD SET IS CLOSED, AND THE CAVEAT THAT GOES WITH IT.
+ * `additionalProperties` is false and every property but `origin_nonce` is
+ * required. THE SPECIFICATION DOES NOT STATE THIS RULE. AT-8b closes the
+ * Attestation Object field set and calls the closure the security property
+ * itself; there is no AT-8b for the receipt. Closure is adopted here because
+ * it is the fail-safe direction -- an unknown key is refused rather than
+ * ignored, a missing key is refused rather than defaulted -- and because the
+ * alternative is a per-implementation field set on the one object whose
+ * canonical bytes are signed and whose size is capped. It is recorded as a
+ * gap, not presented as a reading: a clause saying for the receipt what
+ * AT-8b says for the object is a text change this schema cannot make.
+ *
+ * Z4 DOES NOT REACH THIS OBJECT THE WAY IT REACHES THE ATTESTATION OBJECT,
+ * AND THE DIFFERENCE IS WORTH STATING RATHER THAN ASSUMED. An Attestation
+ * Object's ledger identity is a digest of itself, so two encodings are two
+ * ids and one human approval claims two slots (T-14). A receipt's ledger
+ * identity is `nonce`, a carried field consumed under CL-3, so two encodings
+ * of one receipt still claim one slot. What an optional field costs here is
+ * not amplification but DIVERGENCE: one verifier refuses the unknown key,
+ * another ignores it, and at the verifier a divergence is indistinguishable
+ * from a forgery. That is a weaker consequence than Z4's and it is still a
+ * reason to close the set.
+ *
+ * ENCODING. Canonical CBOR, RFC 8949 section 4.2 (WE-1, WE-2) -- the same
+ * canonicalization AT-8a pins for the Attestation Object. JCS (RFC 8785) is
+ * the Proposal's rule and MUST NOT be used here. WE-3: a reference decoder
+ * emits JSON for review and JSON MUST NOT be accepted as receipt input, so
+ * the shape below is diagnostic form and never a wire form.
+ *
+ * WHAT THIS SCHEMA CANNOT CONSTRAIN. Listed so that shape validity is never
+ * read as conformance; each item is a per-implementation obligation and
+ * several carry their own conformance case and mutant (AB-5).
+ * - AB-2's ORDERING. `attestation_digests` MUST be sorted strictly ascending
+ * over the UTF-8 bytes of the digest strings including the `sha256:` prefix.
+ * JSON Schema has no sortedness keyword, so an unsorted list is shape-valid
+ * here and MUST still be refused under AB-2.
+ * - AB-6's SIZE BOUND. 4,096 bytes of canonical encoding is a property of an
+ * encoding, not of a JSON shape, and AB-6 requires it be checked on measured
+ * bytes rather than on any proxy such as an entry count -- the first draft
+ * capped the count at 50 and measured 4,107 bytes at that cap.
+ * - AB-4's CARDINALITY and AB-1's MEMBERSHIP. Both relate this object to
+ * entries that are not members of it, so neither is expressible here.
+ * - L-14 / 9.3 step 5's WINDOW LENGTH: `expires_at - issued_at` <= 120 s is
+ * arithmetic across two fields.
+ * - CR-3's conjunctive verification and CR-4's containment floor. `alg`
+ * names the suite; whether every declared primitive verified, and whether
+ * the suite contains every primitive the bundle floor names, are decided
+ * elsewhere and never from a transmitted value.
+ * - WHETHER THIS IS A RE-DRIVE. DS-6b says a re-drive receipt MUST carry
+ * `origin_nonce`, and no field in the receipt declares that it is one, so
+ * the conditional obligation cannot be expressed at any layer that reads
+ * only this object.
+ *
+ * SHARED TYPES ARE REFERENCED, NEVER REPEATED. `sha256` and `risk_level`
+ * come from attestation_object.schema.json, the 128-bit `b64:` nonce from
+ * ledger_claim.schema.json where CL-3 consumes it, and two come from the
+ * SIGNED BUNDLE root across the root boundary: `suite_id` from
+ * signature.schema.json, where CR-4's floor is registered, and
+ * `fidelity_class` from adapters.schema.json, the table TR-8 verifies this
+ * receipt's `fidelity` against (ACP-73; it lived in proposal.schema.json, on
+ * the side being verified, until that table existed). Each is defined once
+ * and pointed at from here. A second copy would be a second statement of one
+ * object, which is the defect this repository publishes corrections for --
+ * and the generator halts on a duplicate `x-acp-name` within a root and
+ * across the two, so the copy would not even be silent. A `$ref` may cross
+ * roots for a named SCALAR only (ACP-78 M1): the vocabulary a receipt is
+ * compared against is owned by the signed side, and an object crossing would
+ * drag its field graph with it. This paragraph had said the opposite -- that
+ * a cross-root `$ref` was not a rule the generator had and `suite_id` was
+ * therefore one type in two files -- for the whole of M1, while the `alg`
+ * property below already crossed; prose describing a generator is exactly as
+ * trustworthy as prose describing anything else nothing executes.
+ *
+ * That the homes of the wire-root types are scattered across message schemas
+ * is an accident of which file happened to need them first, not a design.
+ * The durable answer is one shared definitions file in this root that every
+ * message schema references; there is none, so the placement is recorded
+ * here rather than presented as intentional.
+ *
+ * SUITE 12 CLASSIFICATION. At the schema layer every field is class T,
+ * because this document constrains SHAPE and shape is not authority. The
+ * Executor's obligations are elsewhere and are named on the individual
+ * properties rather than restated here: `proposal_hash` and the bundle basis
+ * are BOUND (9.3 steps 3 and 4), floor-only risk and fidelity are RECOMPUTED
+ * and the transmitted values only ever raise a critical alert on
+ * disagreement (TR-8, 9.3 step 7a), the operator identity is taken from the
+ * verified Attestation Objects and never from this body (Y4), and the origin
+ * nonce is read from the immutable ledger binding (DS-6f).
+ *
+ * DISAGREEMENTS SURFACED BY WRITING THIS SCHEMA, PUBLISHED RATHER THAN
+ * SMOOTHED OVER. Section 9.2's example is the only enumeration of receipt
+ * fields the specification gives, and it omits two fields other clauses make
+ * mandatory: `alg` (CR-1 names the receipt explicitly, CR-5 makes it
+ * signature-covered) and `idempotency_key` (DS-6b: 'MUST be carried as a
+ * distinct receipt field'). An implementer building a receipt from that
+ * block alone emits one that is CR-1 non-conformant while conforming to the
+ * text they read, which is the PB-8 shape the document has already published
+ * a correction for. In the other direction, both current implementations
+ * omit nine fields the example carries -- `schema_id`, `schema_version`,
+ * `schema_hash`, `fidelity`, `context_snapshot_hash`, `rule_id`,
+ * `risk_level_effective`, `risk_level_floor_only` and `audit_id` -- and
+ * spell `issued_at` and `expires_at` as numeric epoch seconds where the
+ * example spells RFC 3339. Modelling the specification therefore makes every
+ * fixture in the repository invalid against this file. That is disclosed,
+ * not designed around; ACP-52 already records that nothing validates a
+ * fixture against these schemas and that the fixtures are schema-invalid.
+ * Generated from decision_receipt.schema.json.
+ */
+export interface DecisionReceipt {
+    /**
+     * AB-0: exactly 3, verified BEFORE any other check, and every other value
+     * rejected including its absence. Written as an inclusive bound of exactly
+     * one value because that is what AB-0 admits.
+     *
+     * THERE IS NO COMPATIBILITY WINDOW AND THE REASON IS NOT COMPATIBILITY.
+     * Version 2 is the weaker representation; a verifier that accepts both lets
+     * an attacker present version 2 and never face the digest binding at all. A
+     * transition window is therefore not a migration aid, it is a downgrade path
+     * -- the CR-4 shape one layer up, with the FORMAT rather than the suite
+     * negotiated by the party under verification.
+     *
+     * The number is 3 and not 2 because section 9.2's published example already
+     * carried `"receipt_version": 2` for the containment form, and one version
+     * number with two meanings is the two-definitions defect at the wire.
+     *
+     * A verifier MUST NOT let shape validation stand in for this check: a
+     * version-2 receipt has to be refused by the name AB-0, because the
+     * cross-language differential compares refusal names and a generic schema
+     * error is not one.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minimum 3, maximum 3.
+     */
+    readonly receiptVersion: number;
+    /**
+     * CR-1: every signed structure MUST carry an explicit `alg` naming a
+     * signature suite registered in the signed bundle, and the receipt is named
+     * in that clause. CR-5 makes it signature-covered, so an issuer cannot
+     * rewrite the suite without invalidating the receipt it travelled on.
+     *
+     * Carrying the suite is not the same as choosing it. The FLOOR comes from
+     * the signed bundle and is satisfied by CONTAINMENT of primitives, never by
+     * rank (CR-4): a suite is a set, `hybrid-ed25519-mldsa65` and `slhdsa128s`
+     * are incomparable, and every implementation that built a rank table from
+     * the pre-v1.3.15 wording served a lattice signature to a deployment that
+     * had chosen hash-based precisely to avoid one. Reading the floor from
+     * anything transmitted asks the party under verification how strictly to
+     * judge it.
+     *
+     * NOTE that section 9.2's receipt example does not show this field, while
+     * CR-1 and CR-5 require it. The clauses govern; the example is incomplete.
+     *
+     * THE VALUE DOMAIN IS DECLARED ONCE, IN THE BUNDLE ROOT, and this field
+     * `$ref`s it across roots:
+     * `spec/schemas/bundle/signature.schema.json#/$defs/suite_id`. It was
+     * declared in both roots until ACP-78 M1 -- one vocabulary, two definitions,
+     * with each copy carrying its own note saying the two must move together,
+     * which is the arrangement that let the strict-Ed25519 rule sit in two
+     * languages. CR-4 compares the receipt's suite against the bundle's
+     * registered floor, so the two artifacts must draw from ONE set or the
+     * comparison is between two vocabularies that merely look alike. It is
+     * deliberately NOT `const`: listing only the hybrid suite would make a
+     * receipt signed under `ed25519` fail SHAPE validation when the required
+     * outcome is a CR-4 refusal naming the floor. A name outside the set is
+     * refused under CR-1 by the verifier and never defaulted to a known suite.
+     */
+    readonly alg: SuiteId;
+    /**
+     * The graded outcome of section 8.4 step 11. 9.3 step 2: the Executor
+     * proceeds only on ALLOW.
+     *
+     * DELIBERATELY NOT `const: "ALLOW"`, for the reason `suite_id` in the bundle
+     * signature schema is not a single-value enum: pinning the only acceptable
+     * value here would make a DENY receipt fail SHAPE validation when the
+     * required outcome is a refusal named 9.3-2. A check that fires under the
+     * wrong name is a divergence waiting to happen, because the cross-language
+     * differential compares names.
+     *
+     * EO-1: HIGH is never auto-allowed by any configuration, so an ALLOW over a
+     * floor-HIGH action is a claim about a quorum, and that claim is checked
+     * against `attestation_digests` and the entries beside the receipt rather
+     * than believed.
+     */
+    readonly decision: DecisionOutcome;
+    /**
+     * The canonical Proposal this receipt authorises. 9.3 step 3: the Executor
+     * hashes the Proposal IT received over the same channel (B-1a),
+     * canonicalized identically, and compares -- it hashes what it will execute,
+     * never 'whatever the receipt describes'. Class B.
+     *
+     * This field is a name for a binding. The binding is the comparison, and it
+     * exists because a receipt that merely asserts what it covers is a claim by
+     * the party under verification (RES-9).
+     */
+    readonly proposalHash: Sha256Hash;
+    /**
+     * SR-1: schemas are content-addressed by `schema_id` + `schema_version` +
+     * `schema_hash`, and SR-5 requires every Decision to carry the triple. The
+     * pattern is section 6.3's `AtomEnvelope`, so the receipt's identifier is
+     * the same type the ingress validated.
+     *
+     * The triple is not decoration: TR-8 has the Executor verify `fidelity`
+     * against the bundle-registered adapter binding for THIS `schema_id`, so an
+     * unregistered id refuses rather than grading.
+     */
+    readonly schemaId: SchemaId;
+    /**
+     * Semver, per SR-1 and section 6.3's `AtomEnvelope`. Part of the content
+     * address, not a compatibility hint: SR-3 decides narrowing against a
+     * bounded lattice precisely because v1.2.0 left 'narrowing' undefined and a
+     * net-widening change could self-classify and bypass distinct-reviewer
+     * approval.
+     */
+    readonly schemaVersion: SchemaVersion;
+    /**
+     * The third leg of the SR-1 content address. SR-2: the validator refuses to
+     * start on a signature or hash mismatch, so a receipt naming a schema hash
+     * the bundle does not carry describes a grammar nobody signed.
+     */
+    readonly schemaHash: Sha256Hash;
+    /**
+     * The adapter-stamped intent-fidelity class of the Proposal (SR-5).
+     * DIAGNOSTIC AND AUDIT ONLY, stated normatively in section 9.2's authority
+     * note.
+     *
+     * 9.3 step 7 has the Executor verify fidelity against the bundle-registered
+     * adapter binding for `schema_id`, and 7a makes disagreement with this
+     * transmitted value a CRITICAL ALERT rather than a preference: a
+     * validly-signed receipt asserting `F-HIGH` for a Proposal from an
+     * F-LOW-bound adapter means the signing substrate is emitting Decisions the
+     * bundle does not support (T-18).
+     *
+     * TWO VALUES, NOT THREE, AND THE TYPE IS DEFINED ONCE. There is no
+     * `F-MEDIUM`: this class is what actually varied between the retired Door A
+     * / Door B binary, and it is a property of an INGRESS ADAPTER rather than a
+     * separate architecture; it is also orthogonal to the provider class (static
+     * entitlements against live directory sync), a conflation the document
+     * already carries a correction for in rows 7 and 8 of its applicability
+     * table. The type itself lives in the signed bundle's adapters.schema.json
+     * -- the table this value is verified AGAINST (ACP-73), where it was homed
+     * once that table existed; before that it lived in proposal.schema.json, on
+     * the side being verified -- and is referenced here rather than repeated:
+     * two definitions of one type is the defect this repository publishes
+     * corrections for, and the generator halts on a duplicate `x-acp-name`
+     * within a root and across the two.
+     */
+    readonly fidelity: FidelityClass;
+    /**
+     * The signed bundle the Decision was computed against. 9.3 step 4: it MUST
+     * match the bundle the Executor already trusts. Class B, and the direction
+     * matters -- the Executor compares against its own bundle rather than
+     * loading the one the receipt names, which would be the verifier taking its
+     * policy from the party under verification.
+     */
+    readonly policyBundleHash: Sha256Hash;
+    /**
+     * Epoch of that bundle. 9.3 step 4 requires it to be at least the Executor's
+     * last-seen epoch, and the ledger records the high-water mark (CL-3), so a
+     * receipt naming an older epoch is a rollback attempt and fails closed.
+     *
+     * Monotonicity is ALSO enforced one hop earlier, at the KMS, against a
+     * durable high-water mark before it will sign at all (9.1.1 step 5, RAD-3).
+     * Two enforcement points, neither redundant: the KMS check stops a
+     * stale-bundle Decision being minted, the Executor check stops one being
+     * replayed.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minimum 0.
+     */
+    readonly bundleEpoch: number;
+    /**
+     * The Context read the Decision was computed over (section 8.8
+     * `snapshot_hash()`). Context reads are snapshot-consistent and AC-3 makes
+     * the consumed snapshot part of the audit record, so replay is exact rather
+     * than approximate.
+     *
+     * Recording the snapshot does not make Context trustworthy, and the receipt
+     * is not where that is decided: TR-8 has the Executor recompute floor-only
+     * risk while IGNORING every Context-Store raise, which is why a compromised
+     * Context Store can still withhold a capability fact (DENY, safe) or raise a
+     * tier (more attestation, safe) but cannot suppress escalation.
+     */
+    readonly contextSnapshotHash: Sha256Hash;
+    /**
+     * The bundle rule that decided. AT-3 makes the rule identity part of what an
+     * attester is SHOWN -- floor tiers and the bundle `rule_id`s that raised the
+     * risk, deliberately not Context-asserted values, which is the separation
+     * that closes A-8's display path -- and section 9.2 carries one in the
+     * receipt for replay.
+     *
+     * TWO CAVEATS, BOTH GAPS RATHER THAN DESIGN. No clause pins this
+     * identifier's syntax; the only pattern the specification attaches to a
+     * thing called `rule_id` belongs to a DIFFERENT object -- the firewall rule
+     * identifier inside section 6.3's `ModifyFirewallRule` payload, constrained
+     * to `^[a-z0-9-]{1,32}$`, which the receipt example's own `RULE-002` would
+     * fail. One name, two normative meanings, which is the CL-7 shape the
+     * document has published a correction for. And AT-3 speaks of the rule idS
+     * that raised the risk, plural, while the receipt carries one; nothing says
+     * which one that is when several raised it. No pattern is asserted here
+     * because inventing one would be a third meaning.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minLength 1, maxLength 128.
+     */
+    readonly ruleId: string;
+    /**
+     * Risk after Context raises and accumulator effects (section 8.4 step 9,
+     * AC-4, RK-3 monotone max). DIAGNOSTIC AND AUDIT ONLY -- section 9.2's
+     * authority note is explicit that this field is NOT authoritative for any
+     * Executor control decision.
+     *
+     * It is carried because replay needs it and refused authority because X1 was
+     * exactly this field's neighbour being believed. Effective risk can only
+     * ever be at or above floor-only risk, and the Executor keys every
+     * attestation requirement on the RECOMPUTED floor-only value (TR-8), so a
+     * receipt inflating this field buys an attacker nothing and deflating it
+     * changes nothing.
+     */
+    readonly riskLevelEffective: Risk;
+    /**
+     * Floor-only risk: the value derived from the target resource's signed tier
+     * floor and the bundle's risk functions, with every Context-Store raise
+     * ignored. DIAGNOSTIC AND AUDIT ONLY.
+     *
+     * THIS IS THE FIELD RES-8 IS ABOUT. In v1.3.0 the Executor read it, and a
+     * forged `risk_level_floor_only` below the bundle-derived value suppressed
+     * the attestation requirement entirely (X1). TR-8 now has the Executor
+     * RECOMPUTE it from the trusted bundle's floors and risk functions applied
+     * to the independently-received canonical Proposal, and 9.3 step 7a makes
+     * disagreement with the value transmitted here a CRITICAL ALERT, not a log
+     * line: it means the signing substrate produced a Decision the bundle does
+     * not support (T-18).
+     *
+     * The fail-safe defaults that feed the recomputation live in the bundle
+     * schemas and are not restated here: a resource absent from `floors.json` is
+     * T3 (RK-1), an action with no risk function is REFUSED at 8.4-3 rather than
+     * graded HIGH, and unknown is never LOW (P-4).
+     */
+    readonly riskLevelFloorOnly: Risk;
+    /**
+     * AB-1: the receipt's commitment to the attestations, one digest per entry,
+     * with the entries themselves travelling alongside and never inside the
+     * signed body. THIS ARRAY IS THE ENTIRE BINDING under version 3.
+     *
+     * THE PREIMAGE IS THE WHOLE ENTRY, AND THAT IS THE TRAP. Each digest is
+     * `sha256:` over the canonical encoding of the complete entry -- `obj`,
+     * `kind`, `attester` and `sig` together -- and MUST NOT be `attestation_id`,
+     * nor any digest whose preimage is the Attestation Object alone.
+     * `attestation_id` already exists, is already normative, and is the obvious
+     * thing to reuse; it is wrong. The AT-1 field set is closed over the OBJECT
+     * and contains no `kind`, no `attester` and no `sig`, while quorum
+     * composition is decided from the ENTRY -- `kind` selects approval or
+     * confirmation, `attester` supplies the identity distinctness is counted
+     * over -- and the attester signs neither. Under version 2 containment sealed
+     * them. Commit only to the object and an attacker on the transport path
+     * flips one entry's `kind` from `confirmation` to `approval` while every
+     * digest still matches. Two identifiers now exist and MUST NOT be merged:
+     * `attestation_id` is what the ledger consumes for single use under CL-3,
+     * this digest is what the receipt authorised byte for byte.
+     *
+     * WHAT `uniqueItems` DOES AND DOES NOT SAY. AB-3 forbids repeated digests
+     * and requires the check at THIS layer rather than delegated to CL-3's
+     * `attestation_id` claim, because CL-3 is object-scoped and needs a
+     * Consumption Ledger -- a stateless verifier has no ledger for it to fire
+     * in, and there AB-3 is the only defence. `uniqueItems` is the shape
+     * statement of that rule; a duplicate MUST still be refused under the name
+     * AB-3, not as a generic validation error. In an Executor that does hold a
+     * ledger AB-3 is masked by CL-3 and kills no mutant, which is recorded as a
+     * positive-path obligation rather than dressed up as a control.
+     *
+     * AN EMPTY ARRAY IS VALID AND `minItems` IS DELIBERATELY ABSENT. A LOW or
+     * MEDIUM Decision carries no attestations. Requiring one entry would make
+     * every fast-path receipt malformed, and requiring the quorum size here
+     * would be reading the size of the quorum off the receipt -- AB-4 says
+     * quorum MUST be counted from VERIFIED attestations and never derived from
+     * the length of this list, which is AT-3's defect one layer down.
+     *
+     * ORDERING IS NOT CONSTRAINED HERE AND IS NORMATIVE: AB-2 requires strictly
+     * ascending lexicographic order over the UTF-8 bytes of the digest strings
+     * INCLUDING the `sha256:` prefix, because without a declared order one
+     * quorum yields two canonical encodings of one receipt and therefore two
+     * receipt identities -- the Z4 encoding split reached with no optional field
+     * involved.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: uniqueItems.
+     */
+    readonly attestationDigests: readonly Sha256Hash[];
+    /**
+     * The tenant the Decision was made for. 9.3 step 8: it MUST equal the tenant
+     * of the independently-received Proposal, so a validly-signed receipt from
+     * another tenant fails closed rather than executing across the boundary.
+     *
+     * The ledger is shared per tenant and its uniqueness constraints are keyed
+     * on `(tenant_id, artifact_class, identifier)` (CL-5), so this value also
+     * decides which single-use registry a nonce is claimed in. No pattern is
+     * pinned because the specification pins none.
+     */
+    readonly tenantId: TenantId;
+    /**
+     * The operator the action is attributed to. DIAGNOSTIC ONLY, and this is
+     * stated normatively rather than as guidance (section 9.2's authority note,
+     * Y4).
+     *
+     * The authoritative operator identity for approver-distinctness (AT-2) and
+     * for the 9.3 step 9 capability recheck is `obj.operator` inside each
+     * verified Attestation Object, which is signature-covered; 9.3 step
+     * 7b(iii-a) requires it to be identical across every entry and requires the
+     * identity to be taken from the verified object, NEVER resolved in favour of
+     * this body field. A receipt whose body `operator` differs from the attested
+     * one fails closed. Mechanized as `Y4_OperatorTamperDetected`.
+     *
+     * Below floor-HIGH no quorum exists and there is no attested operator to
+     * prefer, so this field is what audit records -- which is a disclosed
+     * asymmetry, not a second authority.
+     */
+    readonly operator: OperatorId;
+    /**
+     * RFC 3339 instant of issuance, as section 9.2 renders it. 9.3 step 5: not
+     * future beyond a 5 s skew allowance.
+     *
+     * Evaluated against NTS-disciplined wall time within the L-20 skew
+     * allowance, never against a monotonic clock -- the two are different
+     * quantities and DP-52 states the distinction; leg F9.1 carries the
+     * dependency.
+     *
+     * TWO DISAGREEMENTS ARE RECORDED HERE RATHER THAN RESOLVED. Both current
+     * implementations spell this field as numeric epoch seconds, because 9.3
+     * step 5 does arithmetic on it, while the specification renders it RFC 3339
+     * in the only place it shows a receipt; the schema follows the
+     * specification. And RFC 3339 admits several spellings of one instant -- `Z`
+     * against `+00:00`, fractional seconds present or absent -- so a
+     * canonical-CBOR body containing one is not yet one encoding per instant.
+     * For the receipt that costs a diagnostic mismatch; for the Attestation
+     * Object, whose id is a digest of itself, it is Z4's two-ids consequence
+     * reached through a type no clause pins, which is the WE-4 shape one layer
+     * over.
+     */
+    readonly issuedAt: Rfc3339Instant;
+    /**
+     * RFC 3339 instant after which the receipt is void. 9.3 step 5 refuses an
+     * expired receipt AND enforces `expires_at - issued_at <= 120 s`.
+     *
+     * THE WINDOW LENGTH IS EXECUTOR-ENFORCED, WHICH IS THE WHOLE POINT OF Y2.
+     * Both endpoints are written by the KMS, so a verifier that only checks 'not
+     * yet expired' has delegated the validity window to the party under
+     * verification: a compromised signer issues a receipt valid for a week and
+     * every subsequent check still passes. Violation fails closed with a
+     * critical alert.
+     *
+     * The relation between the two fields cannot be expressed in this schema, so
+     * shape validity says nothing about it (DR-6 depends on the same bound: a
+     * hold window at or above the L-14 ceiling would outlive receipt validity
+     * and fails closed).
+     */
+    readonly expiresAt: Rfc3339Instant;
+    /**
+     * The receipt nonce, claimed atomically against the Consumption Ledger at
+     * 9.3 step 6 (CL-2 compare-and-swap; if the ledger is unavailable the
+     * Executor fails closed; CL-4 keeps the claim for at least receipt validity
+     * plus 24 h, because a registry that forgets a nonce before the receipt
+     * expires is a replay window). Single use is enforced by that claim, not
+     * asserted as a property.
+     *
+     * IT IS ALSO THE ORIGIN OF ACTION IDENTITY. DS-6a: the nonce of the FIRST
+     * receipt issued for a Proposal becomes `origin_nonce`, and DS-6f has the
+     * ledger claim the immutable `proposal_hash -> origin_nonce` binding
+     * atomically with this claim. That binding is written once and read many
+     * times, a rebind attempt is a critical alert, and its retention is
+     * indefinite because an expiring origin binding reopens Z3 for any
+     * long-lived re-drive.
+     *
+     * CHECKED AT 9.3 STEP 6, BEFORE THE CLAIM, IN BOTH LANGUAGES (ACP-89 -- this
+     * paragraph recorded a gap until then, and the gap is why it is still here).
+     * WE-4 governs this field exactly as it governs the attestation nonce -- the
+     * `b64:` prefix is part of the value, carried and hashed as that string --
+     * and for three releases nothing read the clause here: the value went
+     * straight into the ledger claim in the reference and was unread in
+     * `acp-decision`, so two spellings of one nonce claimed two ledger slots,
+     * which is T-13 through the hole WE-4 exists to close. Step 6 now reads the
+     * nonce BEFORE it claims: a value that is not `b64:` + RFC 4648 section 4
+     * with padding refuses under WE-4, a well-formed value that is not 128-bit
+     * then refuses under L-17, and only the validated string reaches the ledger
+     * -- so a malformed nonce never consumes a slot, and it is rejected rather
+     * than normalized for the reason the next paragraph gives.
+     * `reference/src/acp_executor.py` and `crates/acp-decision/src/decide.rs`
+     * carry the two checks at the same position in the same order, and the
+     * cross-language differential compares both refusal NAMES rather than both
+     * verdicts. WHAT THIS STILL DOES NOT REACH, because a control that
+     * overstates itself here is the defect this paragraph was written about:
+     * only the stateless half is checked -- the CL-2 claim and L-17's retention
+     * half (CL-4) are the ledger's and are absent from `acp-decision` (ACP-46)
+     * -- and nothing validates a receipt against this schema at any point
+     * (ACP-52), so the pattern below is enforced by two implementations that
+     * agree with it, never by a validator reading this file.
+     *
+     * THE TYPE IS DEFINED ONCE AND THE PATTERN IS TWO RULES THAT REFUSE UNDER
+     * DIFFERENT NAMES. `b64:` followed by the RFC 4648 section 4 alphabet WITH
+     * padding is WE-4, the wire type; the twenty-two characters plus `==` are
+     * L-17's 128 bits. A verifier folding them into one check answers WE-4 for a
+     * 64-bit nonce, which is a perfectly well-formed `b64:` value -- the wrong
+     * clause name, and the cross-language differential compares names. The
+     * prefix is PART OF THE VALUE: WE-4 requires it be carried, hashed and
+     * signed as that string, and stripping it, dropping the padding or
+     * substituting the URL-safe alphabet each produce a DIFFERENT value that
+     * MUST be rejected rather than normalized -- normalizing makes one verifier
+     * accept both spellings and hands the divergence to the next implementation,
+     * where it is indistinguishable from a forgery. The type was pinned at the
+     * root only in v1.3.18, after existing solely inside section 9.2's
+     * diagnostic JSON with no clause saying whether the prefix counted; it was
+     * found by writing a schema (ACP-87), which is the argument for writing
+     * them. It is referenced from ledger_claim.schema.json rather than repeated
+     * here, because the ledger is where a nonce is consumed and one wire type
+     * must have one definition.
+     */
+    readonly nonce: Nonce128;
+    /**
+     * The identifier of the audit record for this Decision, carried so a receipt
+     * can be tied to the hash-chained audit entry (AU-1) without a search.
+     * Section 9.2 carries it; R-1 uses the same name for the identifier returned
+     * with a rejection, so one value class spans both outcomes.
+     *
+     * NO CLAUSE PINS ITS SYNTAX, and none is invented here --
+     * `minLength`/`maxLength` bound the shape and nothing more. Note also what
+     * this field is NOT: a receipt naming an audit id is not evidence that the
+     * record exists or that the chain contains it. AU-3a's detection rests on
+     * multi-party anchoring of the chain, never on an identifier the same party
+     * transmits.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minLength 1, maxLength 128.
+     */
+    readonly auditId: string;
+    /**
+     * The target idempotency key, `SHA-256(canonical(action_id))` where
+     * `action_id` is the pair `(proposal_hash, origin_nonce)`. DS-6b requires it
+     * be carried as a distinct receipt field; DS-1 requires the Executor use it
+     * as the target's idempotency key, which is what makes exactly-once hold
+     * ACROSS re-drives.
+     *
+     * ACTION IDENTITY IS NOT AUTHORIZATION IDENTITY, AND CONFLATING THEM WAS Y3.
+     * Through v1.3.3 this key was `attestation_id`, which is fresh on every
+     * re-drive -- so in exactly the lost-outcome case DS-3 exists to handle, the
+     * target saw a new key for an action that may already have committed and a
+     * floor-HIGH non-idempotent action doubled. DS-6c keeps both properties: the
+     * key is stable, the authorization is fresh.
+     *
+     * IT IS TRANSMITTED AND IT IS NOT BELIEVED. The Executor derives the key
+     * from the ledger-pinned origin binding and compares (DS-6f); a re-drive
+     * receipt whose key differs from the ledger-derived value fails closed.
+     * DS-6d forbids a coarser key such as `proposal_hash` alone, which would
+     * suppress a legitimate second execution of an identical Proposal.
+     *
+     * Section 9.2's example does not show this field although DS-6b says it MUST
+     * be carried, and the reference treats it as optional; both are recorded as
+     * gaps.
+     */
+    readonly idempotencyKey: Sha256Hash;
+    /**
+     * THE ONE OPTIONAL FIELD IN THIS SCHEMA, and the justification is owed
+     * rather than assumed.
+     *
+     * WHAT IT IS. The receipt nonce of the FIRST receipt issued for this
+     * Proposal (DS-6a). DS-6b requires a re-drive receipt to carry it. DS-6f
+     * then makes the carried value DIAGNOSTIC ONLY: the Executor reads
+     * `origin_nonce` from the immutable ledger binding and derives
+     * `idempotency_key` from the value it read, and if this field is present it
+     * MUST equal the ledger value or the Executor fails closed with a critical
+     * alert.
+     *
+     * WHY IT IS OPTIONAL RATHER THAN REQUIRED. DS-6f says 'if present', in those
+     * words, so requiring it would contradict the text; and a first receipt has
+     * no origin other than its own nonce, so there is nothing for it to carry.
+     * The alternative -- omitting the property entirely -- is worse under
+     * `additionalProperties: false`, because it would make every conformant
+     * re-drive receipt malformed.
+     *
+     * WHY THAT IS NOT Z4 HERE, STATED SO THE EXEMPTION IS ARGUED RATHER THAN
+     * CLAIMED. Z4's consequence is two canonical encodings of one object
+     * yielding two ids and therefore two ledger slots. That reaches the
+     * Attestation Object because its ledger identity IS a digest of itself. A
+     * receipt's ledger identity is `nonce`, carried, so present-and-absent forms
+     * of one receipt still claim one slot. And omission cannot move the
+     * idempotency key, because DS-6f makes the ledger the source and this field
+     * merely a cross-check against it -- which is exactly the fix for Z3, where
+     * DS-6b as first drafted required only that the claimed origin be A consumed
+     * nonce. That is a MEMBERSHIP test, not a PINNING test: a compromised KMS
+     * named any other consumed nonce, the key moved, the target could not
+     * deduplicate, and the floor-HIGH action doubled. Fourth recurrence of the
+     * RES-8 class, in the machinery the previous fix introduced.
+     *
+     * WHAT OMITTING IT DOES COST: the diagnostic cross-check disappears, so a
+     * signing substrate that has lost track of an origin binding produces a
+     * receipt nobody can tell apart from a correct one until the ledger is
+     * consulted. The field set is therefore NOT closed, and the specification
+     * has no way to say 'this is a re-drive' that would let the obligation be
+     * expressed conditionally. Recorded as a gap.
+     *
+     * Same 128-bit `b64:` wire type as `nonce`, referenced from its single
+     * definition; the WE-4 and L-17 rules written out on that field apply here
+     * unchanged.
+     */
+    readonly originNonce?: Nonce128;
+}
+/**
+ * The lenient projection of DecisionReceipt: every field optional, every enum
+ * degraded to `string`. What a verifier parses. Never make a decision on
+ * one — the fail-safe lookups live on the strict type only.
+ */
+export interface RawDecisionReceipt {
+    readonly receiptVersion?: number;
+    readonly alg?: string;
+    readonly decision?: string;
+    readonly proposalHash?: string;
+    readonly schemaId?: string;
+    readonly schemaVersion?: string;
+    readonly schemaHash?: string;
+    readonly fidelity?: string;
+    readonly policyBundleHash?: string;
+    readonly bundleEpoch?: number;
+    readonly contextSnapshotHash?: string;
+    readonly ruleId?: string;
+    readonly riskLevelEffective?: string;
+    readonly riskLevelFloorOnly?: string;
+    readonly attestationDigests?: readonly string[];
+    readonly tenantId?: string;
+    readonly operator?: string;
+    readonly issuedAt?: string;
+    readonly expiresAt?: string;
+    readonly nonce?: string;
+    readonly auditId?: string;
+    readonly idempotencyKey?: string;
+    readonly originNonce?: string;
+}
+/**
+ * The out-of-band summary of a held floor-HIGH action, as it travels: a
+ * signed Rendered Summary (`$defs/rendered_summary`, role `notification`)
+ * beside its signature, delivered to every attester recorded in the verified
+ * Attestation Objects and to the operator (DR-2, DR-3). Carried on legs F5.3
+ * and F8.2 of the leg register (ZIFFER-DEPLOY-001 Annex A); F8.2 is the same
+ * notification reaching the operator, whom DR-3 makes a required recipient.
+ *
+ * THIS SCHEMA IS THE ONE PERMITTED COMMON DEPENDENCY BETWEEN THE NOTIFIER
+ * AND THE APPROVAL SERVICE, AND NOTHING ELSE IS. DR-2 requires the summary
+ * to be rendered by a service that shares NO rendering code path with the
+ * Attestation Presentation Service, and states the consequence in as many
+ * words: a shared formatting library used by both is a conformance failure
+ * EVEN WHEN it renders honestly from canonical bytes, because independence
+ * has to hold under compromise. So a shared renderer, formatter, sanitiser,
+ * date helper or component library between the two services is the
+ * vulnerability, not a refactor. Two channels sourced from one renderer are
+ * one channel wearing two hats: a single compromise of that renderer lies to
+ * both simultaneously, and the approver's veto -- the mechanism deferred
+ * release exists to provide -- disappears with no signature failing
+ * anywhere. The wire format is the permitted dependency precisely because it
+ * carries no rendering behaviour. `sim/notify/render.py` and
+ * `sim/approve/render.py` are two files that do the same job differently on
+ * purpose, and say so at the top.
+ *
+ * NONE OF THAT IS CHECKABLE HERE. DR-2's structural half is a property of
+ * two code trees; JSON Schema constrains one message. Nothing below detects
+ * a shared renderer, and this file must not be read as though it did.
+ *
+ * T-32 CLOSED HERE FOR TWO OF ITS THREE ROWS, AND THIS FILE SAYS HOW
+ * (v1.3.25). Through v1.3.24 this object carried `source_path` and
+ * `from_canonical` -- the notification service describing itself to the
+ * Executor, classified T (rows 24-25 of ACP-CLASS-001) because a description
+ * a service gives of itself is not evidence -- and an earlier revision of
+ * this description recorded why it could be nothing more: the notification
+ * was not among CR-1's signed structures, so there were no bytes to verify.
+ * There are now. `obj` is a Rendered Summary signed under the `notification`
+ * key that door_identities.json (PB-11) names in the signed bundle; the
+ * Executor verifies the signature under that key and compares
+ * `obj.proposal_hash` against its own canonical hash of the held Proposal
+ * (DR-14). Both self-descriptions are WITHDRAWN, and the rows move T -> B.
+ *
+ * WHY THE OBJECT IS A `$defs` ENTRY HERE AND NOT ITS OWN FILE. Two producers
+ * sign one shape -- the presentation service signs the approval summary, the
+ * notifier signs this -- and the generator resolves a `$ref` to a `$defs`
+ * entry only, never to a whole document (it halted on the alternative, which
+ * is the right answer: a document is a message and a message is not a
+ * field). The Acknowledgement carries its signed object the same way. The
+ * approval summary has no wire schema of its own because no clause puts it
+ * on a leg between two trust domains: it reaches the Executor from the
+ * presentation service on the leg the Attestation Objects already travel, in
+ * this shape.
+ *
+ * WHAT IS DELIBERATELY NOT A FIELD.
+ * (a) THE RECIPIENT SET. DR-3's audience is every attester recorded in the
+ * VERIFIED Attestation Objects plus the operator, both available to the
+ * Executor from the receipt it has already verified -- the operator inside
+ * the attestation signature rather than the receipt body (AT-8, Y4). A
+ * transmitted recipient set would be the notification service certifying its
+ * own coverage: RES-8, the shape DR-13(2) and PB-10 refused by putting
+ * audiences in the signed bundle. Disclosed asymmetry, unchanged: DR-13(2)
+ * puts the fast-path audience under signed policy and DR-3 does not, and
+ * `reference/src/acp_executor.py` asks the notifier for it on this path.
+ * (b) `delivered`. The notifier's report of whom it actually reached,
+ * consumed at DR-8. A return value on the way back to the Executor, not a
+ * field of this object, and the ONE T-32 row that stays T: a signed delivery
+ * report is still the party under verification describing its own coverage,
+ * and DR-14 states the bound rather than inventing a field that would look
+ * like closing it.
+ * (c) A THIRD SHAPE FOR THE DR-13 NOTICE. The register's artifact vocabulary
+ * holds `notification` (DR-3) and `notice` (DR-13), and they are two
+ * artifacts: the notice is committed by the Executor to its OWN durable
+ * audit state before an IRREVERSIBLE action executes below floor-HIGH,
+ * involves no rendering and no service, and its delivery is explicitly not a
+ * precondition of execution. ACP-86's register names this schema for
+ * `notice`; that is still not true of this file -- no tag discriminates the
+ * two, and DR-13(1)'s content appears in no field here -- and the
+ * disagreement is recorded rather than resolved, because resolving it is a
+ * decision about the register.
+ *
+ * ENCODING. AT-8a pins canonical CBOR for the Attestation Object and §8 pins
+ * JCS for the Proposal; DR-14 pins the signature as taken over the canonical
+ * encoding of `obj` alone. The closed field sets here are Z4's reason -- an
+ * optional field gives one object two valid encodings -- and not a rule
+ * quoted from a clause.
+ * Generated from notification.schema.json.
+ */
+export interface Notification {
+    /**
+     * The signed Rendered Summary, `role` = `notification`. Carried in its own
+     * member rather than flattened beside the signature because the signature is
+     * taken over THIS map alone -- the Acknowledgement's shape, for the
+     * Acknowledgement's reason (ACK-2).
+     */
+    readonly obj: RenderedSummary;
+    /**
+     * CR-2: a signature under a suite is a MAP from primitive name to signature
+     * value, one entry per primitive of the suite named in `obj.alg`. A bare
+     * scalar MUST NOT be accepted under any suite, not even a single-primitive
+     * one -- format leniency is a downgrade in disguise. OPEN MAP, deliberately:
+     * the suite registry lives in the signed bundle (CR-1) and CR-7 makes
+     * migration forward-only, so a closed `{classical, pq}` object here would
+     * hard-code one suite into the wire format. CR-3 is conjunctive and not
+     * expressible here: every primitive of the declared suite MUST verify and
+     * the supplied set MUST exactly match it, checked in code against `obj.alg`
+     * resolved through the bundle. Value encoding follows
+     * acknowledgement.schema.json's `sig`, whose description records that the
+     * two implementations of it disagree (WE-4 base64 vs the reference's hex) --
+     * one report, not two.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: values minLength 1.
+     */
+    readonly sig: Readonly<Record<string, string>>;
+}
+/**
+ * The lenient projection of Notification: every field optional, every enum
+ * degraded to `string`. What a verifier parses. Never make a decision on
+ * one — the fail-safe lookups live on the strict type only.
+ */
+export interface RawNotification {
+    readonly obj?: RawRenderedSummary;
+    readonly sig?: Readonly<Record<string, string>>;
+}
+/**
+ * The immutable `proposal_hash` to `origin_nonce` binding (CL-3, DS-6f,
+ * T-22), claimed at the FIRST receipt for a Proposal. Unlike the three
+ * classes above this is a BINDING and not a consumption: it is written once
+ * and read many times, its retention is indefinite (CL-3), and a rebind
+ * attempt is a critical alert.
+ *
+ * WHY IT EXISTS. DS-6b as drafted in v1.3.4 required the Executor to verify
+ * a receipt-claimed `origin_nonce` was "recorded as consumed in the
+ * Consumption Ledger". That is a MEMBERSHIP test: it proves the value is *a*
+ * consumed nonce, never that it is *the* origin of this Proposal. A
+ * compromised KMS therefore names any other consumed nonce as the origin,
+ * the idempotency key moves, the target cannot dedup, and the floor-HIGH
+ * action doubles -- Z3, the fourth recurrence of the RES-8 class, found
+ * inside the fix for Y3.
+ *
+ * WHAT THIS CLAIM IS AND IS NOT. It PINS a value; it is not evidence that a
+ * value was pinned. On a re-drive the Executor MUST read the origin from the
+ * ledger and derive `idempotency_key` from what it read; a receipt-carried
+ * `origin_nonce` is diagnostic only and must match or the Executor fails
+ * closed with a critical alert (DS-6f). That read is a different operation
+ * and this schema does not model it.
+ *
+ * CL-7 GOVERNS THE WRITE AND CANNOT BE SEEN FROM HERE. The binding MUST (i)
+ * read from a reachable majority, (ii) fail closed if reachable replicas
+ * disagree, never resolving a security value by majority vote, and (iii)
+ * adopt an existing binding where one is found, writing only when none
+ * exists. The converse ordering leaves a partitioned write permanently split
+ * across the replica set: every later read sees two values and fails closed
+ * forever, a durable denial of service on that Proposal produced by an
+ * ordinary network event with no attacker. That defect was real, was found
+ * by `partition_suite.py`, and is invisible to this document -- a claim that
+ * validates here says nothing about the order in which the ledger read and
+ * wrote.
+ * Generated from ledger_claim.schema.json#/$defs/origin_binding_claim.
+ */
+export interface OriginBindingClaim {
+    readonly tenantId: TenantId;
+    readonly artifactClass: 'origin_binding';
+    /**
+     * The `proposal_hash` (DS-6f), which is the KEY half of the binding and
+     * therefore the ledger key's `identifier` position under CL-5. It is the
+     * canonical Proposal's hash under RFC 8785 (JCS), §9.2 -- the Proposal
+     * canonicalizes differently from the receipt and the Attestation Object
+     * (canonical CBOR, WE-1/WE-2/AT-8a), and mixing the two is the encoding
+     * split at the point it does the most damage.
+     */
+    readonly identifier: Sha256Hash;
+    /**
+     * The BOUND half: the receipt nonce of the first receipt issued for this
+     * Proposal (DS-6f). Carried in the claim because the ledger cannot derive it
+     * -- it is the value being pinned. It is not a second spelling of the
+     * receipt-nonce claim's `identifier` and does not consume a slot in that
+     * class; the two claims are distinct rows even where the value is
+     * byte-identical, which is what `artifact_class` in the key is for.
+     *
+     * DS-6f requires this binding to be claimed ATOMICALLY "alongside the nonce
+     * claim itself", and a schema of one message per class cannot express an
+     * atomic pair. Whether the two travel as one message or two is unanswered by
+     * the specification and is recorded as an open question against this schema;
+     * the Python reference issues them as two separate calls four checklist
+     * steps apart (§9.3 step 6 and step 10).
+     */
+    readonly originNonce: Nonce128;
+}
+/**
+ * The lenient projection of OriginBindingClaim: every field optional, every enum
+ * degraded to `string`. What a verifier parses. Never make a decision on
+ * one — the fail-safe lookups live on the strict type only.
+ */
+export interface RawOriginBindingClaim {
+    readonly tenantId?: string;
+    readonly artifactClass?: string;
+    readonly identifier?: string;
+    readonly originNonce?: string;
+}
+/**
+ * One floor-HIGH action, verified and HELD between §9.3 and execution.
+ * Committed by the Executor as S1 of the leg register (ZIFFER-DEPLOY-001
+ * Annex A), which carries it among the Executor-local durable commits and
+ * not among the legs. F5.1 was its identifier while the register read it as
+ * a leg; ACP-86 retired that id, because an Executor-internal hold crosses
+ * no domain boundary and DP-83 makes a leg a crossing.
+ *
+ * S1 IS AN EXECUTOR-INTERNAL HOLD, AND THAT CHANGES WHAT THIS SCHEMA IS FOR.
+ * Every other artifact in this directory crosses between two parties. This
+ * one does not: the register records it as a commit whose component column
+ * reads "Executor" and which names no crossing, so nothing here is received,
+ * and no field is class T in the sense §14 suite 12 means it -- a value
+ * transmitted by the party under verification. Every value below was
+ * verified by the Executor at §9.3, recomputed by it (TR-8, RV-3), or drawn
+ * by it (DR-11); the one exception is `notified`, and it is called out on
+ * the field. What the schema constrains is therefore DURABLE STATE, and that
+ * state is normative because DP-48 makes it so: an Executor MUST record
+ * entry into `pending_release` before the hold begins, and on recovery MUST
+ * enumerate every held action, void each with a critical alert and an audit
+ * record, and MUST NOT resume, re-time, or release any of them. A hold that
+ * lives only in process memory is a hold an ordinary restart erases -- along
+ * with a repudiation (DR-4) that has already arrived.
+ *
+ * WHY THE HOLD EXISTS AT ALL. §9.3 establishes that a receipt is authentic,
+ * bound, fresh and quorum-satisfying. It cannot establish that the approvers
+ * SAW the action they approved. DR-1 therefore forbids a floor-HIGH action
+ * from executing at verification time and holds it while a summary rendered
+ * independently from the canonical bytes is delivered out of band (DR-2,
+ * DR-3) and any recipient may veto (DR-4). That raises the bar from one
+ * compromised component to two independent ones. A-8 is not closed and is
+ * not claimed to be.
+ *
+ * WHAT IS BOUND TO WHAT, WHICH IS THE POINT OF THE RECORD. A release must
+ * not be re-pointable at a different action, so the record pins three things
+ * and not one. `proposal_hash` names the action -- and it is a NAME, not
+ * evidence: at release the Executor re-hashes the bytes it is about to
+ * execute and compares (9.3-3, "the Executor hashes what it will execute --
+ * never whatever the receipt describes"). `receipt_nonce` pins the ONE
+ * receipt whose quorum authorized this hold, because a Proposal can have
+ * more than one live receipt (DS-3 re-drives through a NEW attestation;
+ * DS-6a fixes the action identity across them), and a hold keyed only on the
+ * Proposal would let a later receipt inherit a hold -- and a veto -- raised
+ * against an earlier one. `policy_bundle_hash` and `bundle_epoch` name the
+ * signed policy the recomputations were made against, so `reversibility`,
+ * which decides whether silence releases, is something an auditor can
+ * reproduce rather than an assertion they must accept.
+ *
+ * THE FIELD SET IS CLOSED, AND THE REASON IS NOT AT-8b's. `required` lists
+ * every property and `additionalProperties` is false, but Z4's argument does
+ * not carry over unchanged: nothing hashes this record, so two encodings of
+ * it do not become two ids and two ledger slots. What does carry over is the
+ * other half of it. An optional field is a field the release path sometimes
+ * reads as absent, the absent branch is the one nothing exercises, and here
+ * that branch decides whether an IRREVERSIBLE action releases with no
+ * acknowledgement. `acknowledged_by` and `repudiated_by` are therefore
+ * REQUIRED and MAY be empty arrays: an empty array is the honest encoding of
+ * "nobody did", where an omitted field is the same state spelled a second
+ * way. And DP-48's recovery path has to enumerate these records after a
+ * restart, which it cannot do faithfully for a record carrying a field it
+ * does not know about.
+ *
+ * `x-acp-absent` APPEARS NOWHERE BELOW, DELIBERATELY. An absent rule answers
+ * "what does the SIGNED POLICY say when a lookup misses", and this record is
+ * not policy -- `tools/codegen.py` states that as a rule for the whole wire
+ * root, because a default supplied by the party under verification is not a
+ * fail-safe. RV-1's absent-from-`reversibility.json` default (IRREVERSIBLE)
+ * lives at the lookup, in `spec/schemas/bundle/reversibility.schema.json`,
+ * which is where it has effect. Restating it here would give one fail-safe
+ * two homes.
+ *
+ * WHAT IS NOT A FIELD. (a) `release_at`: it is `held_at` plus
+ * `hold_window_seconds`, and a stored instant that can disagree with its own
+ * inputs is a second definition of one moment; the disagreement that matters
+ * is the early one, which is DR-1's refusal bypassed by a value rather than
+ * by a clock. (b) `release_mode`: DR-1 says it is determined by the
+ * recomputed reversibility class and the sampling draw, so it IS
+ * `reversibility` and `sampled`, computed at release and never stored --
+ * stored, one flipped field converts a DR-9 hold into a DR-7 silent release.
+ * RV-4 does require the mode recorded, but in AUDIT, a different artifact on
+ * a different leg (F6.1). (c) `idempotency_key`: DS-6f pins `proposal_hash`
+ * to `origin_nonce` immutably in the Consumption Ledger and requires the
+ * Executor to READ origin from that binding and derive the key from what it
+ * read; a key copied in here would be read at the target call instead, which
+ * is Z3 one layer in -- the membership-versus-pinning distinction that let a
+ * compromised KMS move an idempotency key and double a floor-HIGH action.
+ * (d) A Context snapshot or a stored capability decision: 9.3 step 9 is a
+ * RE-QUERY written to close the issuance-to-execution window (T-10), a
+ * capability read before the hold is stale by the whole window, and carrying
+ * one would invite exactly the read that step forbids. (e) The Attestation
+ * Objects, their signatures, and their `attestation_id`s: the quorum was
+ * decided at 9.3 step 7b and the ids were consumed in the ledger (CL-3,
+ * AT-5), and re-deciding it at release against a copy this record supplied
+ * is a verification with no fresh binding. The attester IDENTITIES are kept,
+ * because DR-3 and DR-5 need to know who must be notified and who may veto.
+ * (f) The canonical Proposal bytes: where an Executor keeps what it is about
+ * to execute is a storage question the specification does not answer; what
+ * it does answer is that the hash of those bytes is recomputed and compared
+ * (9.3-3).
+ *
+ * WHAT THIS SCHEMA DOES NOT CONSTRAIN. Almost everything that matters about
+ * a hold is a relation -- between fields, between times, or between
+ * components -- and JSON Schema expresses none of them: that the window has
+ * elapsed (DR-1), that the receipt has not expired during it (DR-6), that
+ * `notified` covers every attester and the operator (DR-3, DR-8), that an
+ * acknowledgement came from a notified non-operator (DR-9, DR-5), that a
+ * non-empty `repudiated_by` is terminal (DR-4), that `held_at` plus
+ * `hold_window_seconds` still leaves a processing margin inside the
+ * receipt's validity (DR-6). A record can be schema-valid and unreleasable,
+ * and a record can be schema-valid and MUST NOT release. This document
+ * constrains shape, and shape is not authority.
+ *
+ * Two limits stated rather than left to be assumed. DR-2's render-path
+ * distinctness is a property of two CODE PATHS and cannot be a property of
+ * any object; nothing here can carry it, and the notifier self-certifying
+ * its own independence and coverage is the OPEN finding T-32 in
+ * ACP-CLASS-001. DR-11's requirement that the sampling draw come from a
+ * CSPRNG and be uninfluenceable by the requester is likewise
+ * unrepresentable: `sampled` records the OUTCOME of a draw and can say
+ * nothing about its source, so an implementation whose draw an attacker
+ * grinds against produces records that validate perfectly.
+ *
+ * Finally, this record carries no signature and no integrity envelope,
+ * because the specification gives it none: its integrity is the Executor's
+ * own durable store. The closed field set above is a discipline about what
+ * the release path may read. It is not a defence against an Executor that
+ * writes whatever it likes.
+ * Generated from pending_release.schema.json.
+ */
+export interface PendingRelease {
+    /**
+     * The canonical Proposal (JCS, WE-1) this action was authorized for. It is
+     * the name of the held action and not evidence of it: 9.3-3 requires the
+     * Executor to hash what it will execute and compare, and the hold is exactly
+     * the interval during which the thing to be executed and the thing that was
+     * approved can drift apart. Under DS-6f this is also the key of the
+     * immutable `proposal_hash` to `origin_nonce` ledger binding, which is where
+     * the idempotency key comes from at the target call -- not from anything
+     * recorded here.
+     */
+    readonly proposalHash: Sha256Hash;
+    /**
+     * The `nonce` of the ONE receipt whose quorum authorized this hold, claimed
+     * in the Consumption Ledger at 9.3 step 6.
+     *
+     * WHY THE RECORD NEEDS IT AND `proposal_hash` IS NOT ENOUGH. DS-3 re-drives
+     * an `indeterminate` outcome through a NEW attestation and therefore a new
+     * receipt, and DS-6a fixes the action identity across re-drives, so one
+     * Proposal can have several receipts alive inside a retention window. A hold
+     * identified only by its Proposal is a hold any of them can be released
+     * against -- including one whose attesters were never notified under DR-3,
+     * which detaches the DR-4 veto from the authorization it was raised against.
+     *
+     * THE TYPE IS TWO RULES AND THEY REFUSE UNDER DIFFERENT NAMES. `b64:` plus
+     * the RFC 4648 §4 alphabet WITH padding is WE-4, the wire type, and the
+     * prefix is part of the value: it is carried, hashed and signed as that
+     * string, and stripping it, dropping the padding, or substituting the
+     * URL-safe alphabet each produce a different value and MUST be rejected
+     * rather than normalized. The twenty-two characters are L-17's 128 bits. A
+     * verifier folding the two into one check answers `WE-4` for a 64-bit nonce,
+     * which is a perfectly well-formed `b64:` value -- the wrong clause name,
+     * and the cross-language differential compares names.
+     * `tools/nonce-type-vectors.json` pins that pair for the ATTESTATION nonce
+     * across three implementations after they had already diverged for a release
+     * with every gate green; the receipt nonce has the same two rules and no
+     * such corpus.
+     */
+    readonly receiptNonce: Nonce128;
+    /**
+     * The verified receipt's `expires_at`, copied at 9.3 step 5 so DR-6 can be
+     * evaluated at release without re-reading the receipt. DR-6: release MUST
+     * fail closed if the receipt expired during the window, because a hold that
+     * outlives its authorization executes on an expired receipt, and L-14's 120
+     * s ceiling exists to bound exactly that. Note what this value's authority
+     * rests on and what it does not: step 5 enforced the window LENGTH itself
+     * rather than reading it from the KMS-written value (Y2), and nothing
+     * re-derives it here -- this is a copy of a checked value, kept because the
+     * checker and the release step are separated by the hold.
+     */
+    readonly receiptExpiresAt: Rfc3339Instant;
+    /**
+     * The signed bundle established at 9.3 step 4, under which the values below
+     * were recomputed. It authorizes nothing at release -- no clause reads
+     * policy through this hash -- and it is here because a recomputation with no
+     * named input is not reproducible: RV-4 requires the recomputed
+     * reversibility class recorded in audit, and an auditor who cannot name the
+     * bundle cannot check the class or the release mode it selected.
+     */
+    readonly policyBundleHash: Sha256Hash;
+    /**
+     * Epoch of that bundle (9.3 step 4, which requires it be at least the
+     * Executor's last-seen epoch). Monotonicity is enforced at the KMS against a
+     * durable high-water mark (RAD-3) and, across a restart, against the
+     * Executor's own recovered mark (DP-47) -- never from this value. It is
+     * recorded so that a hold raised under epoch N is still visibly a hold
+     * raised under epoch N after a rotation, which is the only way to read a
+     * release decision made under a bundle that is no longer current.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minimum 0.
+     */
+    readonly bundleEpoch: number;
+    /**
+     * The tenant scope verified at 9.3 step 8, where the receipt's tenant must
+     * match the tenant scope of the credentials about to be used. Three
+     * obligations need it at release rather than at verification: DR-12 counts
+     * silent releases in a PER-TENANT counter, DR-13 counts its below-HIGH
+     * notices as a separate class in the same discipline, and AU-2 makes
+     * `(tenant_id, seq)` unique and gapless in the audit chain. A release that
+     * cannot name its tenant cannot be counted and cannot be anchored.
+     */
+    readonly tenantId: TenantId;
+    /**
+     * The operator identity taken from the VERIFIED Attestation Objects at 9.3
+     * step 7b(iii-a) -- never from the receipt body's `operator`, which is
+     * diagnostic only (Y4). Three rules read it during the hold. DR-3 makes the
+     * operator a required notification recipient alongside every attester. DR-9
+     * refuses an acknowledgement from the operator: the party who initiated the
+     * action carries no independent information about whether the displayed
+     * summary was honest, which is AT-2's approver-distinctness restated at the
+     * release step. And 9.3 step 9 rechecks capability on this identity, which
+     * is why it must be the signature-covered one.
+     */
+    readonly operator: OperatorId;
+    /**
+     * Every attester recorded in the verified Attestation Objects. DR-3 requires
+     * the notification to reach each of them and the operator, over a channel
+     * distinct from the one that obtained approval; DR-5 accepts a repudiation
+     * or an acknowledgement only from a party recorded as notified.
+     *
+     * IT IS KEPT AS THE RECOMPUTED HALF OF THAT PAIR. The set of parties who
+     * MUST be notified is derived from signatures the Executor itself verified,
+     * so DR-8's completeness test can compare `notified` against this rather
+     * than asking the notification service who its audience should have been.
+     * Asking the notifier is the shape of T-32, still OPEN in ACP-CLASS-001: a
+     * service that selects and then certifies its own coverage is verifying
+     * itself.
+     *
+     * `minItems` is 2 because L-16 puts the floor-HIGH quorum at two distinct
+     * attesters, each distinct from the operator, and a floor-HIGH receipt with
+     * no attestations fails closed at INV-1-HIGH before any hold exists.
+     * `uniqueItems` compares identity STRINGS, which is deliberately the weaker
+     * check: AT-2 distinctness is resolved over registry KEYS and not over names
+     * (PB-7, where changing a `role` string let one key holder satisfy a k=2
+     * quorum alone), and that resolution happened at 9.3 step 7b(vi). This
+     * constraint restates none of it.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minItems 2, uniqueItems; items minLength 1, maxLength 128.
+     */
+    readonly attesters: readonly string[];
+    /**
+     * The recomputed floor-only risk that put this action on the deferred path.
+     * The `const` is DR-1's scope made checkable: DR-1 defers an action whose
+     * RECOMPUTED floor-only risk is HIGH, and DR-13 states in as many words that
+     * DR-1 through DR-12 govern that path only -- an irreversible action below
+     * HIGH takes the notice path instead, which is a different artifact on a
+     * different path -- the Executor-local commit S2, whose leg id F5.6 ACP-86
+     * retired for the same reason as F5.1's. A `pending_release` record graded
+     * anything else is a record that should not exist.
+     *
+     * IT IS HERE TO BE REFUSED ON, NOT RELIED ON. TR-8 admits one source for a
+     * risk grade: recomputation from the signed bundle's floors and risk
+     * functions applied to the independently received canonical Proposal,
+     * ignoring Context-Store raises and ignoring any transmitted value. Nothing
+     * at release may read this field as the grade. Reading a stored grade
+     * instead of recomputing is X1 -- a forged `risk_level_floor_only`
+     * suppressing attestation -- with the storage moved inside the verifier.
+     */
+    readonly floorOnlyRisk: Risk;
+    /**
+     * The class RECOMPUTED at verification from the trusted bundle and the
+     * Proposal's `task_type` (RV-3), never read from the receipt: a
+     * receipt-asserted `REVERSIBLE` would suppress the DR-9 acknowledgement
+     * requirement exactly as v1.3.0's forged `risk_level_floor_only` suppressed
+     * attestation, same defect class and a different field. RV-2 puts the class
+     * in the signed bundle only -- no Context raise, no runtime override, no
+     * receipt field of record -- and makes downgrading one as dangerous a policy
+     * operation as lowering a tier floor (RK-5).
+     *
+     * With `sampled` it decides the release mode (DR-1), and the two outcomes
+     * are not variations on one control. `IRREVERSIBLE` requires positive
+     * acknowledgement from a notified non-operator and TIMES OUT CLOSED (DR-9).
+     * `REVERSIBLE` releases on silence, and only there, because a control whose
+     * default outcome equals its approved outcome teaches its own users to
+     * ignore it and decays into a log entry while the dashboard still reports
+     * that human oversight exists (DR-7).
+     *
+     * RV-1's absent-from-`reversibility.json` default is IRREVERSIBLE, and it
+     * belongs to the LOOKUP, not to this field: it is carried by
+     * `spec/schemas/bundle/reversibility.schema.json`'s `x-acp-absent` and
+     * generated into the table's accessor. This field is required and has no
+     * default.
+     *
+     * IT IS THE BUNDLE'S TYPE, NOT A SECOND ONE. This field `$ref`s
+     * `spec/schemas/bundle/reversibility.schema.json#/$defs/reversibility`
+     * across roots. It was declared twice until ACP-78 M1 --
+     * `ReversibilityClass` here beside the bundle's `Reversibility` -- on the
+     * argument that signed policy and a recorded value are never interchangeable
+     * (RES-8) and the module a reader holds should say which they have. That
+     * argument is right about the VALUE and wrong about the TYPE: what carries
+     * the provenance is the object the value sits in, a signed
+     * `reversibility.json` against a transmitted record, and a two-case
+     * vocabulary duplicated is two definitions of one object. RV-3 also has to
+     * COMPARE the recomputed class against the table it came from, and a
+     * comparison between two enums that merely look alike is the CR-4 defect one
+     * artifact down.
+     */
+    readonly reversibility: Reversibility;
+    /**
+     * The DR-10 confirmation-sampling draw for this action. A bundle-configured
+     * fraction of REVERSIBLE floor-HIGH actions (L-29, default 10%) inherits
+     * DR-9's acknowledgement duty, for a reason about people rather than
+     * cryptography: if recipients learn that reversible actions never require a
+     * response they stop reading those notifications too, and the channel decays
+     * for the class that is most of the traffic.
+     *
+     * DR-11 governs the draw and none of it is visible here. It MUST come from a
+     * cryptographically secure source at the Executor or an equivalently
+     * isolated component; it MUST NOT be derived from the Proposal, the operator
+     * identity, or any requester-supplied value, because a derived draw is one
+     * an attacker grinds inputs against until the action falls outside the
+     * sample; and it MUST be recorded so the realised rate is verifiable after
+     * the fact. This field is that record, and it is the OUTCOME only.
+     *
+     * Because it is REQUIRED, the draw is made no later than the durable commit
+     * -- earlier than DR-10 demands, and out of reach of anything that happens
+     * during the hold. DR-10 scopes sampling to REVERSIBLE actions and the
+     * specification does not say what the value means for an IRREVERSIBLE one,
+     * where DR-9 already requires acknowledgement; there both `true` and `false`
+     * describe the same release mode.
+     */
+    readonly sampled: boolean;
+    /**
+     * RFC 3339 instant at which the action entered `pending_release` and the
+     * window started (DR-1). DP-48 makes it the moment the DURABLE record must
+     * already exist by -- "before the hold begins" is the whole of that clause's
+     * ordering, and it is AU-7's anchor-before-release rule applied to the
+     * Executor's own state, for the same reason: a record written after the fact
+     * can be suppressed by whatever the action enabled.
+     *
+     * Evaluated against NTS-disciplined wall time within the L-20 skew allowance
+     * of five seconds, never against a monotonic clock. Leg F9.1 carries that
+     * dependency and DP-52 states the distinction. It matters more here than on
+     * a receipt: DR-6's margin between the end of the hold and the expiry of the
+     * receipt is measured across two components' clocks.
+     */
+    readonly heldAt: Rfc3339Instant;
+    /**
+     * The window this action must survive before it may release, read from the
+     * SIGNED BUNDLE in force at 9.3 step 4 (DR-1; L-28: default 60 s, minimum 30
+     * s). Release before it has elapsed MUST fail closed.
+     *
+     * THE UPPER BOUND IS A REFUSAL, NOT A STYLE CHOICE. L-14 caps receipt
+     * validity at 120 s, so DR-6 makes a window at or above that ceiling an
+     * UNSATISFIABLE configuration -- no legal receipt can outlive it -- which
+     * MUST be rejected rather than silently never releasing. Testing found the
+     * interaction directly: a 60 s hold inside a 60 s receipt window expires
+     * mid-hold and never releases the honest path. `maximum` is inclusive and
+     * this repository's generator carries no exclusive bound, so 119 is
+     * "strictly below the ceiling" written in the only keyword available. It is
+     * the loosest value the specification permits and emphatically not a safe
+     * one: DR-6's actual requirement is `hold_window + processing margin <
+     * receipt validity`, the margin is a property of the deployment, and no
+     * schema can check it.
+     *
+     * Two choices here are this schema's and not the specification's, and both
+     * are recorded rather than hidden. L-28 states the window in seconds but
+     * nowhere states its granularity; integer seconds is a decision. And pinning
+     * the window IN the record rather than re-reading it from the bundle at
+     * release is a decision too -- it stops a rotation during the hold from
+     * retroactively lengthening or shortening a window the attesters were
+     * notified about -- on a question §9.6 does not answer.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minimum 30, maximum 119.
+     */
+    readonly holdWindowSeconds: number;
+    /**
+     * The parties the notification service reported delivering to. DR-3 requires
+     * that to be every attester in the verified Attestation Objects and the
+     * operator, over a channel distinct from the one used to obtain approval.
+     * Two clauses then read this set: DR-8, where an unreachable recipient or
+     * any failed delivery means the action MUST NOT release, because executing
+     * while the detection channel is absent is executing unwatched; and DR-5,
+     * where an acknowledgement or a repudiation is accepted ONLY from a party
+     * recorded here, or a compromised presentation service suppresses the veto
+     * the mechanism exists to enable.
+     *
+     * THIS IS THE ONE VALUE IN THE RECORD THE EXECUTOR NEITHER VERIFIED NOR
+     * RECOMPUTED. It is the notifier's claim about its own coverage, which is
+     * RES-8's shape and the OPEN finding T-32 in ACP-CLASS-001, where
+     * `delivered` is classified T against a disclosed residual. `attesters` sits
+     * beside it so DR-8's completeness test compares this claim against a set
+     * derived from verified signatures instead of against the notifier's own
+     * answer about who its audience should have been.
+     *
+     * MAY BE EMPTY, and the empty case is not slack. DP-48 requires the durable
+     * record to exist BEFORE the hold begins while DR-3's delivery happens
+     * DURING it, so a committed, not-yet-delivered record is a state the
+     * specification's own ordering produces. What may be done with such a record
+     * -- how long it may sit undelivered, whether an undelivered hold expires or
+     * is voided -- §9.6 does not say.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: uniqueItems; items minLength 1, maxLength 128.
+     */
+    readonly notified: readonly string[];
+    /**
+     * Notified parties that positively acknowledged during the window. Where the
+     * recomputed reversibility class is IRREVERSIBLE, DR-9 requires at least one
+     * such acknowledgement before release and TIMES OUT CLOSED -- a timed-out
+     * action needs a fresh quorum, never a replay. DR-10 gives sampled
+     * REVERSIBLE actions the same duty. The acknowledgement MUST NOT come from
+     * the operator (DR-9), which is why `operator` is carried in this record
+     * rather than looked up later.
+     *
+     * Empty is the ordinary state on the DR-7 silent path, and it is not free:
+     * DR-12 requires every release with an empty set here to increment a
+     * per-tenant counter recorded in audit, so that silence is a MEASURABLE DEBT
+     * rather than an invisible acknowledgement, and deployments SHOULD alert on
+     * the rate rather than merely record it.
+     *
+     * WHAT AN IDENTITY IN THIS ARRAY IS NOT. The reference-level ACK-1..ACK-6
+     * rules make each acknowledgement a signed, closed-schema, single-use object
+     * bound to `proposal_hash` and verified against a registered key (leg F5.4).
+     * This field records only the identities that survived those checks. An
+     * identity is not evidence of the object it came from, and nothing
+     * downstream may treat it as one.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: uniqueItems; items minLength 1, maxLength 128.
+     */
+    readonly acknowledgedBy: readonly string[];
+    /**
+     * Notified parties that repudiated during the window (DR-4, DR-5). Any
+     * notified party MAY repudiate; repudiation MUST fail closed with a critical
+     * alert; consumed attestations remain consumed, so a repudiated action
+     * requires a fresh quorum and never a replay. A non-empty array is therefore
+     * TERMINAL for this record: no later acknowledgement and no elapsed window
+     * releases it.
+     *
+     * An array rather than a nullable identity, because `null` and an omitted
+     * field are one state spelled two ways -- Z4's argument at the record layer,
+     * where the cost is an unexercised branch in the release path rather than a
+     * second ledger slot, and where the branch decides whether a veto is seen.
+     * The empty array means nobody repudiated, and it means it in exactly one
+     * way.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: uniqueItems; items minLength 1, maxLength 128.
+     */
+    readonly repudiatedBy: readonly string[];
+}
+/**
+ * The lenient projection of PendingRelease: every field optional, every enum
+ * degraded to `string`. What a verifier parses. Never make a decision on
+ * one — the fail-safe lookups live on the strict type only.
+ */
+export interface RawPendingRelease {
+    readonly proposalHash?: string;
+    readonly receiptNonce?: string;
+    readonly receiptExpiresAt?: string;
+    readonly policyBundleHash?: string;
+    readonly bundleEpoch?: number;
+    readonly tenantId?: string;
+    readonly operator?: string;
+    readonly attesters?: readonly string[];
+    readonly floorOnlyRisk?: string;
+    readonly reversibility?: string;
+    readonly sampled?: boolean;
+    readonly heldAt?: string;
+    readonly holdWindowSeconds?: number;
+    readonly notified?: readonly string[];
+    readonly acknowledgedBy?: readonly string[];
+    readonly repudiatedBy?: readonly string[];
+}
+/**
+ * The typed candidate operation the Policy Engine decides over (§3), and the
+ * hash preimage every other artifact in this system binds to. Carried on
+ * legs F1.3, F4.1, F4.2 and F5.2 of the leg register (ZIFFER-DEPLOY-001
+ * Annex A).
+ *
+ * ONE SCHEMA, NOT TWO, AND THE CANONICAL FLAG IS AN ENCODING RULE RATHER
+ * THAN A PROPERTY. The closed artifact vocabulary carries two names for this
+ * object -- `Proposal` (§3) and `canonical Proposal` (B-1a) -- and they are
+ * one field set. `canonical` names an ENCODING of these bytes, not a second
+ * artifact with a second shape: B-1a requires the Proposal reaching the
+ * Executor to be `canonicalized identically before hashing`, and identical
+ * canonicalization of two different field sets is not a thing that can be
+ * asked for. A `canonical_proposal.schema.json` beside this file would put
+ * two definitions on one object, which is the defect this repository has
+ * published corrections for three times. The flag is therefore stated once,
+ * here, in the ENCODING paragraph below -- and NOT as a property. A field
+ * asserting `I am canonical` would be the party under verification
+ * certifying its own encoding; B-1a's obligation is discharged by the
+ * receiver hashing what it actually received (9.3-3), never by reading a
+ * claim about it.
+ *
+ * ENCODING: JCS, AND IT MUST NOT BE MIXED WITH THE CBOR RULE. §9.2 states
+ * the split in one sentence -- RFC 8785 (JCS) for the Proposal, canonical
+ * CBOR (RFC 8949 §4.2) for the receipt and the Attestation Object
+ * (WE-1/WE-2, AT-8a). AT-8a writes the second half as a prohibition (`JCS
+ * MUST NOT be used for the Attestation Object`) and this schema writes the
+ * first half the same way: canonical CBOR MUST NOT be used for the Proposal.
+ * Mixing them is the encoding split at the point it does the most damage,
+ * because `proposal_hash` is not one artifact's identifier -- it is the
+ * binding EVERY other artifact carries. AT-1 puts it in the object the
+ * humans sign; 9.3-3 makes the Executor recompute it over what it will
+ * actually execute; DS-6a builds `action_id` from it and DS-6f pins an
+ * IMMUTABLE `proposal_hash -> origin_nonce` binding in the Consumption
+ * Ledger, retained INDEFINITELY because an expiring one would reopen Z3
+ * (CL-3, CL-4); DR-13 writes it into the notice. Two encoders therefore do
+ * not merely disagree about a digest. They give ONE action two identities.
+ * The quorum the humans raised binds to a hash the Executor never computes,
+ * so 9.3-3 fails closed and at the verifier that is indistinguishable from a
+ * forgery -- the sentence WE-4's rationale already had to write once, for a
+ * type nobody had written down. And a re-drive re-encoded by the second
+ * encoder presents a `proposal_hash` DS-6f holds no binding for, so the
+ * recovery path DS-3 mandates fails closed on an authorized action; an
+ * implementation that instead BINDS the new hash has silently given one
+ * action two action identities and two DS-6b idempotency keys, which is the
+ * doubled trade DS-4 names as the worst failure available. Y5.2/AT-8a is
+ * that hazard one artifact over, against a binding kept for 24 hours; this
+ * one is kept forever.
+ *
+ * THE FIELD SET IS PR-1's (v1.3.27), AND THIS SCHEMA IS ITS RENDERING.
+ * Through v1.3.26 ZIFFER-SPEC-001 STATED NO FIELD SET FOR THE PROPOSAL: §3
+ * defined it in one sentence, SR-5 required the `(schema_id, schema_version,
+ * schema_hash)` triple and the fidelity class, B-6 forbade the client to set
+ * the stamp, V-11 spoke of an `envelope` and its `payload` and put
+ * `task_type` inside the payload -- and `reference/src/acp_executor.py` read
+ * a THIRD shape, flat, with `tenant_id`, `targets`, `params` and `cidrs` at
+ * top level and no `schema_version`, `schema_hash` or `fidelity` at all.
+ * Three shapes, one artifact, and `proposal_hash` was a hash over whichever
+ * one an implementer chose. This file reported that choosing between them
+ * was a normative act and refused to make it. v1.3.27 made it, after the
+ * first end-to-end build (M7) put the two shapes on one wire: the door
+ * emitted this envelope, the verifier graded the flat object, §9.3 step 8
+ * looked for a `tenant_id` the envelope could not carry, and neither side
+ * could be called wrong. PR-1 fixes the envelope -- the triple, the fidelity
+ * class, the tenant the admitting adapter's VERIFIED bundle names, and a
+ * CLOSED payload of `task_type`, `operator`, `targets`, `params` and `cidrs`
+ * -- as the one Proposal, the one hash preimage, and the one object §8.3.1's
+ * typing environment is derived from. The flat shape is gone: the reference
+ * reads the envelope through one accessor, `acp_executor.payload()`, and the
+ * Rust verifier through `acp_decision::Proposal::from_wire`, so a second
+ * reading has nowhere to live.
+ *
+ * WHY BOTH LEVELS ARE CLOSED, AND WHAT THAT REFUSES. `additionalProperties`
+ * is false at the root AND at the payload, and every property at both levels
+ * is REQUIRED -- `params` and `cidrs` may be EMPTY objects, never absent. An
+ * optional field means one object has two valid encodings and therefore two
+ * `proposal_hash` values -- Z4, which AT-8b closes for the Attestation
+ * Object by making its field set closed and every field required. Until
+ * v1.3.27 no clause did the same for the Proposal, although it is hashed,
+ * bound and ledger-keyed by the same machinery and its DS-6f binding is the
+ * one retained indefinitely; PR-1 now states AT-8b's rule for it in as many
+ * words, and this schema is where the rule is machine-readable. One
+ * consequence is disclosed rather than resolved: §7.4 permits a deployment
+ * to insert a domain-screening stage whose verdict `enters the Proposal as a
+ * field policy can rule on`. V-1 forbids unknown fields on the registered
+ * Input Schema that governs `params`, and PR-1 closes the payload around it,
+ * so that verdict has no key to live under. The specification names the
+ * field, does not name its key, does not type it, and does not say whether
+ * it is inside the hash preimage. A deployment that inserts a screen is
+ * outside this schema and needs a version increment, on AT-8b's reasoning
+ * applied here.
+ *
+ * WHAT IS NOT A FIELD. `proposal_hash` is DERIVED, not carried, and has no
+ * property below. It is SHA-256 over the canonical encoding of these bytes
+ * (§9.2), and §9.3 step 3 makes the Executor hash `the Proposal the Executor
+ * independently received and canonicalized` -- `never whatever the receipt
+ * describes`. A Proposal carrying its own hash invites a reader to compare a
+ * transmitted value against a transmitted value, which is TR-10 exactly: a
+ * transmitted identifier is a NAME for a binding, not evidence of one. Also
+ * absent, each deliberately: `risk_level` and `reversibility`, recomputed by
+ * the Executor from the signed bundle and these bytes (TR-8, RV-3) because a
+ * receipt-asserted risk is X1 and a receipt-asserted reversibility is the
+ * same defect with a new field; and `origin_nonce` and `idempotency_key`,
+ * pinned by the ledger with any receipt-carried claim diagnostic only
+ * (DS-6f, Z3). `operator` IS a field since PR-1 -- it is what §8.4 step 4
+ * checks capability for -- and it is still not authority at floor-HIGH,
+ * where the value the Executor acts on is `attestations[].obj.operator`
+ * inside the attester signature (Y4, §9.3 step 7b(iii-a)).
+ *
+ * SUITE 12 CLASSIFICATION. Every property below is class T at the schema
+ * layer: this document constrains SHAPE, and shape is not authority. What
+ * discharges each one lives elsewhere and is cited on the property rather
+ * than restated (DP-84). The triple is a NAME for a binding until §8.4 step
+ * 1 verifies it against the SIGNED registry (TR-10, SR-2). `fidelity` is
+ * RECOMPUTED from the bundle-registered adapter binding for `schema_id`
+ * (TR-8, §9.3 step 7) and is never read as authority from here,
+ * notwithstanding that B-6 requires it to be carried. `tenant_id` is stamped
+ * by the adapter from the bundle it VERIFIED (PR-2) -- B at the door -- and
+ * is T on the wire until §9.3 step 8 compares it against the receipt's and
+ * against the bundle the Executor trusts, at which point a receipt, a
+ * Proposal and a manifest that all name one tenant is what the step
+ * establishes. `operator` below floor-HIGH is the disclosed residual the
+ * receipt's `operator` already was (ACP-CLASS-001); at floor-HIGH it is B
+ * through Y4.
+ * Generated from proposal.schema.json.
+ */
+export interface Proposal {
+    /**
+     * Names the registered schema the payload was validated against. Schemas are
+     * content-addressed by `schema_id` + `schema_version` + `schema_hash` (SR-1)
+     * and SR-5 requires that triple on every Proposal. It is also the key the
+     * Executor uses to look up the bundle-registered ADAPTER binding when it
+     * recomputes `fidelity` (§9.3 step 7), so a Proposal without it leaves TR-8
+     * with nothing to recompute against and the FC-2 confirmation requirement
+     * resting on a transmitted stamp.
+     *
+     * THE PATTERN IS §6.3's, CHARACTER FOR CHARACTER, AND THE REFERENCE DOES NOT
+     * SATISFY IT. `reference/suites/conformance.py` builds `schema_id: "fw.v1"`,
+     * and `.` is outside that class. The pattern is kept as written: widening a
+     * schema's own pattern to admit the fixture that violates it proves only
+     * that the instrument is adjustable. Whether a pattern stated inside a
+     * NORMATIVE EXAMPLE binds an implementation is itself unresolved and is
+     * reported, not assumed.
+     */
+    readonly schemaId: SchemaId;
+    /**
+     * The semantic version of that registered schema (SR-1), carried on the
+     * Proposal by SR-5 so the artifact says which admissible SET it was checked
+     * against and not merely which schema name. This is the axis SR-3 decides
+     * change direction over: a change is NARROWING only where the new admissible
+     * set is a provable subset of the old in every dimension of the bounded
+     * lattice -- character class, length bound, enum set, numeric range -- and
+     * anything not provably narrowing in every dimension is widening and takes
+     * the distinct-reviewer path. v1.2.0 left `narrowing` undefined, which let a
+     * net-widening change self-classify as narrowing and bypass review.
+     */
+    readonly schemaVersion: SchemaVersion;
+    /**
+     * The content address of that schema version (SR-1), and the reason the
+     * triple is a triple rather than a pair: `schema_id` and `schema_version`
+     * are names a registry could remap, a hash is not. Class T here and a NAME
+     * for a binding, not evidence of one (TR-10). The binding is discharged at
+     * §8.4 step 1 -- schema attestation, valid `(schema_id, version, hash)` in
+     * bundle, else DENY -- against the SIGNED registry, and the validator MUST
+     * refuse to start on a signature or hash mismatch (SR-2). SR-6 supplies the
+     * other direction: a Proposal naming a removed schema receives DENY with
+     * `schema_retired`.
+     */
+    readonly schemaHash: Sha256Hash;
+    /**
+     * The fidelity class of the adapter that produced this Proposal. Stamped by
+     * the ADAPTER, bound into the Decision and the receipt, and MUST NOT be
+     * settable by the client (B-6); carried here because B-6 and SR-5 both say
+     * the Proposal carries it.
+     *
+     * CARRIED IS NOT TRUSTED. The Executor MUST verify fidelity against the
+     * bundle-registered adapter binding for this `schema_id` and MUST NOT accept
+     * it as transmitted (TR-8, §9.3 step 7), because a forged `F-HIGH` stamp
+     * suppresses the FC-2 confirmation requirement exactly as v1.3.0's forged
+     * `risk_level_floor_only` suppressed attestation (X1). The value is inside
+     * the hash preimage, so it is bound to everything `proposal_hash` binds --
+     * including the object the attesters signed and the
+     * `resource.effective_tier` comparisons that read `fidelity` in §8.3's own
+     * reference bundle -- and it is still not authority for any control
+     * decision.
+     *
+     * AND NO CLAUSE SAYS WHAT A DISAGREEMENT HERE MEANS. §9.3 step 7a makes a
+     * disagreement between the recomputed value and the RECEIPT's value a
+     * critical alert. Nothing states the outcome when the recomputed value
+     * disagrees with the value carried in the PROPOSAL, which is the value AT-3
+     * showed the attesters and the one the quorum is bound to. The Python
+     * reference never reaches the question: its Proposal carries no `fidelity`
+     * field at all, which is B-6 and SR-5 unimplemented rather than a reading of
+     * them.
+     */
+    readonly fidelity: FidelityClass;
+    /**
+     * The tenant the admitting Ingress Adapter's VERIFIED bundle governs
+     * (RAD-5's value, the manifest's `tenant_id`), stamped by the adapter under
+     * PR-2 and never settable by the client -- B-6's rule for `fidelity`,
+     * applied to the second value the door supplies. It exists so that §9.3 step
+     * 8 has a byte to compare: the step requires the receipt's tenant to equal
+     * the Proposal's AND the trusted bundle's, both held independently of the
+     * receipt, and until v1.3.27 the schema-shaped Proposal carried no tenant at
+     * all, so a conformant door's output could not pass a conformant Executor's
+     * step 8. Class T on the wire, discharged at step 8 -- and NOT a lookup key:
+     * the Executor selects its bundle from its own configuration and compares
+     * this value against it, never the other way round, because a transmitted
+     * tenant that selected the policy would be the KMS's pre-RAD-5 defect one
+     * component over.
+     */
+    readonly tenantId: TenantId;
+    /**
+     * The validated object itself: PR-1's closed payload of `task_type`,
+     * `operator`, `targets`, `params` and `cidrs`, all five REQUIRED. V-11 is
+     * the clause that names both halves -- it requires the validator to reject
+     * any envelope whose payload `task_type` disagrees with its `schema_id`.
+     * §8.3.1 says the typing environment risk expressions resolve against is
+     * `derived from the Proposal schema`: since PR-1 that environment is
+     * `params` (each entry an EL-2 value, bound under its own name) together
+     * with each target's tier from `floors.json` (`<target>.effective_tier`,
+     * RK-2), and nothing else in the envelope is visible to a rule.
+     */
+    readonly payload: ProposalPayload;
+}
+/**
+ * The lenient projection of Proposal: every field optional, every enum
+ * degraded to `string`. What a verifier parses. Never make a decision on
+ * one — the fail-safe lookups live on the strict type only.
+ */
+export interface RawProposal {
+    readonly schemaId?: string;
+    readonly schemaVersion?: string;
+    readonly schemaHash?: string;
+    readonly fidelity?: string;
+    readonly tenantId?: string;
+    readonly payload?: RawProposalPayload;
+}
+/**
+ * `task_type` and the four fields PR-1 closes the payload around. CLOSED at
+ * this level since v1.3.27, and the registered Input Schema's fields live
+ * INSIDE `params`, where V-1 closes them.
+ *
+ * WHAT WAS OPEN HERE, AND WHY IT IS NOT ANY MORE. Through v1.3.26 this
+ * object declared `task_type` and left everything else undeclared, on the
+ * argument that the payload's field set is closed SOMEWHERE ELSE -- the
+ * per-tenant, content-addressed registry SR-1 and L-06 describe, a
+ * DEPLOYMENT fact this file must not restate. The argument stands, and PR-1
+ * relocates it one level down: the registered schema governs `params`, an
+ * object whose keys are the deployment's, while the four members every
+ * Proposal has in common -- the action class, the principal, the resources,
+ * the CIDR widths -- are named once, here, and REQUIRED. An open payload had
+ * left the verifier no way to tell a registered field from a smuggled one,
+ * and the generated types carried `task_type` and nothing else, which a
+ * reader could take for the whole payload (ACP-153, item 14).
+ *
+ * Z4, SAID PLAINLY. Every member REQUIRED and both objects closed is AT-8b's
+ * rule -- no optional fields, no defaultable fields, no extension points --
+ * applied to the Proposal, which through v1.3.26 had no counterpart of it.
+ * `params` and `cidrs` are EMPTY objects when an action has none, never
+ * absent, so one action has one encoding. What this cannot close: a
+ * registered Input Schema that declares an optional or defaulted field
+ * inside `params` reopens it there, and no clause forbids one from doing so;
+ * B-1a is what stops that becoming two hashes -- the CANONICAL Proposal
+ * travels to the Executor and §9.3 step 3 hashes what arrived -- and the
+ * absence of an AT-8b-style rule for registered schemas is reported, not
+ * assumed harmless.
+ *
+ * WHAT THIS TYPE ENFORCES, AND WHAT IT DOES NOT. EL-2: every `params` value
+ * is an integer or a string, and a value of any other JSON type -- a
+ * non-integer number, a boolean, null, an array, an object, or an integer
+ * outside the width the deployment declares under AC-1a -- MUST cause the
+ * Proposal to be REFUSED, never re-typed and never coerced. Since v1.3.27
+ * the generated types carry that domain (`param_value`), so an off-domain
+ * value fails to parse rather than being read as a string; the clause exists
+ * because a JSON `22.0` bound as a STRING in the Python reference graded
+ * MEDIUM where `port: 22` graded HIGH, against this document's own reference
+ * bundle. Not enforced here and enforced at the validator instead: V-7 (NFC
+ * before pattern matching, bidi and zero-width code points refused), V-6
+ * (duplicate keys refused at every depth), L-01 to L-05 (32 KiB before
+ * parsing, depth 8, 24 fields per schema, 2,048 characters per string, 100
+ * items per list), and V-1's closure of `params` against the registered
+ * schema -- for which no signed registry exists yet in the bundle (ACP-153,
+ * item 12).
+ * Generated from proposal.schema.json#/$defs/proposal_payload.
+ */
+export interface ProposalPayload {
+    /**
+     * The action class: a `Literal` over the registered set, closed world, no
+     * dynamic dispatch and no plugins (V-8). §8.4 step 3 looks up a risk
+     * function by it and DENIES where none exists -- an action with no risk
+     * function is refused at `8.4-3` rather than graded HIGH, because grading an
+     * unknown action is P-4's rule broken. RV-3 recomputes the reversibility
+     * class from the trusted bundle and THIS value, never from the receipt, and
+     * RV-1's absent-implies-IRREVERSIBLE default keys on it; DR-13 then reads
+     * that default on the fast path, which is what turned it from documentation
+     * into a control.
+     *
+     * V-11 REQUIRES IT TO AGREE WITH `schema_id` AND DOES NOT SAY WHAT AGREEMENT
+     * IS. The clause admits two readings -- string identity, or a lookup
+     * resolving `schema_id` to the task type it registers -- and the two
+     * disagree on this repository's own fixtures, which pair `schema_id:
+     * "fw.v1"` with `task_type: "modify_firewall_rule"`. §6.3's normative
+     * example implements identity (`v.task_type != info.data["schema_id"]`),
+     * under which these are two spellings of one value and this property is
+     * redundant with `schema_id` -- and V-11 exists precisely because two
+     * spellings can disagree. The pattern below is `schema_id`'s, for that
+     * reason and no stronger one: no clause states a pattern for `task_type`
+     * directly, and this is the strongest thing the text supports.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: pattern `^[a-z0-9_-]{1,32}$`.
+     */
+    readonly taskType: string;
+    /**
+     * The operating principal the action is proposed for: the identity §8.4 step
+     * 4 checks every required capability against, step 6 tests against the
+     * excluded roles, and §8.5 groups accumulators by. The Attestation Object's
+     * `operator_id`, referenced rather than re-declared: one definition of a
+     * principal identifier. CARRIED IS NOT TRUSTED. Below floor-HIGH this is the
+     * disclosed residual the receipt's `operator` already was -- a
+     * client-asserted principal, bounded by the capability check that binds it
+     * to signed entitlements (§8.8). At floor-HIGH the authoritative value is
+     * `attestations[].obj.operator` inside every attester signature (Y4, §9.3
+     * step 7b(iii-a)), and the Policy Engine copies THIS value into the object
+     * the attesters sign, so a Proposal whose `operator` differs from what the
+     * quorum attested cannot execute.
+     */
+    readonly operator: OperatorId;
+    /**
+     * The resources the action names, by the identifiers `floors.json` is keyed
+     * by (RK-1; the item bounds are that table's `propertyNames`). At least one:
+     * an action that names no resource has no floor to recompute a risk from,
+     * and TR-8 has nothing to recompute against -- refused at the door under
+     * this schema rather than graded against nothing. At most 100 (L-05's
+     * per-list bound). Each target's tier enters the typing environment as
+     * `<target>.effective_tier` (RK-2), and a target absent from `floors.json`
+     * resolves to `T3` (RK-1) -- unknown is never LOW.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minItems 1, maxItems 100; items minLength 1, maxLength 256.
+     */
+    readonly targets: readonly string[];
+    /**
+     * The registered Input Schema's object -- the fields `(schema_id,
+     * schema_version, schema_hash)` resolves to and V-1 closes -- carried under
+     * one key so the four common members beside it can be named without
+     * restating a per-tenant registry here. Each value is an EL-2 value
+     * (`param_value`): an integer or a string, bound into the typing environment
+     * under its own name. EMPTY, never absent, for an action with no parameters
+     * (Z4). Nothing in this repository validates a payload against a registered
+     * Input Schema, because no signed registry exists in the bundle yet
+     * (ACP-153, item 12): until it does, `params` is closed by name at the
+     * registry a deployment holds and open to this file, which is disclosed
+     * rather than papered over.
+     *
+     * Map keys: A parameter name as the registered Input Schema declares it and
+     * as a rule names it in an expression (§8.3.1): lower-case, underscores, at
+     * most 64 characters. The set of names is the REGISTERED schema's (SR-1,
+     * V-1), closed there and not here.
+     */
+    readonly params: Readonly<Record<string, ParamValue>>;
+    /**
+     * Prefix widths of the CIDR-typed parameters, by parameter name:
+     * `{"source_cidr": 24}` for a `/24`. §8.3.1's `prefix_len(...)` reads them,
+     * and the environment builder binds each as `<name>.prefix_len` (AC-1a's
+     * integer width). A width is 0..128; an IPv4 width above 32 is the
+     * registered schema's to refuse. EMPTY, never absent, for an action with no
+     * CIDR parameter. Carried apart from `params` rather than parsed out of a
+     * string there, because the width is what a rule compares and a rule that
+     * had to parse a CIDR would be a rule that could be made to parse it
+     * wrongly.
+     *
+     * Map keys: The name of the CIDR-typed parameter the width belongs to, in
+     * the same class as a `params` name.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: values minimum 0, maximum 128.
+     */
+    readonly cidrs: Readonly<Record<string, number>>;
+}
+/**
+ * The lenient projection of ProposalPayload: every field optional, every enum
+ * degraded to `string`. What a verifier parses. Never make a decision on
+ * one — the fail-safe lookups live on the strict type only.
+ */
+export interface RawProposalPayload {
+    readonly taskType?: string;
+    readonly operator?: string;
+    readonly targets?: readonly string[];
+    readonly params?: Readonly<Record<string, unknown>>;
+    readonly cidrs?: Readonly<Record<string, number>>;
+}
+/**
+ * One execution per receipt (CL-3, T-09). The Executor claims the receipt
+ * nonce at §9.3 step 6, before any effect leaves the control plane, and a
+ * second receipt bearing the same nonce is refused because the ledger
+ * already holds it. AT-5's shape applies here too: single use is enforced by
+ * consumption, never by assertion -- v1.2.0 stated the property and shipped
+ * no mechanism.
+ * Generated from ledger_claim.schema.json#/$defs/receipt_nonce_claim.
+ */
+export interface ReceiptNonceClaim {
+    readonly tenantId: TenantId;
+    /**
+     * CL-3's first identifier class. See the note on `artifact_class` naming in
+     * `$defs/tenant_id` and in the schema description: the four tokens are this
+     * schema's rendering of class names the specification states only in prose.
+     */
+    readonly artifactClass: 'receipt_nonce';
+    /**
+     * The receipt's `nonce` (§9.2), sized 128 bits by L-17 and typed by WE-4.
+     * Named `identifier` rather than `nonce` because CL-5 writes the ledger key
+     * as `(tenant_id, artifact_class, identifier)` and a second spelling of one
+     * column is the defect this repository is built around.
+     */
+    readonly identifier: Nonce128;
+}
+/**
+ * The lenient projection of ReceiptNonceClaim: every field optional, every enum
+ * degraded to `string`. What a verifier parses. Never make a decision on
+ * one — the fail-safe lookups live on the strict type only.
+ */
+export interface RawReceiptNonceClaim {
+    readonly tenantId?: string;
+    readonly artifactClass?: string;
+    readonly identifier?: string;
+}
+/**
+ * The SIGNED OBJECT a door produces during a deferred-release hold (DR-14):
+ * the human-readable summary of one action, bound to the canonical Proposal
+ * it was rendered from and to the role that rendered it. One shape, two
+ * producers -- the Attestation Presentation Service signs the approval
+ * summary under the `presentation` key and the notification service signs
+ * the Notification under the `notification` key, both named in the bundle's
+ * door_identities.json (PB-11). The Executor verifies each under the key for
+ * its role and compares each `proposal_hash` against its own canonical hash
+ * of the held Proposal.
+ *
+ * WHAT THE SIGNATURE DOES NOT PROVE. That `summary` is faithful to the bytes
+ * `proposal_hash` names. A compromised door signs whatever it renders; what
+ * it can no longer do is sign for the OTHER door, because it does not hold
+ * that key. Rendering honesty remains DR-2's structural requirement -- no
+ * shared rendering path, demonstrated at build time under conformance suite
+ * 3 -- and this object must not be read as though a signature supplied it.
+ *
+ * CLOSED FIELD SET, FOR Z4'S REASON: an optional field gives one summary two
+ * valid encodings. No nonce, on purpose: the object binds `proposal_hash`, a
+ * replay of it is the same summary for the same action, and DR-4/DR-5 key
+ * repudiation on the proposal, not on the summary.
+ * Generated from notification.schema.json#/$defs/rendered_summary.
+ */
+export interface RenderedSummary {
+    /**
+     * CR-1: the signature suite this object is signed under, inside the signed
+     * bytes. An unregistered suite fails closed.
+     */
+    readonly alg: SuiteId;
+    /**
+     * Which door rendered this. Inside the signed bytes so the object says what
+     * it is: the Executor still resolves the key by the slot it expects
+     * (notification under `notification`, approval summary under
+     * `presentation`), and PB-11's distinctness means a summary signed for one
+     * slot cannot verify in the other -- but a signed object that does not name
+     * its own role is one whose meaning depends on where it was found, which is
+     * the two-encodings defect one step removed.
+     */
+    readonly role: DoorRole;
+    /**
+     * The canonical Proposal this summary was rendered from. The binding the
+     * object exists to carry: the Executor compares it against its OWN canonical
+     * hash of the Proposal being held, never against a transmitted value
+     * (TR-10's shape). This is also what DR-4's repudiation cites, which the
+     * unsigned notification of v1.3.24 could not name -- an earlier revision of
+     * this file reported that gap and did not patch it; DR-14 closes it.
+     */
+    readonly proposalHash: Sha256Hash;
+    /**
+     * The human-readable summary DR-2 requires, rendered from the canonical
+     * Proposal bytes by the door named in `role`. §7.3 governs its content and
+     * this is the field most exposed to the model: the canonical Proposal
+     * carries parameters that passed validation and are still
+     * attacker-influenced, so whatever displays this string MUST treat it as
+     * DATA and never as markup -- an approver reading attacker-influenced prose
+     * is an injection target, and T-02 includes humans. Empty is refused
+     * (`minLength: 1`, this schema's reading): a summary with no content is a
+     * detection channel that is present and blank. No maximum, deliberately: an
+     * invented bound silently truncates a legitimate summary, which is a display
+     * lie manufactured by the schema. Named for the specification's word;
+     * `reference/src/acp_executor.py` called it `text` through v1.3.24.
+     *
+     * Schema constraints, carried as documentation and NOT enforced by this
+     * type: minLength 1.
+     */
+    readonly summary: string;
+}
+/**
+ * The lenient projection of RenderedSummary: every field optional, every enum
+ * degraded to `string`. What a verifier parses. Never make a decision on
+ * one — the fail-safe lookups live on the strict type only.
+ */
+export interface RawRenderedSummary {
+    readonly alg?: string;
+    readonly role?: string;
+    readonly proposalHash?: string;
+    readonly summary?: string;
+}
+/**
+ * What the KMS receives from the Policy Engine. It is the only artifact that
+ * crosses leg F3.2 of the leg register (ZIFFER-DEPLOY-001 Annex A), and it
+ * carries one thing: the canonical bytes the KMS is being asked to sign with
+ * the `receipt_signing_key` (§9.1.1 step 6).
+ *
+ * WHY THE FIELD SET IS CLOSED, AND WHY IT HAS EXACTLY ONE MEMBER. §9.1.1
+ * step 2 has the KMS extract 'the claimed `policy_bundle_hash` and
+ * `bundle_epoch`' from every signing request. Both are already inside the
+ * bytes below, because both are receipt fields (§9.2). Carrying them AGAIN
+ * beside those bytes would give one value two spellings, and the two
+ * spellings are separately chosen by the party under verification. A
+ * compromised Policy Engine puts the current epoch and the current bundle
+ * hash in the request fields -- which is what the KMS retrieves, verifies
+ * and checks against its high-water mark (steps 3-5) -- and a superseded,
+ * genuinely signed, more permissive bundle's hash and epoch in the body it
+ * hands over. Every step of §9.1.1 passes, and the KMS then signs, under the
+ * one key the Executor trusts, a receipt naming a bundle it never verified.
+ * That is not a subtle failure of the protocol: it is RAD-4 violated in the
+ * exact words RAD-4 uses, reached without the KMS breaking any rule it was
+ * given, because the rule was given about a different field. Downstream it
+ * is T-15 bundle rollback, and §9.3 step 4 is the only thing left in its way
+ * -- a comparison against the Executor's last-seen epoch, which
+ * ZIFFER-SPEC-001 never makes durable or shared (ZIFFER-DEPLOY-001 DP-40
+ * supplies that obligation and records the gap as a live one).
+ * `additionalProperties: false` with one required member is what forbids the
+ * second spelling, and it is the reason this artifact needs a schema at all
+ * rather than being left to the transport.
+ *
+ * WHAT THE KMS DOES WITH THIS, SO THE SCHEMA IS NOT MISREAD AS AUTHORITY.
+ * Every value reachable through this field is a CLAIM by the Policy Engine,
+ * and RAD-4 is explicit that the KMS MUST NOT accept bundle metadata, epochs
+ * or policy hashes from the Policy Engine runtime without cryptographic
+ * verification. The `policy_bundle_hash` in the body is a NAME for a bundle,
+ * never evidence of one: the KMS retrieves that bundle from the read-only
+ * repository the Policy Engine runtime cannot write to (§9.1.1 step 3,
+ * isolation stronger than filesystem permissions) and verifies its Ed25519
+ * signature against its own copy of the `policy_signing_key` public key
+ * (step 4). On failure it rejects all signing requests until a valid bundle
+ * is presented (RAD-4). The `bundle_epoch` in the body is not authority
+ * either: RAD-3 compares it against the highest epoch the KMS has ever
+ * validated for that tenant in durable storage, rejects anything lower, and
+ * updates the mark (step 5). The mark is state at the KMS and appears in no
+ * message here. TR-10 states the general form -- a transmitted identifier is
+ * a name for a binding, not evidence of one.
+ *
+ * WHAT IS NOT A FIELD, each absence with its reason. (a) No
+ * `policy_bundle_hash`, `bundle_epoch` or `tenant_id` beside the body: one
+ * value, one spelling, per the paragraph above; the tenant RAD-1, RAD-2 and
+ * RAD-3 are all scoped to is the body's `tenant_id` (§9.2). (b) No key
+ * identifier and no algorithm or suite selector: the Executor verifies under
+ * the `receipt_signing_key` the signed bundle registers (§9.3 step 1), so
+ * the key is settled by the bundle the KMS has just verified, not by the
+ * requester. Offering the party under verification a negotiable parameter is
+ * the downgrade shape AB-0 refuses one layer up, where accepting receipt
+ * versions 2 and 3 concurrently would let an attacker present the weaker
+ * one. (c) No canonical Proposal: §9.1.1 gives the KMS steps 2-5 and no
+ * policy evaluation. The KMS is independent about BUNDLE AUTHENTICITY, not
+ * about whether the Decision is correct, and §10's compromise table already
+ * grants that a compromised Policy Engine emits arbitrary Decision content,
+ * answering it with RAD-1/RAD-2 rate limits, the Executor's recomputation
+ * (TR-8) and audit replay. A Proposal on this leg would read as a second
+ * evaluation that no clause defines. (d) No attestation entries: under
+ * receipt version 3 they are excluded from the signed body by construction
+ * (AB-5), they reach the KMS from the approver devices on leg F4.4, and they
+ * travel beside the receipt on F3.3. (e) No `x-acp-absent` anywhere: no
+ * clause declares a fail-safe default for any part of this artifact, and
+ * inventing one would give an absent field a meaning the specification does
+ * not give it.
+ *
+ * WHAT THIS SCHEMA DOES NOT CONSTRAIN, stated so the claim is not read wider
+ * than it is. It constrains SHAPE, and shape is not authority: under the §14
+ * suite-12 classification every value reachable through this field is class
+ * T at the schema layer, and the receiving obligations are RAD-3 and RAD-4
+ * exactly as the leg register cites them, not restated here
+ * (ZIFFER-DEPLOY-001 DP-84). It says nothing about ORDER, and §9.1.1 is an
+ * ordered checklist: a KMS that signs first and verifies afterwards
+ * satisfies every line below. It says nothing about the durable high-water
+ * mark, which is per-tenant state and crosses no leg. It says nothing about
+ * freshness of the request itself -- no clause gives this leg an anti-replay
+ * value, and a replayed request re-signs the same body, whose duplicate is
+ * caught downstream only by CL-3's consumption of the receipt nonce. And it
+ * says nothing about the response: §9.1.1 step 7's `SIGNING_DENIED` is a
+ * normative reply with no schema here and no row in the leg register.
+ *
+ * WHAT THE SPECIFICATION DOES NOT ANSWER. Recorded rather than filled in,
+ * because a schema that invents an answer publishes it as though the
+ * specification had one. (1) Who assembles `attestation_digests` (AB-1) is
+ * unstated, and the register gives the Policy Engine no leg on which
+ * attestation entries or their digests reach it -- F4.4 routes them to the
+ * KMS. If the KMS assembles them, this leg carries a PARTIAL body and this
+ * schema is wrong in shape rather than in detail. (2) §9.1.1 step 2 does not
+ * say whether the claimed values are separate request fields or are read out
+ * of the body; this schema takes the second reading and gives its reason
+ * above, but the text settles neither. (3) No clause names the party that
+ * canonicalizes the receipt body, nor forbids the KMS re-encoding a
+ * structure it decoded before signing; AT-8a states that rule for the
+ * Attestation Object only. (4) AB-6's 4,096-byte bound is written about the
+ * Executor, and no clause states it at this leg even though the bytes are
+ * the same bytes. (5) Nothing in this repository builds or consumes a
+ * signing request: `sim/receipts.py` plays the KMS and signs directly, there
+ * is no KMS-side epoch mark anywhere, and `tools/check-flow-legs.py`
+ * resolves this leg's RAD-3 citation against a raise site in the Executor
+ * and exempts RAD-4 outright. So the two obligations this leg cites have no
+ * executable consumer AT THIS BOUNDARY, which is the
+ * normative-text-with-no-executable-consumer shape ACP-50, ACP-56 and ACP-57
+ * each landed a check for.
+ * Generated from signing_request.schema.json.
+ */
+export interface SigningRequest {
+    /**
+     * The bytes to be signed: the canonical CBOR encoding (RFC 8949 §4.2) of the
+     * receipt body WITHOUT the attestation entries (WE-1, WE-2, AB-5), carried
+     * as a WE-4 value.
+     *
+     * THE NAME IS THE SPECIFICATION'S. AB-5, AB-6 and §9.3 step 7b all call
+     * these bytes 'the signed body', so calling them anything else here would be
+     * a second vocabulary for one object -- the defect ZIFFER-DEPLOY-001 DP-16
+     * forbids one layer down. At this leg the signature does not exist yet; the
+     * name is for the bytes the signature will cover, and no field here carries
+     * a signature.
+     *
+     * THE KMS SIGNS THE BYTES IT RECEIVED. It parses them to extract the claimed
+     * `policy_bundle_hash` and `bundle_epoch` of §9.1.1 step 2, and signs the
+     * received encoding rather than a re-encoding of the structure it decoded.
+     * Two encoders on one signing path is the defect AT-8a names for the
+     * Attestation Object -- issuer and verifier disagree and one object acquires
+     * two identities -- and nothing about the receipt makes it immune, since the
+     * Executor recomputes nothing here and verifies the signature over the bytes
+     * it is handed (§9.3 step 1). WE-3 refuses JSON as receipt input for the
+     * same reason; it is written about a receipt consumer rather than about this
+     * leg, so it supports the rule here without stating it. Carrying bytes
+     * rather than a decoded object is also what makes 'the bytes signed are the
+     * bytes the Policy Engine composed' a checkable claim instead of an
+     * assumption.
+     *
+     * THE LENGTH BOUND IS DERIVED, NOT CITED, AND IT IS NOT EXACT. AB-6 caps the
+     * signed body at 4,096 bytes and requires the check on MEASURED BYTES rather
+     * than on any proxy, having been written after a draft capped the digest
+     * count at 50 and measured 4,107 bytes at that cap. These are the bytes AB-6
+     * bounds (AB-5), so a request over the cap asks for a receipt no conformant
+     * Executor may accept and no custody tier T2 key can produce -- the
+     * 4,096-byte limit is AWS KMS's `MessageType: RAW` cap, executed rather than
+     * read in `tools/kms-compat-2026-08-22.json` (5/5 PASS, 2026-08-22).
+     * `maxLength` here is on the base64 TEXT, and base64 quantizes at three
+     * bytes: 5,468 characters admits 4,098 bytes, two more than AB-6 allows. It
+     * is therefore a floor on refusal and never the check. An implementation
+     * MUST measure the decoded bytes, which is AB-6's own warning about proxies
+     * applied to AB-6's own transport encoding. No clause places the bound at
+     * this leg at all; that gap is recorded on the schema above rather than
+     * closed here.
+     *
+     * EVERYTHING IN THESE BYTES IS A CLAIM. The KMS verifies the bundle they
+     * name (RAD-4) and the epoch they reference (RAD-3) against artifacts and
+     * state it holds itself; it does not verify the Decision they assert, and no
+     * clause asks it to.
+     */
+    readonly signedBody: Base64Bytes;
+}
+/**
+ * The lenient projection of SigningRequest: every field optional, every enum
+ * degraded to `string`. What a verifier parses. Never make a decision on
+ * one — the fail-safe lookups live on the strict type only.
+ */
+export interface RawSigningRequest {
+    readonly signedBody?: string;
+}
+/**
+ * One claim made against the Consumption Ledger. Carried on leg F3.4 of the
+ * leg register (ZIFFER-DEPLOY-001 Annex A), Executor -> Consumption Ledger,
+ * whose cited receiving obligations are CL-2, CL-3, CL-6 and CL-7. The
+ * Consumption Ledger is TCB (§4.3): a ledger that falsely reports an
+ * identifier absent reopens T-09 (receipt replay) and T-14 (attestation
+ * amplification). This document is the smallest thing that can be wrong
+ * before any of those guarantees is reachable at all.
+ *
+ * WHY THIS IS FOUR CLOSED OBJECTS AND NOT ONE OBJECT WITH OPTIONAL FIELDS.
+ * CL-3 enumerates four identifier classes and they do not carry the same
+ * value: a receipt nonce is 128 bits rendered `b64:` (WE-4, L-17), an
+ * attestation id is a `sha256:` digest over the canonical CBOR of the whole
+ * Attestation Object (AT-1, AT-8a), a bundle epoch is an integer high-water
+ * mark (CL-3, RAD-3), and an origin binding is a PAIR, `proposal_hash` to
+ * `origin_nonce` (DS-6f). Folding those into one object requires optional
+ * fields, and an optional field is Z4 exactly as AT-8b describes it one
+ * layer up: the same claim present-as-null and the same claim with the field
+ * omitted are each well formed, encode differently, and any ledger that keys
+ * or audits on the encoded claim then holds two rows for one claim. One
+ * nonce, two slots, which is the hole CL-3 exists to close. So each class is
+ * its own object, every field is REQUIRED, `additionalProperties` is false,
+ * and the composition is `oneOf` rather than `anyOf` so that a document
+ * matching two branches is REFUSED rather than resolved to the first match.
+ *
+ * `x-acp-absent` deliberately appears nowhere below. §9.3.1 declares no
+ * absent-value default for a claim, and inventing one here would let a
+ * malformed claim be normalized into a well-formed one, which is the precise
+ * opposite of what CL-2 requires when the ledger cannot proceed. A default
+ * that turns a refusal into an acceptance is not a fail-safe default.
+ *
+ * WHY `artifact_class` IS CARRIED AND NOT INFERRED FROM THE VALUE. CL-5's
+ * key is the triple `(tenant_id, artifact_class, identifier)`, and the class
+ * is what keeps the four namespaces disjoint. Without it, one execution per
+ * receipt (T-09) and one receipt per attestation (T-14) stop being
+ * independent guarantees: an identifier claimed in one class is observed as
+ * claimed in the other, so consuming an attestation can silently consume a
+ * nonce that was never issued, or fail to consume one that was. Inferring
+ * the class from the value's syntax is strictly worse than carrying it,
+ * because two of the four classes already share the `sha256:` form -- an
+ * attestation id and the key half of an origin binding are both digests, and
+ * nothing in the string distinguishes them.
+ *
+ * WHAT IS NOT A FIELD, AND WHY. (a) No timestamp. CL-8 requires identifier,
+ * class, timestamp and Executor identity in the audit row of every claim
+ * operation, hit and miss; it does not say the claim carries them, and F3.4
+ * does not cite CL-8 at all. A claim-carried timestamp lets the party the
+ * audit row is ABOUT choose the time that row is dated, which is the T-32
+ * shape -- a component certifying a fact about itself -- while the ledger
+ * has its own clock and is the party doing the recording. (b) No Executor
+ * identity, for the same reason: an identity taken from the authenticated
+ * connection (mTLS is REQUIRED between components, §4.3) is evidence, an
+ * identity typed into the message by the sender is a name for one. (c) No
+ * compare-and-swap comparand. CL-2 requires CAS or an equivalent atomic
+ * primitive, but the expected value is fixed by the semantics rather than
+ * chosen per call -- absence, for the three consumption classes, and
+ * absence-or-the-already-adopted-value for the binding (CL-7) -- so a
+ * transmitted expectation would let the claimant choose the bar it is
+ * measured against. For the epoch class that is not a subtlety: a
+ * transmitted expected high-water mark is T-15 bundle rollback with extra
+ * steps. (d) No response. The ledger's answer travels the other way and the
+ * register has no return row for it; that omission is recorded against this
+ * schema rather than silently repaired by modelling a message the register
+ * does not carry.
+ *
+ * WHAT THIS SCHEMA CANNOT CONSTRAIN, STATED SO THE CLAIM IS NOT READ WIDER
+ * THAN IT IS. Every clause F3.4 cites is about BEHAVIOUR or ORDERING, and
+ * none of them is expressible in a message shape. CL-1 linearizability; CL-2
+ * atomicity and fail-closed when the ledger is unavailable; CL-6 fail-closed
+ * when absence cannot be confirmed; CL-7 completing the read phase across
+ * the quorum before mutating any replica, and never resolving a disagreement
+ * by vote; CL-4 retention; DS-6f immutability of the binding and the
+ * critical alert on a rebind attempt. A schema-valid claim says nothing
+ * about any of them. They are per-implementation obligations
+ * (`spec/vectors/OBLIGATIONS.md`), exercised by
+ * `reference/suites/partition_suite.py` and `partition_integration.py`. An
+ * implementation reporting "CL-7 satisfied" because a claim validated
+ * against this file has answered a different question from the one CL-7
+ * asks.
+ *
+ * THIS SCHEMA HALTED `tools/codegen.sh`, AND THE HALT IS WHAT GOT THE RULE
+ * WRITTEN. `oneOf` was on the generator's refused list, because it emitted
+ * no rule for a tagged union and a generated type that looked complete while
+ * expressing none of the union would be worse than no type at all. Neither
+ * way of making the halt go away was taken, because both damage something
+ * real: collapsing the four classes into one object needs optional fields,
+ * which is the Z4 defect this schema is shaped to refuse, and dropping a
+ * class contradicts CL-3, which enumerates four. What the halt actually said
+ * is that the ACP-78 wire surface contains a tagged union -- so in M1 the
+ * generator was taught one. It accepts a `oneOf` whose branches are closed
+ * objects made disjoint by a single required `const` field, PROVES that
+ * discriminator from the schema rather than being told it, and still halts
+ * on any `oneOf` that is not tagged. The tag is `artifact_class`, which CL-5
+ * already makes a column of the ledger key, so nothing here exists for the
+ * generator's benefit. What the generated union deliberately does NOT carry
+ * is a decoder that tries branches until one fits: `first shape that fits`
+ * is how a document meant as one artifact class is accepted as another,
+ * which is the namespace collapse `artifact_class` exists to prevent.
+ *
+ * SUITE 12 CLASSIFICATION. Every field below is class T at the schema layer,
+ * because shape is not authority and this document constrains shape. Two of
+ * them need their residual said out loud. `tenant_id` NAMES a namespace and
+ * does not authorise one: where a deployment runs one ledger per tenant
+ * (CL-5) the tenant is fixed by the instance and the authenticated
+ * connection, and a claim MUST NOT reach another tenant's namespace by
+ * naming it. `origin_nonce` is a value being pinned for the first time,
+ * never evidence that a binding exists -- on a re-drive the Executor MUST
+ * READ the origin from the ledger and derive `idempotency_key` from what it
+ * read (DS-6f, closing Z3), and that read is a different operation from this
+ * message.
+ * Generated from ledger_claim.schema.json.
+ *
+ * A DISCRIMINATED union over `artifactClass`, which every branch pins to a
+ * literal. Narrow it by switching on that field; a `default` arm that
+ * accepts an unrecognised value is a branch this union does not have, and
+ * the fail-safe answer there is to refuse. There is no `Raw` union: with
+ * every field optional each branch would accept every other document and the
+ * tag would decide nothing.
+ */
+export type LedgerClaim = ReceiptNonceClaim | AttestationIdClaim | BundleEpochClaim | OriginBindingClaim;
+//# sourceMappingURL=generated_wire.d.ts.map