The Open Record REST API.

Machine-readable state.

Human-readable, exact, never alarmist.

Where applicable, the open-record entry the reader can cross-check.

Sequential wave identifier, zero-padded.

When participants may begin seating.

Last moment to seat a participation. Must be ≥ opens_at.

When the mechanism seed is revealed and the outcome resolves. Must be ≥ closes_at.

ULID reference to the published mechanism for this wave. The mechanism is published — including its seed commitment — before the wave opens.

Fraction of the wave's outcome that flows to the beneficiary cause. Expressed in [0, 1], e.g. 0.12 == 12%.

Slug of the verified cause receiving the charitable share.

Wave lifecycle. 'announced' = mechanism published, not yet open. 'resolving' = window between closes_at and the recorded outcome. 'settled' = outcome verified and contributions transferred.

ULID of this mechanism document.

Identifier of the algorithm spec in the veraq-protocol repository.

Algorithm-specific parameters. Shape is determined by the algorithm field and validated by the spec in veraq-protocol/algorithms/<algorithm>.md.

Lowercase hex SHA-256 of (seed || parameters_canonical_json). Binding commitment published before the wave opens.

Lowercase hex of the 32-byte seed. Null until resolves_at; non-null after. Verifying: SHA-256(seed_revealed || parameters_canonical_json) must equal seed_commitment.

When the commitment was published. Must be < the linked wave's opens_at.

When seed_revealed was published. Null while undisclosed; ≥ wave.resolves_at when set.

Optional URL to a verifying transcript (re-run output) for additional inspectability.

Stable participant identifier (ULID).

Foreign key into Verdify's own identity space (ADR 0011). Names the `usr_…` identity this participant record projects. Required and non-null — an explicit design decision of this epic, not an inference from a ceremony this repo has not built yet (`04` `W6-E04`, `W6-E09` are unbuilt): ADR 0011 and `01-platform-architecture.md` §3.4 D4 establish only that Veraq builds no sign-in of its own, not when a `Participant` row is first created relative to identity resolution. If a future epic finds a real lifecycle state where a seat exists before its Verdify identity resolves, this field's nullability is this epic's call to revisit, not a settled fact to work around. Only the `usr_` prefix is validated; the token's own internal structure is Verdify's to define, not Veraq's — following the same opaque-external-id convention `commitment_id` and `product_id` already use (ADR 0023 Decision 6).

Optional public-facing handle. May be null for participants who choose not to display one.

When the participant first seated.

When identity verification was completed, if applicable. Null if unverified.

Wave-scoped participation id. Format: wave_id, hyphen, 4-character suffix.

