Appendix B
Engineering Considerations
The objection is straightforward: receipts sound like overhead. Every coercive act generates a record. Every record must be stored, signed, delivered, and made available for verification. At scale (billions of users, millions of decisions per second) the cumulative cost would grind systems to a halt. The framework is intellectually coherent but practically impossible.
This appendix addresses the objection directly. The answer is not that receipts are free, but that they are cheaper than their absence. The cost of upstream documentation is lower than the cost of downstream dispute resolution. Receipts shift costs. They do not simply add them. The shift is economically favorable by several orders of magnitude.
The Tiered Architecture
Not all consequential acts require the same treatment. Appendix A established proportionality based on reversibility of harm. The engineering follows the same logic.
High-tier events include account termination, credential revocation, and asset seizure. These are difficult or impossible to reverse. The harm compounds over time: a professional whose license is revoked cannot practice while appealing. A user whose account is terminated loses accumulated relationships and reputation that cannot be reconstructed. High-tier events warrant the full receipt specification: act, authority, bounds, justification, appeal path. They warrant external commitment—a cryptographic anchor to a ledger the platform does not solely control. They warrant longer retention, independent verification before action where feasible, and guaranteed access to bonded arbitration.
Medium-tier events include account restrictions, feature suspensions, and credential flags. These are reversible but consequential. A temporary suspension disrupts livelihood; a flag affects access to opportunities. Medium-tier events warrant the full receipt specification with proactive delivery: the affected party should not have to discover the action through its consequences. They warrant structured appeal paths with guaranteed response times. Storage is measured in months, not years. The record need not survive the platform itself. It must survive long enough for meaningful contest.
Low-tier events include content demotion, recommendation exclusion, and algorithmic ranking changes. These are individually reversible and low-stakes, but they constitute the majority of platform influence. A content creator whose videos are systematically demoted experiences this as coercion, even if no single demotion is catastrophic. The low tier cannot simply be exempted.
What the low tier warrants is queryable state, not the full receipt. The affected party should be able to ask: what has changed about my standing, and when? The answer need not include full justification for each change. It must include enough to establish patterns. If demotion is systematic, the pattern becomes visible. If the pattern becomes visible, it can be contested. The minimum viable low-tier receipt is: what changed, when it changed, and a path to escalate if the pattern persists. This is more than a log entry for auditors. It is inspectable state for the person it concerns.
If the pattern persists beyond a threshold—multiple demotions within a period, or cumulative impact exceeding a defined harm level—the affected party can invoke medium-tier treatment, requiring full justification and structured appeal. The escalation trigger transforms systematic low-tier actions into a single medium-tier event: the pattern itself becomes contestable, not merely visible.
The scaling math. For a platform with a billion users, high-tier events number in the thousands per day. Medium-tier events number in the hundreds of thousands. Low-tier events number in the billions. The tiered architecture assigns different overhead to each tier. High-tier receipts are measured in kilobytes and require external commitment. Medium-tier receipts are measured in hundreds of bytes with platform-side storage. Low-tier records are measured in tens of bytes with user-queryable access.
The aggregate storage for a billion-user platform is measured in tens of gigabytes per day. This is trivial. Data centers handle petabytes. The objection that receipts are "too expensive" assumes uniform treatment. Tiered architecture dissolves the objection.
Batching and Commitment
Individual receipt verification is expensive if done naively. Every signature must be checked; every hash must be computed; every proof must be validated. At scale, the verification costs exceed the documentation costs.
The solution is batch verification. Instead of verifying each receipt independently, many receipts are committed together, and any individual receipt can be verified against the batch commitment with minimal overhead.
The pattern has been solved repeatedly in computer science. A commitment structure (currently instantiated as Merkle trees, and similar constructions) allows a system to commit to N records with a single root value. Any individual record can be proven to be part of the batch with a proof whose size grows logarithmically with batch size. A daily commitment covering a hundred thousand medium-tier events requires fewer than twenty hash operations to verify any single receipt.
More sophisticated batch verification (currently instantiated as ZK-SNARKs, STARKs, and related cryptographic proofs) allows properties of entire batches to be proven without revealing individual contents. "This batch contains no receipt older than fourteen days without resolution" can be proven without exposing individual cases. The affected party can verify that their case was included in the batch; regulators can verify batch-level properties; the system can prove compliance without sacrificing privacy.
Optimistic verification shifts cost to disputes. Most receipts are never contested. Rather than verifying every receipt upfront, the system assumes validity and allows a challenge window. Verification cost is paid only when someone actually challenges. This pattern is familiar from financial settlement: transactions clear provisionally and finalize after a dispute window.
Historical parallel. Encrypting every HTTP connection was "too expensive" in 2000. Hardware acceleration, protocol optimization, and session resumption made HTTPS universal within two decades. The same trajectory applies to receipt verification: computationally expensive at first, commodity soon after. Every "impossible at scale" objection in computing history has eventually been overcome by cost curves and engineering ingenuity. This pattern will not be the exception.
The Baseline Comparison
The objection frames receipts as pure overhead: a cost added to systems that currently operate without it. This framing is incomplete. Systems without receipts bear significant costs that receipts would reduce or eliminate.
Dispute resolution costs. Every unexplained suspension generates support tickets. Human agents investigate. Escalations consume management attention. The cost per ticket is measured in tens of dollars; the cost per receipt is measured in fractions of a cent. The ratio favors upstream documentation by four to five orders of magnitude.
Litigation costs. Unexplained adverse actions generate lawsuits. Discovery is expensive. Settlements are expensive. Judgments are expensive. A single successful lawsuit can cost more than a decade of receipt infrastructure.
Regulatory costs. Data protection regimes, digital services regulations, and emerging AI governance frameworks increasingly require explainability. Fines for unexplained automated decisions can reach significant fractions of annual revenue. Receipt infrastructure is compliance infrastructure by another name.
Reputational costs. Public incidents of unexplained bans, deplatforming without process, and opaque algorithmic decisions erode trust. The cost is diffuse but real: users who distrust a platform are more likely to maintain alternatives, reducing engagement and network effects.
The correct framing. Receipts do not add costs to a zero-cost baseline. They shift costs from downstream dispute resolution to upstream documentation. The shift is economically favorable. A system that invests in receipts spends less on support, litigation, regulation, and reputation repair than a system that does not.
Cost Trajectories
The costs of receipt infrastructure are not static. They decline on predictable trajectories.
Storage costs have declined at double-digit annual rates for decades. Each generation of storage technology (magnetic disk, solid state, distributed object storage) has driven costs down by orders of magnitude. A receipt that costs a measurable amount to store today will cost a negligible amount to store in a decade.
Computation costs follow a similar trajectory. The cryptographic operations required for receipt generation and verification (hashing, signing, proof generation) become cheaper with each generation of hardware. Operations that required dedicated accelerators become commodity. Operations that were once expensive become free in the noise of system overhead.
Bandwidth costs are declining but matter less than they appear. Receipt delivery is measured in kilobytes. Even high-tier receipts with full justification and appeal documentation are measured in tens of kilobytes. Against network capacity, this is negligible.
The pattern. Every "impossible at scale" engineering objection has eventually been overcome by cost curves. Full-text search at internet scale. Real-time video delivery to billions. End-to-end encryption for every message. Each was deemed impractical until it became routine. Receipt infrastructure follows the same trajectory. The costs are real but temporary; the benefits are structural and permanent.
Implementation Patterns
The patterns described here are technology-agnostic. They could be implemented with today's tools or with tools not yet invented. What matters is the structural properties, not the specific instantiation.
Append-only audit logs. Every consequential state change writes to an immutable log. The log is the source of truth for receipts. This pattern is ancient: the ledger that could not be erased, the record that could not be altered after the fact. Modern implementations use cryptographic chaining (currently instantiated as hash chains and blockchain structures) to make immutability verifiable, but the pattern predates the technology.
Cryptographic commitment to external ledgers. For high-tier events, the platform publishes a commitment to a ledger it does not solely control. This could be a public blockchain, a Certificate Transparency-style log, a consortium ledger maintained by multiple parties, or a future equivalent. The point is not the specific technology but the structural property: the commitment exists somewhere the platform cannot unilaterally revoke or alter.
Selective disclosure. Receipts contain information that may be sensitive. The justification field may reveal more than the affected party wants public. The solution is encryption with subject-controlled keys: the system can prove the receipt exists without revealing contents. The subject decides when and whether to disclose. The privacy tension identified in Appendix A is addressed architecturally.
Staged verification. Low-tier records are verified only on query. Medium-tier receipts are verified on delivery. High-tier receipts are verified by an independent third party before the action takes effect. Verification cost is proportional to stakes.
Receipt registries. Third-party services accept receipt commitments from multiple platforms, providing cross-platform audit trails. No single platform controls the registry; no single platform can make records disappear. The law merchant pattern: interstitial infrastructure that emerges between institutions rather than within them.
Human Factors
Receipts are for humans. A receipt that is technically correct but practically unusable is theater.
Presentation. How does the affected party encounter the receipt? A push notification that links to a structured document. An email with the receipt attached. A dedicated inbox within the platform. For high-tier events, perhaps physical mail to an address on record. The delivery mechanism must be appropriate to the stakes: a content demotion can be queried, but an account termination must be proactively delivered through channels the user is likely to check.
Legibility. The justification field is useless if it contains technical jargon incomprehensible to the affected party. "Content ID 9f4e2a matched policy trigger P-14" is accurate but not actionable. A legible justification explains in terms the affected party can understand: "Your post was removed because it was classified as coordinated inauthentic behavior. The classification was based on posting patterns similar to known spam networks." Accuracy and legibility are both required.
Actionability. A receipt must include what to do about it, not just what happened. Where is the appeal form? What information should the appeal include? What is the timeline for response? What happens if the appeal is denied? The appeal path must be navigable, not just specified—a clear sequence of steps the affected party can actually take.
Accessibility. Receipts must work for users who are not technical, who do not speak the platform's primary language, who have disabilities affecting how they consume information. The receipt specification is the minimum. The presentation layer must make that minimum actually usable by the people it concerns.
The human factors determine whether receipts constrain domination or merely document it. They are not engineering at scale. A receipt system optimized for machine processing but hostile to human comprehension fails its purpose.
Interoperability
The law merchant worked because it crossed jurisdictions. A judgment from a fair court in one city was enforceable at fairs in other cities. The credential issued by one guild was recognized by guilds elsewhere. Receipts that only work within a single platform do not enable the exit that Appendix A requires.
Cross-platform verification. A receipt from Platform A should be verifiable by Platform B's arbitration system, by a regulator, by a court. This requires either common formats (a receipt specification that multiple platforms adopt) or translation layers (services that convert between formats while preserving cryptographic validity).
Portable evidence. When a user exits a platform, their receipt history should travel with them. The receipts documenting prior adverse actions, the appeals filed, the resolutions reached—these constitute evidence of standing that should not be locked to any single platform.
Standards emergence. The pattern from other domains is instructive. Email became interoperable through SMTP. The web became interoperable through HTTP and HTML. Payment cards became interoperable through interchange networks. Each required either de facto standards (one implementation became dominant) or de jure standards (industry or regulatory bodies defined common formats). Receipt interoperability will likely require similar standardization—either organic emergence around a successful implementation or deliberate coordination around a specification.
The infrastructure question. Who builds the interoperability layer? The honest answer is: whoever finds it valuable enough to build. Regulators who want cross-platform audit trails. Arbitration services that want to accept disputes from multiple platforms. User advocates who want portable evidence. Civil society organizations that want accountability infrastructure. The law merchant was not decreed. It emerged because merchants needed it. Receipt interoperability will emerge because parties who benefit from it will build it.
The transition period. Interoperability assumes multiple platforms with receipt infrastructure. During the transition, some platforms will have receipts and others will not. A user who exits Platform A (with receipts) for Platform B (without receipts) carries evidence but arrives in a system that cannot process it. The portable evidence remains valuable for external arbitration, regulatory complaint, or litigation—but the user's standing within Platform B starts from zero. The transition is merely better than remaining in a system without exit. It is not seamless.
Infrastructure Governance
Receipt infrastructure is itself a chokepoint. A system that requires receipts to pass through a single registry, a single ledger, a single verification service has merely relocated the domination problem. Who governs the receipt infrastructure?
Defense in depth. The answer is a multiplicity of parties, not a single trusted party. None of them can unilaterally deny service. Multiple receipt registries. Multiple commitment ledgers. Multiple verification services. If one becomes captured or fails, others remain available. The affected party can choose which infrastructure to trust; the platform cannot choose which infrastructure to permit.
Pluralization. No single ledger should be required. The high-tier commitment requirement can be satisfied by commitment to any of several acceptable ledgers. Competition among ledgers disciplines each: a ledger that becomes expensive, slow, or captured loses users to alternatives.
Transparency about the infrastructure. The entities operating receipt infrastructure should themselves be subject to audit. Their operations, their governance, their funding sources—all should be visible. The question "who audits the auditors?" has no final answer, but the recursive application of transparency and pluralization makes capture progressively more difficult.
Failure modes. The infrastructure itself can fail. Ledgers can become unavailable. Registries can be DDoSed. Verification services can be compromised. The receipt system must degrade gracefully: high-tier events can require some external commitment without requiring a specific ledger. The system should accept commitments to any of several alternatives and add more as they emerge.
Funding models. Receipt infrastructure requires resources. The law merchant was funded by merchant fees; fair courts charged for judgments; guilds collected dues. Analogous models exist: platform fees for registry access, regulatory mandates that shift costs to covered entities, civil society funding for public-interest infrastructure. The funding model shapes the governance: fee-funded registries have different incentives than publicly funded ones. The plurality requirement applies here too—no single funding model should dominate, lest funders capture the infrastructure they fund.
Adversarial Considerations
A hostile platform operator might comply with receipt requirements formally while undermining them substantively. Engineering for non-domination requires engineering against process theater—the deliberate performance of remedy where no remedy exists.
Justification obscurity. The justification field contains technical jargon incomprehensible to the affected party. Formally, a justification exists; substantively, it is useless. The remedy: legibility requirements. Justifications must be comprehensible to a reasonable person without specialized technical knowledge. Regulators and arbiters should treat obscure justifications as deficient justifications.
Appeal path friction. The appeal path exists but requires resources disproportionate to stakes. A medium-tier suspension can be appealed, but the appeal requires notarized documents, legal representation, and a filing fee. Formally, an appeal path exists; substantively, it is foreclosed. The remedy: proportionality of appeal process. The burden of appealing should be proportionate to the burden imposed by the adverse action.
Commitment burial. Batch commitments are published to a ledger no one monitors. Formally, commitments exist. Substantively, no one can find them. The remedy: discoverability requirements. Commitments must be published to ledgers that are actively monitored by third parties. Registry services that aggregate and index commitments provide the discoverability that makes commitments meaningful.
Delivery evasion. Receipts are delivered to an inbox the user never checks, at an email address they no longer use, in a format that fails silently. Formally, delivery occurred; substantively, the affected party never learned of the action. The remedy: verified delivery. High-tier events should require acknowledgment of receipt or escalating delivery attempts (platform inbox, then email, then registered mail, then account-level notification on next login).
Retroactive receipting. The action is taken, then documented after the fact. The timestamp is accurate for the receipt, not the action. Formally, a receipt exists; substantively, the affected party had no warning. The remedy: temporal binding. The receipt must be generated contemporaneously with the action. The commitment must bind the two together cryptographically so that backdating is detectable.
Selective enforcement. Receipts are rigorously generated for some users and loosely generated for others. Formally, the system complies; substantively, compliance varies by who you are. This is bias disguised as compliance variance—formally compliant overall, substantively discriminatory in application. The remedy: statistical audit of receipt quality across user populations. Systematic variance in receipt completeness, justification legibility, or appeal resolution times should be detectable and contestable.
The pattern across all these cases: formal compliance is insufficient. The specification must include requirements that make substantive compliance necessary for formal compliance. Legibility, proportionality, discoverability, verified delivery, temporal binding—these are structural requirements, not optional polish.
What This Appendix Does Not Claim
Not zero cost. Receipts have overhead. The claim is that overhead is bounded, declining, and cheaper than the alternative—not that it is negligible or free.
Not automatically just. A system can produce perfect receipts for unjust policies. Receipts enable inspection. They do not guarantee good outcomes. A platform with excellent receipt infrastructure can still make terrible decisions. The receipts merely make those decisions visible and contestable.
Not all problems solved. Receipt infrastructure requires governance. The recursive question—who audits the auditors?—has no final answer. Defense in depth and pluralization make capture difficult but do not make it impossible.
Not immune to adversarial pressure. A sufficiently motivated adversary with sufficient resources can produce formally compliant but substantively empty receipts. The adversarial considerations section addresses common evasion patterns, but no specification anticipates all adversarial creativity. The goal is to make evasion expensive and visible, not to make it impossible.
Not a substitute for politics. Technical infrastructure creates the preconditions for accountability. It does not guarantee it. Receipts without political will to act on them are documentation without consequence. The architecture described here is necessary. It is not sufficient. What makes it sufficient is the political mobilization to demand and use it.
The question this appendix addresses is whether receipted coercion is feasible at scale. The answer is yes. Tiered architecture makes the volume manageable. Batch verification makes commitment efficient. Cost trajectories make overhead declining. Interoperability makes the infrastructure portable. Governance pluralization makes capture difficult.
The question this appendix does not address is whether it will be built. Truth needed witnesses — verification systems exist. Value needed work — proof-of-work systems exist. Freedom needs receipts. The engineering is tractable. The infrastructure is specifiable. What remains is the will to build it.