VRX-1 · Schema reference

Every field in a receipt, documented — so anyone can verify one without contacting us.

All PLENA VRX-1 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.

Verification is independent. A receipt is checked by recomputing a SHA-256 hash over its canonical JSON — in your own browser, with your own tools, against the field definitions on this page. It does not require PlenaProof, an account, a network connection, or any third party. If PlenaProof ceased to exist tomorrow, every receipt already issued would remain verifiable.

A receipt is self-attested: it proves the record has not changed since it was made, not that its contents are true.

Six receipt types

The receipt types in the VRX-1 catalogue.

Type 1 · Submission Receipt

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

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

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 proof 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

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); a core part of PLENA's accountability vocabulary. 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

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); 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

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 receipt type via the corrected_receipt_id / corrected_receipt_type fields; supports the 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 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 receipt asserts: a self-attestation by its creator, with content tamper-evident via SHA-256 over the canonical JSON. What no 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