Replaces `participant_id` per `01-platform-architecture.md` §4.3 change 5: "Replace `participant_id` and any durable signature in published entries with a per-instance pseudonym; hold the mapping salted in Custody, so erasure destroys the salt rather than the record." PER-INSTANCE, LOAD-BEARING NOT DECORATIVE: this value is scoped to THIS participation record only — never a stable value reused across the same participant's other participations in other waves. A single durable pseudonym reused across many published Participation records would ITSELF become "a durable signature" and re-enable cross-wave correlation of one participant's activity, which is exactly what change 5 also separately bans by naming "any durable signature," not only the literal field `participant_id`. RESOLUTION (pseudonym → the real participant) happens ONLY via a salted mapping held in Custody — the `.net` port `04` W2-E03 builds — never inline in this record, and never derivable from these bytes alone by an outside reader. NO PATTERN, DELIBERATELY, on fund.schema.json `id`'s own precedent ("no document fixes an id space for this... inventing one would freeze a byte before its gate"): this schema commits only to SHAPE — opaque, non-empty, per-instance, unlinkable without Custody's mapping — never to a derivation scheme (which hash, which KDF). The exact construction is UNSPECIFIED because the authority that was meant to specify it, "Core blueprint §11.4," does not exist anywhere in this repository or its git history — `G-blueprint` (`03-product-model.md`:611, "UNRESOLVED — recorded, not removed"; `04-implementation-roadmap.md`:169). Building that mapping, its salt storage and the cascade it must survive is `W8-E14`'s job (`04-implementation-roadmap.md`:740-742), not this schema-shape change's. ERASURE (later, `W8-E14`'s job) destroys the salt in Custody's mapping, not this record — the published Participation entry survives unchanged, append-only, per this corpus's Open Record philosophy, while re-identification becomes permanently impossible.

Optional weighting used by weighted-selection mechanisms. Omitted means weight = 1.

ADR 0039 — the participation-role distinction. OPTIONAL, WITH NO DEFAULT: a family whose participations play one undifferentiated role (official-result, sponsored-funding, forecasts, community-participation) simply never sets this field, and omission asserts nothing about whether that participation paid into the container — declaring a default here would misdescribe those families' non-paying, free-entry seated participants as payers by default, exactly the false assertion ADR 0039 exists to avoid. `contributor`: this participation funded the container's pool. `recipient`: this participation did not fund the pool and may instead receive value the mechanism assigns to it — `sortition-funding`'s qualified-proposal recipient (`03-product-model.md` §5.2) is the motivating case, and `allocation.schema.json`'s `recipient_participation_id` is expected to resolve to a `recipient`-kind participation for that family, never to a `contributor`-kind one, though this schema enforces no cross-document check. BOTH KINDS MAY COEXIST IN ONE CONTAINER: this is a per-participation leaf property, never a per-container setting, because `sortition-funding`'s own pool holds contributing participants and qualified-proposal recipients side by side — that coexistence is exactly what invariant 3's 2026-08-14 qualification (`03` §5.2) names. THIS DOES NOT REACH ADR 0015 §5's closed, seven-item crossing-authority set: `Allocation` still discharges 'to a participant, from `OBLIGATION_PARTICIPANT`' (ADR 0015:100) exactly as written — this field only names which role a given `Participation` record plays; it neither widens, renames nor adds to the authority set, and `allocation.schema.json`'s own description already distinguishes the record-level `Allocation` entity from ADR 0015's crossing authority for the identical reason. NOT A REGULATORY CLAIM: this field records a mechanical fact — who paid in and who did not — and settles no question about whether any family is a chance-prize product in any jurisdiction; see `03` §5.2's own 'Regulatory character' paragraph and ADR 0012's classification-memo gate, which this field neither answers nor forecloses.

Optional Ed25519 signature (hex, 64 bytes) by the participant over canonical(wave_id || participant_pseudonym || seated_at) — updated from canonical(wave_id || participant_id || seated_at) now that `participant_id` no longer exists as a field (`01-platform-architecture.md` §4.3 change 5). When present, the open record can verify the participation was authorised by the participant's key. OPEN — RECORDED, NOT RESOLVED: change 5 names "any durable signature" as in scope, not only the literal `participant_id` field. A signature verified against a participant's own STABLE, reused Ed25519 key would itself remain a durable, cross-participation-correlatable signal — regardless of this pseudonym fix — if the same key is reused across a participant's multiple participations. Whether the signing key itself must become per-instance too (e.g. a fresh keypair per participation) is a genuine open cryptographic-protocol design question this schema-shape change does not resolve. Flagged, citing `G-blueprint` (the "Core blueprint §11.4" authority this all traces to does not exist in this repository or its git history — `03-product-model.md`:611): key-management policy is `W8-E14`'s to decide (or a future epic's), not this one's. No key-rotation scheme is asserted here.

Wave-scoped composite (03 §2 level 6 — an Outcome is genuinely container-bound, unlike Contribution.outcome_id, which W1-E11 deliberately decoupled). NO LONGER derived from, or equal to, any recipient_participation_id by convention (canon-defect-register.md D20, resolved by this epic): W1-E08's Allocation set already gives an Outcome many recipients, so no single recipient_participation_id is left for this id to be named after — the derivation convention the pre-Allocation design practised is gone, not merely undocumented.

The participation selected by the mechanism. The participant behind it can be looked up via the participation record.

Snapshot of the mechanism state at the moment of settlement. Sufficient on its own — combined with the wave's participation list — for an independent verifier to reproduce the selection.

Whether at least one independent verifier has replayed the mechanism and matched the recipient. Outcomes are not considered fully settled until verified == true.

The outcome this transfer settles. NO PATTERN: this field previously carried the wave-scoped composite pattern (`^[0-9]{3,6}-[0-9A-HJKMNP-TV-Z]{4}$`), which made this money leg wave-shaped in the frozen bytes even though `01` §1.3 calls it primitive-agnostic — the defect `03` §1.4 diagnoses: "`contribution.schema.json:25` patterns `outcome_id` as the wave-scoped composite, so the money leg that `01` §1.3 calls primitive-agnostic is wave-shaped in the frozen bytes." ADR 0025 §7 confirms `W1-E11` acceptance 3 undoes that here, on `Allocation.outcome_id`'s own no-pattern precedent (`allocation.schema.json`). `minLength: 1` is strictly weaker than any pattern: it refuses only the empty string, which names no outcome, and freezes no id space.

When the transfer was confirmed. Null while pending.

Optional URL to a third-party transfer proof — bank receipt, on-chain transaction, etc.

Stable slug. Used wherever a cause is referenced.

How this cause was verified as eligible to receive charitable share. The brand promise requires this to be inspectable.

Where the contribution is transferred — now the payout-rail discriminated union `payout-rail.schema.json` defines (`01-platform-architecture.md` §4.3 change 3, driven by D5, ADR 0012; `04` W4-E02), rather than opaque free text. `01` §4.3 change 3's own defect text: 'Nullable free text, mixing escrow handles, IBANs and `0x` addresses — three incompatible rails, no discriminator.' `$defs.payoutRail` above is a byte-for-byte copy of `payout-rail.schema.json`'s own `oneOf` — `cause.schema.json` is a vendored schema and this package's ajv setup compiles each schema independently with no cross-file `$ref` registration (no `ajv.addSchema` linking files together), so the only reuse mechanism available here is verbatim duplication into a local `$defs` entry, proven never to silently diverge by this schema's own structural test in `cause.test.mjs` (`schemas.cause.$defs.payoutRail.oneOf` deep-equals `schemas.payout_rail.oneOf`). `null` remains valid — unchanged from this field's prior nullability, meaning 'not yet set.' Any non-null value must now match exactly one of the three named, `kind`-discriminated rails: `bank_iban`, `crypto_address`, or `escrow_handle`; the old bare free-text form no longer validates. Wired in HERE, in one commit with `01` §4.3's other five changes, because `04` W1-E11's own acceptance 5 requires exactly that sequencing.

ADR 0031 Decision 3: '`Fund` and `Cause` gain a jurisdiction-linked, computed-allocation-input field at v1 — an actual schema field, not descriptive text — landing as part of `W1-E11`'s one-shot migration.' `02-ecosystem-architecture.md` §8, the Foundation Principle: 'The system records jurisdiction faithfully and makes jurisdiction-linked flows reportable... The system does not encode an allocation rule... The architecture supplies the evidence; the Foundation makes the decision.' THIS FIELD CARRIES NO ALLOCATION LOGIC ITSELF — ADR 0031 Consequences: 'No allocation-rule code exists yet... this is a decision, not an implementation.' A plain jurisdiction value, the same record-shape-not-computation separation this corpus draws everywhere (e.g. `reserve-obligation.schema.json`'s own top-level description: 'THIS IS A RECORD SHAPE, NOT A COMPUTATION'). Named `operating_jurisdiction`, deliberately NOT `source_jurisdiction` (`fund.schema.json`'s own field, ADR 0013 Decision 1) — `Cause` is destination-side while `Fund` is source-side (ADR 0028 Decision 4: Fund/Cause cardinality stays orthogonal), and this field creates no foreign key or cardinality relationship to `Fund`; each entity independently carries its own jurisdiction dimension. REQUIRED, not optional or nullable — matching this batch's established precedent of adding new required fields to existing vendored entities rather than leaving one that could silently go unpopulated (see `participant.schema.json`'s `verdify_identity_id`). ISO 3166-1 alpha-2 shape, the SAME pattern `fund.schema.json`'s `source_jurisdiction` uses. `G-jurisdictions` (which real markets are served) remains OPEN, so every real fixture uses an ISO 3166-1 user-assigned test code (e.g. `ZZ`), never a real market — matching `fund.schema.json`'s own fixtures' convention.

Identity. NO PATTERN, on container.schema.json's precedent: no document fixes an id space for this leaf, and inventing one would freeze a byte before its gate. ITS IDENTITY IS INDEPENDENT OF THE RECIPIENT: an entry is not named after the participation it allocates to, and no description here says otherwise — which is the convention 04 W1-E08 acceptance 3 strikes, applied at the level this epic owns. The vendored `Outcome` still states the derivation for its own id; that sentence is 04 W1-E11's to remove, and ADR 0025 §3 records why it could not be removed here. NON-EMPTY: an empty string is not an identity, and a leaf naming nothing would validate while referring to no object. `minLength: 1` is strictly weaker than any pattern, so it freezes no id space — it only refuses the one value that can never be one.

The outcome whose distribution this entry belongs to. MANY entries may name one outcome — that is the whole point, and it is what the singular `Outcome.recipient_participation_id` could not express. NO PATTERN, DELIBERATELY: 03 §1.4 diagnoses the defect a pattern would repeat — 'contribution.schema.json:25 patterns outcome_id as the wave-scoped composite, so the money leg that 01 §1.3 calls primitive-agnostic is wave-shaped in the frozen bytes. That leak happened BECAUSE THE CONTAINER HAD NO LEVEL, so its shape defaulted sideways into its neighbour.' 04 W1-E11 acceptance 3 has to undo that in `contribution`; committing it a second time here would double the migration. NON-EMPTY: an empty string is not an identity, and a leaf naming nothing would validate while referring to no object. `minLength: 1` is strictly weaker than any pattern, so it freezes no id space — it only refuses the one value that can never be one.

The participation this entry allocates to. NO PATTERN: participation.schema.json owns that id space and 04 W1-E11 owns the one-shot migration that may change it, so repeating the pattern here would put one piece of knowledge in two places and make the migration two edits. THE RECIPIENT IS A PARTICIPATION, NOT A PARTICIPANT — 01 §4.3 change 5 replaces participant identifiers in published entries with a per-instance pseudonym, and an allocation naming a participant directly would be a durable identifier in an anchored entry. NON-EMPTY: an empty string is not an identity, and a leaf naming nothing would validate while referring to no object. `minLength: 1` is strictly weaker than any pattern, so it freezes no id space — it only refuses the one value that can never be one.

The amount allocated, in the CONTAINER'S DECLARED UNIT — the same unit as that container's `target` (03 §1.3), resolved through this entry's outcome. No currency member, deliberately: the unit is declared once, by the container, and a per-entry currency would be a second place to say one thing AND would drag in contribution.schema.json's `^[A-Z]{3,4}$`, which is 01 §4.3 change 4 and blocked by G-Q5.

When this entry was recorded. Ordering against the container's resolution is not expressible in JSON Schema and is 04 W3-E09's, on the precedent container.schema.json set for `opens_at`.

Identity. NO PATTERN, on container.schema.json's precedent: no document fixes an id space for this class, and inventing one would freeze a byte before its gate. NON-EMPTY, because an empty string is not an identity.

The settled outcome this attestation reports on. NO PATTERN, DELIBERATELY: 03 §1.4 records that contribution.schema.json patterns `outcome_id` as the wave-scoped composite, so 'the money leg that 01 §1.3 calls primitive-agnostic is wave-shaped in the frozen bytes', and 04 W1-E11 acceptance 3 has to undo it there. Repeating it here would make that migration one file wider. NON-EMPTY, because an attestation of nothing is not an attestation.

WHO REPLAYED IT — AN OPEN SET. Resolved against nothing: no pattern, no enum, no registry, no format. 03 §5.5(b): 'anyone may publish, and for which Veraq certifies nobody and pays nobody.' This is the exact inverse of the envelope's `publisher`, which specs/record-envelope-v1.md §2 makes registry-resolved and fail-closed; see this schema's own description for why the two do not share a name. `minLength: 1` is the ONLY bound and is not a narrowing of the set: an unnamed attester is not a party, and an attestation nobody made cannot be checked by anyone. A verifier reading this member learns who to go and ask, and learns nothing about whether Veraq agrees.

What the attester found. `attested` — replayed and matched. `mismatch` — replayed and did not match. `pending` — has not finished. The three are 04 W1-E09 acceptance 1's, and NONE of them names Veraq or an endorsement, because the value set is as much a surface for an upward default as a member name is. A CLOSED enum rather than a registry: 03 §11's resolution discipline is for the SEVEN registry kinds, an eighth would fail tooling/ci/registry-artefact-check.mjs's seven-artefact rule, and 05 §11 forbids this epic adding a registry row. The cost of the closed set — 03 §1.3's 'a new enum member added after the first anchor invalidates every existing verifier's exhaustiveness check' — is real and recorded at ADR 0026 open item 1 rather than resolved here.

The transcript digest the attester actually computed — 03 §5.5's 'an attestation that a published algorithm on published inputs produced transcript digest D'. NULL while `pending`, present otherwise, and never absent: 03 §1.4 rules out an optional field in an anchored proof format, so a verifier reads a present null rather than guessing at an absence. It is the OBSERVED value only. The published value it is compared against is reached through `outcome_id` and is not copied here, because a figure with two homes in one record is a figure that can disagree with itself. The hex shape is stated ONCE, in `$defs/digest`, and reached here through a `oneOf` with null — the shape commitment.schema.json uses for `revealed_at`.

When the attester recorded this report. Ordering against the outcome's settlement is not expressible in JSON Schema and belongs to the verification pipeline, on the precedent container.schema.json set for `opens_at`.

Identity. NO PATTERN, on `container.schema.json`/`attestation.schema.json`'s shared precedent: no document fixes an id space for this class, and inventing one would freeze a byte ahead of its own gate.

The container this challenge is raised against — container-generic from the start (`03` §1.2's container level, ADR 0023), never a family-scoped id space. Deliberately NOT `wave_id`: `participation.schema.json`'s own inherited mismatch (a Wave-only id pattern at a container-generic entity) is a defect this schema, authored after the container level already existed, has no reason to repeat.

`raised` — filed, undecided. `upheld` — the challenge stands; `03` §5.1's own reward-model line names exactly this state ('surviving void, an empty match set and an upheld challenge'), and it is what `apps/io`'s `provisional -> final` gate checks for (04 W3-E13 criterion 3). `dismissed` — the challenge does not stand; final is unaffected. A CLOSED enum, on `attestation.schema.json`'s own precedent for the identical reason: `03` §11's registry discipline is for the seven registry KINDS, and adding an eighth here would fail `tooling/ci/registry-artefact-check.mjs`'s seven-artefact rule for no corpus-named benefit — this is a small, closed, non-extensible outcome set, not a membership `03` §11 ever asks to keep open. This epic does not build the adjudication workflow that moves a Challenge from `raised` to `upheld`/`dismissed` — out of scope, `04` W3-E13's own acceptance criteria test only that an ALREADY-`upheld` challenge blocks `final`, never how one comes to be upheld.

The challenger's stated grounds. Optional and nullable — no acceptance criterion of `04` W3-E13 requires a Challenge's own reason to be present (contrast `container.schema.json`'s forthcoming void-reason requirement, `03` §6.2, which is a DIFFERENT record — the container's own `void_reason` column, `tooling/io/migrations/0004_challenge_window.sql` — not this entity). Carried here anyway, matching every other leaf's own practice of recording why, because a Challenge with no stated ground is harder to adjudicate honestly, not because a numbered criterion requires it.

When the challenge was filed. Ordering against the container's own `provisional_at` (when its challenge window began counting, `tooling/io/migrations/0004_challenge_window.sql`) is not expressible in JSON Schema and belongs to the write path, on `container.schema.json`'s own precedent for `opens_at`.

Identity. NO PATTERN: 03 §1.2 preserves Wave's own id space ('Wave keeps its name, its id space and its app destination'), which is `^[0-9]{3,6}$`, while Pool's is unfixed — so a shared pattern would either break the one the corpus preserves or invent the other.

Provenance: the product this container belongs to. Opaque and NOT registry-resolved (record-envelope-v1.md §2, corrected 2026-08-05). The kill switch is specified at product_id granularity (03 §8.4), and 04 W3-E04 requires killing a product to prevent its containers reaching `open` — which is why the container must carry it.

The start. A container is immutable after `opens_at` (03 §2 level 5), and its Commitment must be timestamped STRICTLY EARLIER (03 §1.3; 04 W3-E09 tests the equal-timestamp boundary).

The freeze predicate, as a DISCRIMINATED OBJECT and never a shape enum. 03 §1.3: 'A new enum member added after the first anchor invalidates every existing verifier's exhaustiveness check. A new keyed branch is purely additive — if and only if verifiers are required to fail closed on an unknown kind.' Two members ship and no third is named; a third (continuous participation) is 03 §9 item 5 and 04 §12, deliberately unscheduled. Both branches are closed, so a document mixing their parameters matches neither.

The container's state. 03 §1.2 keeps a status in the shared container, so the member is REQUIRED — 03 §1.4 rules out an optional field in an anchored proof format. THE VALUE SET LANDS HERE, per ADR 0023 §5's own delegation ('The enum lands there, with the transitions, in one change'): the six main-sequence states 03 §5.1 names for the `official-result` family (announced, open, closed, observing, provisional, final), promoted to the CONTAINER level by 04 W3-E09 as shared vocabulary — `observing` is harmless for a non-`external` container, which simply never visits it — plus `void`/`cancelled`, the two exits that same section names. 04 W3-E09 owns the transition machine (`apps/io/src/lifecycle.ts`, `tooling/io/migrations/0002_containers.sql`) and its own dedicated table-driven test enumerates every ordered pair of the SIX main-sequence states; `void`/`cancelled` reachability is a separate, explicitly flagged, provisional design choice — see that epic's own report.

A digest-bound snapshot of the product manifest, and THE ONLY PLACE a regulated fact may live (03 §1.2). Open on purpose: its members are the product's — the partition rule, the assistance binding, share origin, funded_by, the cause class — and several are blocked on counsel or on an owner decision. What is fixed today is `value_bearing`, plus `challenge_window` (04 W3-E13). Note that a `terms` carrying a value outside canonical-form-v1.md §2's domain has no canonical form, so its `terms_digest` cannot be computed; that is enforced by Rule D4's computation refusing, not by this schema, which is schema-blind to the distinction.

canonical-form-v1.md Rule D4: SHA-256(utf8(canonicalForm(terms))) over the `terms` object ALONE — no wrapper, no key added, no reference to the product manifest included — rendered per Rule D3 as lowercase unprefixed hexadecimal. The partition rule and the assistance binding are bound BY INCLUSION, as members of `terms`, so neither needs a separate digest.

The per-container Commitment (03 §1.2) — where the mechanism state that left Wave now lives, `oneOf` on verification form. Built by 04 W1-E06; this is the reference, not the object.

The container this total is computed over. NO PATTERN, on container.schema.json's and funding.schema.json's precedent: no document fixes an id space for a container reference here. NON-EMPTY: an empty string is not an identity, and a total naming no container belongs to no container's report.

One of ADR 0015 §4's seven segregation domains, or a policy-extensible obligation class mapping onto one — the design doc's own wording (docs/ops/foundation-principle-reporting-dimension.md:89). NO ENUM, deliberately: the design doc's own description already states the set is policy-extensible, and `03` §11's registry-resolution discipline is reserved for the SEVEN registry kinds — an enum here would freeze a membership the design doc itself declares open. NON-EMPTY, on the same reasoning as `container_id`.

The container's total for this class, in the container's declared unit (paired with `currency` below, the way `03` §1.3 pairs a Funding `amount` with a Container's declared unit). Decimal string, per canonical-form-v1.md Rule N4 — never a float (docs/ops/foundation-principle-reporting-dimension.md:90).

ISO-4217 alphabetic code, or a supported crypto ticker — the identical spelling contribution.schema.json's `amount.currency` uses (`^[A-Z]{3,4}$`), reused rather than reinvented so one pattern governs one meaning across the corpus. The supported crypto set is defined at the application layer (`@veraq/i18n` `CRYPTO`); other pattern-valid codes are not rejected here.

Identity. NO PATTERN: ADR 0028's Consequences say a Fund is 'keyed by its own id (e.g. a ULID)' — an illustrative example, not a mandate, exactly as funding.schema.json's own `id` reasons: 'no document fixes an id space for this leaf, and inventing one would freeze a byte before its gate.' NON-EMPTY: an empty string is not an identity, and a Fund naming nothing would validate while referring to no object.

ISO 3166-1 alpha-2 — the one shape the corpus already fixes for a jurisdiction value: `04`:236 tests `01` §8 Q1 against '≥1 market by ISO 3166-1 alpha-2'. ADR 0013 Decision 1: 'Fund becomes a first-class Core entity carrying source_jurisdiction. Every inflow inherits its classification from the Fund it lands in.' `G-jurisdictions` — 'the named target market set' — is OPEN today; no repository names one. This field fixes SHAPE only, never a real value: every fixture in this corpus uses an ISO 3166-1 user-assigned code (e.g. `ZZ`), reserved by the standard for exactly this — a value that validates without naming a target market this schema-authoring epic is not authorised to name. DUAL ROLE, per ADR 0031 Decision 3 (answering `G-FD6`, 2026-08-11): this field satisfies ADR 0031's requirement that `Fund` 'gain a jurisdiction-linked, computed-allocation-input field at v1' — it is not only a reported dimension (`04` W4-E10's own scope) but also the computed *input* Decision 1 activates for how a `ReserveObligation`'s disposition is allocated. No SECOND field is added for this: `source_jurisdiction` already carries the one fact both roles need, and duplicating it would put one piece of knowledge in two places (the same reasoning `source_fund_id`'s own description gives for not restating `Fund`'s fields elsewhere). ADR 0031's own Consequences are explicit that this is 'a decision, not an implementation' — no allocation-rule code exists yet, and none is authorised by this field's presence.

Which of ADR 0028 Decision 7's two creation tracks this Fund was created on. `default`: 'A jurisdiction's first Fund is created by the operator, once, at jurisdiction onboarding.' `additional`: 'Any additional Fund in an already-served jurisdiction requires an owner-recorded governance reason before it may be created... following an admission discipline analogous to 03 §11's before-code gate.' A Fund is never created by a container, a product, or a participant action (Decision 7's own closing sentence). CLOSED to these two, because Decision 7 names exactly two tracks and no document names a third.

The recorded governance reason for an `additional` Fund, by digest reference — a SHA-256 digest in canonical-form-v1.md Rule D3's rendering (the spelling commitment.schema.json and attestation.schema.json both use for the same kind of value), or NULL for a `default` Fund, because Decision 7 gives the jurisdiction's first Fund no reason to record (it coincides with jurisdiction onboarding, an operational event ADR 0013 already assumes) — PRESENT for an `additional` Fund, whose creation 'requires an owner-recorded governance reason BEFORE it may be created.' Present-but-null rather than absent, on record-envelope-v1.md's and attestation.schema.json's shared convention: 03 §1.4 rules out an optional field in an anchored proof format, so a verifier reads a present null instead of guessing at an absence. The pairing is enforced structurally by this schema's top-level `if`/`then`/`else`, on attestation.schema.json's own precedent for its `pending`/`observed_digest` pairing — never left to review. `pattern` applies only where `type` resolves to `string`, per JSON Schema's own per-keyword type scoping, so it constrains the digest form without rejecting `null`.

Identity. NO PATTERN, on container.schema.json's precedent: no document fixes an id space for this leaf, and inventing one would freeze a byte before its gate. NON-EMPTY: an empty string is not an identity, and a leaf naming nothing would validate while referring to no object. `minLength: 1` is strictly weaker than any pattern, so it freezes no id space — it only refuses the one value that can never be one.

The container this inflow is recorded against, and therefore the container whose `raised` it projects into. REQUIRED: 03 §1.3 makes the projection per-container, and an entry that names no container belongs to no projection and can be counted into any of them. NO PATTERN — container.schema.json carries none, because 03 §1.2 preserves Wave's id space while a Pool's is unfixed. NON-EMPTY: an empty string is not an identity, and a leaf naming nothing would validate while referring to no object. `minLength: 1` is strictly weaker than any pattern, so it freezes no id space — it only refuses the one value that can never be one.

The amount, in the CONTAINER'S DECLARED UNIT — the same unit as that container's `closes_on.target` (03 §1.3: 'a quantity in the container's declared unit'). No currency member, deliberately: the unit is declared once, by the container, and a per-entry currency would be a second place to say one thing AND would drag in contribution.schema.json's `^[A-Z]{3,4}$`, which is 01 §4.3 change 4 and blocked by G-Q5.

When the inflow was recorded. The threshold predicate reads the entries whose `funded_at` falls inside the container's window; that ordering is not expressible in JSON Schema and is 04 W3-E09's, on the precedent container.schema.json set for `opens_at`.

The container whose per-jurisdiction breakdown this digest commits to. NO PATTERN, NON-EMPTY, on `container-class-total.schema.json`'s precedent — the same container a `ContainerClassTotal` for the same `class_id` totals without a jurisdiction breakdown.

The obligation class this per-jurisdiction breakdown belongs to — the same open, policy-extensible set `container-class-total.schema.json`'s `class_id` names (ADR 0015 §4's seven segregation domains, or a policy-extensible mapping onto one). NO ENUM, on the same reasoning: the membership is not this schema's to freeze.

SHA-256 hex digest over the per-jurisdiction breakdown, per canonical-form-v1.md Rule D2's computation and Rule D3's rendering (docs/ops/foundation-principle-reporting-dimension.md:102). The breakdown itself stays control-ledger — THIS FIELD IS THE ONLY MEMBER of this schema that carries jurisdiction-linked information, and it carries it as an opaque committed digest, never as a raw jurisdiction value, a balance keyed by jurisdiction, or any structure a reader could invert into one. `additionalProperties: false` plus this `required` list is what makes 'anchored as digests only' (ADR 0015 §6) a fact this schema cannot violate, rather than a sentence a future author could work around by adding a member.

The participation this partition-rule digest is published for. NO PATTERN — participation.schema.json's own `id` carries none either. NON-EMPTY: an empty string is not an identity, and a report naming no participation belongs to no participation's report. NOT a `participant_id`: `03` §7.3 rule 3 makes jurisdiction-linked reporting a property of the PARTICIPATION, never of the PARTICIPANT — see this schema's own top-level description.

The digest of the published, versioned partition rule applied to this participation (ADR 0015 §6: 'a required member of the Product manifest… digest-bound into `Container.terms_digest`'), openable by the holder. THIS IS THE ONLY MEMBER of this schema — the applied `(product, jurisdiction)` pair is never published beside it, because doing so would publish the participant's jurisdiction (`03` §7.3 rule 3, quoted verbatim in this schema's top-level description). `additionalProperties: false` plus a two-member `required` list is what makes that non-publication a fact this schema cannot violate, rather than a sentence a future author could work around by adding a member.

Identity — the value a product manifest's binding 6 names as `policy_binding_ref` (`packages/product-registry/src/manifest.ts`'s `PolicyBindingInput.policy_binding_ref`, `04` W4-E06 criterion 1). NO PATTERN, on `fund.schema.json`'s own `id` reasoning: no document fixes an id space for this record, and inventing one would freeze a byte before its gate. NON-EMPTY: an empty string is not an identity.

ISO 3166-1 alpha-2 — the SAME shape `fund.schema.json`'s `source_jurisdiction` already fixes for a jurisdiction value, reused rather than reinvented. Unlike that field's own fixtures (which deliberately use the reserved `ZZ` code because `G-jurisdictions` named no real market when that schema was authored), THIS schema's own fixtures use `GB` for real: `04` W4-E06's own 2026-08-18 unblocking note states `G-jurisdictions` is now 'partially answered, UK named, which is sufficient to build and test the per-market age-floor machinery' — this field's real first value. Renamed from `03` §3's own table header 'jurisdiction' to `market` to match this epic's own accept-criteria language ('the age floor is per-market') — the identical fact under the vocabulary this epic actually uses, not a second one.

`03` §3 binding 6's `eligibility` member. Open shape, presence-only — `packages/product-registry/src/manifest.ts`'s own `PolicyBindingInput` gives every binding-6 member this same presence-only treatment ('no epic in this catalogue owns their shape yet'); this epic's own four accept criteria do not name an eligibility shape either, so none is invented here.

`03` §3 binding 6's `age` member, as a plain non-negative integer — the number of years. `04` W4-E06 criterion 3: read from `apps/org`'s own per-market adapter (`governance/market-age-floor.ts`) at PROPOSE time, never asserted independently of it and never hardcoded anywhere this schema's own validation runs. This schema fixes only the STORED SHAPE of the number the adapter already resolved — it cannot itself call the adapter (a JSON Schema has no access to a market table), so 'never hardcoded into domain logic' is enforced one layer up, in code, not here.

`03` §3 binding 6's `limits` member. Open shape, presence-only — same reasoning as `eligibility` above.

This record's own lifecycle position. `proposed`: recorded, awaiting a second, distinct principal's approval. `in_force`: approved by a principal DISTINCT from the proposer (`04` W4-E06 criterion 2) — the ONLY status a product manifest's `policy_binding_ref` may resolve to and still be admitted (`04` W4-E06 criterion 1: 'a manifest whose binding 6 references no in-force PolicyBinding is rejected at admission'). `withdrawn`: no longer governs anything; retained, never deleted, on `apps/org`'s own oversight-trail 'superseded, never amended in place' convention (`04` W4-E08 acceptance 4).

The identity that proposed this PolicyBinding — opaque, on `apps/console/src/lib/operator/identity-port.ts`'s own 'opaque Verdify-issued reference' convention. `04` W4-E06 criterion 2's whole subject: `approved_by` below must never equal this value once `status` is `in_force`.

The identity that approved this PolicyBinding, or `null` while `status` is `proposed` (no approval has happened yet). `04` W4-E06 criterion 2, direct template of `apps/console/src/lib/operator/actions.ts`'s `approveAction`: an approval whose identity equals `proposed_by` is refused by the WORKFLOW that would otherwise write this field (`E_SELF_APPROVAL_FORBIDDEN`, ADR 0015 §11.6) — never by this schema, which sees only the already-accepted result of that check, on `container.schema.json`'s own 'schema-blind to the distinction' precedent. Present-but-null rather than absent while unresolved, on `attestation.schema.json`'s and `fund.schema.json`'s own shared convention (`03` §1.4: no optional field in an anchored shape).

The instant this PolicyBinding became `in_force`, or `null` before that has happened. `apps/org/src/governance/policy-binding-registry.ts` sets this at the moment `approvePolicyBinding` succeeds — the same 'effective-dated, not merely stored inertly' discipline `apps/console/src/lib/operator/controls/declared-deficiency-register.ts`'s own `effectiveFrom` and `apps/org/src/oversight/supersession.ts`'s own `effectiveFrom` already establish for an unrelated record.

The instant this PolicyBinding was withdrawn, or `null` while it has not been. Present-but-null, same reasoning as `approved_by` and `effective_from` above.

Identity. NO PATTERN, on container.schema.json's and funding.schema.json's shared precedent: no document fixes an id space for this record, and inventing one would freeze a byte before its gate. NON-EMPTY: an empty string is not an identity.

ADR 0013 Decision 3: 'The jurisdiction on a reserved amount is snapshotted, not referenced. Re-domiciling a Fund never rewrites the classification of amounts already calculated.' This is a COPY taken at recognition, never a live pointer through `source_fund_id` — which is exactly why it is a distinct field here rather than something a reader derives by following the Fund reference. ISO 3166-1 alpha-2, the SAME shape `fund.schema.json`'s own `source_jurisdiction` carries (proven structurally in this schema's test suite), because a snapshot of a fact and the fact itself must be the same fact, byte for byte. `G-jurisdictions` is open; every fixture uses an ISO 3166-1 user-assigned code, never a real market.

