VRX-1 · Schema reference · d19.82

Six gating receipt types. One reference page.

All PLENA VRX-1 gating receipts share the same canonical JSON shape, SHA-256-over-canonical integrity model, and self-attested truth boundary. This page lists every type with its schema_version constant, receipt_id pattern, required fields, published schema file, and worked sample receipt. Each type also has a working reference implementation that builds, verifies, and saves receipts entirely client-side.

Six gating types

Locked in the d19.75 strategic architecture lock, Part 3. Built across d19.69 (Type 1), d19.81 (Types 3 and 4), and d19.82 (Types 2, 5, 6). All six were required to close Part 7 item 5 of the lock.

Type 1 · Submission Receipt

d19.69
discriminator: SUBMISSION_RECEIPT
vrx1.submission-receipt.v1
PLENA-SUB-YYYYMMDD-XXXX

Records that a submitter handed something to a recipient: an application, claim, form, document set, packet, or filing. The entry-point receipt of the VRX-1 family.

Anchors: Institutional Trust & Proof Suite; the intake side of any institutional workflow; pairs naturally with Missing-Item, Human Review, and Refusal Receipts on the review side.

Required fields (13)
  • vrx1_version
  • schema_version
  • receipt_id
  • receipt_type
  • created_at
  • submitter
  • recipient_institution
  • service
  • submission_date
  • privacy_level
  • verification_url
  • integrity_note
  • hash

Optional fields are documented in the schema file and the reference implementation’s schema preview.

Schema file: not yet published as a standalone schema file
Worked sample: no worked sample published yet
Receipt_id pattern: ^PLENA-SUB-[0-9]{8}-[A-F0-9]{4}$

Type 1 was published before the schema-per-file pattern (d19.69). The reference implementation carries the canonical field shape inline; a future round may publish vrx1-submission-receipt.schema.json without changing the field shape.

Type 2 · Missing-Item Receipt

d19.82
discriminator: MISSING_ITEM_RECEIPT
vrx1.missing-item-receipt.v1
PLENA-MIR-YYYYMMDD-XXXX

Returned to a submitter when an application, form, claim, or document set is incomplete. Lists the missing items, why they are required, by when, with what consequence if not provided, and what correction or escalation path applies.

Anchors: National ID / Passport / Public Service Suite (citizen journeys); Institutional Trust & Proof Suite (intake/review boundary); pairs with Submission Receipt at intake and with Correction-Trail Receipt when the list is later amended.

Required fields (15)
  • vrx1_version
  • schema_version
  • receipt_id
  • receipt_type
  • created_at
  • recipient_institution_or_role
  • submitter_or_subject
  • submission_context
  • missing_items
  • consequence_of_non_provision
  • correction_path
  • privacy_level
  • verification_url
  • integrity_note
  • hash

Optional fields are documented in the schema file and the reference implementation’s schema preview.

Schema file: vrx1-missing-item-receipt.schema.json
Worked sample: receipts/PLENA-MIR-20260101-0001.json
Receipt_id pattern: ^PLENA-MIR-[0-9]{8}-[A-F0-9]{4}$

Type 3 · Human Review Receipt

d19.81
discriminator: HUMAN_REVIEW_RECEIPT
vrx1.human-review-receipt.v1
PLENA-HRR-YYYYMMDD-XXXX

Records that a named human reviewer considered specific evidence and reached a decision — accept, refuse, escalate, correct, or defer — with the reason recorded, AI-assistance disclosed, and an appeal or correction path stated.

Anchors: AI Accountability & Human Review Suite (anchored by AEQUITA); the AGI-era moat receipt; pairs with Refusal Receipt when the decision is a refuse, and with Submission Receipt when the review traces back to an earlier intake.

