Appendix B
Engineering Considerations
Aa
Receipt infrastructure imposes real costs. It creates data, verification work, delivery obligations, privacy risk, operational dependencies, and a new attack surface. The engineering question is not whether those costs disappear. It is whether the system can allocate them explicitly while preserving evidence that would otherwise have to be reconstructed after harm.
No general ratio between receipt cost and dispute cost is defensible across domains. A high-volume ranking system, a benefits decision, a cross-chain transfer, and a professional-license suspension have different event rates, retention rules, evidence burdens, and remedies. Cost claims should be measured in the intended deployment rather than borrowed from storage trends or transaction-fee anecdotes.
Separate the Cost Layers
A useful cost model distinguishes at least six layers.
Event capture records the operative act, rule version, authority, inputs, and time. Capture may be cheap when the system already maintains reliable event logs. It may be difficult when decisions are assembled across contractors, manual processes, and models that do not expose stable intermediate states.
Commitment makes later alteration detectable. A signed record, append-only log, hash commitment, timestamping service, or distributed ledger can serve this function. Commitment establishes integrity and provenance under its assumptions. It does not establish that the underlying observation was true or the rule legitimate.
Storage retains the receipt, supporting evidence, schema, key history, and correction lineage for the required period. Storage policy must distinguish durable evidence of institutional power from personal material subject to minimization, sealing, access limits, and loss of authority over time.
Verification lets another party test signatures, provenance, calculations, policy versions, or other declared propositions. Verification cost includes software, documentation, key distribution, protected access to confidential material, and the human expertise needed to understand what the proof does and does not establish.
Delivery places a usable copy or access route in the affected person's hands while contest remains possible. Delivery includes identity resolution, accessibility, language, durable export, confirmation, recovery when an account is unavailable, and protection against interception.
Adjudication and remedy determine whether a challenge changes the consequence. These are institutional costs: trained reviewers, independent forums, interim relief, evidence protection, correction propagation, compensation, and reserves or insurance where monetary relief must remain solvent.
Collapsing the layers produces misleading comparisons. Cheap commitment does not make delivery cheap. Cheap storage does not make adjudication cheap. Automated verification does not make interpretation or remedy automatic.
A Reference Event Flow
A production design should preserve the relation among the following objects:
- the prospective mandate and rule version
- the consequential event
- observations and derived inferences
- the decision and executing component
- the surviving principal
- the issued receipt
- delivery status
- any contest and interim order
- the final disposition and remedy; and
- correction lineage to every material downstream use.
Each object needs a stable identifier and a versioning rule. The links should remain testable after software deployment, key rotation, organizational restructuring, or vendor replacement.
The architecture need not place every object in one database. Separation can improve security and privacy. A public commitment may prove that a protected receipt existed at a time without exposing its contents. Personal evidence may remain encrypted in a controlled repository while a minimal event record is retained by the institution. The design succeeds only if authorized reviewers can reconstruct the chain without trusting the operator's current account of its former system.
A receipt issued after the fact should be marked as reconstructed. It must identify the records used, the reconstruction date, and any missing contemporaneous evidence. Retroactive generation cannot be presented as if the mandate and evidence had been bound before execution.
Batching, Commitment, and Retention
Batching can reduce commitment overhead by placing many receipt digests under one authenticated root. The design must still let an affected person prove inclusion, identify the relevant schema and key, and distinguish one receipt from its neighbors. A batch that can be verified only by the operator hides individual failure inside aggregate integrity.
Commitment burial occurs when technically valid evidence is placed in a structure no affected person can locate or interpret. Engineers should test discovery from the claimant's position: given the notice and the public documentation, can the person find the commitment, obtain the inclusion material, select the correct verification key, and understand the result without private operator knowledge?
Retention should be proposition-specific. The institution may need to preserve proof that it exercised coercive authority long after some personal evidence loses its presumptive force for new decisions. Deleting every copy can frustrate accountability; retaining every detail can create permanent exposure. A retention design should record:
- the purpose for which each data class is held
- access roles and logging
- the event that starts its retention period
- sealing or resolution-reduction stages
- conditions for lawful preservation
- rules for renewed adverse use
- correction and litigation holds; and
- the evidence that deletion or restriction propagated downstream.
Claims about future storage prices should not substitute for this policy. Cheap retention can increase constitutional risk by making indefinite collection easier.
Delivery and Accessibility
An engineering team should treat delivery as a state machine rather than a send operation.
Possible states include prepared, delivered, delivery failed, accessed, exported, representative-accessed, superseded, corrected, sealed, and expired for a specified use. State transitions should be attributable and should not overwrite the prior history.
Delivery must survive the very restriction the receipt describes. A person whose account has been suspended may need an external address, download token, paper route, authorized representative, or other channel that does not depend on logging into the disabled account. Recovery procedures must resist impersonation without requiring the claimant to prove identity through the contested system alone.
Human-readable and machine-readable forms should express the same propositions. The human form should state the practical consequence, evidence class, material uncertainty, next deadline, and available relief. The machine form should carry stable identifiers, versions, signatures or commitments, and typed relations. Neither should contain a material claim absent from the other.
Accessibility includes language, disability access, device constraints, and time. A technically complete explanation that requires proprietary software, exceptional bandwidth, or specialist vocabulary may fail delivery in practice.
Verification Boundaries
Every proof should name its proposition.
A digital signature may establish that a key signed bytes. It does not establish the signer's legal authority, understanding, freedom from coercion, or natural-person identity unless other institutions supply those relations.
A reproducible calculation may establish that declared inputs produced an output. It does not establish that those were the operative inputs, that the data described the world accurately, or that the rule should govern the person.
A zero-knowledge proof may establish a predicate without exposing the underlying witness. It does not establish that the predicate is constitutionally sufficient.
A model card, audit, or benchmark may describe measured behavior under specified conditions. It does not establish the result for an untested population or the legitimacy of a particular adverse act.
Receipt schemas should encode these limits. Fields for source status, uncertainty, unavailable evidence, inferential steps, and unresolved interpretation are more useful than a single verified flag. Verification can narrow a dispute. It should not launder a partial proposition into universal finality.
Adversarial Failure Tests
A receipt system should be tested by teams instructed to defeat its constitutional function while satisfying its formal requirements.
Obscurity
Issue a formally complete receipt whose explanation uses policy references, model features, or cryptographic material an ordinary claimant cannot interpret.
Failure condition: the claimant cannot identify the practical reason, disputed proposition, or next action.
Required response: revise the human representation, supply interpretation support, and preserve access to the underlying technical record for independent review.
Appeal friction
Provide a valid appeal URL while imposing identity loops, short deadlines, repeated uploads, inaccessible evidence, fees, or response times that outlast the interest.
Failure condition: a reasonable claimant cannot reach a merits review before the consequence becomes practically irreversible.
Required response: toll deadlines after demonstrated access failure, measure abandonment points, provide representative access, and give the reviewing forum power to preserve the status quo.
Commitment burial
Publish hashes or batch roots without a discoverable mapping to the affected receipt.
Failure condition: no party independent of the operator can prove inclusion and retrieve the committed version.
Required response: issue inclusion material at delivery, publish key and schema history, and test verification from outside the operator's network.
Delivery failure
Send the receipt only through the disabled account, to a stale address, or in a format the recipient cannot use.
Failure condition: the system counts delivery without evidence that a usable contest route was made available.
Required response: maintain alternate channels, track failure states, and prohibit finality based solely on an unsuccessful delivery attempt where the operator controls the channel.
Retroactive receipting
Generate authority, evidence, or reasoning after a challenge begins and present it as contemporaneous.
Failure condition: the system cannot distinguish records bound before execution from later reconstruction.
Required response: timestamp and sign the prospective mandate and event record, label reconstructions, and expose missing evidence.
Selective enforcement
Issue detailed receipts to well-resourced users or regulated markets while supplying weaker records to others affected by the same system.
Failure condition: receipt quality, review time, or remedy varies by status without a lawful and disclosed reason.
Required response: compare service levels across populations, protect claim-specific differences, and authorize systemic review where disparity persists.
Process theater
Meet every schema field while the appeal body lacks independence or remedial power.
Failure condition: successful verification cannot alter the consequence, reach a solvent remedy, or propagate a correction.
Required response: treat forum authority, funding, conflicts, and implementation of relief as part of the system under test.
Institutional capture
Allow the operator to finance, appoint, inform, and remove the bodies that audit or review it without countervailing controls.
Failure condition: formal independence conceals structural dependence, retaliation risk, or exclusive reliance on operator-supplied information.
Required response: disclose relationships, diversify appointment and review, protect dissent, test the regulator's own information sources, and preserve routes to public or plural oversight. No single numerical indicator proves capture.
Interoperability and Versioning
Interoperability should preserve meaning, not merely syntax. A receiving system needs to know which field is an observation, inference, decision, correction, or legal status; which authority issued it; which domain the term governs; and what translation occurred at the boundary.
Schema evolution should be explicit. New versions must state compatibility rules, migration behavior, deprecated fields, security implications, and effects on existing receipts. A system should retain the verifier, schema, key history, and interpretation needed for old records throughout their lawful life.
Cross-system use creates seam jurisdiction. Engineering documentation should identify who answers when a source record is valid locally but mistranslated downstream. The relation may be governed by contract, standard, bridge, clearing service, regulator, court, or other forum. Leaving it unnamed exports the hardest dispute to the claimant.
Correction messages require the same interoperability as original claims. Downstream systems should acknowledge receipt, record whether the correction altered an operative state, and explain any lawful reason for continued use. Version churn must not erase the lineage.
Measured Deployment
Cost and performance claims should be derived from representative workloads. At minimum, measure:
- event and evidence volume by consequence class
- receipt size before and after protected attachments
- commitment, signing, and verification latency
- delivery success and recovery rates
- accessibility failures
- appeal initiation, abandonment, and time to merits review
- correction propagation and unresolved downstream copies
- retention volume by purpose and legal hold
- human review time
- remedy implementation time; and
- operational behavior during key rotation, vendor failure, and schema migration.
These measures describe system behavior. They do not determine fairness. A low appeal rate may mean accurate decisions, inaccessible recourse, fear of retaliation, low expected remedy, or a population that never received notice. Quantitative monitoring should be paired with claimant interviews, independent case review, and attention to people absent from the logs.
A staged deployment should begin with consequence classes whose authority and remedies are already defined. Teams can then test whether receipts improve reconstruction, challenge, and correction without claiming that a successful pilot proves the framework across domains.
Engineering Boundary
A production system fails this appendix if it cannot preserve an attributable chain from mandate to event, evidence, delivery, contest, remedy, and correction. It also fails if that chain is formally intact but unusable by the affected person.
The objective is bounded: make consequential acts easier to reconstruct and challenge, keep correction attached to the claims it repairs, and expose the dependencies on which remedy relies. Receipts can prove that evidence was preserved and that specified procedures occurred. They remain evidence infrastructure. They do not make the evidence true, the procedure independent, or the outcome just.