The Fund this amount was recognised into (ADR 0013 Decision 1). A REFERENCE ONLY: fund.schema.json owns `creation_tier` and `governance_reason_digest`, and this record does not restate them — on allocation.schema.json's own precedent for `recipient_participation_id` ('participation.schema.json owns that id space'). NO PATTERN: fund.schema.json's own `id` fixes none, so repeating one here would put one piece of knowledge in two places. NON-EMPTY, because a reserved amount naming no Fund is unclassifiable by jurisdiction at all.

The SAME spelling contribution.schema.json already established for a currency field (ISO-4217 alphabetic code, or a supported crypto ticker) — reused rather than reinvented, proven structurally in this schema's test suite. ADR 0015 §11.1 amended point 5: 'No implicit FX. Held and remitted in the currency it arose in. Conversion is a policy decision with counsel input, never an operational convenience' — so this is the ONE currency field on the record, never a pair, and there is no conversion-rate member anywhere in this schema.

The versioned calculation rule this amount was recognised under (ADR 0013 Decision 4: 'The reserve is calculated from the first day, under a versioned calculation rule'). ADR 0015 §11.1 amended point 1 makes `calc_rule_version` a REQUIRED POSTING-LEVEL DIMENSION — 'which is what makes per-obligation balances derived rather than stored.' NO PATTERN: the versioning SCHEME belongs to whichever registry eventually publishes calculation rules, not to this record shape, and inventing one here would freeze a byte that registry has not yet fixed.