Required fields (19)
  • vrx1_version
  • schema_version
  • receipt_id
  • receipt_type
  • created_at
  • reviewer_name_or_role
  • review_scope
  • subject_of_review
  • review_datetime
  • evidence_reviewed
  • decision
  • decision_reason
  • reviewer_role_relative_to_decider
  • appeal_or_correction_path
  • ai_assistance
  • privacy_level
  • verification_url
  • integrity_note
  • hash

Optional fields are documented in the schema file and the reference implementation’s schema preview.

Schema file: vrx1-human-review-receipt.schema.json
Worked sample: receipts/PLENA-HRR-20260101-0001.json
Receipt_id pattern: ^PLENA-HRR-[0-9]{8}-[A-F0-9]{4}$

Type 4 · Refusal Receipt

d19.81
discriminator: REFUSAL_RECEIPT
vrx1.refusal-receipt.v1
PLENA-RFR-YYYYMMDD-XXXX

Records that a person or institution declined to certify, sign, submit, accept, pay, consent, share, or proceed, with reason codes, the missing or required items, and the correction or appeal path. Carries the two locked outputs of the Rights, Risk & Protection suite: Institutional Refusal Receipt and Personal Refusal Receipt.

Anchors: Rights, Risk & Protection Suite (anchored by PROVA, AEQUITA, LEGIBLA); the strategic moat per d19.75 Part 2.13. The PLENA-RFR-* namespace is intentionally distinct from the legacy PLENA-RR-* namespace used by founder-activation candidate instances.

Required fields (16)
  • vrx1_version
  • schema_version
  • receipt_id
  • receipt_type
  • created_at
  • refusal_mode
  • refuser_name_or_role
  • subject_of_refusal
  • refusal_date
  • refusal_reason_codes
  • refusal_reason_summary
  • correction_path
  • privacy_level
  • verification_url
  • integrity_note
  • hash

Optional fields are documented in the schema file and the reference implementation’s schema preview.

Schema file: vrx1-refusal-receipt.schema.json
Worked sample: receipts/PLENA-RFR-20260101-0001.json
Receipt_id pattern: ^PLENA-RFR-[0-9]{8}-[A-F0-9]{4}$

Type 5 · Deadline Receipt

d19.82
discriminator: DEADLINE_RECEIPT
vrx1.deadline-receipt.v1
PLENA-DRR-YYYYMMDD-XXXX

Documents a date-bound obligation: what must be done by when, by whom, with what consequence if missed and what correction or extension path applies. Covers legal, administrative, immigration, appeal-window, expiry, renewal, submission, payment, medical, and other deadline kinds.