The versioned partition rule under which this amount's obligation class was assigned at receipt (ADR 0015 §1 and §6: 'a published, versioned partition rule keyed on (product, jurisdiction)'). A COMPANION to `calc_rule_version`, not a substitute for it — ADR 0013's own amended Consequences: 'calc_rule_version gains a companion partition_rule_version.' Distinct from `partition_rule_digest` (`03` §7.3 rule 3; ADR 0015 §6): the digest is what is PUBLISHED per participation, openable by the holder; the version is the ledger-side posting dimension this record carries. NO PATTERN, for the same reason `calc_rule_version` carries none: `04` W5-E05 (the partition-rule registry) owns that versioning scheme, and this epic does not pre-empt it.

The reserved amount itself, before income or fees. A SEPARATE ACCOUNT from `income` and `fees` from day one (ADR 0013 Consequences), never their sum folded into one figure. STRICTLY POSITIVE, unlike `income`/`fees`: no document states principal is ever expected to be zero — a `ReserveObligation` records that a jurisdiction's obligation class received something, so a principal of zero is not this record's normal case the way a zero income or fee is.

Income attributable to this obligation, tracked separately even though 'expected to be zero' (ADR 0013 Consequences: 'A retroactive determination that income belongs to the obligee is unanswerable if income was never tracked separately'). ADR 0015 §11.1 amended point 4: 'Income is separately classified and unavailable, attributed by a versioned rule, rounded against Veraq, under the SAME RESTRICTIONS AS PRINCIPAL' — which is why this shares `principal`'s exact `nonNegativeQuantity` $defs rather than a looser spelling of its own.

Fees attributable to this obligation (e.g. a rule-declared, capped `cost-of-acceptance` class — ADR 0015 §8), tracked as a separate account from day one, 'even though income and fees are expected to be zero' (ADR 0013 Consequences).

ADR 0013 Decision 5: 'The legal classification is an explicit field defaulting to PROVISIONAL, effective-dated and evidence-referenced. It is never inferred from any other state in the system.' ONE FIELD bundling the three facts Decision 5 names together, on container.schema.json's own precedent for `closes_on` (one field, several required members) — never three top-level members whose pairing could drift apart. CLOSED TO `PROVISIONAL` TODAY: ADR 0015's Deferred table restates ADR 0013 unchanged — 'PROVISIONAL until counsel classifies' — and no document names a second value; that value is blocked on counsel (`G-memo`), and inventing one here would answer a counsel-gated question by implication.

ADR 0013 Decision 5: 'lifecycle status is a separate axis from legal status.' ITS VALUE SET IS DELIBERATELY UNCONSTRAINED HERE — the same recorded gap container.schema.json's own `status` field states rather than hides: 'no document fixes a member set' for this record's lifecycle today. Recognition is atomic at receipt (ADR 0015 §2); what happens after — accrual, partial or full disposition, closure — is a transition machine `04` W5-E04's crossing authorities and `04` W5-E07's reconciliation harness are positioned to own, on `04` W3-E09's precedent for `Container.status`. REQUIRED, never optional: `03` §1.4 rules out an optional field in a record shape, so a ReserveObligation with no lifecycle state at all is not a valid record even before that transition machine lands.