Anchors: TEMPORA (the deadline platform — Part 1.6 #13 of the lock); diagnostic module across Rights/Risk/Protection, Institutional Continuity, and National ID / Public Service suites.

Required fields (17)
  • vrx1_version
  • schema_version
  • receipt_id
  • receipt_type
  • created_at
  • subject
  • deadline_kind
  • deadline_datetime
  • responsible_party
  • required_action
  • consequence_of_miss
  • correction_or_extension_path
  • reminder_dates
  • privacy_level
  • verification_url
  • integrity_note
  • hash

Optional fields are documented in the schema file and the reference implementation’s schema preview.

Schema file: vrx1-deadline-receipt.schema.json
Worked sample: receipts/PLENA-DRR-20260101-0001.json
Receipt_id pattern: ^PLENA-DRR-[0-9]{8}-[A-F0-9]{4}$

Type 6 · Correction-Trail Receipt

d19.82
discriminator: CORRECTION_TRAIL_RECEIPT
vrx1.correction-trail-receipt.v1
PLENA-CTR-YYYYMMDD-XXXX

Records that a prior receipt has been amended, withdrawn, sharpened, or superseded. Originals are not rewritten; corrections travel alongside them. Single-link supersedes pointer plus an integer correction_index gives the chain position.

Anchors: Institutional Continuity Suite (records that survive); pairs with every other gating receipt type via the corrected_receipt_id / corrected_receipt_type fields; supports the d19.81 d19.75 doctrine that the receipt is the audit trail.

Required fields (17)
  • vrx1_version
  • schema_version
  • receipt_id
  • receipt_type
  • created_at
  • corrected_receipt_id
  • corrected_receipt_type
  • corrector_name_or_role
  • correction_index
  • correction_kind
  • correction_summary
  • correction_reason
  • corrected_at
  • privacy_level
  • verification_url
  • integrity_note
  • hash

Optional fields are documented in the schema file and the reference implementation’s schema preview.

Schema file: vrx1-correction-trail-receipt.schema.json
Worked sample: receipts/PLENA-CTR-20260101-0001.json
Receipt_id pattern: ^PLENA-CTR-[0-9]{8}-[A-F0-9]{4}$

Shared field grammar

Nine fields are present on every gating receipt and carry the same meaning across types. Per-type fields are documented on each type’s reference implementation page and in its published schema file.

FieldRole
vrx1_versionReference-implementation version string; bound to the round that built it.
schema_versionStable per-type schema identifier (e.g. vrx1.deadline-receipt.v1).
receipt_idPer-type-prefixed unique identifier (PLENA-SUB / MIR / HRR / RFR / DRR / CTR).
receipt_typeType discriminator (SUBMISSION_RECEIPT / MISSING_ITEM_RECEIPT / ...).
created_atISO-8601 timestamp from the device that built the receipt.
privacy_levelrestricted | private | public.
verification_urlDirect URL ending with #verify on the reference implementation.
integrity_notePlain-language statement of the receipt’s truth boundary (verbatim across all six types).
hashSHA-256 hex digest, prefixed sha256:, over canonical JSON with the hash field removed.

Integrity model

What the SHA-256 hash proves

  • The receipt content has not been altered since the hash was computed.
  • Anyone holding the JSON can recompute the hash and confirm a match using the canonical-JSON algorithm documented inline in every reference implementation.
  • A creation timestamp recorded by the device that built the receipt.

What the SHA-256 hash does not prove

  • That the facts inside the receipt are true. Every receipt is self-attested by its creator.
  • That the receipt is signed by an institutional issuer key. The current reference implementation uses no signing key.
  • That the timestamp is anchored to an external clock or registry. The timestamp is taken from the device that built the receipt.
  • That any institution, regulator, court, employer, university, board, or platform must accept the receipt as evidence. Acceptance is decided by the receiving party.

Canonical-JSON algorithm

All six types use the same canonical-JSON algorithm to produce the input bytes that SHA-256 is computed over:

  • The hash field is removed before canonicalisation.
  • Object keys are recursively sorted.
  • No whitespace; strings JSON-encoded; numbers use JSON number form.
  • null is rendered as the literal token null; non-finite numbers (NaN, Infinity) are rendered as null.
  • The SHA-256 hex digest, prefixed sha256:, is written back as the hash field.

The algorithm is implemented inline in every reference implementation’s canonicalize() function and in the round’s build script. The two implementations are byte-equivalent: any worked sample published in receipts/ verifies in any of the six reference implementations’ Verify tabs.

Truth boundary (locked)

PlenaProof does not certify AI systems or guarantee regulatory compliance. No VRX-1 receipt is a certificate, a court filing, a regulator-issued audit, or an official acknowledgement by any external authority. PlenaProof helps institutions and individuals document submissions, missing items, human review, refusals, deadlines, and the correction trail across them.

What every gating receipt asserts: a self-attestation by its creator, with content tamper-evident via SHA-256 over the canonical JSON. What no gating receipt asserts: a signed institutional issuance, an externally anchored timestamp, third-party certification, regulatory approval, court admissibility, or unconditional acceptance by any recipient.

Future production releases may add issuer signing keys, external timestamp anchoring, a public revocation registry, and certified-reviewer status. These remain roadmap items and would each require a distinct decision round before adoption.

Where to go next