The append-only history of amounts discharged from this obligation via ADR 0015 §5's crossing authorities (`Disposition`, `Release`, `Return`, `ContinuityRelease`) — the field `01` §4.3 change 6 names directly. EMPTY BY DEFAULT AT RECOGNITION: ADR 0015's own 'What's needed to execute' blocks 'any Release or ContinuityRelease execution' and 'all rule evaluation' on counsel, so a freshly recognised obligation has discharged nothing yet, and this schema must not require a first entry that cannot yet exist. Each entry references the discharging event BY ID rather than embedding the crossing authority's own mechanics — `04` W5-E04's `packages/obligation-*` owns those authorities' shape, not this schema.

Identity. NO PATTERN, on `container.schema.json`'s precedent, applied here as `allocation.schema.json` already applies it to a level-6-shaped leaf: no document fixes an id space for this class, and inventing one would freeze a byte before its gate.

The outcome this observation was recorded for — `official-result-reference-v1.md` "Outcome integrity": "the `observed_value` recorded in `Outcome.verification`'s `ResultObservation`". NO PATTERN, DELIBERATELY, on `allocation.schema.json`'s own precedent and its own citation of `03` §1.4: a pattern here would repeat the leak that made `contribution.schema.json` wave-shaped in its frozen bytes.

`official-result-reference-v1.md` "Inputs" §4, verbatim: "an integer at `parameters.value_scale`, or `null` if no capture landed inside `parameters.observation_window_seconds`" — the `substitute_none` fallback's legitimate value, never an absent member (`03` §1.4: a verifier reads a present null rather than guessing at an absence). The declared scale itself is `Mechanism.parameters`', not this schema's — `canonical-form-v1.md` §2.1 places scale enforcement at the schema that declares a decimal-with-scale field, and this one carries no per-container scale to enforce against.

`02` §7's own unpacking of `03` §5.1's "provenance": "where fetched, when, by whom". Required as a whole, whether or not the capture ultimately succeeded — even a `substitute_none` resolution names the observation process and the moment its window closed, not only a successful fetch.

`03` §5.1's "source-publication digest" / `02` §7's "an evidence digest of the source publication" — computed under `Mechanism.parameters.evidence_digest_algorithm` (fixed to `sha256` at v1). ATOMIC WITH `observed_value` (the root `if`/`then`/`else` above, on `attestation.schema.json`'s `RevealIsAtomic`-shaped precedent): null exactly when `observed_value` is null — there is no evidence to digest for a capture that never landed — and a real digest exactly when a value was observed.

The total number of capture attempts this document claims were made. `04` `W1-E07` acceptance 1: must equal `failed_capture_attempts.length` plus one more if `observed_value` is not `null` — enforced by `veraqAttemptCountConsistent`, not merely declared here.

EVERY FAILED CAPTURE ATTEMPT — `03` §5.1's own phrase, verbatim, and the member that makes mis-observation (THREAT_MODEL.md adversary 2) inspectable rather than asserted: a `ResultObservation` claiming a success is not permitted to omit the failures `attempt_count` says preceded it (`veraqAttemptCountConsistent`). MAY be empty — a capture that succeeded on its first attempt records zero failures, and `attempt_count` reflects that.

`03` §5.1, verbatim: `Outcome.verification.observer_independence ∈ {single_party, multi_party}` — "recorded and rendered, never asserted beyond what it states." `04` `W1-E07` acceptance 2: required, exactly these two members, no default — omission rejects precisely because `required` above names it and this is a `type: string` `enum`, never a member with a fallback value.

`03` §5.1 "Relationship to `.net`", verbatim: "the observation batch digest" — the digest of the WHOLE capture batch (every attempt, failures included), anchored on the open record before `value_published_at`. Never null: a batch digest exists once observation begins, independent of whether any attempt inside it succeeds.

WHEN `batch_digest` was anchored to the open record. `04` `W1-E07` acceptance 3: must be STRICTLY EARLIER than `value_published_at` — the observe-dislike-reobserve defence, enforced by `veraqStrictlyBefore` below, not left to the write path alone. This is an INTRA-document comparison (both timestamps live on this one entity), unlike `commitment.schema.json`'s `published_at` vs. a DIFFERENT document's `Container.opens_at`, which is genuinely cross-entity and stays `04` `W3-E09`'s.

WHEN the extracted value — `observed_value`, including the `substitute_none` sentinel — was published to the open record. Always present, even under `substitute_none`: `official-result-reference-v1.md` "Fallback handling" states `ALG` **is** invoked and returns a legitimate verdict in that case, so a value (the `none` verdict) is still published.

WHICH independent authority is observed — `official-result-reference-v1.md`'s worked example: "National Meteorological Office". Self-declared and unverifiable by the protocol alone, the same posture `revision_policy` has (the spec's own "Known limitation").

WHERE the authority publishes the figure. Part of the four-member pin (`source_authority`, `publication_url`, `field`, `format`) `03` §5.1 names verbatim as committed before opening, and THREAT_MODEL.md adversary 4's mitigation: "the field is ambiguous" is exactly what an honestly-pinned source without this member would leave open.

The EXACT field, inside the publication, the observers watch — `official-result-reference-v1.md`'s worked example: "mean_temperature_c". A publication with several figures on one page is not enough; this pins which one.

The shape the pinned field is published in — `official-result-reference-v1.md`'s worked example: "json:number". Free text at v1: the spec fixes no closed vocabulary for this member, so this schema fixes none either rather than inventing a stricter contract the spec itself does not commit to.

WHICH revision counts, committed in advance, for an authority that later revises a preliminary figure — `official-result-reference-v1.md` "Inputs" §1, verbatim: `first_published` binds the earliest published figure regardless of later revision; `final_only` binds observers to wait for the authority's own "final" marking (the observation stays absent if none arrives inside the window); `latest_as_of_window_close` binds whatever revision was current when `observation_window_seconds` elapses. EXACTLY these three members, spelled exactly as the spec spells them — a fourth or a renamed member would silently stop being a superset of what `veraq-protocol` already fixed.

Five booleans, one per disjunct of `03` §5.1's source-exclusion clause, required because the exclusion is drawn "by object referenced rather than by publisher" (`03` §5.1) — the predicate needs something to check that is not a heuristic over `publication_url` or `field` text. `official-result-reference-v1.md` "Source exclusion": a `ResultSource` with any flag `true` MUST NOT be committed — checked once, at commitment time, by `veraq-protocol`'s `is_excluded`, not by this schema.