Network Working Group S. Das Internet-Draft Independent Researcher Intended status: Experimental 1 October 2026 Expires: 4 April 2027 A Permit to Effect Once Is Not a Permit to Effect Permanently: Reality as a Cryptographic Dependency for AI Machines, Frontier AI Model Providers, and Critical Systems draft-das-safety-first-execution-finality-00 Abstract A permit to effect once is not a permit to effect permanently. An approval, a policy decision, or one successful effect is not standing authority for a larger or repeated one. For AI machines and frontier AI models that can now act in the world, this separates a contained mistake from an irreversible one. Today, security checks who is asking, inspects a token, opens the gate, and hopes that the downstream network path, destination, or physical machine is safe. AI agents now send messages and files, move money, change production infrastructure, invoke tools, update model and memory state, release sensitive data, and drive vehicles, robots, and industrial equipment. Approval can show that an action was allowed in principle without showing that the exact action reaches the right recipient, device, or outcome. Simulations and dry-runs do not close this gap, because a simulation can pass in a clean sandbox while the real target, route, or actuator has been hijacked. Logs do not close it either, because a log explains a disaster after it has happened. This document makes reality a cryptographic dependency. The full- consequence command is held in a state that cannot execute. First, a deliberately bounded real effect is produced on the exact operational path: a trailing capsule, one record, a payment hold, a canary deployment, a constrained session, or a millimetre of actuator movement. The destination, transaction system, network element, sensor, or hardware controller then returns an Effect Confirmation Receipt. An Interim Effectuation Validator validates that receipt out of band against the intended act, nonces, epoch, scope, destination, current policy, and revocation state. Only then does it issue the continuation instruction that reconstructs the key, releases the split credential, or unlocks the hardware register for the next phase. Without the receipt, the key for full effect does not exist on the machine. Evidence is therefore a structural dependency and not a log. Das Expires 4 April 2027 [Page 1] Internet-Draft Reality as a Cryptographic Dependency October 2026 Two properties are central. First, the validator never relays the original command: the micro-effect proceeds independently and the validator observes the proof from a distance, so compromising an inline proxy or manipulating routing through prompt injection does not hand over the keys. Second, uncertainty is a first-class state. If a micro-effect fires but trustworthy evidence is missing, the system quarantines and refuses progression instead of retrying, so an autonomous loop cannot compound a duplicate transfer, a double commit, or an over-actuation. These properties hold under stated assumptions, including receipt integrity, path completeness, and atomic consumption of continuation authority, which the document identifies. The architecture covers single-phase and multi-phase execution; human, automatic, hybrid, threshold, and hardware-rooted approval; anti-replay and anti-substitution controls; alternate-path closure; reconciliation of indeterminate outcomes; and rollback, compensation, and safe-state handling. It consolidates thirty-five workflow profiles across communications, files, payments, databases, cloud and model deployment, AI tool invocation, data export, robotics, vehicles, UAVs, industrial control, radio and satellite systems, GPU and accelerator egress, and software and firmware activation. The Safety-First Critical-System Profile applies where avoiding catastrophic or hard-to-reverse outcomes comes before minimum latency: a deployment MUST NOT remove a validation, receipt, anti- replay, or safe-state protection merely to be faster, when protected policy classifies it as necessary for the consequence class. Authority in the era of autonomous machines cannot be granted session-wide. It is earned progressively from the real pathway, one bounded step at a time. Patent pending: the concept described in this document is the subject of Indian Patent Office application number 202631117633, "Systems and Methods for Cryptographically Staged Effectuation with Verified Partial Effect, Receipt-Bound Full Effectuation, and Software- Hardware Enforcement". Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Das Expires 4 April 2027 [Page 2] Internet-Draft Reality as a Cryptographic Dependency October 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 36 1.1. Design Principle: Computation Is Not Effectuation Authority . . . . . . . . . . . . . . . . . . . . . . . . 37 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 37 1.3. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 38 2. Consolidated Technical Source Set and Industry Map . . . . . 38 2.1. Twelve E01-E35 Workflow Documents . . . . . . . . . . . . 38 2.2. IEV Technical Family . . . . . . . . . . . . . . . . . . 41 2.3. Topology-Independent and Alternative-Authority Closure Source . . . . . . . . . . . . . . . . . . . . . . . . . 42 3. Executive Summary of Workflow Profiles E01-E35 . . . . . . . 43 3.1. E01 — Single-Phase Protected Effectuation . . . . . . . . 43 3.2. E02 — Real Bounded Demonstration Effect, Verified Receipt, Then Full Effectuation . . . . . . . . . . . . . . . . . 43 3.3. E03 — Real Demonstration Effect with Receipt-Gated Multi-Phase Progressive Effectuation . . . . . . . . . . 43 3.4. E04 — Verified Demonstration Effect, Protected Human Approval, Then Broader or Full Effectuation . . . . . . 44 3.5. E05 — Verified Demonstration Effect, Automatic Protected Decision, Then Receipt-Gated Continuation . . . . . . . 44 3.6. E06 — Hybrid Human and Automatic Receipt-Gated Continuation . . . . . . . . . . . . . . . . . . . . . . 44 3.7. E07 — Software Protected Enforcement Domain . . . . . . . 44 3.8. E08 — Hardware Protected Enforcement Domain . . . . . . . 44 Das Expires 4 April 2027 [Page 3] Internet-Draft Reality as a Cryptographic Dependency October 2026 3.9. E09 — Split Software/Hardware Protected Enforcement Domain . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.10. E10 — Receipt-Conditioned Hardware Cryptographic Key-Chain Effectuation . . . . . . . . . . . . . . . . . . . . . . 45 3.11. E11 — Threshold / Multi-Party Cryptographic Continuation . . . . . . . . . . . . . . . . . . . . . . 45 3.12. E12 — Message-SEND Demonstration / Trailer-Then-Full Effectuation . . . . . . . . . . . . . . . . . . . . . . 45 3.13. E13 — Receipt-Gated File Transfer and Progressive File Release . . . . . . . . . . . . . . . . . . . . . . . . 45 3.14. E14 — Payment Demonstration and Receipt-Gated Full / Progressive Payment . . . . . . . . . . . . . . . . . . 45 3.15. E15 — Escrow / Conditional Settlement and Receipt-Gated Release . . . . . . . . . . . . . . . . . . . . . . . . 46 3.16. E16 — Receipt-Gated Database Commit, Provisional Persistence, and Promotion . . . . . . . . . . . . . . . 46 3.17. E17 — Receipt-Gated Cloud Deployment and Progressive Infrastructure Rollout . . . . . . . . . . . . . . . . . 46 3.18. E18 — Receipt-Gated AI Model Deployment, Model Activation, and Progressive Consequence Release . . . . . . . . . . 46 3.19. E19 — Receipt-Gated Tool Use and External Action Invocation . . . . . . . . . . . . . . . . . . . . . . . 46 3.20. E20 — Progressive Credential Release and Receipt-Gated Authority Expansion . . . . . . . . . . . . . . . . . . 46 3.21. E21 — Receipt-Gated Data Export, Progressive Disclosure, and Cryptographic Release . . . . . . . . . . . . . . . 47 3.22. E22 — Receipt-Gated Storage Release, Provisional Persistence, and Progressive Visibility . . . . . . . . 47 3.23. E23 — Receipt-Gated Robotic Actuation and Progressive Physical Effectuation . . . . . . . . . . . . . . . . . 47 3.24. E24 — Hardware Actuator, Protected Sensor Confirmation, and Receipt-Derived Motion Authority . . . . . . . . . . . . 47 3.25. E25 — Receipt-Gated Vehicle Effectuation and Progressive Vehicular Authority . . . . . . . . . . . . . . . . . . 47 3.26. E26 — Receipt-Gated UAV and Mobile-Robot Effectuation . . 47 3.27. E27 — Receipt-Gated Industrial, PLC, Machine, and Process-Control Effectuation . . . . . . . . . . . . . . 48 3.28. E28 — Receipt-Gated Telecom Effectuation and Progressive Network Authority . . . . . . . . . . . . . . . . . . . 48 3.29. E29 — Receipt-Gated Radio, Satellite, and Non-Terrestrial Network Effectuation . . . . . . . . . . . . . . . . . . 48 3.30. E30 — Receipt-Gated GPU, Accelerator, and Compute-Egress Effectuation . . . . . . . . . . . . . . . . . . . . . . 48 3.31. E31 — Receipt-Gated Model-State Update, Protected Memory Commit, and Progressive Model-State Effectuation . . . . 48 3.32. E32 — Receipt-Gated Software, Firmware, and Configuration Update with Progressive Activation . . . . . . . . . . . 49 Das Expires 4 April 2027 [Page 4] Internet-Draft Reality as a Cryptographic Dependency October 2026 3.33. E33 — Multi-Destination, Multi-Recipient, Multi-Sink, and Distributed Receipt-Gated Effectuation . . . . . . . . . 49 3.34. E34 — Replicated, Quorum-Confirmed, and Consensus Receipt-Gated Effectuation . . . . . . . . . . . . . . . 49 3.35. E35 — Negative, Indeterminate, Conflict, Reconciliation, and Recovery Receipt-Gated Effectuation . . . . . . . . 49 4. Detailed Interim Effectuation Validator (IEV) Integration Summary . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.1. Evidence Intake and Independent Decision . . . . . . . . 50 4.2. Continuation Condition and Cryptographic Missing Material . . . . . . . . . . . . . . . . . . . . . . . . 50 4.3. Validator Placement and Substitution Invariance . . . . . 51 4.4. Taint, Origin Attribution, and Boundary Credential Surrogation . . . . . . . . . . . . . . . . . . . . . . . 51 4.5. Failure, Remediation, and Human Escalation . . . . . . . 52 5. Detailed Design-Around / Implementation-Equivalence Closure (T1-T12) . . . . . . . . . . . . . . . . . . . . . . . . 52 5.1. T1 — Monolithic Protected Executor . . . . . . . . . . . 52 5.2. T2 — Implicit-State / No-Token Authority . . . . . . . . 53 5.3. T3 — Direct Human-Signed Exact Act . . . . . . . . . . . 53 5.4. T4 — Human Re-Originated Operation After AI Recommendation . . . . . . . . . . . . . . . . . . . . . 53 5.5. T5 — Structural Capability / Object-Capability / Typed Authority . . . . . . . . . . . . . . . . . . . . . . . 53 5.6. T6 — Native Transactional Invariant / Commit-State Enforcement . . . . . . . . . . . . . . . . . . . . . . 54 5.7. T7 — Risk-Selective or Consequence-Selective Mediation . 54 5.8. T8 — Post-Effect Compensation as Ancillary or Fallback . 54 5.9. T9 — Formally Verified / Attested / Deterministic Runtime Within a Protected Envelope . . . . . . . . . . . . . . 54 5.10. T10 — Native Destination Policy and Destination-Local Finality . . . . . . . . . . . . . . . . . . . . . . . . 55 5.11. T11 — Replicated / Quorum / Consensus-Native Effectuation . . . . . . . . . . . . . . . . . . . . . . 55 5.12. T12 — Pre-Authorized Finite Action Machine / Bounded Action Graph . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.13. Cross-Cutting Closure Rule . . . . . . . . . . . . . . . 55 6. Internet-Draft Integration Summary . . . . . . . . . . . . . 56 7. Conventions and Requirements Language . . . . . . . . . . . . 57 8. Terminology and Formal Notation . . . . . . . . . . . . . . . 57 9. Threat and Consequence Model . . . . . . . . . . . . . . . . 59 10. Safety-First Critical-System Profile . . . . . . . . . . . . 59 10.1. Mandatory Safety-First Properties . . . . . . . . . . . 60 10.2. Latency Reduction Without Safety Reduction . . . . . . . 61 11. Core Execution-Finality Architecture . . . . . . . . . . . . 61 11.1. Candidate Act Binding . . . . . . . . . . . . . . . . . 61 11.2. Protected Validation and Effectuation Boundary . . . . . 62 11.3. Single-Phase Mode . . . . . . . . . . . . . . . . . . . 62 Das Expires 4 April 2027 [Page 5] Internet-Draft Reality as a Cryptographic Dependency October 2026 11.4. Staged Real Effectuation . . . . . . . . . . . . . . . . 62 11.5. Effect Observation and Receipt . . . . . . . . . . . . . 63 11.6. Expected-vs-Observed Validation . . . . . . . . . . . . 63 11.7. Receipt-Gated Continuation . . . . . . . . . . . . . . . 63 11.8. Multi-Phase Progression . . . . . . . . . . . . . . . . 64 11.9. Atomic State Advancement and Receipt Consumption . . . . 64 12. Approval and Decision Modes . . . . . . . . . . . . . . . . . 65 12.1. Protected Human Continuation . . . . . . . . . . . . . . 65 12.2. Automatic Continuation . . . . . . . . . . . . . . . . . 65 12.3. Hybrid and Multi-Authority Continuation . . . . . . . . 65 13. Protected Enforcement Domains . . . . . . . . . . . . . . . . 66 13.1. Software PED . . . . . . . . . . . . . . . . . . . . . . 66 13.2. Hardware PED . . . . . . . . . . . . . . . . . . . . . . 66 13.3. Split Software/Hardware PED . . . . . . . . . . . . . . 66 14. Cryptographic and Distributed Continuation . . . . . . . . . 66 14.1. Receipt-Conditioned Key Chains . . . . . . . . . . . . . 66 14.2. Threshold Continuation . . . . . . . . . . . . . . . . . 67 14.3. Replicated and Quorum-Confirmed Effectuation . . . . . . 67 15. Sensitive-Work Workflow Families . . . . . . . . . . . . . . 67 16. Failure, Indeterminate State, and Recovery . . . . . . . . . 69 16.1. No Blind Retry . . . . . . . . . . . . . . . . . . . . . 69 16.2. Conflicting Evidence . . . . . . . . . . . . . . . . . . 69 16.3. Safe-State and Compensation . . . . . . . . . . . . . . 70 17. Anti-Substitution, Anti-Skip, and Alternate-Path Closure . . 70 18. Generic Operational Algorithm . . . . . . . . . . . . . . . . 70 19. Security Considerations . . . . . . . . . . . . . . . . . . . 72 20. Privacy Considerations . . . . . . . . . . . . . . . . . . . 73 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 22. Normative References . . . . . . . . . . . . . . . . . . . . 73 23. Informative References . . . . . . . . . . . . . . . . . . . 73 Appendix A. Detailed Workflow Profiles E01-E35 . . . . . . . . . 74 A.1. E01 — Single-Phase Protected Effectuation . . . . . . . . 74 A.1.1. E01.1 Purpose . . . . . . . . . . . . . . . . . . . . 74 A.1.2. E01.2 Initial Actors and Functional Components . . . 74 A.1.3. E01.3 Protected Enforcement Domain Intake . . . . . . 76 A.1.4. E01.4 Protected State Acquisition . . . . . . . . . . 77 A.1.5. E01.5 Validation Predicate Formation . . . . . . . . 78 A.1.6. E01.6 Approval-Mode Determination . . . . . . . . . . 78 A.1.7. E01.7 Automatic Approval Workflow . . . . . . . . . . 79 A.1.8. E01.8 Protected Human Approval Workflow . . . . . . . 79 A.1.9. E01.9 Selection of Single-Phase Mode . . . . . . . . 81 A.1.10. E01.10 Formation of Effectuation Authority . . . . . 82 A.1.11. E01.11 Authority Binding . . . . . . . . . . . . . . 83 A.1.12. E01.12 Delivery to Effectuation Boundary . . . . . . 83 A.1.13. E01.13 Sink-Side Verification . . . . . . . . . . . . 84 A.1.14. E01.14 Full Effectuation . . . . . . . . . . . . . . 85 A.1.15. E01.15 Completion Observation . . . . . . . . . . . . 86 A.1.16. E01.16 Completion Receipt . . . . . . . . . . . . . . 87 Das Expires 4 April 2027 [Page 6] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.1.17. E01.17 Authority Consumption . . . . . . . . . . . . 87 A.1.18. E01.18 Indeterminate Completion . . . . . . . . . . . 87 A.1.19. E01.19 Anti-Bypass Requirement . . . . . . . . . . . 88 A.1.20. E01.20 Software Implementation Variation . . . . . . 89 A.1.21. E01.21 Hardware Implementation Variation . . . . . . 89 A.1.22. E01.22 Required Invariants . . . . . . . . . . . . . 89 A.2. E02 — Real Bounded Demonstration Effect, Verified Receipt, Then Full Effectuation . . . . . . . . . . . . . . . . . 90 A.2.1. E02.1 Purpose . . . . . . . . . . . . . . . . . . . . 90 A.2.2. E02.2 Technical Distinction . . . . . . . . . . . . . 90 A.2.3. E02.3 Candidate Act Formation . . . . . . . . . . . . 90 A.2.4. E02.4 Exact-Act / Authorized-Envelope Binding . . . . 91 A.2.5. E02.5 Stage Planner . . . . . . . . . . . . . . . . . 91 A.2.6. E02.6 Bounded Trial Effect Selection . . . . . . . . 91 A.2.7. E02.7 Trial Effect Descriptor . . . . . . . . . . . . 92 A.2.8. E02.8 Approval Before Trial . . . . . . . . . . . . . 93 A.2.9. E02.9 Phase-0 Authority . . . . . . . . . . . . . . . 93 A.2.10. E02.10 Phase-0 Sink Verification . . . . . . . . . . 94 A.2.11. E02.11 Real Bounded Effectuation . . . . . . . . . . 94 A.2.12. E02.12 Effect Observation . . . . . . . . . . . . . . 95 A.2.13. E02.13 Observed-Effect Representation . . . . . . . . 96 A.2.14. E02.14 Effect Confirmation Receipt . . . . . . . . . 96 A.2.15. E02.15 Receipt Status Classes . . . . . . . . . . . . 97 A.2.16. E02.16 Receipt Return . . . . . . . . . . . . . . . . 97 A.2.17. E02.17 Receipt Verification . . . . . . . . . . . . . 97 A.2.18. E02.18 Human Approval After Trial . . . . . . . . . . 98 A.2.19. E02.19 Automatic Approval After Trial . . . . . . . . 98 A.2.20. E02.20 Hybrid Continuation Approval . . . . . . . . . 99 A.2.21. E02.21 Protected State Advancement . . . . . . . . . 99 A.2.22. E02.22 Receipt Consumption . . . . . . . . . . . . . 99 A.2.23. E02.23 Continuation Authority . . . . . . . . . . . . 100 A.2.24. E02.24 Receipt-Derived Cryptographic Authority . . . 100 A.2.25. E02.25 Missing Execution Material Variation . . . . . 100 A.2.26. E02.26 Full / Remaining Effect Sink Verification . . 100 A.2.27. E02.27 Full Effectuation . . . . . . . . . . . . . . 101 A.2.28. E02.28 Completion Receipt . . . . . . . . . . . . . . 101 A.2.29. E02.29 Failure After Trial . . . . . . . . . . . . . 101 A.2.30. E02.30 Indeterminate Trial . . . . . . . . . . . . . 102 A.2.31. E02.31 Crash After Trial Effect . . . . . . . . . . . 102 A.2.32. E02.32 Alternate-Path Closure . . . . . . . . . . . . 103 A.2.33. E02.33 Communication “Trailer” Example . . . . . . . 103 A.2.34. E02.34 Ciphertext-First Communication Variation . . . 103 A.2.35. E02.35 Hardware Demonstration Example . . . . . . . . 104 A.2.36. E02.36 Required Invariants . . . . . . . . . . . . . 104 A.3. E03 — Real Demonstration Effect with Receipt-Gated Multi-Phase Progressive Effectuation . . . . . . . . . . 105 A.3.1. E03.1 Purpose . . . . . . . . . . . . . . . . . . . . 105 A.3.2. E03.2 Candidate Act and Maximum Effect Envelope . . . 105 Das Expires 4 April 2027 [Page 7] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.3.3. E03.3 Phase Plan . . . . . . . . . . . . . . . . . . 105 A.3.4. E03.4 Fixed Phase Plan . . . . . . . . . . . . . . . 105 A.3.5. E03.5 Adaptive Phase Plan . . . . . . . . . . . . . . 106 A.3.6. E03.6 Initial Validation . . . . . . . . . . . . . . 106 A.3.7. E03.7 Human Authorization of Entire Progressive Envelope . . . . . . . . . . . . . . . . . . . . . . 107 A.3.8. E03.8 Human Authorization Per Phase . . . . . . . . . 107 A.3.9. E03.9 Automatic Progressive Approval . . . . . . . . 107 A.3.10. E03.10 Hybrid Progressive Approval . . . . . . . . . 107 A.3.11. E03.11 Phase-Specific Authority . . . . . . . . . . . 107 A.3.12. E03.12 Phase-Receipt Chain . . . . . . . . . . . . . 108 A.3.13. E03.13 Receipt-Chain Mathematical Representation . . 108 A.3.14. E03.14 Next-Phase Predicate . . . . . . . . . . . . . 108 A.3.15. E03.15 Protected State Transition . . . . . . . . . . 108 A.3.16. E03.16 Phase Counter . . . . . . . . . . . . . . . . 109 A.3.17. E03.17 Cryptographic Key Progression . . . . . . . . 109 A.3.18. E03.18 Hardware Key Progression . . . . . . . . . . . 109 A.3.19. E03.19 Hardware Phase Latch . . . . . . . . . . . . . 109 A.3.20. E03.20 Progressive Communication Workflow . . . . . . 109 A.3.21. E03.21 Progressive Payment Workflow . . . . . . . . . 110 A.3.22. E03.22 Progressive Hardware Workflow . . . . . . . . 111 A.3.23. E03.23 Cumulative Effect State . . . . . . . . . . . 111 A.3.24. E03.24 Progressive Scope Enlargement . . . . . . . . 111 A.3.25. E03.25 Progressive Credential Authority . . . . . . . 112 A.3.26. E03.26 Receipt-Quality-Controlled Phase Size . . . . 112 A.3.27. E03.27 Risk-Adaptive Phase Size . . . . . . . . . . . 112 A.3.28. E03.28 Taint-Adaptive Progression . . . . . . . . . . 112 A.3.29. E03.29 Parallel Trial Sub-Phases . . . . . . . . . . 113 A.3.30. E03.30 Quorum Confirmation . . . . . . . . . . . . . 113 A.3.31. E03.31 Nested Phase Structure . . . . . . . . . . . . 113 A.3.32. E03.32 Partial Success . . . . . . . . . . . . . . . 114 A.3.33. E03.33 Failure at Intermediate Phase . . . . . . . . 114 A.3.34. E03.34 Indeterminate Intermediate Phase . . . . . . . 114 A.3.35. E03.35 Reconciliation Workflow . . . . . . . . . . . 115 A.3.36. E03.36 Phase Replay Protection . . . . . . . . . . . 115 A.3.37. E03.37 Receipt Consumption . . . . . . . . . . . . . 115 A.3.38. E03.38 Policy Change Between Phases . . . . . . . . . 116 A.3.39. E03.39 Revocation Between Phases . . . . . . . . . . 116 A.3.40. E03.40 Human Veto . . . . . . . . . . . . . . . . . . 116 A.3.41. E03.41 Maximum-Envelope Enforcement . . . . . . . . . 116 A.3.42. E03.42 Alternate-Path Closure . . . . . . . . . . . . 117 A.3.43. E03.43 Multi-Sink Variation . . . . . . . . . . . . . 117 A.3.44. E03.44 Same-Sink Variation . . . . . . . . . . . . . 117 A.3.45. E03.45 Distributed Protected Enforcement Domain . . . 117 A.3.46. E03.46 Final Completion . . . . . . . . . . . . . . . 118 A.3.47. E03.47 Final Receipt . . . . . . . . . . . . . . . . 118 A.3.48. E03.48 Required Invariants . . . . . . . . . . . . . 118 Das Expires 4 April 2027 [Page 8] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.4. E04 — Verified Demonstration Effect, Protected Human Approval, Then Broader or Full Effectuation . . . . . . 129 A.4.1. E04.1 Purpose . . . . . . . . . . . . . . . . . . . . 129 A.4.2. E04.2 Inheritance from E02 and E03 . . . . . . . . . 129 A.4.3. E04.3 Candidate Act and Human-Approval Requirement . 130 A.4.4. E04.4 Human Approval May Be Required at Different Locations in the . . . . . . . . . . . . . . . . . . 131 A.4.5. E04.5 Bounded Real Effect . . . . . . . . . . . . . . 132 A.4.6. E04.6 Effect Confirmation Receipt . . . . . . . . . . 132 A.4.7. E04.7 Protected Receipt Verification Before Human Presentation . . . . . . . . . . . . . . . . . . . . 133 A.4.8. E04.8 Protected Human Review Object . . . . . . . . . 133 A.4.9. E04.9 Separation from the Proposing Agent . . . . . . 134 A.4.10. E04.10 Human Authentication . . . . . . . . . . . . . 135 A.4.11. E04.11 Human Presence and Anti-Synthetic Approval . . 136 A.4.12. E04.12 Human Decision Set . . . . . . . . . . . . . . 136 A.4.13. E04.13 Human Approval Artifact . . . . . . . . . . . 137 A.4.14. E04.14 Cryptographic Binding of Human Approval to Prior Effect Evi- . . . . . . . . . . . . . . . . . . . . . 137 A.4.15. E04.15 Exact Scope Binding . . . . . . . . . . . . . 138 A.4.16. E04.16 Approval Freshness . . . . . . . . . . . . . . 138 A.4.17. E04.17 Policy Change Between Receipt and Human Approval . . . . . . . . . . . . . . . . . . . . . . 138 A.4.18. E04.18 Revocation Between Receipt and Approval . . . 139 A.4.19. E04.19 Human Approval After Evidence, Not Merely Before Evidence . . . . . . . . . . . . . . . . . . . . . . 139 A.4.20. E04.20 Continuation Predicate . . . . . . . . . . . . 139 A.4.21. E04.21 Continuation Authority Generation . . . . . . 139 A.4.22. E04.22 Receipt-and-Approval-Derived Key . . . . . . . 140 A.4.23. E04.23 Split-Key Human Approval Variation . . . . . . 140 A.4.24. E04.24 Human Approval Through Hardware . . . . . . . 140 A.4.25. E04.25 Human Approval Through Software PED . . . . . 141 A.4.26. E04.26 Remote Human Approval . . . . . . . . . . . . 141 A.4.27. E04.27 Multi-Human Approval . . . . . . . . . . . . . 141 A.4.28. E04.28 Human Approval Can Reduce But Not Silently Expand Scope . . . . . . . . . . . . . . . . . . . . 142 A.4.29. E04.29 Human Denial . . . . . . . . . . . . . . . . . 142 A.4.30. E04.30 Human Requests Another Trial . . . . . . . . . 142 A.4.31. E04.31 Human Approval of Final Irreversible Phase . . 143 A.4.32. E04.32 Communication Embodiment . . . . . . . . . . . 143 A.4.33. E04.33 Payment Embodiment . . . . . . . . . . . . . . 143 A.4.34. E04.34 Hardware Actuator Embodiment . . . . . . . . . 143 A.4.35. E04.35 Cloud / Deployment Embodiment . . . . . . . . 144 A.4.36. E04.36 Indeterminate Receipt Before Human Approval . 144 A.4.37. E04.37 Crash After Human Approval But Before Continuation . . . . . . . . . . . . . . . . . . . . 144 A.4.38. E04.38 Approval Consumption . . . . . . . . . . . . . 144 A.4.39. E04.39 Alternate-Path Closure . . . . . . . . . . . . 145 Das Expires 4 April 2027 [Page 9] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.4.40. E04.40 Agent Non-Authority Invariant . . . . . . . . 145 A.4.41. E04.41 Required Invariants . . . . . . . . . . . . . 145 A.5. E05 — Verified Demonstration Effect, Automatic Protected Decision, Then Receipt-Gated Continuation . . . . . . . 146 A.5.1. E05.1 Purpose . . . . . . . . . . . . . . . . . . . . 146 A.5.2. E05.2 Automatic Does Not Mean Unprotected . . . . . . 146 A.5.3. E05.3 Automatic Decision Authority . . . . . . . . . 147 A.5.4. E05.4 Inputs to Automatic Decision . . . . . . . . . 147 A.5.5. E05.5 Automatic Predicate Set . . . . . . . . . . . . 148 A.5.6. E05.6 Deterministic Automatic Decision . . . . . . . 149 A.5.7. E05.7 Multi-State Automatic Decision . . . . . . . . 149 A.5.8. E05.8 Automatic Decision Record . . . . . . . . . . . 150 A.5.9. E05.9 Automatic Decision Cryptographic Binding . . . 150 A.5.10. E05.10 Independence from Agent-Controlled State . . . 151 A.5.11. E05.11 Model-Assisted Evidence Without Model Authority . . . . . . . . . . . . . . . . . . . . . . 151 A.5.12. E05.12 Receipt Validation . . . . . . . . . . . . . . 151 A.5.13. E05.13 Automatic Next-Phase Predicate . . . . . . . . 152 A.5.14. E05.14 Receipt-Plus-Automatic-Decision Key Derivation . . . . . . . . . . . . . . . . . . . . . 152 A.5.15. E05.15 Internal Protected State Variation . . . . . . 152 A.5.16. E05.16 Low-Latency Hot-Path Variation . . . . . . . . 152 A.5.17. E05.17 Preauthorized Automatic Envelope . . . . . . . 153 A.5.18. E05.18 Risk-Adaptive Automatic Progression . . . . . 153 A.5.19. E05.19 Receipt-Quality-Adaptive Progression . . . . . 154 A.5.20. E05.20 Error-Rate-Controlled Rollout . . . . . . . . 154 A.5.21. E05.21 Automatic Communication Embodiment . . . . . . 154 A.5.22. E05.22 Automatic Payment Embodiment . . . . . . . . . 154 A.5.23. E05.23 Automatic Hardware Embodiment . . . . . . . . 154 A.5.24. E05.24 Automatic Telecom Embodiment . . . . . . . . . 155 A.5.25. E05.25 Automatic Cloud Rollout Embodiment . . . . . . 155 A.5.26. E05.26 Automatic Credential Escalation . . . . . . . 155 A.5.27. E05.27 Automatic Denial and Safe-Limited Outcome . . 155 A.5.28. E05.28 Indeterminate Prior Effect . . . . . . . . . . 156 A.5.29. E05.29 Reconciliation Before Automatic Retry . . . . 156 A.5.30. E05.30 Automatic Decision Freshness . . . . . . . . . 156 A.5.31. E05.31 Automatic Decision Consumption . . . . . . . . 157 A.5.32. E05.32 Hardware ACA . . . . . . . . . . . . . . . . . 157 A.5.33. E05.33 Distributed ACA . . . . . . . . . . . . . . . 157 A.5.34. E05.34 Policy Rollback Protection . . . . . . . . . . 157 A.5.35. E05.35 Alternate-Path Closure . . . . . . . . . . . . 157 A.5.36. E05.36 Required Invariants . . . . . . . . . . . . . 158 A.6. E06 — Hybrid Human and Automatic Receipt-Gated Continuation . . . . . . . . . . . . . . . . . . . . . . 158 A.6.1. E06.1 Purpose . . . . . . . . . . . . . . . . . . . . 158 A.6.2. E06.2 Inheritance from E04 and E05 . . . . . . . . . 159 A.6.3. E06.3 Conjunctive Hybrid Approval . . . . . . . . . . 159 A.6.4. E06.4 Representative Conjunctive Predicate . . . . . 160 Das Expires 4 April 2027 [Page 10] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.6.5. E06.5 Automatic-First, Human-Second Sequence . . . . 160 A.6.6. E06.6 Human-First, Automatic-Second Sequence . . . . 160 A.6.7. E06.7 Parallel Human and Automatic Decisions . . . . 160 A.6.8. E06.8 Disjunctive Hybrid Approval . . . . . . . . . . 160 A.6.9. E06.9 Threshold-Based Approval . . . . . . . . . . . 161 A.6.10. E06.10 Role-Separated Hybrid Approval . . . . . . . . 161 A.6.11. E06.11 Human Cannot Override Certain Automatic Denials . . . . . . . . . . . . . . . . . . . . . . . 161 A.6.12. E06.12 Automatic Authority Cannot Fabricate Human Approval . . . . . . . . . . . . . . . . . . . . . . 162 A.6.13. E06.13 Human Scope Reduction . . . . . . . . . . . . 162 A.6.14. E06.14 Automatic Scope Reduction . . . . . . . . . . 162 A.6.15. E06.15 Conflict State . . . . . . . . . . . . . . . . 162 A.6.16. E06.16 Escalation from Automatic to Human . . . . . . 163 A.6.17. E06.17 Escalation from Human to Additional Automatic Verification . . . . . . . . . . . . . . . . . . . . 163 A.6.18. E06.18 Human Veto over Automatic Continuation . . . . 163 A.6.19. E06.19 Automatic Veto over Human Approval . . . . . . 164 A.6.20. E06.20 Two-Key Hybrid Authority . . . . . . . . . . . 164 A.6.21. E06.21 Threshold-Key Hybrid Authority . . . . . . . . 164 A.6.22. E06.22 Receipt + Human + Automatic Cryptographic Binding . . . . . . . . . . . . . . . . . . . . . . . 164 A.6.23. E06.23 Hybrid Protected State Machine . . . . . . . . 165 A.6.24. E06.24 Human Approval Expiry and Automatic Decision Expiry . . . . . . . . . . . . . . . . . . . . . . . 165 A.6.25. E06.25 Policy Change During Hybrid Approval . . . . . 165 A.6.26. E06.26 Revocation During Hybrid Approval . . . . . . 165 A.6.27. E06.27 Consumption of Hybrid Artifacts . . . . . . . 166 A.6.28. E06.28 Partial Consumption and Crash Recovery . . . . 166 A.6.29. E06.29 Human-Optional Hybrid Mode . . . . . . . . . . 166 A.6.30. E06.30 Risk-Threshold Hybrid Mode . . . . . . . . . . 167 A.6.31. E06.31 Consequence-Threshold Hybrid Mode . . . . . . 167 A.6.32. E06.32 Taint / Provenance Hybrid Mode . . . . . . . . 167 A.6.33. E06.33 Multi-Human + Automatic Hybrid . . . . . . . . 168 A.6.34. E06.34 Multi-Automatic + Human Hybrid . . . . . . . . 168 A.6.35. E06.35 Communication Embodiment . . . . . . . . . . . 168 A.6.36. E06.36 Payment Embodiment . . . . . . . . . . . . . . 168 A.6.37. E06.37 Hardware / Robotics Embodiment . . . . . . . . 168 A.6.38. E06.38 Cloud / Infrastructure Embodiment . . . . . . 169 A.6.39. E06.39 Telecom Embodiment . . . . . . . . . . . . . . 169 A.6.40. E06.40 Destination-Side Hybrid Enforcement . . . . . 169 A.6.41. E06.41 Hardware-Rooted Hybrid Enforcement . . . . . . 169 A.6.42. E06.42 Distributed Hybrid PED . . . . . . . . . . . . 170 A.6.43. E06.43 Fail-Closed and Fail-Limited Hybrid Behavior . . . . . . . . . . . . . . . . . . . . . . 170 A.6.44. E06.44 Alternate-Path Closure . . . . . . . . . . . . 171 A.6.45. E06.45 Required Invariants . . . . . . . . . . . . . 171 A.7. E07 — Software Protected Enforcement Domain . . . . . . . 177 Das Expires 4 April 2027 [Page 11] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.7.1. E07.1 Purpose . . . . . . . . . . . . . . . . . . . . 177 A.7.2. E07.2 Software PED Functional Boundary . . . . . . . 177 A.7.3. E07.3 Candidate Act Intake . . . . . . . . . . . . . 179 A.7.4. E07.4 Caller Attribution . . . . . . . . . . . . . . 179 A.7.5. E07.5 Protected Software State . . . . . . . . . . . 180 A.7.6. E07.6 Software Validation Predicate . . . . . . . . . 181 A.7.7. E07.7 Automatic Approval Integration . . . . . . . . 181 A.7.8. E07.8 Human Approval Integration . . . . . . . . . . 181 A.7.9. E07.9 Hybrid Approval Integration . . . . . . . . . . 181 A.7.10. E07.10 Scoped Software Capability . . . . . . . . . . 182 A.7.11. E07.11 Capability Without Exposed Token . . . . . . . 182 A.7.12. E07.12 Credential Brokerage . . . . . . . . . . . . . 183 A.7.13. E07.13 Late Credential Injection . . . . . . . . . . 183 A.7.14. E07.14 Network Egress Gate . . . . . . . . . . . . . 183 A.7.15. E07.15 Kernel-Level Software Gate . . . . . . . . . . 184 A.7.16. E07.16 eBPF / Security-Hook Variation . . . . . . . . 184 A.7.17. E07.17 LSM / Mandatory-Access-Control Variation . . . 185 A.7.18. E07.18 Proxy-Based Effectuation Gate . . . . . . . . 185 A.7.19. E07.19 Database Gate . . . . . . . . . . . . . . . . 186 A.7.20. E07.20 Storage Gate . . . . . . . . . . . . . . . . . 186 A.7.21. E07.21 Message-Broker Gate . . . . . . . . . . . . . 186 A.7.22. E07.22 Transaction Manager Variation . . . . . . . . 187 A.7.23. E07.23 Remote Software PED . . . . . . . . . . . . . 187 A.7.24. E07.24 Software Attestation Input . . . . . . . . . . 187 A.7.25. E07.25 Receipt Generation in Software . . . . . . . . 187 A.7.26. E07.26 Durable Software State . . . . . . . . . . . . 188 A.7.27. E07.27 Crash Recovery . . . . . . . . . . . . . . . . 188 A.7.28. E07.28 Software Rollback Resistance . . . . . . . . . 188 A.7.29. E07.29 Alternate-Path Closure . . . . . . . . . . . . 189 A.7.30. E07.30 Software PED Fail-Closed Mode . . . . . . . . 189 A.7.31. E07.31 Software PED Fail-Limited Mode . . . . . . . . 189 A.7.32. E07.32 SEND Example . . . . . . . . . . . . . . . . . 190 A.7.33. E07.33 Payment Example . . . . . . . . . . . . . . . 190 A.7.34. E07.34 Required Invariants . . . . . . . . . . . . . 191 A.8. E08 — Hardware Protected Enforcement Domain . . . . . . . 191 A.8.1. E08.1 Purpose . . . . . . . . . . . . . . . . . . . . 191 A.8.2. E08.2 Hardware PED Components . . . . . . . . . . . . 191 A.8.3. E08.3 Hardware Root of Authority . . . . . . . . . . 193 A.8.4. E08.4 Hardware Protected State . . . . . . . . . . . 193 A.8.5. E08.5 Hardware Identity . . . . . . . . . . . . . . . 193 A.8.6. E08.6 Platform Measurement . . . . . . . . . . . . . 194 A.8.7. E08.7 Hardware Attestation . . . . . . . . . . . . . 194 A.8.8. E08.8 Hardware Validation Predicate . . . . . . . . . 195 A.8.9. E08.9 Hardware Phase Key . . . . . . . . . . . . . . 195 A.8.10. E08.10 Receipt-Derived Hardware Key . . . . . . . . . 195 A.8.11. E08.11 Hardware Unsealing Variation . . . . . . . . . 195 A.8.12. E08.12 Protected Hardware Latch . . . . . . . . . . . 196 A.8.13. E08.13 Monotonic Counter . . . . . . . . . . . . . . 196 Das Expires 4 April 2027 [Page 12] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.8.14. E08.14 Secure-Element Embodiment . . . . . . . . . . 196 A.8.15. E08.15 HSM Embodiment . . . . . . . . . . . . . . . . 197 A.8.16. E08.16 TEE / Secure-Enclave Embodiment . . . . . . . 197 A.8.17. E08.17 DPU / SmartNIC Network Embodiment . . . . . . 197 A.8.18. E08.18 Storage-Controller Embodiment . . . . . . . . 198 A.8.19. E08.19 GPU / Accelerator Embodiment . . . . . . . . . 198 A.8.20. E08.20 Motor / Actuator Controller Embodiment . . . . 198 A.8.21. E08.21 Vehicle / Flight Controller Embodiment . . . . 198 A.8.22. E08.22 Radio / Baseband Embodiment . . . . . . . . . 199 A.8.23. E08.23 Hardware Human-Approval Verification . . . . . 199 A.8.24. E08.24 Hardware Automatic-Decision Verification . . . 200 A.8.25. E08.25 Hardware Receipt Generation . . . . . . . . . 200 A.8.26. E08.26 Hardware Receipt Verification . . . . . . . . 200 A.8.27. E08.27 Hardware Anti-Replay . . . . . . . . . . . . . 200 A.8.28. E08.28 Hardware Crash / Power-Loss Recovery . . . . . 201 A.8.29. E08.29 Hardware Rollback Protection . . . . . . . . . 201 A.8.30. E08.30 Hardware Alternate-Path Closure . . . . . . . 201 A.8.31. E08.31 Fail-Closed Hardware Mode . . . . . . . . . . 202 A.8.32. E08.32 Fail-Safe Physical Mode . . . . . . . . . . . 202 A.8.33. E08.33 SEND Example . . . . . . . . . . . . . . . . . 202 A.8.34. E08.34 Payment Example . . . . . . . . . . . . . . . 203 A.8.35. E08.35 Required Invariants . . . . . . . . . . . . . 203 A.9. E09 — Split Software/Hardware Protected Enforcement Domain . . . . . . . . . . . . . . . . . . . . . . . . . 203 A.9.1. E09.1 Purpose . . . . . . . . . . . . . . . . . . . . 203 A.9.2. E09.2 Functional Separation . . . . . . . . . . . . . 203 A.9.3. E09.3 Software Decision Record . . . . . . . . . . . 204 A.9.4. E09.4 Authorization Digest . . . . . . . . . . . . . 205 A.9.5. E09.5 Hardware Does Not Blindly Trust Software . . . 205 A.9.6. E09.6 Software Scope and Hardware Scope . . . . . . . 206 A.9.7. E09.7 Hardware Root Secret . . . . . . . . . . . . . 206 A.9.8. E09.8 Receipt-Gated Split Progression . . . . . . . . 206 A.9.9. E09.9 Software-First Receipt Verification . . . . . . 206 A.9.10. E09.10 Hardware-First Receipt Verification . . . . . 206 A.9.11. E09.11 Dual Verification . . . . . . . . . . . . . . 207 A.9.12. E09.12 Human Approval Split . . . . . . . . . . . . . 207 A.9.13. E09.13 Automatic Approval Split . . . . . . . . . . . 207 A.9.14. E09.14 Hybrid Approval Split . . . . . . . . . . . . 207 A.9.15. E09.15 Split Key Shares . . . . . . . . . . . . . . . 208 A.9.16. E09.16 Software Cannot Use Hardware Share for Another Act . . . . . . . . . . . . . . . . . . . . . . . . . 208 A.9.17. E09.17 Hardware Cannot Independently Expand Software Policy . . . . . . . . . . . . . . . . . . . . . . . 208 A.9.18. E09.18 Split Transaction Atomicity . . . . . . . . . 209 A.9.19. E09.19 Two-Record Commit Variation . . . . . . . . . 209 A.9.20. E09.20 Hardware Receipt of Software State . . . . . . 209 A.9.21. E09.21 Software Receipt of Hardware State . . . . . . 209 A.9.22. E09.22 Local Split Embodiment . . . . . . . . . . . . 210 Das Expires 4 April 2027 [Page 13] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.9.23. E09.23 Remote Hardware Split Embodiment . . . . . . . 210 A.9.24. E09.24 DPU Split Embodiment . . . . . . . . . . . . . 210 A.9.25. E09.25 Storage Split Embodiment . . . . . . . . . . . 210 A.9.26. E09.26 Payment Split Embodiment . . . . . . . . . . . 210 A.9.27. E09.27 SEND Split Embodiment . . . . . . . . . . . . 210 A.9.28. E09.28 Robotics Split Embodiment . . . . . . . . . . 211 A.9.29. E09.29 Cloud/Accelerator Split Embodiment . . . . . . 211 A.9.30. E09.30 Software Compromise Scenario . . . . . . . . . 211 A.9.31. E09.31 Hardware Compromise / Failure Containment . . 212 A.9.32. E09.32 Version and Upgrade Binding . . . . . . . . . 212 A.9.33. E09.33 Revocation Synchronization . . . . . . . . . . 212 A.9.34. E09.34 Policy Synchronization . . . . . . . . . . . . 212 A.9.35. E09.35 Split Anti-Rollback . . . . . . . . . . . . . 212 A.9.36. E09.36 Alternate-Path Closure . . . . . . . . . . . . 213 A.9.37. E09.37 Fail-Closed Split Rule . . . . . . . . . . . . 213 A.9.38. E09.38 Fail-Limited Split Rule . . . . . . . . . . . 213 A.9.39. E09.39 Indeterminate Split State . . . . . . . . . . 214 A.9.40. E09.40 Completion Receipt . . . . . . . . . . . . . . 214 A.9.41. E09.41 Required Invariants . . . . . . . . . . . . . 214 A.10. E10 — Receipt-Conditioned Hardware Cryptographic Key-Chain Effectuation . . . . . . . . . . . . . . . . . . . . . . 220 A.10.1. E10.1 Purpose . . . . . . . . . . . . . . . . . . . 220 A.10.2. E10.2 Hardware Root of Authority . . . . . . . . . . 220 A.10.3. E10.3 Candidate Act Binding . . . . . . . . . . . . 221 A.10.4. E10.4 Initial Phase Authority . . . . . . . . . . . 221 A.10.5. E10.5 Narrow Phase Scope . . . . . . . . . . . . . . 222 A.10.6. E10.6 Phase-0 Verification at Hardware Boundary . . 222 A.10.7. E10.7 Real Initial Effect . . . . . . . . . . . . . 223 A.10.8. E10.8 Receipt Acquisition . . . . . . . . . . . . . 223 A.10.9. E10.9 Hardware Receipt Validation . . . . . . . . . 223 A.10.10. E10.10 Receipt-Conditioned Key Derivation . . . . . 223 A.10.11. E10.11 Receipt-Conditioned Unsealing Variation . . . 224 A.10.12. E10.12 Wrapped-Key Variation . . . . . . . . . . . . 224 A.10.13. E10.13 Hardware Latch Coupling . . . . . . . . . . . 224 A.10.14. E10.14 Monotonic Phase State . . . . . . . . . . . . 225 A.10.15. E10.15 Atomic Receipt Consumption and State Advance . . . . . . . . . . . . . . . . . . . . . . . 225 A.10.16. E10.16 Key Separation Across Phases . . . . . . . . 225 A.10.17. E10.17 Compromise Containment . . . . . . . . . . . 225 A.10.18. E10.18 Key Zeroization . . . . . . . . . . . . . . . 226 A.10.19. E10.19 Human Approval Integration . . . . . . . . . 226 A.10.20. E10.20 Automatic Approval Integration . . . . . . . 226 A.10.21. E10.21 Hybrid Approval Integration . . . . . . . . . 226 A.10.22. E10.22 Single-Phase Compatibility . . . . . . . . . 227 A.10.23. E10.23 Multi-Phase Key Chain . . . . . . . . . . . . 227 A.10.24. E10.24 Entire-History Binding Variation . . . . . . 227 A.10.25. E10.25 Multiple-Sink Variation . . . . . . . . . . . 227 A.10.26. E10.26 Device-Bound Variation . . . . . . . . . . . 227 Das Expires 4 April 2027 [Page 14] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.10.27. E10.27 SEND Example . . . . . . . . . . . . . . . . 228 A.10.28. E10.28 Payment Example . . . . . . . . . . . . . . . 228 A.10.29. E10.29 Actuator Example . . . . . . . . . . . . . . 228 A.10.30. E10.30 Network / SmartNIC Example . . . . . . . . . 228 A.10.31. E10.31 Storage Controller Example . . . . . . . . . 228 A.10.32. E10.32 Policy Epoch Change . . . . . . . . . . . . . 229 A.10.33. E10.33 Revocation Between Key Stages . . . . . . . . 229 A.10.34. E10.34 Receipt Replay Protection . . . . . . . . . . 229 A.10.35. E10.35 Rollback Protection . . . . . . . . . . . . . 229 A.10.36. E10.36 Crash and Power-Loss Recovery . . . . . . . . 230 A.10.37. E10.37 Invalid Receipt Handling . . . . . . . . . . 230 A.10.38. E10.38 Root-Key Rotation . . . . . . . . . . . . . . 231 A.10.39. E10.39 Anti-Bypass Requirement . . . . . . . . . . . 231 A.10.40. E10.40 Completion Evidence . . . . . . . . . . . . . 231 A.10.41. E10.41 Required Invariants . . . . . . . . . . . . . 232 A.11. E11 — Threshold / Multi-Party Cryptographic Continuation . . . . . . . . . . . . . . . . . . . . . . 232 A.11.1. E11.1 Purpose . . . . . . . . . . . . . . . . . . . 232 A.11.2. E11.2 Participant Set . . . . . . . . . . . . . . . 232 A.11.3. E11.3 Threshold Rule . . . . . . . . . . . . . . . . 233 A.11.4. E11.4 Distinction from Receipt Quorum . . . . . . . 233 A.11.5. E11.5 Per-Phase Authority Share . . . . . . . . . . 234 A.11.6. E11.6 Share Binding . . . . . . . . . . . . . . . . 234 A.11.7. E11.7 Receipt-Conditioned Share Release . . . . . . 234 A.11.8. E11.8 Local Independent Validation . . . . . . . . . 235 A.11.9. E11.9 Authority Contribution Set . . . . . . . . . . 235 A.11.10. E11.10 Mandatory-Participant Variation . . . . . . . 235 A.11.11. E11.11 Combined Continuation Authority . . . . . . . 235 A.11.12. E11.12 No-Reconstruction Variation . . . . . . . . . 236 A.11.13. E11.13 Human Share Variation . . . . . . . . . . . . 236 A.11.14. E11.14 Automatic Authority Share . . . . . . . . . . 237 A.11.15. E11.15 Hardware Share . . . . . . . . . . . . . . . 237 A.11.16. E11.16 Destination Share . . . . . . . . . . . . . . 237 A.11.17. E11.17 Sink Share . . . . . . . . . . . . . . . . . 238 A.11.18. E11.18 Phase-Specific Threshold . . . . . . . . . . 238 A.11.19. E11.19 Risk-Adaptive Threshold . . . . . . . . . . . 238 A.11.20. E11.20 Role-Constrained Threshold . . . . . . . . . 238 A.11.21. E11.21 Geographic / Jurisdictional Split . . . . . . 238 A.11.22. E11.22 Multi-Organization Split . . . . . . . . . . 239 A.11.23. E11.23 SEND Workflow . . . . . . . . . . . . . . . . 239 A.11.24. E11.24 Payment Workflow . . . . . . . . . . . . . . 239 A.11.25. E11.25 Robotic / Industrial Workflow . . . . . . . . 239 A.11.26. E11.26 Threshold Key Release . . . . . . . . . . . . 240 A.11.27. E11.27 Threshold Signature Variation . . . . . . . . 240 A.11.28. E11.28 Multi-Signature Variation . . . . . . . . . . 240 A.11.29. E11.29 Share Freshness . . . . . . . . . . . . . . . 240 A.11.30. E11.30 Share Replay Protection . . . . . . . . . . . 240 A.11.31. E11.31 Participant Revocation . . . . . . . . . . . 240 Das Expires 4 April 2027 [Page 15] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.11.32. E11.32 Dynamic Membership . . . . . . . . . . . . . 241 A.11.33. E11.33 Re-Sharing / Key Rotation . . . . . . . . . . 241 A.11.34. E11.34 Participant Failure . . . . . . . . . . . . . 241 A.11.35. E11.35 Conflicting Participant Decisions . . . . . . 241 A.11.36. E11.36 Human Veto Variation . . . . . . . . . . . . 242 A.11.37. E11.37 Indeterminate Receipt Before Threshold . . . 242 A.11.38. E11.38 Share Confidentiality . . . . . . . . . . . . 242 A.11.39. E11.39 Collusion Consideration . . . . . . . . . . . 242 A.11.40. E11.40 Alternate-Path Closure . . . . . . . . . . . 242 A.11.41. E11.41 Completion Receipt . . . . . . . . . . . . . 243 A.11.42. E11.42 Required Invariants . . . . . . . . . . . . . 243 A.12. E12 — Message-SEND Demonstration / Trailer-Then-Full Effectuation . . . . . . . . . . . . . . . . . . . . . . 243 A.12.1. E12.1 Purpose . . . . . . . . . . . . . . . . . . . 243 A.12.2. E12.2 Communication Candidate Act . . . . . . . . . 244 A.12.3. E12.3 Full Communication Object . . . . . . . . . . 244 A.12.4. E12.4 Bounded Trailer Object . . . . . . . . . . . . 245 A.12.5. E12.5 Real SEND Requirement . . . . . . . . . . . . 245 A.12.6. E12.6 Full-Payload Commitment . . . . . . . . . . . 246 A.12.7. E12.7 Trailer Descriptor . . . . . . . . . . . . . . 246 A.12.8. E12.8 Recipient Binding . . . . . . . . . . . . . . 247 A.12.9. E12.9 Account and Device Binding . . . . . . . . . . 247 A.12.10. E12.10 Phase-0 SEND Authority . . . . . . . . . . . 247 A.12.11. E12.11 Egress Boundary Verification . . . . . . . . 248 A.12.12. E12.12 Trailer Transmission . . . . . . . . . . . . 248 A.12.13. E12.13 Recipient Processing . . . . . . . . . . . . 249 A.12.14. E12.14 Recipient Effect Confirmation Receipt . . . . 249 A.12.15. E12.15 Receipt Authentication . . . . . . . . . . . 250 A.12.16. E12.16 Receipt Verification . . . . . . . . . . . . 250 A.12.17. E12.17 Wrong-Recipient Receipt . . . . . . . . . . . 250 A.12.18. E12.18 Human Review After Trailer . . . . . . . . . 251 A.12.19. E12.19 Automatic Continuation After Trailer . . . . 251 A.12.20. E12.20 Hybrid Continuation . . . . . . . . . . . . . 251 A.12.21. E12.21 Trailer-Then-Full Payload Variation . . . . . 251 A.12.22. E12.22 Trailer-Then-Phased Payload Variation . . . . 252 A.12.23. E12.23 Ciphertext-First Variation . . . . . . . . . 252 A.12.24. E12.24 Partial-Decryption Trailer Variation . . . . 252 A.12.25. E12.25 Key-Chain SEND Variation . . . . . . . . . . 252 A.12.26. E12.26 Threshold SEND Variation . . . . . . . . . . 253 A.12.27. E12.27 File Attachment Variation . . . . . . . . . . 253 A.12.28. E12.28 Link / Object-Store Variation . . . . . . . . 253 A.12.29. E12.29 Multi-Recipient Variation . . . . . . . . . . 254 A.12.30. E12.30 Recipient-Specific Semantic Release . . . . . 254 A.12.31. E12.31 Group / Distribution-List Variation . . . . . 254 A.12.32. E12.32 Thread / Conversation Binding . . . . . . . . 254 A.12.33. E12.33 Reply-Path Verification . . . . . . . . . . . 254 A.12.34. E12.34 Protocol-Downgrade Protection . . . . . . . . 255 A.12.35. E12.35 Content Substitution Protection . . . . . . . 255 Das Expires 4 April 2027 [Page 16] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.12.36. E12.36 Attachment Substitution Protection . . . . . 255 A.12.37. E12.37 Recipient Redirection Protection . . . . . . 255 A.12.38. E12.38 Expiry and Stale Receipt . . . . . . . . . . 255 A.12.39. E12.39 Revocation Between Trailer and Full SEND . . 256 A.12.40. E12.40 Destination-State Change . . . . . . . . . . 256 A.12.41. E12.41 Crash After Trailer SEND . . . . . . . . . . 256 A.12.42. E12.42 Duplicate Full-SEND Protection . . . . . . . 256 A.12.43. E12.43 Indeterminate Full SEND . . . . . . . . . . . 256 A.12.44. E12.44 Negative Receipt . . . . . . . . . . . . . . 257 A.12.45. E12.45 Privacy-Preserving Trailer . . . . . . . . . 257 A.12.46. E12.46 Sensitive-Content Variation . . . . . . . . . 258 A.12.47. E12.47 Low-Risk Message Variation . . . . . . . . . 258 A.12.48. E12.48 Hardware-Enforced SEND . . . . . . . . . . . 258 A.12.49. E12.49 Software-Enforced SEND . . . . . . . . . . . 258 A.12.50. E12.50 Split Software/Hardware SEND . . . . . . . . 258 A.12.51. E12.51 Telecom / Radio SEND Variation . . . . . . . 258 A.12.52. E12.52 Machine-to-Machine SEND . . . . . . . . . . . 259 A.12.53. E12.53 SEND Versus Payment Analogy . . . . . . . . . 259 A.12.54. E12.54 Anti-Bypass Requirement . . . . . . . . . . . 259 A.12.55. E12.55 Completion Receipt . . . . . . . . . . . . . 260 A.12.56. E12.56 Required Invariants . . . . . . . . . . . . . 260 A.13. E13 — Receipt-Gated File Transfer and Progressive File Release . . . . . . . . . . . . . . . . . . . . . . . . 265 A.13.1. E13.1 Purpose . . . . . . . . . . . . . . . . . . . 266 A.13.2. E13.2 File Candidate Act . . . . . . . . . . . . . . 266 A.13.3. E13.3 Full File Object and Authorized Envelope . . . 267 A.13.4. E13.4 File Manifest . . . . . . . . . . . . . . . . 267 A.13.5. E13.5 Transfer Session Binding . . . . . . . . . . . 268 A.13.6. E13.6 Selection of File-Release Mode . . . . . . . . 268 A.13.7. E13.7 Bounded File Effect . . . . . . . . . . . . . 269 A.13.8. E13.8 Segment Representation . . . . . . . . . . . . 270 A.13.9. E13.9 Trial Segment Descriptor . . . . . . . . . . . 270 A.13.10. E13.10 Initial File Authority . . . . . . . . . . . 270 A.13.11. E13.11 Real Transfer Through Intended Path . . . . . 271 A.13.12. E13.12 Destination-Side Processing . . . . . . . . . 271 A.13.13. E13.13 File Effect Receipt . . . . . . . . . . . . . 272 A.13.14. E13.14 Receipt Semantics . . . . . . . . . . . . . . 272 A.13.15. E13.15 File Receipt Verification . . . . . . . . . . 273 A.13.16. E13.16 Human Continuation Variation . . . . . . . . 273 A.13.17. E13.17 Automatic Continuation Variation . . . . . . 274 A.13.18. E13.18 Hybrid Continuation Variation . . . . . . . . 274 A.13.19. E13.19 Progressive Chunk Transfer . . . . . . . . . 274 A.13.20. E13.20 Chunk-Chain Binding . . . . . . . . . . . . . 274 A.13.21. E13.21 Merkle-Root Variation . . . . . . . . . . . . 274 A.13.22. E13.22 Ciphertext-First File Transfer . . . . . . . 274 A.13.23. E13.23 Semantic File Release . . . . . . . . . . . . 275 A.13.24. E13.24 Partial Decryption Variation . . . . . . . . 275 A.13.25. E13.25 Staged Storage Promotion . . . . . . . . . . 275 Das Expires 4 April 2027 [Page 17] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.13.26. E13.26 Promotion Receipt . . . . . . . . . . . . . . 276 A.13.27. E13.27 File-Type Transformation Variation . . . . . 276 A.13.28. E13.28 Deduplication Variation . . . . . . . . . . . 277 A.13.29. E13.29 Sparse or Range-Based File Variation . . . . 277 A.13.30. E13.30 Resume After Interruption . . . . . . . . . . 277 A.13.31. E13.31 Crash After Chunk Commit . . . . . . . . . . 278 A.13.32. E13.32 Receipt Loss . . . . . . . . . . . . . . . . 278 A.13.33. E13.33 Wrong-Recipient Protection . . . . . . . . . 278 A.13.34. E13.34 Wrong-File Protection . . . . . . . . . . . . 278 A.13.35. E13.35 Versioned Object Variation . . . . . . . . . 278 A.13.36. E13.36 Multi-File Bundle Variation . . . . . . . . . 278 A.13.37. E13.37 Multi-Recipient File Release . . . . . . . . 279 A.13.38. E13.38 Recipient-Specific Keys . . . . . . . . . . . 279 A.13.39. E13.39 Network and Storage Split Enforcement . . . . 279 A.13.40. E13.40 Hardware Enforcement Variation . . . . . . . 279 A.13.41. E13.41 Software Enforcement Variation . . . . . . . 280 A.13.42. E13.42 Alternative-Path Closure . . . . . . . . . . 280 A.13.43. E13.43 Indeterminate File State . . . . . . . . . . 281 A.13.44. E13.44 Completion Receipt . . . . . . . . . . . . . 281 A.13.45. E13.45 Required Invariants . . . . . . . . . . . . . 281 A.14. E14 — Payment Demonstration and Receipt-Gated Full / Progressive Payment . . . . . . . . . . . . . . . . . . 282 A.14.1. E14.1 Purpose . . . . . . . . . . . . . . . . . . . 282 A.14.2. E14.2 Rail-Dependent Operation . . . . . . . . . . . 282 A.14.3. E14.3 Full Intended Payment . . . . . . . . . . . . 282 A.14.4. E14.4 Payment Descriptor . . . . . . . . . . . . . . 283 A.14.5. E14.5 Payment Identifier . . . . . . . . . . . . . . 283 A.14.6. E14.6 Selection of Payment Mode . . . . . . . . . . 283 A.14.7. E14.7 Bounded Trial Value . . . . . . . . . . . . . 284 A.14.8. E14.8 Non-Monetary Trial State . . . . . . . . . . . 284 A.14.9. E14.9 Trial Payment Authority . . . . . . . . . . . 284 A.14.10. E14.10 Binding to Beneficiary and Asset . . . . . . 285 A.14.11. E14.11 Real Payment-Rail Effect . . . . . . . . . . 285 A.14.12. E14.12 Payment Effect Observer . . . . . . . . . . . 285 A.14.13. E14.13 Payment Effect Receipt . . . . . . . . . . . 286 A.14.14. E14.14 Payment Receipt Status . . . . . . . . . . . 286 A.14.15. E14.15 Receipt Verification . . . . . . . . . . . . 287 A.14.16. E14.16 Human Approval After Demonstration . . . . . 287 A.14.17. E14.17 Automatic Continuation . . . . . . . . . . . 288 A.14.18. E14.18 Hybrid Continuation . . . . . . . . . . . . . 288 A.14.19. E14.19 Full Payment Continuation Authority . . . . . 288 A.14.20. E14.20 Receipt-Conditioned Payment Key . . . . . . . 289 A.14.21. E14.21 Progressive Payment Phases . . . . . . . . . 289 A.14.22. E14.22 Cumulative Payment Bound . . . . . . . . . . 289 A.14.23. E14.23 Dynamic Phase Amount . . . . . . . . . . . . 289 A.14.24. E14.24 Authorization-Then-Capture Variation . . . . 290 A.14.25. E14.25 Reservation / Hold Variation . . . . . . . . 290 A.14.26. E14.26 Small Verification Transfer Variation . . . . 290 Das Expires 4 April 2027 [Page 18] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.14.27. E14.27 Refund / Reversal Variation . . . . . . . . . 290 A.14.28. E14.28 Fee-Aware Staging . . . . . . . . . . . . . . 291 A.14.29. E14.29 Currency and Asset Binding . . . . . . . . . 291 A.14.30. E14.30 Foreign-Exchange Variation . . . . . . . . . 291 A.14.31. E14.31 Recurring Payment Variation . . . . . . . . . 291 A.14.32. E14.32 Batch Payment Variation . . . . . . . . . . . 292 A.14.33. E14.33 Beneficiary Confirmation Variation . . . . . 292 A.14.34. E14.34 Payment Idempotency . . . . . . . . . . . . . 292 A.14.35. E14.35 Crash After Financial Effect . . . . . . . . 292 A.14.36. E14.36 Indeterminate Payment State . . . . . . . . . 293 A.14.37. E14.37 Proven-Effected Reconciliation . . . . . . . 293 A.14.38. E14.38 Proven-Not-Effected Reconciliation . . . . . 293 A.14.39. E14.39 Settlement-Finality Awareness . . . . . . . . 293 A.14.40. E14.40 Payment State Machine . . . . . . . . . . . . 293 A.14.41. E14.41 Hardware Payment Enforcement . . . . . . . . 294 A.14.42. E14.42 Software Payment Enforcement . . . . . . . . 294 A.14.43. E14.43 Split Software / Hardware Payment Enforcement . . . . . . . . . . . . . . . . . . . . . 294 A.14.44. E14.44 Threshold Payment Continuation . . . . . . . 294 A.14.45. E14.45 Revocation Between Payment Phases . . . . . . 294 A.14.46. E14.46 Risk Change Between Payment Phases . . . . . 294 A.14.47. E14.47 Alternative-Path Closure . . . . . . . . . . 295 A.14.48. E14.48 Full Payment Receipt . . . . . . . . . . . . 295 A.14.49. E14.49 Required Invariants . . . . . . . . . . . . . 295 A.15. E15 — Escrow / Conditional Settlement and Receipt-Gated Release . . . . . . . . . . . . . . . . . . . . . . . . 296 A.15.1. E15.1 Purpose . . . . . . . . . . . . . . . . . . . 296 A.15.2. E15.2 Core Relationship . . . . . . . . . . . . . . 296 A.15.3. E15.3 Conditional Holding Object . . . . . . . . . . 296 A.15.4. E15.4 Escrow / Holding Identifier . . . . . . . . . 297 A.15.5. E15.5 Holding Descriptor . . . . . . . . . . . . . . 297 A.15.6. E15.6 Release Condition Set . . . . . . . . . . . . 298 A.15.7. E15.7 Condition Semantics . . . . . . . . . . . . . 298 A.15.8. E15.8 Real Holding Effect . . . . . . . . . . . . . 298 A.15.9. E15.9 Holding Receipt . . . . . . . . . . . . . . . 299 A.15.10. E15.10 No Release Before Holding Confirmation . . . 299 A.15.11. E15.11 Release Condition Evaluation . . . . . . . . 300 A.15.12. E15.12 Human Approval Condition . . . . . . . . . . 300 A.15.13. E15.13 Automatic Condition . . . . . . . . . . . . . 300 A.15.14. E15.14 Hybrid Release Condition . . . . . . . . . . 300 A.15.15. E15.15 Threshold Release Condition . . . . . . . . . 300 A.15.16. E15.16 Conditional Payment Escrow Variation . . . . 300 A.15.17. E15.17 Trial-Payment Then Holding Variation . . . . 300 A.15.18. E15.18 Holding Then Trial Release Variation . . . . 301 A.15.19. E15.19 Progressive Tranche Release . . . . . . . . . 301 A.15.20. E15.20 Cumulative Release Bound . . . . . . . . . . 301 A.15.21. E15.21 Release Authority Object . . . . . . . . . . 301 A.15.22. E15.22 Receipt-Conditioned Release Key . . . . . . . 301 Das Expires 4 April 2027 [Page 19] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.15.23. E15.23 Destination Binding . . . . . . . . . . . . . 302 A.15.24. E15.24 Asset Binding . . . . . . . . . . . . . . . . 302 A.15.25. E15.25 Expiry and Timeout . . . . . . . . . . . . . 302 A.15.26. E15.26 Refund Path . . . . . . . . . . . . . . . . . 302 A.15.27. E15.27 Refund Receipt . . . . . . . . . . . . . . . 302 A.15.28. E15.28 Cancellation Before Release . . . . . . . . . 303 A.15.29. E15.29 Revocation . . . . . . . . . . . . . . . . . 303 A.15.30. E15.30 Condition Change . . . . . . . . . . . . . . 303 A.15.31. E15.31 Delivery-Evidence Variation . . . . . . . . . 303 A.15.32. E15.32 Data-for-Payment Atomicity-Like Variation . . 303 A.15.33. E15.33 Key Escrow / Key-Holding Variation . . . . . 304 A.15.34. E15.34 Command Escrow Variation . . . . . . . . . . 304 A.15.35. E15.35 Storage-Promotion Holding Variation . . . . . 304 A.15.36. E15.36 Smart-Contract / Ledger Variation . . . . . . 304 A.15.37. E15.37 Bank / Custodial Service Variation . . . . . 305 A.15.38. E15.38 Multi-Party Holding Control . . . . . . . . . 305 A.15.39. E15.39 Dispute State . . . . . . . . . . . . . . . . 305 A.15.40. E15.40 Dispute Resolution Authority . . . . . . . . 305 A.15.41. E15.41 Split Settlement . . . . . . . . . . . . . . 306 A.15.42. E15.42 Hardware Enforcement . . . . . . . . . . . . 306 A.15.43. E15.43 Software Enforcement . . . . . . . . . . . . 306 A.15.44. E15.44 Split Software / Hardware Enforcement . . . . 306 A.15.45. E15.45 Condition-Evidence Commitment . . . . . . . . 306 A.15.46. E15.46 Crash After Release . . . . . . . . . . . . . 307 A.15.47. E15.47 Release Idempotency . . . . . . . . . . . . . 307 A.15.48. E15.48 Indeterminate Holding State . . . . . . . . . 307 A.15.49. E15.49 Reconciliation . . . . . . . . . . . . . . . 307 A.15.50. E15.50 Alternative-Path Closure . . . . . . . . . . 308 A.15.51. E15.51 Final Settlement Receipt . . . . . . . . . . 308 A.15.52. E15.52 Refund Completion Receipt . . . . . . . . . . 308 A.15.53. E15.53 Privacy-Preserving Condition Evidence . . . . 309 A.15.54. E15.54 Multi-Jurisdiction / Policy Variation . . . . 309 A.15.55. E15.55 Required Invariants . . . . . . . . . . . . . 309 A.16. E16 — Receipt-Gated Database Commit, Provisional Persistence, and Promotion . . . . . . . . . . . . . . . 316 A.16.1. E16.1 Purpose . . . . . . . . . . . . . . . . . . . 316 A.16.2. E16.2 Technical problem addressed . . . . . . . . . 316 A.16.3. E16.3 Functional components . . . . . . . . . . . . 317 A.16.4. E16.4 Proposed database mutation . . . . . . . . . . 317 A.16.5. E16.5 Baseline-state binding . . . . . . . . . . . . 319 A.16.6. E16.6 Selection of bounded persistence mode . . . . 319 A.16.7. E16.7 Provisional commit target . . . . . . . . . . 320 A.16.8. E16.8 Bounded mutation descriptor . . . . . . . . . 320 A.16.9. E16.9 Approval before provisional commit . . . . . . 321 A.16.10. E16.10 Phase-0 database authority . . . . . . . . . 322 A.16.11. E16.11 Real provisional persistence . . . . . . . . 322 A.16.12. E16.12 Persistence observation . . . . . . . . . . . 322 A.16.13. E16.13 Database Effect Confirmation Receipt . . . . 323 Das Expires 4 April 2027 [Page 20] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.16.14. E16.14 Receipt validation . . . . . . . . . . . . . 324 A.16.15. E16.15 Human review after provisional persistence . 324 A.16.16. E16.16 Automatic promotion decision . . . . . . . . 325 A.16.17. E16.17 Promotion authority . . . . . . . . . . . . . 325 A.16.18. E16.18 Promotion to production . . . . . . . . . . . 325 A.16.19. E16.19 Multi-phase database progression . . . . . . 326 A.16.20. E16.20 Atomic promotion variation . . . . . . . . . 326 A.16.21. E16.21 Optimistic concurrency variation . . . . . . 327 A.16.22. E16.22 Pessimistic/locked variation . . . . . . . . 327 A.16.23. E16.23 Trigger-aware variation . . . . . . . . . . . 327 A.16.24. E16.24 Replication-aware variation . . . . . . . . . 327 A.16.25. E16.25 Database schema migration variation . . . . . 327 A.16.26. E16.26 Vector database / AI memory variation . . . . 328 A.16.27. E16.27 Delete / destructive mutation variation . . . 328 A.16.28. E16.28 Database hardware-rooted variation . . . . . 328 A.16.29. E16.29 Crash before provisional commit . . . . . . . 329 A.16.30. E16.30 Crash after provisional commit but before receipt delivery . . . . . . . . . . . . . . . . . . 329 A.16.31. E16.31 Indeterminate database state . . . . . . . . 329 A.16.32. E16.32 Rollback and compensating transaction . . . . 329 A.16.33. E16.33 Anti-bypass closure . . . . . . . . . . . . . 330 A.16.34. E16.34 SEND analogue . . . . . . . . . . . . . . . . 330 A.16.35. E16.35 Payment analogue . . . . . . . . . . . . . . 330 A.16.36. E16.36 Required invariants . . . . . . . . . . . . . 331 A.17. E17 — Receipt-Gated Cloud Deployment and Progressive Infrastructure Rollout . . . . . . . . . . . . . . . . . 331 A.17.1. E17.1 Purpose . . . . . . . . . . . . . . . . . . . 331 A.17.2. E17.2 Deployment target model . . . . . . . . . . . 331 A.17.3. E17.3 Deployment descriptor . . . . . . . . . . . . 332 A.17.4. E17.4 Artifact integrity binding . . . . . . . . . . 333 A.17.5. E17.5 Initial trial target selection . . . . . . . . 333 A.17.6. E17.6 Protected approval before trial deployment . . 334 A.17.7. E17.7 Trial deployment authority . . . . . . . . . . 334 A.17.8. E17.8 Real trial deployment . . . . . . . . . . . . 335 A.17.9. E17.9 Installation versus exposure separation . . . 335 A.17.10. E17.10 Deployment health evidence . . . . . . . . . 335 A.17.11. E17.11 Health vector and protected predicate . . . . 336 A.17.12. E17.12 Deployment receipt . . . . . . . . . . . . . 337 A.17.13. E17.13 Automatic rollout continuation . . . . . . . 337 A.17.14. E17.14 Human rollout continuation . . . . . . . . . 338 A.17.15. E17.15 Hybrid rollout continuation . . . . . . . . . 338 A.17.16. E17.16 Fixed progressive rollout . . . . . . . . . . 338 A.17.17. E17.17 Adaptive rollout . . . . . . . . . . . . . . 338 A.17.18. E17.18 Cohort-isolated continuation . . . . . . . . 339 A.17.19. E17.19 Configuration-only rollout . . . . . . . . . 339 A.17.20. E17.20 Infrastructure-as-code variation . . . . . . 339 A.17.21. E17.21 Kubernetes/container orchestration variation . . . . . . . . . . . . . . . . . . . . . . 339 Das Expires 4 April 2027 [Page 21] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.17.22. E17.22 Virtual-machine variation . . . . . . . . . . 340 A.17.23. E17.23 Serverless variation . . . . . . . . . . . . 340 A.17.24. E17.24 Edge/fleet variation . . . . . . . . . . . . 340 A.17.25. E17.25 Hardware attestation variation . . . . . . . 340 A.17.26. E17.26 Network exposure as Finality Sink . . . . . . 341 A.17.27. E17.27 Credential-expansion variation . . . . . . . 341 A.17.28. E17.28 Database/storage dependency variation . . . . 341 A.17.29. E17.29 Rollback authority . . . . . . . . . . . . . 341 A.17.30. E17.30 Freeze-on-indeterminate rule . . . . . . . . 341 A.17.31. E17.31 Crash and recovery . . . . . . . . . . . . . 342 A.17.32. E17.32 Revocation during rollout . . . . . . . . . . 342 A.17.33. E17.33 Multi-region progression . . . . . . . . . . 342 A.17.34. E17.34 Quorum/aggregate health variation . . . . . . 342 A.17.35. E17.35 Anti-bypass closure . . . . . . . . . . . . . 342 A.17.36. E17.36 SEND analogue . . . . . . . . . . . . . . . . 343 A.17.37. E17.37 Payment analogue . . . . . . . . . . . . . . 343 A.17.38. E17.38 Required invariants . . . . . . . . . . . . . 343 A.18. E18 — Receipt-Gated AI Model Deployment, Model Activation, and Progressive Consequence Release . . . . . . . . . . 344 A.18.1. E18.1 Purpose . . . . . . . . . . . . . . . . . . . 344 A.18.2. E18.2 Core causal chain . . . . . . . . . . . . . . 344 A.18.3. E18.3 Model release object . . . . . . . . . . . . . 344 A.18.4. E18.4 Maximum model release envelope . . . . . . . . 346 A.18.5. E18.5 Bounded model cohort . . . . . . . . . . . . . 346 A.18.6. E18.6 Bounded consequence envelope . . . . . . . . . 347 A.18.7. E18.7 Trial model activation . . . . . . . . . . . . 347 A.18.8. E18.8 Protected model activation authority . . . . . 348 A.18.9. E18.9 Separation of inference from effectuation . . 348 A.18.10. E18.10 Runtime evidence collection . . . . . . . . . 349 A.18.11. E18.11 Model evidence vector . . . . . . . . . . . . 350 A.18.12. E18.12 Model deployment receipt . . . . . . . . . . 350 A.18.13. E18.13 Automatic model expansion . . . . . . . . . . 351 A.18.14. E18.14 Human model expansion . . . . . . . . . . . . 351 A.18.15. E18.15 Hybrid model expansion . . . . . . . . . . . 351 A.18.16. E18.16 Progressive user/tenant rollout . . . . . . . 352 A.18.17. E18.17 Progressive tool privilege rollout . . . . . 352 A.18.18. E18.18 Communication/SEND progression . . . . . . . 352 A.18.19. E18.19 Payment progression . . . . . . . . . . . . . 352 A.18.20. E18.20 Data-access progression . . . . . . . . . . . 353 A.18.21. E18.21 Connector progression . . . . . . . . . . . . 353 A.18.22. E18.22 Agentic workflow progression . . . . . . . . 353 A.18.23. E18.23 Model-routing variation . . . . . . . . . . . 353 A.18.24. E18.24 Shadow-model variation . . . . . . . . . . . 354 A.18.25. E18.25 Model-state / memory promotion . . . . . . . 354 A.18.26. E18.26 GPU/accelerator-rooted variation . . . . . . 354 A.18.27. E18.27 Model key-release variation . . . . . . . . . 354 A.18.28. E18.28 Tool credential withholding . . . . . . . . . 355 A.18.29. E18.29 Safety-policy epoch change . . . . . . . . . 355 Das Expires 4 April 2027 [Page 22] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.18.30. E18.30 Model revocation . . . . . . . . . . . . . . 355 A.18.31. E18.31 Rollback . . . . . . . . . . . . . . . . . . 355 A.18.32. E18.32 Indeterminate model phase . . . . . . . . . . 356 A.18.33. E18.33 Crash and recovery . . . . . . . . . . . . . 356 A.18.34. E18.34 Parallel model cohorts . . . . . . . . . . . 356 A.18.35. E18.35 Multi-model ensemble variation . . . . . . . 356 A.18.36. E18.36 Threshold evidence variation . . . . . . . . 356 A.18.37. E18.37 Consequence-specific Finality Sinks . . . . . 357 A.18.38. E18.38 Anti-bypass closure . . . . . . . . . . . . . 357 A.18.39. E18.39 Non-self-certification invariant . . . . . . 358 A.18.40. E18.40 Latency-aware progression . . . . . . . . . . 358 A.18.41. E18.41 Required invariants . . . . . . . . . . . . . 358 A.19. E19 — Receipt-Gated Tool Use and External Action Invocation . . . . . . . . . . . . . . . . . . . . . . . 362 A.19.1. E19.1 Purpose . . . . . . . . . . . . . . . . . . . 362 A.19.2. E19.2 Tool Selection and Candidate Act Formation . . 362 A.19.3. E19.3 Protected Tool Identity Binding . . . . . . . 363 A.19.4. E19.4 Tool Contract / Operation-Schema Validation . 364 A.19.5. E19.5 Tool Proposal Is Not Invocation Authority . . 364 A.19.6. E19.6 Selection of Single-Phase or Staged Tool Use . . . . . . . . . . . . . . . . . . . . . . . . . 365 A.19.7. E19.7 Bounded Real Tool Interaction . . . . . . . . 365 A.19.8. E19.8 Tool Effect Gateway . . . . . . . . . . . . . 365 A.19.9. E19.9 Phase-Specific Tool Authority . . . . . . . . 366 A.19.10. E19.10 Tool-Side Verification . . . . . . . . . . . 366 A.19.11. E19.11 Tool Result Observation and Receipt . . . . . 367 A.19.12. E19.12 Receipt-Gated Full Tool Invocation . . . . . 368 A.19.13. E19.13 Progressive Tool Privilege . . . . . . . . . 368 A.19.14. E19.14 Protected Human Approval . . . . . . . . . . 368 A.19.15. E19.15 Automatic Tool Continuation . . . . . . . . . 369 A.19.16. E19.16 Recursive and Chained Tool Calls . . . . . . 369 A.19.17. E19.17 Tool Argument Mutation Protection . . . . . . 369 A.19.18. E19.18 Credential Withholding During Tool Use . . . 370 A.19.19. E19.19 Tool Crash and Indeterminate Effect . . . . . 370 A.19.20. E19.20 Tool Receipt Consumption . . . . . . . . . . 371 A.19.21. E19.21 Alternate Tool Path Closure . . . . . . . . . 371 A.19.22. E19.22 Software Implementation . . . . . . . . . . . 372 A.19.23. E19.23 Hardware Implementation . . . . . . . . . . . 372 A.19.24. E19.24 SEND Example . . . . . . . . . . . . . . . . 372 A.19.25. E19.25 Payment Example . . . . . . . . . . . . . . . 372 A.19.26. E19.26 Required Invariants . . . . . . . . . . . . . 373 A.20. E20 — Progressive Credential Release and Receipt-Gated Authority Expansion . . . . . . . . . . . . . . . . . . 373 A.20.1. E20.1 Purpose . . . . . . . . . . . . . . . . . . . 373 A.20.2. E20.2 Credential Object and Scope . . . . . . . . . 373 A.20.3. E20.3 Credential Forms . . . . . . . . . . . . . . . 374 A.20.4. E20.4 Credential Surrogate . . . . . . . . . . . . . 375 A.20.5. E20.5 No Unrestricted Credential in Agent Memory . . 375 Das Expires 4 April 2027 [Page 23] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.20.6. E20.6 Initial Credential Ceiling . . . . . . . . . . 376 A.20.7. E20.7 Bounded Credential Phase . . . . . . . . . . . 377 A.20.8. E20.8 Credential Use at a Protected Boundary . . . . 377 A.20.9. E20.9 Real Use and Credential Receipt . . . . . . . 378 A.20.10. E20.10 Credential Upgrade Gate . . . . . . . . . . . 378 A.20.11. E20.11 Receipt-Derived Credential Material . . . . . 378 A.20.12. E20.12 Destination-Bound Credential . . . . . . . . 379 A.20.13. E20.13 Operation-Bound Credential . . . . . . . . . 379 A.20.14. E20.14 Single-Use Credential . . . . . . . . . . . . 379 A.20.15. E20.15 Cumulative-Use Credential . . . . . . . . . . 379 A.20.16. E20.16 Time-Bound Credential . . . . . . . . . . . . 379 A.20.17. E20.17 Human Approval of Credential Expansion . . . 380 A.20.18. E20.18 Automatic Credential Expansion . . . . . . . 380 A.20.19. E20.19 Hybrid Credential Expansion . . . . . . . . . 380 A.20.20. E20.20 Credential Downgrade . . . . . . . . . . . . 381 A.20.21. E20.21 Credential Revocation . . . . . . . . . . . . 381 A.20.22. E20.22 Credential Rotation . . . . . . . . . . . . . 381 A.20.23. E20.23 Split Credential Material . . . . . . . . . . 382 A.20.24. E20.24 Hardware-Rooted Credential Release . . . . . 382 A.20.25. E20.25 Software Broker Variation . . . . . . . . . . 382 A.20.26. E20.26 Credential Theft Resistance . . . . . . . . . 383 A.20.27. E20.27 Crash and Unknown Credential Use . . . . . . 383 A.20.28. E20.28 SEND Example . . . . . . . . . . . . . . . . 384 A.20.29. E20.29 Payment Example . . . . . . . . . . . . . . . 384 A.20.30. E20.30 Required Invariants . . . . . . . . . . . . . 384 A.21. E21 — Receipt-Gated Data Export, Progressive Disclosure, and Cryptographic Release . . . . . . . . . . . . . . . 384 A.21.1. E21.1 Purpose . . . . . . . . . . . . . . . . . . . 384 A.21.2. E21.2 Authorized Export Object . . . . . . . . . . . 385 A.21.3. E21.3 Export Envelope Formation . . . . . . . . . . 385 A.21.4. E21.4 Export Staging Modes . . . . . . . . . . . . . 386 A.21.5. E21.5 Real Bounded Export Effect . . . . . . . . . . 386 A.21.6. E21.6 Export Manifest . . . . . . . . . . . . . . . 387 A.21.7. E21.7 Redacted or Low-Sensitivity Trial . . . . . . 387 A.21.8. E21.8 Ciphertext-First Export . . . . . . . . . . . 388 A.21.9. E21.9 Progressive Chunk Export . . . . . . . . . . . 388 A.21.10. E21.10 Progressive Field Release . . . . . . . . . . 389 A.21.11. E21.11 Progressive Record Release . . . . . . . . . 389 A.21.12. E21.12 Cumulative Disclosure Fraction . . . . . . . 389 A.21.13. E21.13 Destination Receipt . . . . . . . . . . . . . 390 A.21.14. E21.14 Destination Handling-State Evidence . . . . . 390 A.21.15. E21.15 Receipt-Gated Next Export Phase . . . . . . . 391 A.21.16. E21.16 Human Approval After Trial Export . . . . . . 391 A.21.17. E21.17 Automatic Export Progression . . . . . . . . 391 A.21.18. E21.18 Hybrid Export Progression . . . . . . . . . . 392 A.21.19. E21.19 Multi-Recipient Export . . . . . . . . . . . 392 A.21.20. E21.20 Destination Change . . . . . . . . . . . . . 392 A.21.21. E21.21 Jurisdiction-Aware Progression . . . . . . . 392 Das Expires 4 April 2027 [Page 24] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.21.22. E21.22 Taint and Provenance-Aware Export . . . . . . 393 A.21.23. E21.23 Export Encryption-Key Progression . . . . . . 393 A.21.24. E21.24 Object-Specific Keying . . . . . . . . . . . 394 A.21.25. E21.25 Hardware-Rooted Data Release . . . . . . . . 394 A.21.26. E21.26 Network-Enforced Export . . . . . . . . . . . 394 A.21.27. E21.27 Storage-to-Network Export . . . . . . . . . . 395 A.21.28. E21.28 Database Export . . . . . . . . . . . . . . . 395 A.21.29. E21.29 Model and Vector-State Export . . . . . . . . 395 A.21.30. E21.30 Streaming Export . . . . . . . . . . . . . . 396 A.21.31. E21.31 Crash and Indeterminate Export . . . . . . . 396 A.21.32. E21.32 Receipt Consumption and Replay . . . . . . . 396 A.21.33. E21.33 Revocation During Export . . . . . . . . . . 397 A.21.34. E21.34 Anti-Bypass . . . . . . . . . . . . . . . . . 397 A.21.35. E21.35 SEND Example . . . . . . . . . . . . . . . . 398 A.21.36. E21.36 Payment-Data Example . . . . . . . . . . . . 398 A.21.37. E21.37 Required Invariants . . . . . . . . . . . . . 398 A.22. E22 — Receipt-Gated Storage Release, Provisional Persistence, and Progressive Visibility . . . . . . . . 399 A.22.1. E22.1 Purpose . . . . . . . . . . . . . . . . . . . 399 A.22.2. E22.2 Storage Candidate Act Formation . . . . . . . 399 A.22.3. E22.3 Storage Effect Dimensions . . . . . . . . . . 400 A.22.4. E22.4 Provisional Storage State . . . . . . . . . . 401 A.22.5. E22.5 Storage Effect Descriptor . . . . . . . . . . 402 A.22.6. E22.6 Real Bounded Write . . . . . . . . . . . . . . 402 A.22.7. E22.7 Persistence Evidence . . . . . . . . . . . . . 403 A.22.8. E22.8 Persistence Acceptance Predicate . . . . . . . 404 A.22.9. E22.9 Promotion Authority . . . . . . . . . . . . . 404 A.22.10. E22.10 Progressive Replication . . . . . . . . . . . 405 A.22.11. E22.11 Progressive Visibility . . . . . . . . . . . 405 A.22.12. E22.12 Ciphertext-First Storage . . . . . . . . . . 405 A.22.13. E22.13 Human Approval After Storage Confirmation . . 406 A.22.14. E22.14 Automatic Promotion . . . . . . . . . . . . . 406 A.22.15. E22.15 Hybrid Promotion . . . . . . . . . . . . . . 406 A.22.16. E22.16 Hardware-Enforced Storage Variation . . . . . 406 A.22.17. E22.17 Storage Controller Receipt . . . . . . . . . 407 A.22.18. E22.18 Crash After Provisional Write . . . . . . . . 407 A.22.19. E22.19 Overwrite and Destructive Storage Operations . . . . . . . . . . . . . . . . . . . . . 407 A.22.20. E22.20 Storage Anti-Substitution . . . . . . . . . . 408 A.22.21. E22.21 Alternate-Path Closure . . . . . . . . . . . 408 A.22.22. E22.22 SEND Example . . . . . . . . . . . . . . . . 409 A.22.23. E22.23 Payment Example . . . . . . . . . . . . . . . 409 A.22.24. E22.24 Required Invariants . . . . . . . . . . . . . 409 A.23. E23 — Receipt-Gated Robotic Actuation and Progressive Physical Effectuation . . . . . . . . . . . . . . . . . 409 A.23.1. E23.1 Purpose . . . . . . . . . . . . . . . . . . . 410 A.23.2. E23.2 Candidate Physical Act . . . . . . . . . . . . 410 A.23.3. E23.3 Physical Effect Is Not Command Acceptance . . 411 Das Expires 4 April 2027 [Page 25] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.23.4. E23.4 Phase-0 Physical Effect Selection . . . . . . 411 A.23.5. E23.5 Protected Physical Observer . . . . . . . . . 412 A.23.6. E23.6 Expected and Observed Physical State . . . . . 413 A.23.7. E23.7 Multi-Dimensional Safety Envelope . . . . . . 413 A.23.8. E23.8 Robotic Effect Confirmation Receipt . . . . . 413 A.23.9. E23.9 Automatic Continuation . . . . . . . . . . . . 413 A.23.10. E23.10 Human Continuation Approval . . . . . . . . . 414 A.23.11. E23.11 Hybrid Safety Approval . . . . . . . . . . . 414 A.23.12. E23.12 Progressive Motion . . . . . . . . . . . . . 414 A.23.13. E23.13 Mobile Robot Route Segmentation . . . . . . . 415 A.23.14. E23.14 Drone / UAV Variation . . . . . . . . . . . . 415 A.23.15. E23.15 Vehicle Variation . . . . . . . . . . . . . . 415 A.23.16. E23.16 Industrial Process Variation . . . . . . . . 416 A.23.17. E23.17 Multiple Sensor Confirmation . . . . . . . . 416 A.23.18. E23.18 Sensor Disagreement . . . . . . . . . . . . . 417 A.23.19. E23.19 Bounded Safe-State Actuation . . . . . . . . 417 A.23.20. E23.20 Crash After Physical Effect . . . . . . . . . 418 A.23.21. E23.21 Physical Rollback and Compensation . . . . . 418 A.23.22. E23.22 Energy-Bounded Effectuation . . . . . . . . . 418 A.23.23. E23.23 Hardware and Software Enforcement . . . . . . 419 A.23.24. E23.24 Alternate-Path Closure . . . . . . . . . . . 419 A.23.25. E23.25 SEND Example . . . . . . . . . . . . . . . . 420 A.23.26. E23.26 Payment Example . . . . . . . . . . . . . . . 420 A.23.27. E23.27 Required Invariants . . . . . . . . . . . . . 420 A.24. E24 — Hardware Actuator, Protected Sensor Confirmation, and Receipt-Derived Motion Authority . . . . . . . . . . . . 421 A.24.1. E24.1 Purpose . . . . . . . . . . . . . . . . . . . 421 A.24.2. E24.2 Example Hardware Components . . . . . . . . . 421 A.24.3. E24.3 Root of Actuation Authority . . . . . . . . . 422 A.24.4. E24.4 Actuation Capability . . . . . . . . . . . . . 422 A.24.5. E24.5 Hardware Latch . . . . . . . . . . . . . . . . 422 A.24.6. E24.6 Concrete 90-Degree Example . . . . . . . . . . 422 A.24.7. E24.7 Progressive Hardware Motion . . . . . . . . . 423 A.24.8. E24.8 Multiple Measurement Channels . . . . . . . . 423 A.24.9. E24.9 Sensor-Hub Receipt Generation . . . . . . . . 423 A.24.10. E24.10 Sensor Authenticity . . . . . . . . . . . . . 424 A.24.11. E24.11 Command/Sensor Pairing . . . . . . . . . . . 424 A.24.12. E24.12 Counter-Based Anti-Replay . . . . . . . . . . 424 A.24.13. E24.13 Receipt Consumption in Hardware . . . . . . . 425 A.24.14. E24.14 Missing-Execution-Material Variation . . . . 425 A.24.15. E24.15 Secure Boot and Measured Controller State . . 425 A.24.16. E24.16 Power-Stage Enforcement . . . . . . . . . . . 426 A.24.17. E24.17 Bus-Level Enforcement . . . . . . . . . . . . 426 A.24.18. E24.18 Human Approval in the Hardware Chain . . . . 426 A.24.19. E24.19 Automatic Hardware Continuation . . . . . . . 426 A.24.20. E24.20 Hybrid Hardware Continuation . . . . . . . . 427 A.24.21. E24.21 Sensor Failure . . . . . . . . . . . . . . . 427 A.24.22. E24.22 Mechanical Backlash and Tolerance Modeling . 427 Das Expires 4 April 2027 [Page 26] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.24.23. E24.23 Time-Bounded Physical Confirmation . . . . . 427 A.24.24. E24.24 Power Loss During Phase . . . . . . . . . . . 428 A.24.25. E24.25 Alternate Hardware Path Closure . . . . . . . 428 A.24.26. E24.26 Multi-Actuator Coordination . . . . . . . . . 428 A.24.27. E24.27 Independent Safety Controller . . . . . . . . 429 A.24.28. E24.28 SEND Example . . . . . . . . . . . . . . . . 429 A.24.29. E24.29 Payment Example . . . . . . . . . . . . . . . 429 A.24.30. E24.30 Required Invariants . . . . . . . . . . . . . 429 A.25. E25 — Receipt-Gated Vehicle Effectuation and Progressive Vehicular Authority . . . . . . . . . . . . . . . . . . 430 A.25.1. E25.1 Purpose . . . . . . . . . . . . . . . . . . . 430 A.25.2. E25.2 Candidate Vehicle Acts . . . . . . . . . . . . 430 A.25.3. E25.3 Vehicle Act Binding . . . . . . . . . . . . . 431 A.25.4. E25.4 Maximum Vehicle Effectuation Envelope . . . . 432 A.25.5. E25.5 Protected Vehicle State . . . . . . . . . . . 433 A.25.6. E25.6 Vehicle State Vector . . . . . . . . . . . . . 434 A.25.7. E25.7 Protected Safe-State Set . . . . . . . . . . . 434 A.25.8. E25.8 Phase-0 Vehicle Demonstration . . . . . . . . 435 A.25.9. E25.9 Example Bounded Vehicle Phase . . . . . . . . 435 A.25.10. E25.10 Vehicle Finality Sink . . . . . . . . . . . . 435 A.25.11. E25.11 Vehicle Effect Observation . . . . . . . . . 436 A.25.12. E25.12 Vehicle Effect Receipt . . . . . . . . . . . 437 A.25.13. E25.13 Vehicle Continuation Predicate . . . . . . . 438 A.25.14. E25.14 Automatic Vehicle Continuation . . . . . . . 438 A.25.15. E25.15 Human Vehicle Continuation . . . . . . . . . 438 A.25.16. E25.16 Hybrid Vehicle Continuation . . . . . . . . . 439 A.25.17. E25.17 Progressive Route Segmentation . . . . . . . 439 A.25.18. E25.18 Progressive Speed Envelope . . . . . . . . . 439 A.25.19. E25.19 Progressive Steering Envelope . . . . . . . . 439 A.25.20. E25.20 Braking and Emergency-State Variation . . . . 440 A.25.21. E25.21 Transfer of Control . . . . . . . . . . . . . 440 A.25.22. E25.22 Vehicle Credential Separation . . . . . . . . 440 A.25.23. E25.23 Hardware-Rooted Vehicle Variation . . . . . . 441 A.25.24. E25.24 Vehicle Phase Key . . . . . . . . . . . . . . 441 A.25.25. E25.25 Multi-Controller Vehicle Variation . . . . . 441 A.25.26. E25.26 Fleet Variation . . . . . . . . . . . . . . . 442 A.25.27. E25.27 Parking and Docking Variation . . . . . . . . 442 A.25.28. E25.28 Dynamic Environment Change . . . . . . . . . 442 A.25.29. E25.29 Indeterminate Vehicle Effect . . . . . . . . 442 A.25.30. E25.30 Loss of Communication . . . . . . . . . . . . 443 A.25.31. E25.31 Anti-Bypass . . . . . . . . . . . . . . . . . 443 A.25.32. E25.32 Vehicle Crash / Restart Recovery . . . . . . 444 A.25.33. E25.33 Required Invariants . . . . . . . . . . . . . 444 A.26. E26 — Receipt-Gated UAV and Mobile-Robot Effectuation . . 444 A.26.1. E26.1 Purpose . . . . . . . . . . . . . . . . . . . 445 A.26.2. E26.2 Candidate Mobility Acts . . . . . . . . . . . 445 A.26.3. E26.3 Mission Envelope . . . . . . . . . . . . . . . 446 A.26.4. E26.4 Mobility Phase Plan . . . . . . . . . . . . . 446 Das Expires 4 April 2027 [Page 27] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.26.5. E26.5 UAV Initial Demonstration . . . . . . . . . . 447 A.26.6. E26.6 Example UAV Sequence . . . . . . . . . . . . . 447 A.26.7. E26.7 Mobile Ground Robot Sequence . . . . . . . . . 447 A.26.8. E26.8 Protected Mobility Controller . . . . . . . . 447 A.26.9. E26.9 Protected Mobility Observation . . . . . . . . 448 A.26.10. E26.10 Mobility State Vector . . . . . . . . . . . . 449 A.26.11. E26.11 Protected Mobility Receipt . . . . . . . . . 449 A.26.12. E26.12 Geofence / Zone Constraint . . . . . . . . . 450 A.26.13. E26.13 Altitude-Bounded Progression . . . . . . . . 450 A.26.14. E26.14 Distance-Bounded Progression . . . . . . . . 450 A.26.15. E26.15 Energy-Bounded Progression . . . . . . . . . 450 A.26.16. E26.16 Payload-Operation Separation . . . . . . . . 451 A.26.17. E26.17 Takeoff Versus Mission Authority . . . . . . 451 A.26.18. E26.18 Landing Authority . . . . . . . . . . . . . . 451 A.26.19. E26.19 Human Approval Variation . . . . . . . . . . 452 A.26.20. E26.20 Automatic Continuation . . . . . . . . . . . 452 A.26.21. E26.21 Hybrid Continuation . . . . . . . . . . . . . 452 A.26.22. E26.22 GNSS / Localization Uncertainty Variation . . 453 A.26.23. E26.23 Sensor Disagreement . . . . . . . . . . . . . 453 A.26.24. E26.24 Protected Sensor Quorum . . . . . . . . . . . 453 A.26.25. E26.25 Communication-Link Loss . . . . . . . . . . . 454 A.26.26. E26.26 Energy Depletion . . . . . . . . . . . . . . 454 A.26.27. E26.27 Crash After Movement . . . . . . . . . . . . 454 A.26.28. E26.28 Swarm / Multi-Robot Variation . . . . . . . . 455 A.26.29. E26.29 Cooperative Mobility . . . . . . . . . . . . 455 A.26.30. E26.30 Mobile Manipulator Variation . . . . . . . . 455 A.26.31. E26.31 Anti-Bypass . . . . . . . . . . . . . . . . . 455 A.26.32. E26.32 Required Invariants . . . . . . . . . . . . . 456 A.27. E27 — Receipt-Gated Industrial, PLC, Machine, and Process-Control Effectuation . . . . . . . . . . . . . . 456 A.27.1. E27.1 Purpose . . . . . . . . . . . . . . . . . . . 456 A.27.2. E27.2 Candidate Industrial Acts . . . . . . . . . . 456 A.27.3. E27.3 Industrial Effectuation Envelope . . . . . . . 457 A.27.4. E27.4 Protected Industrial Enforcement Domain . . . 458 A.27.5. E27.5 Process State Acquisition . . . . . . . . . . 459 A.27.6. E27.6 Bounded Industrial Trial . . . . . . . . . . . 460 A.27.7. E27.7 Example Valve Sequence . . . . . . . . . . . . 461 A.27.8. E27.8 Example Machine-Cycle Sequence . . . . . . . . 461 A.27.9. E27.9 Industrial Process State Vector . . . . . . . 461 A.27.10. E27.10 Protected Operating Region . . . . . . . . . 461 A.27.11. E27.11 Process Effect Receipt . . . . . . . . . . . 462 A.27.12. E27.12 Process Receipt Status . . . . . . . . . . . 462 A.27.13. E27.13 Automatic Industrial Continuation . . . . . . 463 A.27.14. E27.14 Protected Human Approval . . . . . . . . . . 463 A.27.15. E27.15 Hybrid Industrial Approval . . . . . . . . . 464 A.27.16. E27.16 Safety-System Separation . . . . . . . . . . 464 A.27.17. E27.17 One-Cycle Demonstration . . . . . . . . . . . 464 A.27.18. E27.18 Progressive Batch Authority . . . . . . . . . 464 Das Expires 4 April 2027 [Page 28] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.27.19. E27.19 Progressive Setpoint Change . . . . . . . . . 465 A.27.20. E27.20 Rate-Limited Effectuation . . . . . . . . . . 465 A.27.21. E27.21 Industrial Robot Variation . . . . . . . . . 465 A.27.22. E27.22 CNC / Machine Tool Variation . . . . . . . . 465 A.27.23. E27.23 Power and Electrical Variation . . . . . . . 466 A.27.24. E27.24 Pump / Valve / Flow Variation . . . . . . . . 466 A.27.25. E27.25 Thermal Process Variation . . . . . . . . . . 466 A.27.26. E27.26 Material Release Variation . . . . . . . . . 466 A.27.27. E27.27 Distributed Process Variation . . . . . . . . 466 A.27.28. E27.28 Multi-Controller Quorum . . . . . . . . . . . 466 A.27.29. E27.29 Deterministic / Low-Latency Path . . . . . . 467 A.27.30. E27.30 Offline Industrial Operation . . . . . . . . 467 A.27.31. E27.31 Maintenance Mode . . . . . . . . . . . . . . 467 A.27.32. E27.32 Engineering Workstation Separation . . . . . 468 A.27.33. E27.33 PLC Logic Update Variation . . . . . . . . . 468 A.27.34. E27.34 Process Recipe Update . . . . . . . . . . . . 468 A.27.35. E27.35 Sensor Failure . . . . . . . . . . . . . . . 468 A.27.36. E27.36 Actuator Failure . . . . . . . . . . . . . . 469 A.27.37. E27.37 Crash After Industrial Effect . . . . . . . . 469 A.27.38. E27.38 Process Idempotency . . . . . . . . . . . . . 469 A.27.39. E27.39 Anti-Bypass . . . . . . . . . . . . . . . . . 469 A.27.40. E27.40 SEND Analogue . . . . . . . . . . . . . . . . 470 A.27.41. E27.41 Payment Analogue . . . . . . . . . . . . . . 470 A.27.42. E27.42 Required Invariants . . . . . . . . . . . . . 471 A.28. E28 — Receipt-Gated Telecom Effectuation and Progressive Network Authority . . . . . . . . . . . . . . . . . . . 471 A.28.1. E28.1 Purpose . . . . . . . . . . . . . . . . . . . 471 A.28.2. E28.2 Candidate Telecom Acts . . . . . . . . . . . . 472 A.28.3. E28.3 Telecom Act Binding . . . . . . . . . . . . . 473 A.28.4. E28.4 Maximum Telecom Effectuation Envelope . . . . 474 A.28.5. E28.5 Protected Network State . . . . . . . . . . . 475 A.28.6. E28.6 Phase-0 Live Telecom Effect . . . . . . . . . 476 A.28.7. E28.7 Telecom Phase Scope . . . . . . . . . . . . . 476 A.28.8. E28.8 Phase-Specific Telecom Authority . . . . . . . 477 A.28.9. E28.9 Effectuation Boundary . . . . . . . . . . . . 477 A.28.10. E28.10 Protected Telecom Receipt . . . . . . . . . . 478 A.28.11. E28.11 Telecom Health Vector . . . . . . . . . . . . 479 A.28.12. E28.12 Receipt-Gated Continuation . . . . . . . . . 479 A.28.13. E28.13 Progressive Subscriber or Device Rollout . . 479 A.28.14. E28.14 Progressive Traffic Steering . . . . . . . . 479 A.28.15. E28.15 Route and Service-Chain Verification . . . . 480 A.28.16. E28.16 Message-SEND Telecom Variant . . . . . . . . 480 A.28.17. E28.17 Session Establishment Variant . . . . . . . . 480 A.28.18. E28.18 Network-Slice / Service-Class Variant . . . . 480 A.28.19. E28.19 Edge and Multi-Access Variant . . . . . . . . 481 A.28.20. E28.20 Hardware-Rooted Telecom Enforcement . . . . . 481 A.28.21. E28.21 Local Low-Latency Enforcement . . . . . . . . 482 A.28.22. E28.22 Human Approval . . . . . . . . . . . . . . . 482 Das Expires 4 April 2027 [Page 29] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.28.23. E28.23 Automatic Approval . . . . . . . . . . . . . 483 A.28.24. E28.24 Hybrid Approval . . . . . . . . . . . . . . . 483 A.28.25. E28.25 Failure and Rollback . . . . . . . . . . . . 483 A.28.26. E28.26 Indeterminate Telecom State . . . . . . . . . 483 A.28.27. E28.27 Crash After Network Effect . . . . . . . . . 484 A.28.28. E28.28 Alternate-Path Closure . . . . . . . . . . . 484 A.28.29. E28.29 Multi-Domain Telecom Progression . . . . . . 485 A.28.30. E28.30 E28 Required Invariants . . . . . . . . . . . 485 A.29. E29 — Receipt-Gated Radio, Satellite, and Non-Terrestrial Network Effectuation . . . . . . . . . . . . . . . . . . 485 A.29.1. E29.1 Purpose . . . . . . . . . . . . . . . . . . . 485 A.29.2. E29.2 Candidate Radio and NTN Acts . . . . . . . . . 486 A.29.3. E29.3 Protected RF/NTN Act Binding . . . . . . . . . 487 A.29.4. E29.4 Maximum Radio/NTN Effectuation Envelope . . . 487 A.29.5. E29.5 Phase-0 Real RF Effect . . . . . . . . . . . . 488 A.29.6. E29.6 Phase-Specific RF Parameters . . . . . . . . . 489 A.29.7. E29.7 Protected Receiver-Side Observation . . . . . 489 A.29.8. E29.8 RF Effect Receipt . . . . . . . . . . . . . . 490 A.29.9. E29.9 Receiver Confirmation Receipt . . . . . . . . 490 A.29.10. E29.10 Beam-Progression Embodiment . . . . . . . . . 491 A.29.11. E29.11 Power-Progression Embodiment . . . . . . . . 491 A.29.12. E29.12 Duration-Progression Embodiment . . . . . . . 491 A.29.13. E29.13 Bandwidth / Resource-Block Progression . . . 491 A.29.14. E29.14 Gateway Verification . . . . . . . . . . . . 492 A.29.15. E29.15 Multi-Hop / Relay Path . . . . . . . . . . . 492 A.29.16. E29.16 Aggregate Relay Receipt . . . . . . . . . . . 492 A.29.17. E29.17 Store-and-Forward NTN Variant . . . . . . . . 493 A.29.18. E29.18 Long-Latency Local Continuation . . . . . . . 493 A.29.19. E29.19 Cryptographic Phase Release . . . . . . . . . 493 A.29.20. E29.20 Destination-Key Release . . . . . . . . . . . 494 A.29.21. E29.21 Satellite Payload Communications Variant . . 494 A.29.22. E29.22 Cross-Link Variant . . . . . . . . . . . . . 494 A.29.23. E29.23 Handover Variant . . . . . . . . . . . . . . 495 A.29.24. E29.24 Human Approval . . . . . . . . . . . . . . . 495 A.29.25. E29.25 Automatic Approval . . . . . . . . . . . . . 495 A.29.26. E29.26 Hybrid Approval . . . . . . . . . . . . . . . 496 A.29.27. E29.27 Failure and Indeterminate Link State . . . . 496 A.29.28. E29.28 Duplicate Transmission Protection . . . . . . 496 A.29.29. E29.29 Anti-Bypass . . . . . . . . . . . . . . . . . 496 A.29.30. E29.30 E29 Required Invariants . . . . . . . . . . . 497 A.30. E30 — Receipt-Gated GPU, Accelerator, and Compute-Egress Effectuation . . . . . . . . . . . . . . . . . . . . . . 497 A.30.1. E30.1 Purpose . . . . . . . . . . . . . . . . . . . 497 A.30.2. E30.2 Candidate Accelerator Acts . . . . . . . . . . 498 A.30.3. E30.3 Accelerator Act Binding . . . . . . . . . . . 499 A.30.4. E30.4 Maximum Accelerator Effectuation Envelope . . 500 A.30.5. E30.5 Compute Versus Effectuation Separation . . . . 500 A.30.6. E30.6 Phase-0 Bounded Accelerator Effect . . . . . . 501 Das Expires 4 April 2027 [Page 30] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.30.7. E30.7 Device-Set Progression . . . . . . . . . . . . 501 A.30.8. E30.8 Memory-Region Scope . . . . . . . . . . . . . 501 A.30.9. E30.9 Protected Accelerator State . . . . . . . . . 502 A.30.10. E30.10 Accelerator Effect Receipt . . . . . . . . . 502 A.30.11. E30.11 Protected Device State Vector . . . . . . . . 503 A.30.12. E30.12 Command-Queue Gate . . . . . . . . . . . . . 503 A.30.13. E30.13 Protected Command Release . . . . . . . . . . 504 A.30.14. E30.14 DMA Effectuation Gate . . . . . . . . . . . . 504 A.30.15. E30.15 IOMMU / Memory-Controller Variation . . . . . 505 A.30.16. E30.16 Fabric-Gated Progression . . . . . . . . . . 505 A.30.17. E30.17 DPU / SmartNIC Egress Gate . . . . . . . . . 505 A.30.18. E30.18 Output-Key Release . . . . . . . . . . . . . 505 A.30.19. E30.19 Receipt-Derived Output Authority . . . . . . 506 A.30.20. E30.20 One-Accelerator-to-Cluster Progression . . . 506 A.30.21. E30.21 Batch-Size Progression . . . . . . . . . . . 506 A.30.22. E30.22 Progressive Output Release . . . . . . . . . 506 A.30.23. E30.23 Confidential-Computing Variant . . . . . . . 507 A.30.24. E30.24 GPU Security-Processor Variation . . . . . . 507 A.30.25. E30.25 Multi-Accelerator Receipt Aggregation . . . . 508 A.30.26. E30.26 Partial Device Failure . . . . . . . . . . . 508 A.30.27. E30.27 Human Approval . . . . . . . . . . . . . . . 508 A.30.28. E30.28 Automatic Approval . . . . . . . . . . . . . 509 A.30.29. E30.29 Hybrid Approval . . . . . . . . . . . . . . . 509 A.30.30. E30.30 SEND Example . . . . . . . . . . . . . . . . 509 A.30.31. E30.31 Payment Example . . . . . . . . . . . . . . . 509 A.30.32. E30.32 Crash / Reset / Device-Recovery State . . . . 510 A.30.33. E30.33 Idempotency . . . . . . . . . . . . . . . . . 510 A.30.34. E30.34 Revocation During Compute . . . . . . . . . . 510 A.30.35. E30.35 Alternate-Path Closure . . . . . . . . . . . 511 A.30.36. E30.36 E30 Required Invariants . . . . . . . . . . . 511 A.31. E31 — Receipt-Gated Model-State Update, Protected Memory Commit, and Progressive Model-State Effectuation . . . . 512 A.31.1. E31.1 Purpose . . . . . . . . . . . . . . . . . . . 512 A.31.2. E31.2 Model-State Scope . . . . . . . . . . . . . . 512 A.31.3. E31.3 Candidate Model-State Update . . . . . . . . . 514 A.31.4. E31.4 State-Authority Separation . . . . . . . . . . 515 A.31.5. E31.5 Provisional Model-State Region . . . . . . . . 515 A.31.6. E31.6 Authoritative Model-State Region . . . . . . . 516 A.31.7. E31.7 Bounded Phase-0 State Update . . . . . . . . . 516 A.31.8. E31.8 Model-State Effectuation Envelope . . . . . . 517 A.31.9. E31.9 Delta-Bounded Parameter Update . . . . . . . . 518 A.31.10. E31.10 Protected Evaluation of Updated State . . . . 518 A.31.11. E31.11 Model-State Receipt . . . . . . . . . . . . . 519 A.31.12. E31.12 State-Version Binding . . . . . . . . . . . . 519 A.31.13. E31.13 State-Digest Binding . . . . . . . . . . . . 520 A.31.14. E31.14 Automatic Continuation . . . . . . . . . . . 520 A.31.15. E31.15 Human Continuation . . . . . . . . . . . . . 520 A.31.16. E31.16 Hybrid Continuation . . . . . . . . . . . . . 521 Das Expires 4 April 2027 [Page 31] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.31.17. E31.17 Progressive Memory Promotion . . . . . . . . 521 A.31.18. E31.18 Progressive Vector-Memory Update . . . . . . 521 A.31.19. E31.19 Parameter / Adapter Promotion . . . . . . . . 522 A.31.20. E31.20 Protected Policy-State Update . . . . . . . . 522 A.31.21. E31.21 No Self-Authorization Through State Mutation . . . . . . . . . . . . . . . . . . . . . . 522 A.31.22. E31.22 Rollback and Previous-State Preservation . . 522 A.31.23. E31.23 Crash and Indeterminate State . . . . . . . . 523 A.31.24. E31.24 Multi-Replica Model State . . . . . . . . . . 523 A.31.25. E31.25 Hardware-Rooted Model-State Promotion . . . . 524 A.31.26. E31.26 Accelerator-Resident State . . . . . . . . . 524 A.31.27. E31.27 SEND Analogue . . . . . . . . . . . . . . . . 524 A.31.28. E31.28 Payment Analogue . . . . . . . . . . . . . . 525 A.31.29. E31.29 Anti-Bypass . . . . . . . . . . . . . . . . . 525 A.31.30. E31.30 Required Invariants . . . . . . . . . . . . . 525 A.32. E32 — Receipt-Gated Software, Firmware, and Configuration Update with Progressive Activation . . . . . . . . . . . 526 A.32.1. E32.1 Purpose . . . . . . . . . . . . . . . . . . . 526 A.32.2. E32.2 Candidate Update Act . . . . . . . . . . . . . 526 A.32.3. E32.3 Update Artifact Binding . . . . . . . . . . . 527 A.32.4. E32.4 Staging Versus Activation . . . . . . . . . . 527 A.32.5. E32.5 Maximum Update Envelope . . . . . . . . . . . 527 A.32.6. E32.6 Phase-0 Real Update . . . . . . . . . . . . . 528 A.32.7. E32.7 Target-Cohort Progression . . . . . . . . . . 529 A.32.8. E32.8 Update Manifest . . . . . . . . . . . . . . . 529 A.32.9. E32.9 Phase-Specific Activation Authority . . . . . 530 A.32.10. E32.10 Protected Installation and Activation . . . . 531 A.32.11. E32.11 Post-Activation Observation . . . . . . . . . 531 A.32.12. E32.12 Update Effect Receipt . . . . . . . . . . . . 532 A.32.13. E32.13 Measured-Boot / Secure-Boot Receipt . . . . . 533 A.32.14. E32.14 Automatic Rollout Continuation . . . . . . . 533 A.32.15. E32.15 Human Approval Between Update Phases . . . . 533 A.32.16. E32.16 Hybrid Update Approval . . . . . . . . . . . 534 A.32.17. E32.17 A/B Partition Update . . . . . . . . . . . . 534 A.32.18. E32.18 Firmware Update . . . . . . . . . . . . . . . 534 A.32.19. E32.19 Configuration Update . . . . . . . . . . . . 535 A.32.20. E32.20 Dependency-Aware Update . . . . . . . . . . . 535 A.32.21. E32.21 Multi-Component Atomic Update . . . . . . . . 535 A.32.22. E32.22 Progressive Percentage Rollout . . . . . . . 536 A.32.23. E32.23 Device-Class Segmentation . . . . . . . . . . 536 A.32.24. E32.24 Rollback Authority . . . . . . . . . . . . . 536 A.32.25. E32.25 Update Failure . . . . . . . . . . . . . . . 537 A.32.26. E32.26 Indeterminate Update . . . . . . . . . . . . 537 A.32.27. E32.27 Anti-Rollback Counter . . . . . . . . . . . . 537 A.32.28. E32.28 Cryptographic Activation Material . . . . . . 538 A.32.29. E32.29 Offline Device Update . . . . . . . . . . . . 538 A.32.30. E32.30 SEND Analogue . . . . . . . . . . . . . . . . 538 A.32.31. E32.31 Payment Analogue . . . . . . . . . . . . . . 539 Das Expires 4 April 2027 [Page 32] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.32.32. E32.32 Alternate-Path Closure . . . . . . . . . . . 539 A.32.33. E32.33 Required Invariants . . . . . . . . . . . . . 539 A.33. E33 — Multi-Destination, Multi-Recipient, Multi-Sink, and Distributed Receipt-Gated Effectuation . . . . . . . . . 540 A.33.1. E33.1 Purpose . . . . . . . . . . . . . . . . . . . 540 A.33.2. E33.2 Candidate Multi-Destination Act . . . . . . . 540 A.33.3. E33.3 Maximum Destination Set . . . . . . . . . . . 541 A.33.4. E33.4 Destination Identity Binding . . . . . . . . . 541 A.33.5. E33.5 Destination Descriptor . . . . . . . . . . . . 541 A.33.6. E33.6 Bounded Initial Destination Set . . . . . . . 542 A.33.7. E33.7 Destination-Specific Effectuation Authority . 542 A.33.8. E33.8 Destination-Specific Cryptographic Material . 543 A.33.9. E33.9 Parallel Destination Effectuation . . . . . . 543 A.33.10. E33.10 Aggregate Receipt Set . . . . . . . . . . . . 543 A.33.11. E33.11 All-Destination Confirmation Rule . . . . . . 543 A.33.12. E33.12 Quorum Destination Confirmation . . . . . . . 543 A.33.13. E33.13 Weighted Destination Confirmation . . . . . . 544 A.33.14. E33.14 Critical-Destination Predicate . . . . . . . 544 A.33.15. E33.15 Partial Success . . . . . . . . . . . . . . . 544 A.33.16. E33.16 Failed-Destination Set . . . . . . . . . . . 544 A.33.17. E33.17 Indeterminate-Destination Set . . . . . . . . 545 A.33.18. E33.18 Per-Destination Reconciliation . . . . . . . 545 A.33.19. E33.19 Progressive Destination Expansion . . . . . . 545 A.33.20. E33.20 Destination-Class Progression . . . . . . . . 545 A.33.21. E33.21 Multi-Recipient SEND Workflow . . . . . . . . 546 A.33.22. E33.22 Group Message With Per-Recipient Keys . . . . 546 A.33.23. E33.23 Multi-Beneficiary Payment Workflow . . . . . 546 A.33.24. E33.24 Multi-Region Deployment Workflow . . . . . . 547 A.33.25. E33.25 Multi-Sink Effectuation . . . . . . . . . . . 547 A.33.26. E33.26 Heterogeneous Sink Types . . . . . . . . . . 547 A.33.27. E33.27 Cross-Jurisdiction Destination Control . . . 547 A.33.28. E33.28 Human Approval of Destination Expansion . . . 548 A.33.29. E33.29 Automatic Destination Expansion . . . . . . . 548 A.33.30. E33.30 Hybrid Destination Expansion . . . . . . . . 548 A.33.31. E33.31 Destination Revocation . . . . . . . . . . . 548 A.33.32. E33.32 Destination Substitution . . . . . . . . . . 549 A.33.33. E33.33 Duplicate-Destination and Alias Handling . . 549 A.33.34. E33.34 Destination-Path Binding . . . . . . . . . . 549 A.33.35. E33.35 Recipient Privacy Variation . . . . . . . . . 550 A.33.36. E33.36 Threshold Cryptography Across Destinations . 550 A.33.37. E33.37 Hardware-Enforced Multi-Destination Release . . . . . . . . . . . . . . . . . . . . . . . 550 A.33.38. E33.38 Multi-Destination Receipt Tree . . . . . . . 551 A.33.39. E33.39 Completion Semantics . . . . . . . . . . . . 551 A.33.40. E33.40 Final Multi-Destination Receipt . . . . . . . 551 A.33.41. E33.41 Alternate-Path Closure . . . . . . . . . . . 552 A.33.42. E33.42 Required Invariants . . . . . . . . . . . . . 552 Das Expires 4 April 2027 [Page 33] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.34. E34 — Replicated, Quorum-Confirmed, and Consensus Receipt-Gated Effectuation . . . . . . . . . . . . . . . 553 A.34.1. E34.1 Purpose . . . . . . . . . . . . . . . . . . . 553 A.34.2. E34.2 Replicated Effectuation Set . . . . . . . . . 553 A.34.3. E34.3 Replica-Specific Phase Authority . . . . . . . 554 A.34.4. E34.4 Real Replicated Effect . . . . . . . . . . . . 555 A.34.5. E34.5 Replica Receipt . . . . . . . . . . . . . . . 556 A.34.6. E34.6 Replica Role Binding . . . . . . . . . . . . . 556 A.34.7. E34.7 Protected Receipt Set . . . . . . . . . . . . 557 A.34.8. E34.8 Quorum Rule . . . . . . . . . . . . . . . . . 558 A.34.9. E34.9 Weighted Quorum . . . . . . . . . . . . . . . 558 A.34.10. E34.10 Role-Constrained Quorum . . . . . . . . . . . 559 A.34.11. E34.11 Consensus Confirmation . . . . . . . . . . . 559 A.34.12. E34.12 Commit Certificate . . . . . . . . . . . . . 559 A.34.13. E34.13 Commit Certificate Construction . . . . . . . 560 A.34.14. E34.14 Receipt-Tree Aggregation . . . . . . . . . . 560 A.34.15. E34.15 Replicated-State Version Binding . . . . . . 560 A.34.16. E34.16 Membership Version Binding . . . . . . . . . 560 A.34.17. E34.17 Replica Lag . . . . . . . . . . . . . . . . . 561 A.34.18. E34.18 Partial Replica Success . . . . . . . . . . . 561 A.34.19. E34.19 Critical Replica Requirement . . . . . . . . 561 A.34.20. E34.20 Split-Brain Detection . . . . . . . . . . . . 562 A.34.21. E34.21 Split-Brain Effect State . . . . . . . . . . 562 A.34.22. E34.22 Byzantine or Malicious Replica Variation . . 563 A.34.23. E34.23 Same-Organization Replica Variation . . . . . 563 A.34.24. E34.24 Cross-Organization Replica Variation . . . . 563 A.34.25. E34.25 Phase-Specific Quorum . . . . . . . . . . . . 564 A.34.26. E34.26 Risk-Adaptive Quorum . . . . . . . . . . . . 564 A.34.27. E34.27 Human Approval After Quorum . . . . . . . . . 564 A.34.28. E34.28 Automatic Continuation After Quorum . . . . . 564 A.34.29. E34.29 Hybrid Continuation . . . . . . . . . . . . . 564 A.34.30. E34.30 Receipt-Derived Continuation Authority . . . 565 A.34.31. E34.31 Hardware-Rooted Aggregate Confirmation . . . 565 A.34.32. E34.32 Database Replication Example . . . . . . . . 565 A.34.33. E34.33 Distributed Storage Example . . . . . . . . . 565 A.34.34. E34.34 SEND / Messaging Example . . . . . . . . . . 566 A.34.35. E34.35 Payment Example . . . . . . . . . . . . . . . 566 A.34.36. E34.36 Cloud Deployment Example . . . . . . . . . . 566 A.34.37. E34.37 Telecom Example . . . . . . . . . . . . . . . 567 A.34.38. E34.38 Physical-Control Example . . . . . . . . . . 567 A.34.39. E34.39 Replica Failure During Phase . . . . . . . . 567 A.34.40. E34.40 Membership Change During Phase . . . . . . . 568 A.34.41. E34.41 Late Receipt Handling . . . . . . . . . . . . 568 A.34.42. E34.42 Quorum Receipt Consumption . . . . . . . . . 568 A.34.43. E34.43 Replica Receipt Replay Protection . . . . . . 569 A.34.44. E34.44 Conflicting Aggregate Certificates . . . . . 569 A.34.45. E34.45 Network Partition . . . . . . . . . . . . . . 569 A.34.46. E34.46 Fencing and Epoch Authority . . . . . . . . . 570 Das Expires 4 April 2027 [Page 34] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.34.47. E34.47 Reconciliation After Replica Divergence . . . 570 A.34.48. E34.48 Anti-Bypass Requirement . . . . . . . . . . . 570 A.34.49. E34.49 Software Implementation . . . . . . . . . . . 571 A.34.50. E34.50 Hardware / Split Implementation . . . . . . . 571 A.34.51. E34.51 Required Invariants . . . . . . . . . . . . . 571 A.35. E35 — Negative, Indeterminate, Conflict, Reconciliation, and Recovery Receipt-Gated Effectuation . . . . . . . . 572 A.35.1. E35.1 Purpose . . . . . . . . . . . . . . . . . . . 572 A.35.2. E35.2 Negative Receipt . . . . . . . . . . . . . . . 573 A.35.3. E35.3 Negative Receipt Representation . . . . . . . 574 A.35.4. E35.4 Indeterminate Receipt . . . . . . . . . . . . 574 A.35.5. E35.5 Conflict Receipt / Conflict Evidence . . . . . 575 A.35.6. E35.6 Outcome State Set . . . . . . . . . . . . . . 575 A.35.7. E35.7 Positive Evidence Versus Negative Evidence . . 575 A.35.8. E35.8 Missing Receipt Is Not Negative Receipt . . . 576 A.35.9. E35.9 Negative Receipt Validation . . . . . . . . . 576 A.35.10. E35.10 Effect-State Granularity . . . . . . . . . . 577 A.35.11. E35.11 Protected Reconciliation State . . . . . . . 578 A.35.12. E35.12 Reconciliation Evidence Set . . . . . . . . . 578 A.35.13. E35.13 Reconciliation Function . . . . . . . . . . . 579 A.35.14. E35.14 PROVEN_EFFECTED Result . . . . . . . . . . . 579 A.35.15. E35.15 PROVEN_NOT_EFFECTED Result . . . . . . . . . 580 A.35.16. E35.16 Retry Authority . . . . . . . . . . . . . . . 580 A.35.17. E35.17 Retry Counter . . . . . . . . . . . . . . . . 580 A.35.18. E35.18 Consequence-Safe Retry . . . . . . . . . . . 581 A.35.19. E35.19 Partial Effect Result . . . . . . . . . . . . 581 A.35.20. E35.20 Partial Effect Quantification . . . . . . . . 582 A.35.21. E35.21 Compensation Receipt . . . . . . . . . . . . 582 A.35.22. E35.22 Rollback Receipt . . . . . . . . . . . . . . 583 A.35.23. E35.23 Late Positive Receipt After Negative Receipt . . . . . . . . . . . . . . . . . . . . . . . 583 A.35.24. E35.24 Late Receipt After Retry . . . . . . . . . . 583 A.35.25. E35.25 Duplicate-Effect Detection . . . . . . . . . 584 A.35.26. E35.26 Conflicting Protected Evidence . . . . . . . 584 A.35.27. E35.27 Evidence Authority Hierarchy . . . . . . . . 585 A.35.28. E35.28 Human Reconciliation Approval . . . . . . . . 585 A.35.29. E35.29 Automatic Reconciliation . . . . . . . . . . 585 A.35.30. E35.30 Hybrid Recovery . . . . . . . . . . . . . . . 586 A.35.31. E35.31 Time-Bounded Indeterminate State . . . . . . 586 A.35.32. E35.32 Protected Recovery Query . . . . . . . . . . 586 A.35.33. E35.33 Query Result Receipt . . . . . . . . . . . . 587 A.35.34. E35.34 SEND Example - Missing Delivery Confirmation . . . . . . . . . . . . . . . . . . . . 587 A.35.35. E35.35 SEND Example - Wrong Recipient Rejection . . 588 A.35.36. E35.36 Payment Example - Timeout After Submission . 588 A.35.37. E35.37 Payment Example - Partial Settlement . . . . 588 A.35.38. E35.38 Database Example . . . . . . . . . . . . . . 588 A.35.39. E35.39 Storage Example . . . . . . . . . . . . . . . 589 Das Expires 4 April 2027 [Page 35] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.35.40. E35.40 Hardware Actuation Example . . . . . . . . . 589 A.35.41. E35.41 Vehicle / UAV Example . . . . . . . . . . . . 589 A.35.42. E35.42 Industrial Example . . . . . . . . . . . . . 590 A.35.43. E35.43 Telecom Example . . . . . . . . . . . . . . . 590 A.35.44. E35.44 GPU / Accelerator Example . . . . . . . . . . 590 A.35.45. E35.45 Model-State Example . . . . . . . . . . . . . 591 A.35.46. E35.46 Software/Firmware Update Example . . . . . . 591 A.35.47. E35.47 Multi-Destination Recovery . . . . . . . . . 591 A.35.48. E35.48 Replicated Recovery with E34 . . . . . . . . 592 A.35.49. E35.49 Recovery Receipt . . . . . . . . . . . . . . 592 A.35.50. E35.50 Recovery-Receipt-Derived Authority . . . . . 592 A.35.51. E35.51 Recovery Authority Consumption . . . . . . . 593 A.35.52. E35.52 Recovery Policy Change . . . . . . . . . . . 593 A.35.53. E35.53 Revocation During Reconciliation . . . . . . 593 A.35.54. E35.54 Safe-State Authority . . . . . . . . . . . . 593 A.35.55. E35.55 Audit and Evidence Preservation . . . . . . . 594 A.35.56. E35.56 Privacy-Preserving Reconciliation . . . . . . 594 A.35.57. E35.57 Anti-Bypass Requirement . . . . . . . . . . . 595 A.35.58. E35.58 Fail-Closed and Fail-Limited Recovery . . . . 595 A.35.59. E35.59 Required Invariants . . . . . . . . . . . . . 595 Appendix B. Normalized Mathematical and State-Machine Summary . 597 Appendix C. Workflow Coverage Map . . . . . . . . . . . . . . . 598 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 598 1. Introduction AI and autonomous software increasingly performs work whose outputs are no longer merely advisory. A generated decision can become a message sent to a third party, a transfer of money, a database commit, a cloud deployment, a credential use, a data export, a vehicle command, a radio transmission, a model-state mutation, or another externally consequential effect. For these operations, the architectural question is not only whether a computation was allowed to run, but whether the exact requested consequence should be permitted to become effective at the point where it can no longer be treated as a proposal. This document defines execution finality as protected control over the transition from a proposed or partially authorized act to an externally consequential effect. It consolidates thirty-five workflow profiles into a common architecture that can be implemented in software, firmware, hardware, networks, transaction systems, storage systems, cryptographic modules, or mixed protected domains. Das Expires 4 April 2027 [Page 36] Internet-Draft Reality as a Cryptographic Dependency October 2026 The architecture is especially intended for sensitive work and high- consequence environments where an incorrect full effect may be catastrophic or difficult to reverse. It therefore supports bounded real trials, progressive scopes, protected evidence, receipt- conditioned continuation, conservative handling of unknown outcomes, and alternate-path closure. 1.1. Design Principle: Computation Is Not Effectuation Authority Generating, predicting, recommending, or preparing an act does not by itself make the act final. A proposing model, agent, application, or workflow may possess extensive computational capability while a protected effectuation boundary retains authority over whether the requested consequence becomes externally effective. Proposal(A) != EffectuationAuthority(A) For staged execution: BoundedAuthority(P_0) != Authority(FullEffect) A later phase is technically dependent on protected confirmation of an earlier phase. Figure 1: Core authority separation 1.2. Scope * AI-agent and autonomous-system actions that can cause external effects. * Critical-system operations where failure, misdirection, or unauthorized progression can cause substantial safety, security, financial, operational, or physical consequences. * Single-phase protected finality and multi-phase receipt-gated effectuation. * Human, automatic, hybrid, and multi-authority decision paths. * Software-only, hardware-rooted, split, distributed, and destination-side enforcement. * Negative, partial, conflicting, or indeterminate effect evidence and reconciliation. Das Expires 4 April 2027 [Page 37] Internet-Draft Reality as a Cryptographic Dependency October 2026 1.3. Non-Goals This document does not define one mandatory transport protocol, cryptographic algorithm, operating system, payment rail, cloud provider, messaging protocol, vehicle bus, radio stack, database technology, or hardware vendor. It defines protected causal and state-transition properties that may be realized by different mechanisms. The document also does not claim that every operation should be staged. E01 explicitly permits single-phase protected effectuation when protected policy determines that staging is unnecessary. The safety-first profile concerns the handling of high-consequence cases in which additional validation is justified by the consequence model. 2. Consolidated Technical Source Set and Industry Map This revision consolidates the complete E01-E35 workflow family together with the Interim Effectuation Validator (IEV) materials and the topology-independent / alternative-authority closure material. The purpose of this section is to give an industry reader a fast map of what each source family contributes before entering the normative architecture and detailed appendices. 2.1. Twelve E01-E35 Workflow Documents +==========+==========================+=============================+ | Profiles | Source focus | Industry interpretation | +==========+==========================+=============================+ | E01-E03 | Single-Phase, | Defines the baseline: a | | | Demonstration-Then-Full, | protected one-phase act | | | and Progressive | when staging is | | | Effectuation | unnecessary; a real | | | | bounded demonstration | | | | followed by receipt-gated | | | | full effectuation; and a | | | | multi-phase progression in | | | | which each new consequence | | | | depends on evidence from | | | | the preceding real phase. | +----------+--------------------------+-----------------------------+ | E04-E06 | Protected Human, | Shows how receipt-gated | | | Automatic, and Hybrid | effectuation can be | | | Continuation | governed by protected | | | | human approval, machine | | | | policy, or a conjunction/ | | | | disjunction of human and | | | | automatic authority. | Das Expires 4 April 2027 [Page 38] Internet-Draft Reality as a Cryptographic Dependency October 2026 | | | Human approval can occur | | | | after the reviewer sees | | | | evidence of a real bounded | | | | effect rather than only a | | | | prediction. | +----------+--------------------------+-----------------------------+ | E07-E09 | Software, Hardware, and | Maps the same control | | | Split Protected | invariant into software | | | Enforcement Domains | services and kernels, | | | | hardware roots and | | | | latches, or split | | | | software/hardware systems. | | | | It covers caller | | | | attribution, late | | | | credential injection, | | | | egress gates, kernel | | | | hooks, durable state, | | | | attestation, and hardware- | | | | protected authority. | +----------+--------------------------+-----------------------------+ | E10-E12 | Receipt-Conditioned Key | Adds cryptographic key | | | Chains, Threshold | progression, multi-party | | | Continuation, and | or threshold authority, | | | Message SEND | and a practical | | | | communication pattern in | | | | which a real trailer or | | | | bounded object reaches the | | | | actual recipient path | | | | before the full message or | | | | semantic payload is | | | | released. | +----------+--------------------------+-----------------------------+ | E13-E15 | File Transfer, Payment | Applies the architecture | | | Demonstration, and | to files/data objects, | | | Conditional Settlement | bounded payment or hold | | | | operations before broader | | | | transfer, and escrow/ | | | | conditional settlement | | | | where value, assets, keys, | | | | or authority remain in a | | | | controlled holding state | | | | until required evidence is | | | | satisfied. | +----------+--------------------------+-----------------------------+ | E16-E18 | Database Commit, Cloud | Covers provisional | | | Deployment, and AI Model | database persistence and | | | Deployment | promotion, staged | | | | infrastructure rollout, | Das Expires 4 April 2027 [Page 39] Internet-Draft Reality as a Cryptographic Dependency October 2026 | | | and progressive model | | | | deployment or activation. | | | | The common theme is that | | | | production scope grows | | | | only after protected | | | | evidence from a smaller | | | | real production effect is | | | | accepted. | +----------+--------------------------+-----------------------------+ | E19-E21 | AI Tool Use, Progressive | Separates a tool proposal | | | Credential Release, and | from invocation authority, | | | Data Export | supports phase-specific or | | | | withheld credentials, and | | | | progressively releases | | | | sensitive data or semantic | | | | access only after | | | | destination- or effect- | | | | derived evidence passes | | | | protected checks. | +----------+--------------------------+-----------------------------+ | E22-E24 | Storage, Robotics, and | Covers provisional storage | | | Sensor-Confirmed | and visibility, | | | Hardware Actuation | progressive robot actions, | | | | and hardware motion or | | | | actuation confirmed by | | | | protected sensors. | | | | Physical response can be | | | | measured before a larger | | | | actuator envelope is | | | | unlocked. | +----------+--------------------------+-----------------------------+ | E25-E27 | Vehicles, UAVs / Mobile | Extends staged authority | | | Robots, and Industrial | to vehicular motion, | | | Control | drones/mobile robots, | | | | PLCs, machines, and | | | | industrial processes. | | | | Safe-state sets, | | | | route/speed/steering or | | | | process envelopes, device | | | | identity, sensor evidence, | | | | and crash/indeterminate | | | | behavior are treated as | | | | protected state. | +----------+--------------------------+-----------------------------+ | E28-E30 | Telecom, Radio / | Applies receipt-gated | | | Satellite / NTN, and GPU | continuation to live | | | / Accelerator Egress | network effects, radio or | | | | satellite/NTN actions, and | Das Expires 4 April 2027 [Page 40] Internet-Draft Reality as a Cryptographic Dependency October 2026 | | | accelerator/compute | | | | egress. It covers | | | | progressive traffic, | | | | route/service-chain | | | | checks, low-latency local | | | | enforcement, hardware | | | | roots, and protected | | | | evidence from network or | | | | accelerator boundaries. | +----------+--------------------------+-----------------------------+ | E31-E33 | Model-State Update, | Treats persistent AI | | | Software/Firmware | memory/model-state | | | Activation, and Multi- | mutation, software or | | | Destination Effectuation | firmware activation, and | | | | operations spanning | | | | multiple recipients, | | | | sinks, or destinations as | | | | consequential effects that | | | | can be provisionally | | | | applied, evaluated, and | | | | then promoted under | | | | protected continuation. | +----------+--------------------------+-----------------------------+ | E34-E35 | Replicated / Quorum / | Covers replicas, weighted | | | Consensus Confirmation | or role-constrained | | | and Failure / Conflict | quorum, commit | | | Recovery | certificates, split-brain | | | | and Byzantine conditions, | | | | plus negative receipts, | | | | partial effects, | | | | conflicting authentic | | | | evidence, reconciliation, | | | | crash recovery, and no- | | | | blind-retry behavior. | +----------+--------------------------+-----------------------------+ Table 1: Source document map 2.2. IEV Technical Family The IEV material adds a protected inter-phase judgment layer. Rather than treating a receipt as self-authorizing, an IEV independently evaluates evidence from an earlier real effect and establishes the technically required condition for the next phase. This separates receipt existence from continuation authority. Das Expires 4 April 2027 [Page 41] Internet-Draft Reality as a Cryptographic Dependency October 2026 * Core IEV / Three-Part document: defines the IEV, evidence intake, independent validation, expected-versus-observed comparison, continuation validation instruction (CVI), multi-phase repetition, human escalation, automatic remediation, reconciliation, crash recovery, replay protection, anti-bypass, and pseudocode. * Software / VM / OS document: shows that the validator can be an isolated VM, microVM, daemon, privileged OS service, Android or iOS-associated protected service, Windows service, enclave, remote validator, app/backend combination, or distributed validator set. Changing validator placement does not change the causal sequence if protected validation remains mandatory. * Taint / boundary-surrogation document: adds origin attribution, semantic/process/provenance taint, taint propagation, lower-trust execution domains, surrogate or credential-reference handling, just-in-time protected credential resolution at an effectuation boundary, privilege-separated connector workers, destination verification, classifier inputs, and IEV-gated continuation. Canonical IEV relationship: E_i -> R_i -> IEV_i -> Gamma_(i+1) -> FS_(i+1) -> E_(i+1) Where: E_i = earlier real effect R_i = protected effect evidence IEV_i = protected independent interim validation Gamma_(i+1) = required continuation condition FS_(i+1) = next Finality Sink / effect-capable boundary Receipt existence != continuation authority Figure 2: IEV causal position 2.3. Topology-Independent and Alternative-Authority Closure Source The revised staged-effectuation specification adds T1-T12 alternative realizations so that the architecture is not artificially limited to a separate broker, explicit token, one process topology, or one authority direction. The closure material focuses on the technical condition that governs when a consequential effect may become effective, not on the name or physical placement of a component. The closure set includes a monolithic protected executor, implicit protected state with no token, direct human-signed exact acts, human re-origination after AI recommendation, structural/object-capability authority, native transaction-state enforcement, risk-selective Das Expires 4 April 2027 [Page 42] Internet-Draft Reality as a Cryptographic Dependency October 2026 mediation, post-effect compensation as a separate fallback mode, formally verified or attested runtimes inside protected envelopes, destination-local finality, quorum/consensus-native effectuation, and pre-authorized finite action graphs. 3. Executive Summary of Workflow Profiles E01-E35 This section gives an industry-readable summary of each workflow profile. The detailed source-derived workflow text remains in Appendix A; this summary is intended to let reviewers understand the progression and deployment coverage without reading every subsection first. 3.1. E01 — Single-Phase Protected Effectuation Single-phase protected effectuation. A Candidate Act is bound to protected authority and verified at the effect-capable boundary before the complete authorized effect occurs. It is the baseline for lower-risk or otherwise policy-approved cases where staged progression is unnecessary, while still preserving authority binding, sink-side verification, completion evidence, consumption, and anti- bypass. 3.2. E02 — Real Bounded Demonstration Effect, Verified Receipt, Then Full Effectuation Demonstration-then-full effectuation. The system performs a real bounded effect using the actual consequence-capable path, obtains protected confirmation evidence, and allows the broader/full effect only after that evidence is accepted. This differs from simulation because the first stage genuinely exercises the real path. 3.3. E03 — Real Demonstration Effect with Receipt-Gated Multi-Phase Progressive Effectuation Multi-phase progressive effectuation. Consequence grows through a protected sequence such as small -> medium -> broader -> full, with a receipt and continuation decision between phases. Each phase remains inside a maximum authorized envelope and cannot be skipped when policy marks intermediate phases as mandatory. Das Expires 4 April 2027 [Page 43] Internet-Draft Reality as a Cryptographic Dependency October 2026 3.4. E04 — Verified Demonstration Effect, Protected Human Approval, Then Broader or Full Effectuation Protected human continuation after a verified real effect. A human can review machine-verifiable evidence of what actually happened in the bounded phase before approving broader effectuation. The resulting human approval can be bound to the act, evidence, scope, destination, and current protected state. 3.5. E05 — Verified Demonstration Effect, Automatic Protected Decision, Then Receipt-Gated Continuation Automatic protected continuation. A machine policy engine evaluates authenticated receipts, risk, revocation, destination, device/sink state, and other protected predicates and can continue without contemporaneous human action when the configured conditions are satisfied. 3.6. E06 — Hybrid Human and Automatic Receipt-Gated Continuation Hybrid continuation. Human authority and machine validation can be combined, sequenced, or thresholded. For example, automatic policy may allow an initial bounded phase while a human is required for the full consequence, or a human may authorize the envelope while machine evidence remains mandatory between phases. 3.7. E07 — Software Protected Enforcement Domain Software Protected Enforcement Domain. Implements effectuation control in protected services, brokers, kernel-adjacent components, egress gates, database/storage gates, message brokers, or remote software services. It covers caller attribution, protected state, credential brokerage, late credential injection, and durable crash recovery. 3.8. E08 — Hardware Protected Enforcement Domain Hardware Protected Enforcement Domain. Moves authority, state, keys, counters, latches, or effect gates into secure hardware or hardware- rooted components so ordinary software cannot directly mint or bypass full effect authority. Das Expires 4 April 2027 [Page 44] Internet-Draft Reality as a Cryptographic Dependency October 2026 3.9. E09 — Split Software/Hardware Protected Enforcement Domain Split software/hardware PED. Software performs flexible policy, orchestration, and act preparation while hardware retains critical keys, latches, attestation, monotonic state, or final enablement. Neither side alone necessarily possesses unrestricted completion authority. 3.10. E10 — Receipt-Conditioned Hardware Cryptographic Key-Chain Effectuation Receipt-conditioned hardware cryptographic key chain. A hardware root or sealed secret derives/unseals later phase material only after protected evidence from the preceding real effect is accepted. The security property is receipt-dependent availability of later execution material, not a specific KDF. 3.11. E11 — Threshold / Multi-Party Cryptographic Continuation Threshold or multi-party continuation. No single participant has sufficient authority for the broader effect; a required subset of shares, approvals, or protected participants must contribute. This supports separation of duties, cross-domain control, and quorum-like security. 3.12. E12 — Message-SEND Demonstration / Trailer-Then-Full Effectuation Message-SEND demonstration. A real bounded trailer, verification object, or limited communication reaches the actual recipient path and produces a protected receipt before the full message, file, attachment, decryption key, or semantic payload is released. 3.13. E13 — Receipt-Gated File Transfer and Progressive File Release File transfer and progressive release. A bounded fragment, manifest, object, redacted subset, ciphertext, or storage event exercises the actual file path. Verified evidence then permits additional bytes, decryption material, publication, import, or full semantic access. 3.14. E14 — Payment Demonstration and Receipt-Gated Full / Progressive Payment Payment demonstration and progressive value transfer. A bounded financial state change -- such as a hold, reservation, capped transfer, verification credit, or partial settlement -- confirms the intended payee/rail/state before broader value transfer becomes available. Das Expires 4 April 2027 [Page 45] Internet-Draft Reality as a Cryptographic Dependency October 2026 3.15. E15 — Escrow / Conditional Settlement and Receipt-Gated Release Escrow and conditional settlement. Value, assets, keys, or authority enter a protected holding state and are later released, partially released, returned, or terminated only after the configured evidence and policy conditions are satisfied. 3.16. E16 — Receipt-Gated Database Commit, Provisional Persistence, and Promotion Database provisional persistence and promotion. A candidate mutation is applied to a bounded or provisional target, observed/read back, and promoted to authoritative or broader production state only after protected persistence evidence passes validation. 3.17. E17 — Receipt-Gated Cloud Deployment and Progressive Infrastructure Rollout Cloud deployment and progressive infrastructure rollout. A change can begin with one resource, tenant, zone, region, shard, or canary production unit. Health/effect evidence controls whether the deployment expands, pauses, rolls back, or terminates. 3.18. E18 — Receipt-Gated AI Model Deployment, Model Activation, and Progressive Consequence Release AI model deployment and activation. A model, adapter, inference service, or model-related production change is activated within a bounded scope before broader release. Receipts and health/safety conditions govern progressive exposure and can stop rollout when evidence diverges. 3.19. E19 — Receipt-Gated Tool Use and External Action Invocation AI tool-use effectuation. Tool selection or tool_use output is treated as a proposal, not invocation authority. The selected tool, operation schema, arguments, account, destination, and effect class can be bound to protected authority, with bounded real tool effects preceding broader invocation. 3.20. E20 — Progressive Credential Release and Receipt-Gated Authority Expansion Progressive credential release. Credentials, key shares, scoped tokens, or credential-use authority can grow only as protected evidence permits. The agent need not possess the unrestricted secret, and later credential scope can be withheld, unsealed, substituted, or activated at a protected boundary. Das Expires 4 April 2027 [Page 46] Internet-Draft Reality as a Cryptographic Dependency October 2026 3.21. E21 — Receipt-Gated Data Export, Progressive Disclosure, and Cryptographic Release Receipt-gated data export. Sensitive data can be progressively disclosed, encrypted, or semantically released. Destination commitment, policy, provenance, and receipt state can become prerequisites to releasing additional data or the key that makes previously delivered ciphertext usable. 3.22. E22 — Receipt-Gated Storage Release, Provisional Persistence, and Progressive Visibility Storage release and progressive visibility. Data may first enter provisional persistence or limited visibility. Storage-controller or durable-state evidence then controls replication, namespace promotion, destructive overwrite, wider visibility, or key release. 3.23. E23 — Receipt-Gated Robotic Actuation and Progressive Physical Effectuation Robotic actuation. A robot can execute bounded movement or interaction and return protected evidence before larger movement, force, duration, workspace, or task authority is enabled. The same pattern supports human, automatic, or hybrid progression. 3.24. E24 — Hardware Actuator, Protected Sensor Confirmation, and Receipt-Derived Motion Authority Sensor-confirmed hardware actuation. A protected sensor, encoder, current/pressure/position sensor, or safety controller measures the real physical result of a bounded command. Later motion authority depends on that measured result rather than only on command dispatch. 3.25. E25 — Receipt-Gated Vehicle Effectuation and Progressive Vehicular Authority Vehicle effectuation. Route, speed, steering, braking, control- transfer, and other vehicular authority can be progressively bounded. Protected vehicle state, safe-state sets, sensor evidence, device identity, phase keys, and dynamic environment changes determine whether authority expands. 3.26. E26 — Receipt-Gated UAV and Mobile-Robot Effectuation UAV and mobile-robot effectuation. Flight, navigation, speed, altitude, geofence, payload, mission, or mobile-robot action can proceed through bounded real phases with protected telemetry and state confirmation before broader mission authority is available. Das Expires 4 April 2027 [Page 47] Internet-Draft Reality as a Cryptographic Dependency October 2026 3.27. E27 — Receipt-Gated Industrial, PLC, Machine, and Process-Control Effectuation Industrial and PLC/process control. Machine, valve, motor, process setpoint, production-line, or plant action can be constrained to bounded steps, with sensor/PLC/controller evidence required before a larger or more irreversible process transition. 3.28. E28 — Receipt-Gated Telecom Effectuation and Progressive Network Authority Telecom effectuation. Live network actions -- subscriber rollout, traffic steering, service-chain changes, session establishment, slice/service-class changes, edge operations, or network-control actions -- can start in bounded scope and expand only after protected network evidence and policy checks. 3.29. E29 — Receipt-Gated Radio, Satellite, and Non-Terrestrial Network Effectuation Radio, satellite, and non-terrestrial network effectuation. RF transmission, satellite/NTN actions, spectrum/resource use, links, beams, routes, or session scope can be bounded and progressively expanded under protected radio/network evidence and local safety or policy constraints. 3.30. E30 — Receipt-Gated GPU, Accelerator, and Compute-Egress Effectuation GPU, accelerator, and compute-egress effectuation. Accelerator jobs, model outputs, tensor/data egress, device memory effects, or compute- to-external-action paths can be gated at GPU/accelerator/driver/DPU boundaries, with protected evidence controlling larger or externally visible effects. 3.31. E31 — Receipt-Gated Model-State Update, Protected Memory Commit, and Progressive Model-State Effectuation Model-state and protected-memory update. Persistent memory, vector- store state, parameters, adapters, policy state, or other model- associated state can be written provisionally and evaluated before promotion to authoritative state. The model must not self-authorize broader state mutation merely by writing its own control data. Das Expires 4 April 2027 [Page 48] Internet-Draft Reality as a Cryptographic Dependency October 2026 3.32. E32 — Receipt-Gated Software, Firmware, and Configuration Update with Progressive Activation Software, firmware, and configuration update. Update rollout can use staged activation, measured health, rollback preservation, device cohorts, version binding, and receipt-gated promotion so a bad update does not immediately become universal. 3.33. E33 — Multi-Destination, Multi-Recipient, Multi-Sink, and Distributed Receipt-Gated Effectuation Multi-destination, multi-recipient, and multi-sink effectuation. One Candidate Act can span several targets while preserving target- specific receipts, partial success semantics, aggregate continuation conditions, and rules for whether all, some, or a defined subset must succeed. 3.34. E34 — Replicated, Quorum-Confirmed, and Consensus Receipt-Gated Effectuation Replicated, quorum-confirmed, and consensus receipt-gated effectuation. Multiple replicas or validators contribute evidence or votes; weighted/role-constrained quorum, membership/version binding, split-brain detection, critical replica requirements, Byzantine handling, and commit certificates govern broader effectuation. 3.35. E35 — Negative, Indeterminate, Conflict, Reconciliation, and Recovery Receipt-Gated Effectuation Negative, indeterminate, conflict, reconciliation, and recovery. The architecture distinguishes proven effect, proven non-effect, partial effect, conflicting evidence, and still-indeterminate outcomes. It blocks blind retry, supports evidence re-query and reconciliation, and only resumes progression when a protected recovery rule establishes an acceptable state. 4. Detailed Interim Effectuation Validator (IEV) Integration Summary The IEV is a protected logical or physical validation function placed in the causal path between evidence of one real effect and authority for a later effect. It does not have to relay the original command and does not have to be a physically separate device. Its defining property is that later effectuation is made technically dependent on its protected evaluation of authenticated evidence from the preceding phase. Das Expires 4 April 2027 [Page 49] Internet-Draft Reality as a Cryptographic Dependency October 2026 A -> FS_0 -> E_0 -> R_0 -> IEV_0 -> Gamma_1 -> FS_1 -> E_1 | +-- on mismatch -> HOLD / RECONCILE / REDUCE / REMEDIATE / HUMAN / SAFE_STATE / TERMINATE Figure 3: IEV operational position 4.1. Evidence Intake and Independent Decision The IEV receives an Interim Validation Input Record or equivalent authenticated evidence that can bind the Candidate Act, phase, prior authority, expected and observed effect, sink, destination, observer, resource, transaction identifier, nonce, counter, policy epoch, result code, receipt digest, and time. It then determines whether the earlier effect occurred at the expected place, through an authorized boundary, with an acceptable result and sufficiently current protected state. IEVPass_i = AuthValid(R_i) AND ActMatch(R_i, D_A) AND PhaseMatch(R_i, i) AND SinkMatch(R_i, FS_i) AND DestinationMatch(R_i) AND Fresh(R_i) AND NOT Consumed(R_i) AND EffectAcceptable(O_i, X_i) AND PolicyCurrent AND RevocationClear AND WithinEnvelope(P_(i+1)) Figure 4: Illustrative IEV acceptance predicate 4.2. Continuation Condition and Cryptographic Missing Material On PASS, the IEV can create a Continuation Validation Instruction, protected state transition, key or key share, secure-mailbox entry, hardware latch, transaction role, database state, network permit, actuator enablement, or another protected condition. A stronger implementation makes the next phase cryptographically incomplete without an IEV-controlled secret or share derived from the accepted receipt. Das Expires 4 April 2027 [Page 50] Internet-Draft Reality as a Cryptographic Dependency October 2026 CVI_(i+1) = Protect_KIEV( D_A || H(R_i) || (i+1) || Scope_(i+1) || FS_(i+1) || Destination_(i+1) || PolicyEpoch || Counter || Expiry) Optional receipt-derived material: K_(i+1) = KDF(K_IEV_root, D_A, H(R_i), i+1, FS_(i+1), Counter) Optional split authority: K_final_(i+1) = Combine(K_FS_(i+1), K_IEV_(i+1)) Figure 5: Receipt-bound continuation examples 4.3. Validator Placement and Substitution Invariance The IEV may be a protected process, daemon, kernel-adjacent service, VM, microVM, hypervisor service, Android or iOS-associated protected component, Windows service, TEE/enclave, HSM, DPU/SmartNIC, modem/ baseband security processor, storage or transaction controller, remote service, destination-side service, or distributed validator set. Moving the validator changes topology and assurance assumptions, but it does not change the functional sequence so long as the next protected effect still depends on validated evidence from the earlier real effect. ValidatorLocation != ValidatorFunction ChangeOfValidator != ChangeOfFunctionalSequence For conforming realization v: E_i -> R_i -> V_i^(v) -> Gamma_(i+1)^(v) -> FS_(i+1) -> E_(i+1) Figure 6: Validator-substitution invariant 4.4. Taint, Origin Attribution, and Boundary Credential Surrogation A lower-trust agent or application can be isolated from the protected credential and effectuation domain. The protected boundary may attribute a request to its originating process, track semantic/process/provenance taint, and require a non-authoritative surrogate credential, handle, alias, or reference. Only after protected checks does the boundary resolve or use the real credential. The real secret need not be exposed to the agent. Das Expires 4 April 2027 [Page 51] Internet-Draft Reality as a Cryptographic Dependency October 2026 tau_out = Join(tau_process, tau_input_1, ..., tau_input_n) UnableToValidateTaint => UNVERIFIABLE sigma_i != K_real_i K_real_i not in Memory(D_A_domain) Boundary resolution: sigma_i --[origin + taint + policy + destination + scope checks]--> use(K_real_i) For a later phase: SurrogateValid AND ContinuationValid(Gamma_(i+1)) AND PolicyCurrent AND RevocationClear AND TaintAcceptable -> boundary may use real credential Figure 7: Taint and protected credential boundary 4.5. Failure, Remediation, and Human Escalation A mismatch is not automatically converted into a retry or full continuation. The IEV can enter reconciliation, request stronger evidence, authorize a bounded diagnostic or reduced-scope phase, invoke automatic remediation, request protected human review, quarantine the operation, compensate or roll back where appropriate, or terminate. Human approval is preferably returned through a protected channel and bound to the observed evidence and requested continuation scope rather than treated as unrestricted authority handed to the proposing agent. 5. Detailed Design-Around / Implementation-Equivalence Closure (T1-T12) This section restates the topology-independent and alternative- authority realizations as implementation-equivalence closures. The intent is to make clear that the execution-finality property is defined by protected control of consequential state transitions, not by a requirement for one named broker, one token, one direction of authority flow, or physical separation between components. 5.1. T1 — Monolithic Protected Executor A single protected executor may identify the act, evaluate policy, choose and perform a bounded effect, observe the result, advance protected state, and perform the broader effect. No visible PED-to- token-to-sink chain is required. The non-skippable protected predecessor state is the controlling property. PROPOSED -> VALIDATED -> PARTIAL_EFFECT -> CONFIRMED -> FULL_EFFECT Das Expires 4 April 2027 [Page 52] Internet-Draft Reality as a Cryptographic Dependency October 2026 Figure 8: T1 — Monolithic Protected Executor 5.2. T2 — Implicit-State / No-Token Authority Continuation authority may exist only as protected internal state rather than as a transferable capability or token. An atomic state bit, database state, transaction role, register, latch, counter, secure-monitor state, consensus state, or commit-time predicate can be sufficient. EnableFull := (ProtectedState == CONFIRMED) AND PolicyCurrent AND RevocationClear Figure 9: T2 — Implicit-State / No-Token Authority 5.3. T3 — Direct Human-Signed Exact Act A protected human authenticator may sign the exact consequential act or authorized envelope. The destination or effect boundary verifies the signature and act binding directly. In a staged version, the human can sign continuation after reviewing receipt-bound evidence from the earlier real effect. HumanAuthenticator -> ExactActSignature -> SinkVerification -> Effect Figure 10: T3 — Direct Human-Signed Exact Act 5.4. T4 — Human Re-Originated Operation After AI Recommendation The AI can be technically incapable of executing the consequence. It provides a recommendation or non-authoritative descriptor; a human then uses a separate trusted application to originate a new act. The resulting human-originated act can still use single-phase or receipt- gated finality. 5.5. T5 — Structural Capability / Object-Capability / Typed Authority Authority can be encoded structurally in object capabilities, typed tool/resource handles, language-level effect types, memory-safe capabilities, namespace-limited descriptors, kernel-enforced handles, or hardware protection domains. Receipt validation can expand, replace, narrow, or revoke the authority graph without creating a bearer finality token. AuthorityGraph_i + ValidReceipt_i -> ProtectedTransition -> AuthorityGraph_(i+1) Figure 11: T5 — Structural Capability / Object-Capability / Typed Authority Das Expires 4 April 2027 [Page 53] Internet-Draft Reality as a Cryptographic Dependency October 2026 5.6. T6 — Native Transactional Invariant / Commit-State Enforcement A database, payment service, message system, cloud control plane, storage engine, tool service, or other transactional destination can embed the staged condition directly into its native state machine. An external Finality Sink process is unnecessary if the transaction engine itself refuses invalid state transitions. PROVISIONAL -> OBSERVED/VERIFIED -> COMMITTABLE -> COMMITTED Figure 12: T6 — Native Transactional Invariant / Commit-State Enforcement 5.7. T7 — Risk-Selective or Consequence-Selective Mediation Not every operation must be staged. Protected policy can classify lower-consequence, reversible, pre-authorized, or structurally bounded acts for direct execution while routing high-value, novel- destination, tainted, irreversible, safety-critical, or otherwise selected acts through staged finality. Classify(Act) -> {DIRECT_WITHIN_ENVELOPE | STAGED_EFFECTUATION | DENY} Figure 13: T7 — Risk-Selective or Consequence-Selective Mediation 5.8. T8 — Post-Effect Compensation as Ancillary or Fallback Where pre-effect staging is unavailable or explicitly waived within policy, an authorized effect may occur first and protected post- effect evidence may trigger compensation, rollback, retraction, quarantine, or other remediation. This mode is not treated as equivalent to required pre-effect receipt-gated continuation and must not silently downgrade a class that policy marks as requiring staging. 5.9. T9 — Formally Verified / Attested / Deterministic Runtime Within a Protected Envelope A measured, formally verified, deterministic, secure-booted, or policy-restricted runtime can be granted a pre-authorized bounded envelope wider than an ordinary probabilistic agent. Changed destination, taint, revocation, policy, environment, or higher- consequence operations can still force staged validation or renewed human approval. Das Expires 4 April 2027 [Page 54] Internet-Draft Reality as a Cryptographic Dependency October 2026 5.10. T10 — Native Destination Policy and Destination-Local Finality The destination can combine policy evaluation, exact-act verification, effect gating, receipt generation, and final commitment. It may perform the bounded first effect and advance its own protected state before allowing broader effect, or return a signed receipt that unlocks upstream authority. 5.11. T11 — Replicated / Quorum / Consensus-Native Effectuation Multiple replicas, validators, observers, controllers, or organizations can jointly establish confirmation and continuation. The controlling state may be a quorum certificate, threshold signature, replicated log entry, consensus commit index, or fault- tolerant transition; a separate per-sink receipt token is optional. ValidVotesOrReceipts >= RequiredQuorum -> CommitCertificate/ConfirmedState -> BroaderEffect Figure 14: T11 — Replicated / Quorum / Consensus-Native Effectuation 5.12. T12 — Pre-Authorized Finite Action Machine / Bounded Action Graph A protected principal can authorize a finite or bounded graph of states and transitions before autonomous operation begins. The agent may choose only protected authorized edges from the current state. Receipts can unlock later edges, consume one-time edges, move the protected state pointer, or reduce the remaining graph. G = (V,E); E_authorized is a protected subset of E Figure 15: T12 — Pre-Authorized Finite Action Machine / Bounded Action Graph 5.13. Cross-Cutting Closure Rule T1-T12 may be combined. A monolithic destination can use no transferable token, enforce continuation as native transaction state, accept a direct human exact-act signature, operate within a pre- authorized action graph, and rely on quorum replication. Conversely, a structural-capability operating system can expose only bounded objects until destination-local evidence or consensus state unlocks broader objects. The number of components, token format, direction of authority flow, and physical placement are therefore implementation choices when the selected mode preserves its protected predecessor and continuation conditions. Das Expires 4 April 2027 [Page 55] Internet-Draft Reality as a Cryptographic Dependency October 2026 Implementation substitution does not change the protected causal invariant: RealEffect_i -> ProtectedEvidence_i -> ProtectedValidation_i -> RequiredContinuationCondition_(i+1) -> EffectCapableBoundary_(i+1) -> RealEffect_(i+1) Examples of equivalent realization changes: separate broker -> monolithic executor explicit CVI/token -> protected state / latch / transaction role local validator -> remote / destination / quorum validator software gate -> kernel / TEE / HSM / DPU / controller gate bearer credential -> handle / alias / non-exportable credential use one sink receipt -> quorum certificate / consensus state universal staging -> consequence-selective protected staging Figure 16: Implementation-equivalence closure 6. Internet-Draft Integration Summary The consolidated Internet-Draft is organized so that an implementer can first understand the common safety and execution-finality invariants, then select a workflow profile, then choose an IEV and enforcement realization appropriate to the platform, and finally apply topology-independent closure rules so an alternate implementation path does not accidentally bypass the selected security property. 1. Select the consequence class and maximum authorized envelope. 2. Select single-phase protected effectuation or a staged E01-E35 profile. 3. Bind the Candidate Act and protected state needed by the selected profile. 4. Choose one or more effect-capable Finality Sinks and protected evidence sources. 5. Where inter-phase independent judgment is required, insert an IEV or equivalent protected interim-validation function. 6. Choose continuation representation: explicit instruction, key/ share, protected state, transaction state, hardware latch, structural capability, destination-local state, quorum certificate, or another protected realization. Das Expires 4 April 2027 [Page 56] Internet-Draft Reality as a Cryptographic Dependency October 2026 7. Apply anti-replay, anti-substitution, crash/indeterminate, and alternate-path closure requirements. 8. For critical-system use, apply the Safety-First Critical-System Profile so mandatory protections cannot be removed solely to reduce latency. This structure is intentionally implementation-neutral: the protocol- level property is the protected causal dependency between authority, real effect, evidence, validation, and subsequent effectuation. Product names, component count, process topology, and one specific cryptographic primitive are not part of the functional definition unless a selected deployment profile makes them mandatory. 7. Conventions and Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals. The workflow profiles in Appendix A include source-derived implementation detail. Unless a profile explicitly states that a property is required for the selected profile, examples of components, algorithms, products, physical placement, and mechanism names are non-limiting implementation choices. BCP 14 comprises [RFC2119] and [RFC8174]. 8. Terminology and Formal Notation Candidate Act (A) A proposed operation whose consequence may become externally effective. Canonical Act (A_C) A deterministic or otherwise stable representation of A used for binding. Act Digest (D_A) A protected identifier, for example D_A = H(Canon(A)). Protected Enforcement Domain (PED) A protected software, firmware, hardware, network, transaction, or mixed domain that evaluates or enforces effectuation conditions. Finality Sink (FS_i) The effect-capable boundary that can make phase i consequential. Phase (P_i) A single protected effectuation stage in a staged plan. Das Expires 4 April 2027 [Page 57] Internet-Draft Reality as a Cryptographic Dependency October 2026 Bounded Trial Effect (BTE) A real, limited effect used before broader effectuation; it is not merely a simulation or prediction. Observed Effect (O_i) The protected observation of what actually occurred in phase i. Expected Effect (X_i) The result or property set expected for phase i. Effect Confirmation Receipt (R_i or ECR) Machine-verifiable evidence describing a real phase effect, its binding, and relevant protected state. Continuation Authority (Gamma_{i+1}) Any protected capability, key, key share, latch, permit, transaction state, credential state, signed instruction, or equivalent condition required for phase i+1. Maximum Effectuation Envelope (E_MAX) The maximum cumulative consequence or scope authorized for the act. Indeterminate State A state in which the system cannot prove either that an effect occurred as required or that it did not occur. Alternate-Path Closure The requirement that an act-equivalent path cannot bypass a protected finality condition when that condition is mandatory. A_C = Canon(A) D_A = H(A_C) P_i = protected real effectuation phase i O_i = observed result of phase i X_i = expected result of phase i R_i = protected receipt/evidence for phase i Gamma_i = continuation condition for phase i Scope(P_i) <= E_MAX Figure 17: Normalized notation Das Expires 4 April 2027 [Page 58] Internet-Draft Reality as a Cryptographic Dependency October 2026 9. Threat and Consequence Model The architecture assumes that a proposing model or application may be mistaken, compromised, manipulated by untrusted input, operating on stale state, or correctly authorized at one point while external state changes before effectuation. It also assumes that a downstream component can fail, partially execute, route to an unexpected destination, return an ambiguous result, or expose an alternate path that bypasses an intended control. * Act or parameter substitution between authorization and effectuation. * Wrong recipient, destination, device, route, object, amount, or resource. * Replay or duplicate execution after a crash or uncertain outcome. * Partial execution that is incorrectly treated as complete success. * Policy or revocation changes between phases. * Tainted, untrusted, or conflicting provenance that affects a consequential action. * Credential misuse or privilege expansion beyond the authorized phase. * Alternate APIs, sockets, drivers, administrative paths, credentials, or hardware interfaces that bypass the protected path. * Replica divergence, split brain, quorum ambiguity, and conflicting authentic receipts. * Physical-system deviations in motion, energy, position, route, sensor state, or safe-state constraints. 10. Safety-First Critical-System Profile This profile is intended for sensitive work and critical-system deployments in which safety and security are the primary optimization criteria and minimum latency is not. The profile does not require unnecessary delay. It requires that latency optimization remain subordinate to mandatory safety and finality conditions selected by policy. Das Expires 4 April 2027 [Page 59] Internet-Draft Reality as a Cryptographic Dependency October 2026 Safety-first optimization (conceptual): 1. Minimize risk of unauthorized, catastrophic, irreversible, or materially misdirected effect. 2. Preserve the authorized mission and bounded operating envelope. 3. Minimize latency subject to (1) and (2). In shorthand: Safety / Effect Correctness / Containment > Minimum Latency for deployments that select this profile. Figure 18: Safety-first priority ordering 10.1. Mandatory Safety-First Properties * An UNKNOWN or INDETERMINATE result MUST NOT be interpreted as successful effectuation. * A timeout MUST NOT automatically increase authority or release a broader phase. * A required receipt or protected observation MUST NOT be replaced by a local success assertion from the proposing agent. * Where a later phase is receipt-gated, that phase MUST remain technically unavailable until its protected continuation predicate is satisfied. * Current revocation, policy, destination, and envelope conditions MUST be rechecked when the selected workflow requires effectuation-time freshness. * Unsafe or unresolved states SHOULD transition to a defined safe state, fail-limited state, reconciliation state, or protected human/automatic escalation path. * Required anti-replay and alternate-path controls MUST NOT be disabled solely to reduce latency. Das Expires 4 April 2027 [Page 60] Internet-Draft Reality as a Cryptographic Dependency October 2026 10.2. Latency Reduction Without Safety Reduction Latency-sensitive critical systems can preserve the safety model while reducing overhead. The workflow set explicitly allows local low-latency enforcement, hardware-rooted gates, split software/ hardware designs, pre-authorized envelopes, automatic continuation, parallel or quorum evidence, protected counters, destination-local enforcement, and receipt-derived key material. * Place the Finality Sink and receipt verifier close to the effect- capable device or transaction engine. * Pre-authorize a bounded operating envelope so that safe phases can progress automatically without repeated human interaction. * Use protected hardware, secure elements, HSMs, TEEs, DPUs, SmartNICs, storage controllers, or local safety controllers for fast checks. * Collect independent evidence in parallel where policy permits. * Use phase sizes proportionate to consequence and confidence rather than a fixed small phase for every operation. * Use single-phase E01 when staging is not required by the consequence model. 11. Core Execution-Finality Architecture 11.1. Candidate Act Binding A Candidate Act SHOULD be represented sufficiently precisely that a protected component can determine whether a later operation is the same authorized act, a permitted member of an authorized act class, or a materially different act. A canonical representation and digest are one implementation. A_C = Canon(A) D_A = H(A_C) Authority(A) does not imply Authority(B) for a materially different unauthorized B. Figure 19: Act-binding relationship Das Expires 4 April 2027 [Page 61] Internet-Draft Reality as a Cryptographic Dependency October 2026 11.2. Protected Validation and Effectuation Boundary The PED evaluates the protected state applicable to the act. The Finality Sink performs local verification before making the operation externally consequential. The sink may be an API gateway, network egress gate, payment gateway, database commit engine, storage controller, message broker, kernel or syscall boundary, device controller, GPU or accelerator gate, DPU/SmartNIC, radio controller, secure monitor, or another effect-capable component. 11.3. Single-Phase Mode In E01, protected policy may permit the complete authorized effect in one phase. Even in this mode, proposal and effectuation remain distinct, and the sink verifies the required authority and local protected state before the effect occurs. A completion receipt may be produced afterward. Candidate Act -> Protected Validation -> Effectuation Authority -> Finality Sink -> Authorized Effect -> Completion Evidence Figure 20: Single-phase flow 11.4. Staged Real Effectuation In E02 and later staged workflows, the first phase is a real effect at the actual or policy-relevant effectuation path. It is not merely a dry run, simulation, prediction, or local preview. The first authority is deliberately bounded so that successful execution of P_0 does not by itself imply authority for the full consequence. Candidate Act -> Phase-0 Authority C_0 -> Finality Sink FS_0 -> Real Bounded Effect P_0 -> Observed Effect O_0 -> Protected Receipt R_0 -> Receipt Validation -> Continuation Authority Gamma_1 -> Broader Effect P_1 Figure 21: Demonstration-then-continuation flow Das Expires 4 April 2027 [Page 62] Internet-Draft Reality as a Cryptographic Dependency October 2026 11.5. Effect Observation and Receipt A receipt MAY bind the act digest, phase identifier, observed result, sink, destination, device, route, transaction identifier, nonce, counter, time, policy epoch, revocation epoch, previous receipt digest, and other protected state. The receipt can be signed, MAC- protected, attested, sealed, hash-linked, ledger-anchored, threshold- protected, or represented by protected state in a transaction system or device. R_i = Protect( D_A || Phase_i || O_i || Sink_i || Destination_i || Nonce_i || Counter_i || PolicyEpoch_i || H(R_{i-1}) ) H(R_{i-1}) is optional when another protected sequence-binding mechanism provides equivalent phase ordering. Figure 22: Illustrative receipt construction 11.6. Expected-vs-Observed Validation Validation may use exact equality, tolerance, range, authorized-set membership, semantic equivalence, sensor predicates, transaction- state predicates, or a protected predicate set appropriate to the effect type. Exact: O_i = X_i Tolerance: d(O_i, X_i) <= epsilon_i Range: L_i <= O_i <= U_i Set: O_i in A_i Predicate: AND_k Q_{i,k}(O_i) = TRUE Figure 23: Representative effect comparison models 11.7. Receipt-Gated Continuation A valid receipt is evidence, not an unconditional command to proceed. Protected policy may additionally require current policy, revocation, risk, taint, destination, envelope, human approval, threshold, hardware, or other conditions. If any mandatory condition is FALSE, continuation is denied. If a mandatory condition is UNKNOWN or INDETERMINATE, the safety-first profile does not treat it as success. Das Expires 4 April 2027 [Page 63] Internet-Draft Reality as a Cryptographic Dependency October 2026 Enable(P_{i+1}) = AuthValid(R_i) AND MatchAct(R_i, D_A) AND MatchPhase(R_i, i) AND Fresh(R_i) AND EffectAcceptable(O_i, X_i) AND PolicyCurrent AND RevocationClear AND WithinEnvelope(P_{i+1}) AND ApprovalSatisfied_{i+1} If any mandatory predicate is FALSE: Enable(P_{i+1}) = FALSE Figure 24: General next-phase predicate 11.8. Multi-Phase Progression E03 generalizes the architecture to any number of phases. Each successful phase can produce a new receipt and a phase-specific authority for the next phase. Phase authority SHOULD NOT be valid for a later or broader phase unless policy explicitly makes the phases equivalent. P_0 -> R_0 -> Gamma_1 -> P_1 -> R_1 -> Gamma_2 -> ... -> P_n Scope(P_i) <= E_MAX Mandatory stages cannot be skipped: P_i -/-> P_{i+2} without the required receipt and continuation transition for P_{i+1}. Figure 25: Progressive effectuation chain 11.9. Atomic State Advancement and Receipt Consumption Where replay or double-use is unsafe, the protected controller SHOULD atomically consume the accepted receipt, advance the phase state, increment any protected counter, and establish the next continuation condition. The same receipt MUST NOT independently enable the same single-use progression twice. Das Expires 4 April 2027 [Page 64] Internet-Draft Reality as a Cryptographic Dependency October 2026 ATOMIC { verify R_i assert R_i not consumed mark R_i consumed advance phase from i to i+1 increment protected counter establish Gamma_(i+1) commit protected state } Figure 26: Illustrative atomic phase advancement 12. Approval and Decision Modes 12.1. Protected Human Continuation A human may approve before any effect, after a verified bounded effect, between every phase, or only for selected consequence classes. When human approval is a required security predicate, the approval SHOULD be separately authenticated and bound to the relevant act, receipt, destination, scope, phase, expiry, and protected context. Text generated by the proposing agent is not itself proof that a protected human approval occurred. 12.2. Automatic Continuation Automatic continuation may be used when protected machine-verifiable predicates succeed. This enables safety-first operation without requiring a human in every loop. Automatic progression may depend on receipt quality, destination confidence, risk, taint, policy epoch, revocation state, value limits, device state, route identity, and other protected evidence. 12.3. Hybrid and Multi-Authority Continuation Hybrid workflows can require both automatic checks and human approval, or can vary by phase and consequence threshold. Threshold workflows can require m-of-n cryptographic or role-constrained contributions so that no single participant possesses sufficient authority for the broader effect. Hybrid example: Continue = AutoPass AND HumanPass Threshold example: Continue = (sum_j ValidShare_j >= m) AND RequiredRolesPresent Das Expires 4 April 2027 [Page 65] Internet-Draft Reality as a Cryptographic Dependency October 2026 Figure 27: Hybrid and threshold predicates 13. Protected Enforcement Domains 13.1. Software PED E07 places protected validation and effectuation control in software. Example mechanisms include privilege-separated services, operating- system identities, kernel or syscall gates, network proxies, database and storage gates, message brokers, transaction managers, eBPF/ security hooks, mandatory-access-control systems, remote services, and software attestation. The security property is functional: the proposing process cannot directly obtain or exercise the protected authority required for an unauthorized effect. 13.2. Hardware PED E08 places protected state or effectuation control in hardware, including secure elements, HSMs, TEEs, secure enclaves, security processors, DPUs, SmartNICs, storage controllers, GPU/accelerator security components, or hardware latches and counters. Hardware may retain non-exportable authority material and release or use it only after required protected conditions are satisfied. 13.3. Split Software/Hardware PED E09 divides functions between software and hardware. Software may perform higher-level policy and act interpretation while hardware protects keys, counters, latches, effectuation material, or final sink enforcement. A split-key or split-state design can require both domains for a later phase. 14. Cryptographic and Distributed Continuation 14.1. Receipt-Conditioned Key Chains E10 permits later-phase authority to be derived, unsealed, activated, or made usable only after a preceding receipt is accepted. The important property is causal dependence, not a specific KDF. K_(i+1) = KDF(K_root, D_A, H(R_i), i+1, Sink_(i+1), Counter) If R_i is not accepted, K_(i+1) remains unavailable, sealed, incomplete, or invalid. Figure 28: Receipt-conditioned key derivation Das Expires 4 April 2027 [Page 66] Internet-Draft Reality as a Cryptographic Dependency October 2026 14.2. Threshold Continuation E11 distributes continuation authority across multiple participants or protected domains. A later phase can require a threshold signature, key-share combination, quorum certificate, or other multi- party protected condition. 14.3. Replicated and Quorum-Confirmed Effectuation E34 applies receipt gating to replicated and consensus-oriented effects. Replica-specific receipts may be aggregated under simple quorum, weighted quorum, role-constrained quorum, or consensus rules. Membership version, state version, fencing epoch, split-brain state, lag, critical-replica requirements, and conflicting aggregate certificates may affect whether continuation is permitted. Simple quorum: sum_j Valid(R_i^j) >= m Weighted quorum: sum_j w_j * Valid(R_i^j) >= theta Safety extension: QuorumSatisfied AND NoCriticalContradiction Figure 29: Quorum examples 15. Sensitive-Work Workflow Families The following workflow families apply the same protected-effectuation model to sensitive or consequential work. Detailed source-derived workflow text appears in Appendix A. Communications and SEND E12 provides a trailer-then-full pattern in which a bounded object reaches the actual receiving path before the full message, file, attachment, or semantic payload becomes available. File Release E13 stages file transfer, storage, recipient-path verification, decryption, or visibility before broader semantic release. Payments and Conditional Settlement E14 and E15 cover bounded payment-rail effects, reservations, partial settlements, escrow or conditional holding, followed by evidence-gated release. Database and Storage E16 and E22 use provisional persistence or Das Expires 4 April 2027 [Page 67] Internet-Draft Reality as a Cryptographic Dependency October 2026 visibility, protected receipts, and promotion to authoritative or broader state. Cloud and Model Deployment E17 and E18 stage infrastructure rollout and AI model activation so that a bounded production effect can be observed before broader consequence. AI Tool Use E19 treats tool proposal as distinct from invocation authority and supports bounded real tool interaction, tool identity binding, schema validation, receipt consumption, and alternate-tool-path closure. Credential Release E20 progressively expands credential authority while withholding unrestricted credential material from the proposing agent where required. Data Export E21 stages disclosure by chunk, field, record, ciphertext, or key release and can bind progression to destination handling-state evidence. Robotics and Actuation E23 and E24 bind progressive physical motion to sensor-confirmed real effects, safety envelopes, hardware latches, counters, power-stage or bus-level enforcement, and safe- state handling. Vehicles, UAVs, and Industrial Control E25 through E27 apply receipt-gated progression to routes, speed, steering, flight or mobile-robot operation, PLCs, machines, and process control. Telecom, Radio, Satellite, and NTN E28 and E29 stage network authority, traffic steering, service classes, radio transmission, satellite or non-terrestrial effects, and multi-domain progression. GPU / Accelerator / Compute Egress E30 gates consequential accelerator egress, protected compute outputs, or related effect- capable paths. Model-State and Memory Updates E31 separates provisional and authoritative model state and prevents self-authorization through state mutation. Software, Firmware, and Configuration Updates E32 progressively activates updates and supports rollback or safe-state handling when health or receipt predicates fail. Multi-Destination and Distributed Effectuation E33 provides Das Expires 4 April 2027 [Page 68] Internet-Draft Reality as a Cryptographic Dependency October 2026 destination-specific receipts, scopes, sinks, and continuation rules for fan-out or distributed effects. Negative, Indeterminate, Conflict, and Recovery E35 defines conservative handling for negative evidence, unknown outcomes, conflicting authentic evidence, reconciliation, recovery, and safe retry decisions. 16. Failure, Indeterminate State, and Recovery 16.1. No Blind Retry When a consequential phase may have occurred but no trustworthy receipt is available, a retry can duplicate the external consequence. The controller SHOULD reconcile using transaction identifiers, nonces, idempotency identifiers, sink or destination queries, protected journals, device state, counters, replicated state, or other protected evidence before deciding whether retry is safe. if effect_may_have_occurred and receipt_missing: outcome = RECONCILE(act_digest, phase, nonce, transaction_id) if outcome == PROVEN_EFFECTED: reconstruct_or_recover_evidence() validate_before_continuation() elif outcome == PROVEN_NOT_EFFECTED: authorize_new_bounded_retry_with_fresh_state() elif outcome == PARTIALLY_EFFECTED: calculate_residual_or_compensating_action() else: keep_later_phase_blocked() Figure 30: Non-limiting reconciliation pseudocode 16.2. Conflicting Evidence Two receipts may both authenticate successfully while describing mutually inconsistent outcomes. Authentication alone therefore does not imply consistency. The safety-first profile treats unresolved critical contradictions as a reason to hold, reconcile, reduce scope, or escalate rather than blindly progress. AuthValid(R_a) AND AuthValid(R_b) AND NOT Consistent(R_a, R_b) => HOLD / RECONCILE / ESCALATE Authentic evidence != consistent evidence Figure 31: Conflicting evidence rule Das Expires 4 April 2027 [Page 69] Internet-Draft Reality as a Cryptographic Dependency October 2026 16.3. Safe-State and Compensation Physical, infrastructure, payment, database, software-update, and other stateful workflows may define rollback, compensation, quarantine, fail-limited behavior, or a bounded safe-state action. A compensating action is itself an effect and may require protected authorization and observation. 17. Anti-Substitution, Anti-Skip, and Alternate-Path Closure Security depends on controlling act-equivalent effect paths, not on naming a particular proxy or component. If a required protected path can be bypassed through a direct socket, alternate credential, administrative API, debug interface, recovery interface, database role, message queue, device driver, hardware register, fallback communications route, or another path capable of the same material consequence, that alternate path must be disabled, mediated, capability-limited, cryptographically locked, hardware-gated, transaction-gated, or subjected to equivalent finality checks. For every path q: EffectCapable(q) => RequireEquivalentFinalityControl(q) OR DisableMaterialEffect(q) For mandatory staged phases: P_i -/-> P_(i+2) without the required P_(i+1) state transition and protected evidence. Figure 32: Alternate-path closure 18. Generic Operational Algorithm Das Expires 4 April 2027 [Page 70] Internet-Draft Reality as a Cryptographic Dependency October 2026 FUNCTION EXECUTE_WITH_FINALITY(A, policy): D_A = HASH(CANONICALIZE(A)) E_MAX = policy.maximum_authorized_envelope(A) mode = policy.select_mode(A) if mode == SINGLE_PHASE: authority = PROTECTED_AUTHORIZE(A, E_MAX) return FINALITY_SINK.EFFECTUATE(A, authority) phase_plan = policy.form_phase_plan(A, E_MAX) for i in phase_plan: authority_i = ISSUE_PHASE_AUTHORITY(D_A, i, phase_plan[i]) effect_i = FINALITY_SINK[i].EFFECTUATE(phase_plan[i], authority_i) R_i = OBTAIN_PROTECTED_EFFECT_EVIDENCE(effect_i) result = VALIDATE_RECEIPT_AND_CURRENT_STATE( D_A, i, R_i, policy, E_MAX) if result == PASS: ATOMICALLY_CONSUME_AND_ADVANCE(R_i, i) continue if result == REDUCE_SCOPE: phase_plan = RESTRICT_REMAINING_PLAN(phase_plan) continue if result == HUMAN_REVIEW: result = PROTECTED_HUMAN_DECISION(D_A, R_i) if result permits bounded continuation: continue if result == RECONCILE: result = RECONCILE_EFFECT_STATE(D_A, i, R_i) if result becomes proven acceptable: continue if result == REMEDIATE: AUTHORIZE_ONLY_PROTECTED_REMEDIATION() continue only after new protected evidence ENTER_SAFE_OR_TERMINATED_STATE() return BLOCKED return FINAL_COMPLETION_STATE Figure 33: Generic safety-first effectuation algorithm Das Expires 4 April 2027 [Page 71] Internet-Draft Reality as a Cryptographic Dependency October 2026 19. Security Considerations This entire document describes security controls. Implementations must treat the effectuation boundary, protected state, receipt path, approval channel, credentials, counters, and recovery logic as security-sensitive components. * Forged receipts must be rejected by the selected authenticity mechanism. * Replayed receipts or continuation authorities must be rejected where single-use semantics apply. * Receipt substitution must be prevented by act, phase, sink, destination, route, resource, or equivalent binding as required by the profile. * A valid signature over the wrong operation must not be treated as authorization for the intended operation. * Policy and revocation changes between phases can invalidate previously acceptable evidence or continuation. * Unknown outcome must not silently convert into success. * The proposing agent must not be able to satisfy protected human approval merely by generating an approval-like statement. * Progressive credentials, keys, latches, or state transitions must not permit privilege expansion beyond the maximum authorized envelope. * Hardware roots, secure elements, TEEs, HSMs, DPUs, SmartNICs, or kernel gates do not remove the need to reason about their own compromise and bypass surfaces. * Distributed receipts require membership, epoch, split-brain, Byzantine, or conflicting-certificate handling appropriate to the deployment. * Physical systems require safe-state analysis because rollback may be impossible or itself consequential. * Latency optimizations must preserve mandatory safety checks in deployments selecting the Safety-First Critical-System Profile. Das Expires 4 April 2027 [Page 72] Internet-Draft Reality as a Cryptographic Dependency October 2026 20. Privacy Considerations Effect receipts can reveal sensitive information about recipients, devices, routes, transactions, locations, model state, user actions, infrastructure state, or operational history. Implementations SHOULD minimize receipt contents to the predicates required for the selected security policy. Hash commitments, selective disclosure, encrypted receipts, confidential logs, trusted hardware, or privacy-preserving proofs may be used where raw evidence would reveal unnecessary sensitive information. Progressive data-export and messaging workflows should distinguish proof that a protected effect occurred from unnecessary disclosure of the payload itself. Receipt retention and cross-domain sharing should be governed by the deployment privacy policy. 21. IANA Considerations This document makes no request of IANA. 22. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . 23. Informative References [DAS-MUSE-SENTINEL-GUIDE] Das, S., "Before Comparing Meta Muse / Sentinel, Read the Earlier DAS Disclosures: An AI-Assisted Primary-Source Technical Guide", Zenodo record 23040181 (resource type: Patent, open access), . Patent pending concept: Indian Patent Office application number 202631117633. Das Expires 4 April 2027 [Page 73] Internet-Draft Reality as a Cryptographic Dependency October 2026 Appendix A. Detailed Workflow Profiles E01-E35 This appendix preserves the detailed workflow structure derived from the twelve supplied Advanced Section 1 workflow documents. The material is normalized for RFCXML readability but retains the source terminology, sequence, implementation breadth, and non-limiting character. The common terminology in the main body governs where a workflow uses an inherited term without redefining it. A.1. E01 — Single-Phase Protected Effectuation A.1.1. E01.1 Purpose This embodiment provides the baseline protected-effectuation architecture for a Candidate Act that is permitted to proceed to its complete authorized consequence in a single effectuation phase. The embodiment is important because the disclosed architecture is not limited to trial-first, canary-first, or progressively phased execution. Where protected policy determines that staged execution is unnecessary, the complete authorized effect may be produced in one protected phase while retaining execution-finality controls. The basic relationship is: Candidate Act → P rotected V alidation → Effectuation Authority → Effectuation Boundary → Authorized Effect → Completion Evidence A.1.2. E01.2 Initial Actors and Functional Components The embodiment may include the following logical functions. A. Candidate Act Source The Candidate Act may originate from: * an AI agent; * foundation model; * autonomous agent; * application; * operating system; * workflow engine; * cloud controller; * telecom controller; Das Expires 4 April 2027 [Page 74] Internet-Draft Reality as a Cryptographic Dependency October 2026 * payment application; * database application; * robotic controller; * embedded controller; * human-operated application; * or another computational source. The Candidate Act Source does not become authoritative merely by generating the Candidate Act. B. Candidate Act Representation Component This component forms a machine-processable representation of the proposed act. It may identify, where applicable: * act type; * command; * tool; * target; * destination; * recipient; * resource; * payload; * amount; * object; * file; * database record; * API; * network endpoint; * device; * actuator; Das Expires 4 April 2027 [Page 75] Internet-Draft Reality as a Cryptographic Dependency October 2026 * requested consequence; * permitted scope; * user; * application; * model; * agent; * originating process; * purpose; * timing; * jurisdiction; * and associated authority context. C. Canonicalization / Exact-Act Binding Component Where exact representation is required, the Candidate Act may be transformed into a canonical representation: AC = Canon(A) and a digest may be formed: DA = H(AC ) The canonicalization operation is intended to prevent a later component from interpreting an ambiguously encoded act as a materially different act. Canonicalization may be replaced by another deterministic act-identification mechanism. REQUIRED PROPERTY: the effectuation authority must remain associated with the authorized act or authorized act class. OPTIONAL MECHANISM: canonical hash. A.1.3. E01.3 Protected Enforcement Domain Intake The Candidate Act or its bound representation is submitted to a Protected Enforcement Domain, abbreviated PED. The PED may be: * physically separate; * logically separate; * process-isolated; * privilege-separated; Das Expires 4 April 2027 [Page 76] Internet-Draft Reality as a Cryptographic Dependency October 2026 * hardware-isolated; * remotely hosted; * distributed; * or integrated with the effectuation component while maintaining protected state. The PED receives sufficient information to determine whether the Candidate Act may proceed. A.1.4. E01.4 Protected State Acquisition The PED may obtain current protected state relevant to the Candidate Act. Such state may include: * current policy; * revocation state; * credential state; * user authority; * recipient authorization; * device identity; * application identity; * process identity; * agent identity; * execution environment measurement; * resource state; * taint state; * provenance state; * transaction state; * geographic state; * jurisdiction state; * risk state; Das Expires 4 April 2027 [Page 77] Internet-Draft Reality as a Cryptographic Dependency October 2026 * prior receipt state; * rate limits; * spending limits; * capability state; * sink identity; * and temporal state. The protected state may be obtained from one or more local or remote sources. A.1.5. E01.5 Validation Predicate Formation The PED determines a predicate set applicable to the Candidate Act. Let: ΠA = {p1 , p2 , ... , pm } Each predicate may evaluate to: T RU E, F ALSE, U N KN OW N , IN DET ERM IN AT E depending on implementation. Examples include: p1 = U serAuthorized p2 = DestinationAllowed p3 = P olicyCurrent p4 = RevocationClear p5 = ResourceW ithinScope p6 = SinkT rusted p7 = RiskAcceptable The Candidate Act need not use every listed predicate. A.1.6. E01.6 Approval-Mode Determination The PED determines which approval class applies. Possible classes include: Mode A — Automatic Protected Approval Protected policy permits the act automatically if the required predicates succeed. Das Expires 4 April 2027 [Page 78] Internet-Draft Reality as a Cryptographic Dependency October 2026 Mode B — Protected Human Approval The Candidate Act requires authenticated human approval. The approval should preferably be bound to the specific act or permitted act scope. Mode C — Hybrid Approval Both automatic validation and human approval are required. For example: AU T O_P ASS ∧ HU M AN _P ASS Mode D — Multi-Authority Approval Two or more protected authorities may be required. Mode E — Previously Authorized Envelope A previous protected human or enterprise authorization may already define an execution envelope. The PED determines whether the Candidate Act falls within that envelope. A.1.7. E01.7 Automatic Approval Workflow Where automatic approval applies, the protected policy component evaluates the required predicates. The proposing agent itself need not possess authority to mark those predicates as satisfied. A successful decision may be represented as: DecisionA = ALLOW only where all mandatory protected conditions have reached an acceptable state. A failed decision may produce: DecisionA = DEN Y An unresolved condition may produce: DecisionA = HOLD or: DecisionA = IN DET ERM IN AT E A.1.8. E01.8 Protected Human Approval Workflow Where human approval is required, the PED may form a Protected Approval Object. The approval object may contain or bind: * Candidate Act digest; * meaningful act description; * recipient; * destination; * amount; Das Expires 4 April 2027 [Page 79] Internet-Draft Reality as a Cryptographic Dependency October 2026 * payload identity; * affected resource; * requested consequence; * permitted scope; * expiration; * nonce; * policy epoch; * current risk indication; * sink identity; * and other required context. The approval interface may be: * an operating-system UI; * separate security application; * secure mobile application; * hardware display; * trusted display; * enterprise approval console; * secure element; * remote authenticated approval service; * or equivalent protected interface. The AI agent’s ordinary conversation surface need not itself constitute the protected approval surface. The human may: * approve; * deny; Das Expires 4 April 2027 [Page 80] Internet-Draft Reality as a Cryptographic Dependency October 2026 * restrict scope; * delay; * request additional verification; * or require staged effectuation instead. A.1.9. E01.9 Selection of Single-Phase Mode After protected validation, the PED determines whether the Candidate Act may proceed as a single-phase act. The decision may depend upon: * risk; * consequence magnitude; * confidence in destination; * reversibility; * prior successful history; * recipient trust; * device attestation; * transaction type; * latency requirement; * user preference; * enterprise policy; * legal requirement; * operational requirement; * or other protected state. Where single-phase execution is selected: P haseCount = 1 and the complete permitted effect becomes: P1 = Aauthorized Das Expires 4 April 2027 [Page 81] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.1.10. E01.10 Formation of Effectuation Authority The PED may then create, release, derive, unseal, activate, or validate a bounded effectuation authority. This authority may comprise: * scoped capability; * Execution Handle; * digital signature; * MAC; * transaction authorization; * signing permission; * decryption material; * encryption material; * missing command material; * API authority; * protected state transition; * database state; * hardware latch; * secure monitor result; * device command authenticator; * key share; * network release state; * destination-side enablement state; * or another technical condition. The architecture does not require the authority to be a bearer token. Das Expires 4 April 2027 [Page 82] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.1.11. E01.11 Authority Binding Where applicable, the authority may be bound to: DA and additionally to one or more of: * sink; * destination; * recipient; * device; * process; * application; * hardware identity; * scope; * policy epoch; * revocation epoch; * nonce; * time window; * purpose; * resource; * consequence class; * transaction identifier. The general requirement is: Authority(A) ⇏ Authority(B) where B is an unauthorized materially different act. A.1.12. E01.12 Delivery to Effectuation Boundary The Candidate Act and/or required authority reaches an effect-capable boundary. The boundary may comprise: Das Expires 4 April 2027 [Page 83] Internet-Draft Reality as a Cryptographic Dependency October 2026 * network interface; * API gateway; * payment gateway; * database commit engine; * storage controller; * message broker; * operating-system kernel; * syscall boundary; * hardware driver; * secure monitor; * actuator controller; * robotic controller; * GPU; * DPU; * SmartNIC; * telecom gateway; * radio controller; * cryptographic module; * rendering system; * remote destination; * or another component capable of making the act externally consequential. This component performs the function of a Finality Sink or equivalent effectuation-control component. A.1.13. E01.13 Sink-Side Verification Before producing the effect, the sink verifies the required authority and local state. Sink-side verification may include: Das Expires 4 April 2027 [Page 84] Internet-Draft Reality as a Cryptographic Dependency October 2026 * act matching; * capability validity; * signature validity; * MAC validity; * nonce freshness; * expiration; * policy epoch; * revocation epoch; * recipient; * destination; * resource; * process; * hardware identity; * sink identity; * amount; * command; * payload; * transaction state; * phase identifier; * or protected local state. If sink-side verification fails: Effectuation = BLOCKED A.1.14. E01.14 Full Effectuation Upon successful verification, the complete authorized effect may occur. Examples: Das Expires 4 April 2027 [Page 85] Internet-Draft Reality as a Cryptographic Dependency October 2026 Communication The entire authorized message or file is transmitted. Payment The entire authorized payment is submitted or settled according to the applicable payment state. Database The authorized mutation becomes committed. Storage The authorized object becomes durably stored or externally accessible. Hardware The authorized physical command is executed. Telecom The authorized transmission or network-control action takes effect. AI Tool Invocation The authorized external tool operation is executed. A.1.15. E01.15 Completion Observation The system may obtain evidence describing whether the full effect occurred. Such evidence may originate from: * the sink itself; * destination; * receiving endpoint; * hardware sensor; * transaction network; * database; * storage controller; * remote API; * device; * network observer; * or another protected observer. Das Expires 4 April 2027 [Page 86] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.1.16. E01.16 Completion Receipt A Completion Receipt may be generated. It may bind: * Candidate Act digest; * actual performed operation; * destination; * sink; * completion state; * transaction identifier; * time; * nonce; * policy epoch; * resource state; * result code; * and other protected evidence. The receipt may be signed, MACed, attested, hash-chained, ledger-anchored, or protected by equivalent means. A.1.17. E01.17 Authority Consumption Where the authority is intended for single use, it is marked consumed. For example: Consumed(CA ) = T RU E A subsequent execution attempt must not succeed solely by replaying the previous authority. A.1.18. E01.18 Indeterminate Completion If the sender cannot determine whether the act occurred: State = IN DET ERM IN AT E The architecture may prevent blind retry where duplicate consequence would be unsafe. The PED may reconcile using: * sink query; Das Expires 4 April 2027 [Page 87] Internet-Draft Reality as a Cryptographic Dependency October 2026 * transaction ID; * destination query; * protected journal; * idempotency key; * device state; * database state; * hardware counter; * or equivalent evidence. A.1.19. E01.19 Anti-Bypass Requirement Where the architecture requires single-phase protected finality, another path must not allow equivalent full execution while avoiding the required protected boundary. Relevant alternate paths may include: * direct socket; * hidden API; * administrator API; * alternate database path; * direct device driver; * raw hardware interface; * fallback communication route; * alternate credential; * privileged service; * recovery interface; * or another act-equivalent route. Equivalent effect-capable paths may be: * disabled; Das Expires 4 April 2027 [Page 88] Internet-Draft Reality as a Cryptographic Dependency October 2026 * mediated; * protected; * credential-restricted; * cryptographically locked; * or subjected to equivalent finality verification. A.1.20. E01.20 Software Implementation Variation A software implementation may comprise: Agent Runtime → Protected Broker/PED → Kernel / Proxy / Transaction Gate → External Destination The agent may have no direct effect-capable credential. A.1.21. E01.21 Hardware Implementation Variation A hardware implementation may comprise: Application Processor → request → Secure Processor / TEE / HSM → bounded command authority → Hardware Finality Sink → external effect. Protected keys and state may remain unavailable to ordinary software. A.1.22. E01.22 Required Invariants The minimum frozen conceptual invariants of E01 are: Invariant 1 The proposed act is distinguishable from final effectuation. Invariant 2 At least one protected authority decision occurs before the complete effect is made effective. Invariant 3 The effect-capable boundary is technically dependent upon valid authority. Invariant 4 Failure of required validation prevents the authorized full effect. Invariant 5 The Candidate Act Source cannot obtain full effect merely by asserting that approval occurred. Everything else in E01 may vary by implementation unless expressly required. FIED RECEIPT → FULL EFFECTUATION Das Expires 4 April 2027 [Page 89] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.2. E02 — Real Bounded Demonstration Effect, Verified Receipt, Then Full Effectuation A.2.1. E02.1 Purpose E02 introduces the principal staged-effectuation architecture. The Candidate Act is not immediately permitted to produce its complete intended consequence. Instead, the system first permits a bounded real effect. The real effect is observed. Machine-verifiable evidence is generated. The evidence is validated. Only thereafter may the remaining or complete effect be enabled. The central relationship is: Candidate Act → Bounded Real Effect → V erified Effect Receipt → Continuation Authority → Broader/F ull Effect A.2.2. E02.2 Technical Distinction The initial stage must not be confused with: * simulation; * hypothetical execution; * local preview; * visual mock-up; * model prediction; * static analysis; * dry-run that produces no relevant external state change; * or ordinary risk scoring. The Phase-0 operation causes at least one real effectuation-relevant state transition. The real effect may nevertheless be deliberately restricted in consequence. A.2.3. E02.3 Candidate Act Formation A Candidate Act A is produced. The system determines the intended full effect: EF Examples include: * entire message; * entire file; Das Expires 4 April 2027 [Page 90] Internet-Draft Reality as a Cryptographic Dependency October 2026 * entire payment; * complete database update; * entire actuator trajectory; * complete software deployment; * complete credential authority; * full dataset release; * full telecom action; * or another complete consequence. A.2.4. E02.4 Exact-Act / Authorized-Envelope Binding A protected representation of the Full Candidate Effect may be created. For example: DA = H(Canon(A)) The architecture may additionally bind an authorized maximum envelope: Envelopemax The staged architecture may never increase authority beyond: Envelopemax merely because the trial succeeds. A.2.5. E02.5 Stage Planner The PED determines that E02 staged mode applies. It defines: Phase 0 P0 representing the Bounded Trial Effect. Phase 1 P1 representing the authorized remaining effect or complete release. The relation may be: P0 + P1 = EF where quantitative decomposition is meaningful. Alternatively, P0 and P1 may represent different technical operations contributing to the same final consequence. A.2.6. E02.6 Bounded Trial Effect Selection The trial effect may be bounded by one or more dimensions. Amount Example: Das Expires 4 April 2027 [Page 91] Internet-Draft Reality as a Cryptographic Dependency October 2026 ₹1 before a larger payment. Data A bounded encrypted sample before complete data release. Recipient One protected recipient before a broader distribution. Destination One verified endpoint before broader network use. Time Short operation interval before continuous operation. Hardware Movement Small movement before complete trajectory. Resource One database row, VM, server, device, storage object, model replica, or service instance. Capability Read-only or low-privilege operation before write or broader privilege. Cryptographic Scope Partial key material before complete decryption authority. A.2.7. E02.7 Trial Effect Descriptor A protected Trial Effect Descriptor may be generated. The descriptor may identify: * DA ; * phase identifier; * trial operation; * maximum trial consequence; * authorized destination; * expected sink; * expected observer; * acceptable response; * nonce; * expiry; Das Expires 4 April 2027 [Page 92] Internet-Draft Reality as a Cryptographic Dependency October 2026 * policy epoch; * revocation epoch; * receipt requirements; * permitted continuation; * and anti-replay state. Let: T ED0 denote the descriptor. A.2.8. E02.8 Approval Before Trial The trial itself may require one of several approval modes. Automatic Trial Approval Policy automatically permits the bounded effect. Human Trial Approval A human approves the trial. Hybrid Trial Approval Automatic protected checks and human approval are both required. Preauthorized Trial The user has previously authorized trials within a defined envelope. The existence of staged execution does not eliminate approval policy. A.2.9. E02.9 Phase-0 Authority The PED forms authority sufficient only for the bounded Phase-0 effect. The authority should preferably be incapable of directly enabling Phase 1. Formally: Scope(C0 ) ⊂ Scope(EF ) The trial authority may be: * scoped capability; * temporary credential; * limited signing authority; * hardware enable value; * transaction authorization; Das Expires 4 April 2027 [Page 93] Internet-Draft Reality as a Cryptographic Dependency October 2026 * restricted API capability; * bounded network capability; * partial key; * limited actuator command; * or equivalent technical condition. A.2.10. E02.10 Phase-0 Sink Verification The Phase-0 Finality Sink verifies: * Candidate Act binding; * trial descriptor; * permitted scope; * destination; * nonce; * freshness; * sink identity; * and applicable protected conditions. It must reject an attempt to use C0 for the broader effect. A.2.11. E02.11 Real Bounded Effectuation The sink performs the real bounded effect. This is the defining operational event. Examples follow. SEND Example Instead of transmitting the complete sensitive document, a protected demonstration object is transmitted to the actual intended receiving endpoint. Payment Example A bounded authorization, reversible amount, verification transfer, escrow reservation, or supported test transaction reaches the real payment infrastructure. Hardware Example The motor physically moves a bounded amount. Database Example A bounded state transition actually commits in a restricted namespace. Das Expires 4 April 2027 [Page 94] Internet-Draft Reality as a Cryptographic Dependency October 2026 Cloud Example The software is actually deployed to one protected target. A.2.12. E02.12 Effect Observation An effect observer determines what actually occurred. The observer may comprise: * destination application; * recipient device; * transaction system; * payment institution; * storage engine; * network endpoint; * protected sensor; * motor encoder; * hardware controller; * database engine; * cloud node; * DPU; * SmartNIC; * HSM; * TEE; * secure element; * remote protected service; * or equivalent observer. The observer is preferably positioned such that its evidence is meaningfully connected to the real effect. Das Expires 4 April 2027 [Page 95] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.2.13. E02.13 Observed-Effect Representation The observer forms an observation: O0 The protected system may compare: O0 against expected trial state: X0 For exact systems: O0 = X0 may be required. For tolerance-based systems: d(O0 , X0 ) ≤ ε may be permitted. A.2.14. E02.14 Effect Confirmation Receipt The observer, sink, or protected receipt component generates: R0 The ECR may bind: * Candidate Act; * TED; * Phase 0; * actual observed result; * destination; * sink; * observer; * transaction identifier; * nonce; * time; * policy epoch; * status; * prior protected state; * and next-stage eligibility evidence. The receipt may be authenticated cryptographically. Das Expires 4 April 2027 [Page 96] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.2.15. E02.15 Receipt Status Classes The ECR may report: SUCCESS The bounded effect occurred within the permitted condition. FAILURE The bounded effect did not satisfy the expected condition. REJECTED The destination refused the operation. PARTIAL Only part of the defined BTE occurred. ROLLED_BACK The bounded effect occurred but was safely reversed. INDETERMINATE The system cannot yet prove whether the effect occurred. A.2.16. E02.16 Receipt Return The ECR reaches the PED or another protected receipt verifier. The return path may be: * direct; * through authenticated network transport; * through message queue; * through hardware interrupt; * through protected shared memory; * through secure mailbox; * through storage polling; * through transaction query; * or equivalent protected path. A.2.17. E02.17 Receipt Verification The protected verifier determines whether R0 is acceptable. Verification may include: V erifySignature(R0 ) M atchAct(R0 , DA ) Das Expires 4 April 2027 [Page 97] Internet-Draft Reality as a Cryptographic Dependency October 2026 M atchP hase(R0 , P0 ) M atchDestination(R0 ) M atchN once(R0 ) F resh(R0 ) P olicyCurrent(R0 ) N otRevoked(A) ObservedEffectAcceptable(O0 ) A successful result may be: ReceiptV alid0 = T RU E A.2.18. E02.18 Human Approval After Trial A significant variant requires human approval after the real trial effect. Flow: P0 → R0 → HumanReview → P1 The protected approval interface may display: * what was attempted; * what actually occurred; * verified destination; * trial receipt; * observed state; * recipient identity; * transaction status; * hardware state; * and the consequence of allowing Phase 1. The human therefore approves continuation based upon verified evidence of actual trial behavior. A.2.19. E02.19 Automatic Approval After Trial Another variation automatically authorizes continuation where: Das Expires 4 April 2027 [Page 98] Internet-Draft Reality as a Cryptographic Dependency October 2026 ReceiptV alid0 ∧ P olicyP ass ∧ RiskAcceptable = T RU E The human is not required. This variation is important for: * autonomous systems; * hyperscale systems; * telecom; * cloud; * infrastructure; * routine communications; * low-latency applications; * and high-volume machine operations. A.2.20. E02.20 Hybrid Continuation Approval A higher-assurance implementation may require: ReceiptV alid0 ∧ AutoP olicyP ass ∧ HumanApproval before Phase 1. A.2.21. E02.21 Protected State Advancement Successful receipt verification causes the protected state to move from, for example: T RIAL_ISSU ED to: T RIAL_CON F IRM ED and then, where applicable: CON T IN U AT ION _AU T HORIZED This state transition should preferably occur inside protected state unavailable for arbitrary rewriting by the proposing agent. A.2.22. E02.22 Receipt Consumption Where the receipt is single-use: Consumed(R0 ) = T RU E or equivalent protected state is recorded when continuation authority is generated. This prevents: R0 from authorizing multiple independent Phase-1 completions. Das Expires 4 April 2027 [Page 99] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.2.23. E02.23 Continuation Authority The PED generates, derives, unseals, releases, or activates the authority required for Phase 1. Let: C1 represent the continuation authority. A strong embodiment binds: C1 to: H(R0 ) such that receipt from another trial cannot substitute. A.2.24. E02.24 Receipt-Derived Cryptographic Authority One embodiment derives: K1 = KDF (Kroot , DA , H(R0 ), P hase1 , Sink1 ) The precise cryptographic construction is implementation-dependent. The important protected property is that the later authority becomes dependent upon accepted evidence from the earlier real effect. A.2.25. E02.25 Missing Execution Material Variation Rather than creating a token, the architecture may withhold execution material necessary for Phase 1. Examples: * signing key share; * decryption key; * command authenticator; * actuator enable value; * transaction completion value; * database commit permission; * network release key; * hardware register unlock value. Only successful receipt validation makes the missing material available. A.2.26. E02.26 Full / Remaining Effect Sink Verification The Phase-1 sink verifies C1 , the current Candidate Act and protected state. It may verify: * DA ; Das Expires 4 April 2027 [Page 100] Internet-Draft Reality as a Cryptographic Dependency October 2026 * H(R0 ); * Phase 1 identifier; * sink identity; * destination; * scope; * nonce; * policy epoch; * revocation epoch; * expiration; * human approval where required; * current system state. A.2.27. E02.27 Full Effectuation After successful verification: P1 is performed. The result may complete the originally authorized consequence. A.2.28. E02.28 Completion Receipt A final receipt: RF may bind both: R0 and: P1 For example: RF = P rotect(DA , H(R0 ), Effect1 , F inalState) This creates evidence that the final effect was causally linked to the confirmed bounded effect. A.2.29. E02.29 Failure After Trial If the BTE fails: Das Expires 4 April 2027 [Page 101] Internet-Draft Reality as a Cryptographic Dependency October 2026 R0 = F AILU RE Phase 1 remains unavailable. Possible next states include: * deny; * rollback; * compensate; * reduce scope; * select alternative destination; * require human review; * repeat a newly authorized trial; * or terminate. A failed trial must not automatically become permission for full execution. A.2.30. E02.30 Indeterminate Trial If the system cannot determine whether Phase 0 occurred: R0 = IN DET ERM IN AT E Phase 1 remains blocked. The system enters reconciliation. It may query: * sink state; * idempotency record; * transaction ledger; * destination; * hardware counter; * protected journal; * or another authoritative state source. A.2.31. E02.31 Crash After Trial Effect A particularly important failure sequence is: 1. Phase 0 occurs. 2. Sink records the effect. 3. System crashes before receipt is delivered. A blind retry might duplicate Phase 0. Accordingly the BTE may use an idempotency identifier: Das Expires 4 April 2027 [Page 102] Internet-Draft Reality as a Cryptographic Dependency October 2026 I0 = H(DA ∥ P hase0 ∥ N0 ) The sink stores the identifier atomically with the real effect. After recovery, the system determines whether I0 already corresponds to an effected operation. A.2.32. E02.32 Alternate-Path Closure The full effect must not remain available through an unprotected path while the staged path requires a receipt. Otherwise: T rial Gate could simply be bypassed. The architecture may therefore protect: * direct API; * alternate network socket; * privileged credential; * database admin path; * raw device interface; * alternate key; * recovery path; * fallback route; * or another equivalent full-effect path. A.2.33. E02.33 Communication “Trailer” Example Full intended communication: M A bounded real pre-release object: T is transmitted first. The receiving endpoint validates T and generates: RT The sender verifies RT . Only thereafter may M or its remaining protected content become available. A.2.34. E02.34 Ciphertext-First Communication Variation The full ciphertext may already be transmitted. However, the receiver cannot obtain the complete semantic content. After valid receipt of the initial protected stage, the sender/PED releases: Das Expires 4 April 2027 [Page 103] Internet-Draft Reality as a Cryptographic Dependency October 2026 * missing decryption key; * key share; * unwrap authority; * or equivalent material. This permits network pre-staging without full semantic effectuation. A.2.35. E02.35 Hardware Demonstration Example Requested actuator movement: 90∘ Trial authority permits: 5∘ Protected sensor reports: 4.98∘ If the acceptable range is: 4.9∘ ≤ O0 ≤ 5.1∘ then: ReceiptV alid0 = T RU E and the remaining authorized movement may be enabled. A.2.36. E02.36 Required Invariants Invariant 1 The Phase-0 effect is a real protected effect, not merely a prediction. Invariant 2 Phase 0 is narrower than the full authorized consequence in at least one relevant dimension. Invariant 3 Evidence of Phase-0 outcome is obtained. Invariant 4 The evidence is verified by protected logic. Invariant 5 Phase 1 remains technically unavailable until the required Phase-0 evidence is accepted. Invariant 6 A trial receipt cannot validly enlarge the operation beyond the maximum authorized envelope. Invariant 7 Required staged control cannot be trivially avoided by an equivalent unprotected full-effect path. These constitute the frozen core of E02. MULTI-PHASE PROGRESSIVE EFFECTUATION Das Expires 4 April 2027 [Page 104] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.3. E03 — Real Demonstration Effect with Receipt-Gated Multi-Phase Progressive Effectuation A.3.1. E03.1 Purpose E03 extends E02 from one trial followed by one full-effect stage to an arbitrary number of protected effectuation stages. Instead of: P0 → R0 → PF the architecture permits: P0 → R0 → P1 → R1 → P2 → R2 → ... → Pn → Rn Each required receipt may become a protected prerequisite for a later phase. A.3.2. E03.2 Candidate Act and Maximum Effect Envelope A Candidate Act A defines or is associated with a maximum permitted consequence: EMAX The multi-phase system may progressively approach EMAX , but must not exceed it merely because prior phases succeed. Therefore: Ei ≤ EMAX for every phase i. A.3.3. E03.3 Phase Plan The protected Phase Planner may create: P = {P0 , P1 , ... , Pn } The plan may be established: * entirely in advance; * partly in advance; * adaptively; * dynamically after every receipt; * by protected policy; * by human authorization; * or using a hybrid model. A.3.4. E03.4 Fixed Phase Plan One implementation predefines the complete progression. Example: 1% → 10% → 25% → 50% → 100% Another: Das Expires 4 April 2027 [Page 105] Internet-Draft Reality as a Cryptographic Dependency October 2026 1 device → 10 → 100 → 1000 Another: ₹10 → ₹100 → ₹1000 → remaining authorized amount Another: 5∘ → 20∘ → 45∘ → 90∘ A.3.5. E03.5 Adaptive Phase Plan The scope of the next phase may be determined only after the previous effect is observed. Let: Si+1 = f(Ri , Riski , P olicyi , Approvali , CurrentStatei ) where Si+1 denotes the next permitted scope. The next phase may therefore become: * larger; * smaller; * unchanged; * delayed; * redirected; * human-reviewed; * or terminated. A.3.6. E03.6 Initial Validation Before Phase 0, the PED performs protected validation substantially according to the applicable portions of E01 and E02. The validation determines: * whether the act is authorized at all; * maximum allowed consequence; * allowed phase strategy; * required receipt quality; * approval mode; Das Expires 4 April 2027 [Page 106] Internet-Draft Reality as a Cryptographic Dependency October 2026 * sink requirements; * anti-bypass requirements; * and failure behavior. A.3.7. E03.7 Human Authorization of Entire Progressive Envelope A human may authorize: EMAX once at the beginning while requiring the system to progress only after verified phase receipts. Example: Authorized maximum: deploy to 10,000 devices. Progression must stop automatically if protected health criteria fail. The human need not approve each individual phase. A.3.8. E03.8 Human Authorization Per Phase Alternatively each phase may require: HumanApprovali after receipt Ri−1 . The human therefore sees actual evidence from preceding phases before authorizing expansion. A.3.9. E03.9 Automatic Progressive Approval Protected policy may automatically advance every phase where: ReceiptV alidi ∧ RiskAcceptablei ∧ P olicyV alidi ∧ N otRevokedi is true. No human interaction is required. A.3.10. E03.10 Hybrid Progressive Approval Example protected rule: i < 3 ⇒ Auto and: i ≥ 3 ⇒ HumanApproval or: EffectScope < T hreshold ⇒ Auto EffectScope ≥ T hreshold ⇒ HumanApproval The threshold itself is protected policy. A.3.11. E03.11 Phase-Specific Authority Each phase obtains separate authority: Ci where: Das Expires 4 April 2027 [Page 107] Internet-Draft Reality as a Cryptographic Dependency October 2026 Scope(Ci ) = Scope(Pi ) A Phase-1 authority should not validly authorize Phase 2 unless policy expressly makes them equivalent. A.3.12. E03.12 Phase-Receipt Chain Following each real effect: Pi the sink or observer generates: Ri The receipt may include: H(Ri−1 ) creating: R0 → R1 → R2 → ... as a cryptographically linked history. A.3.13. E03.13 Receipt-Chain Mathematical Representation For i > 0: Ri = P rotectKi (DA ∥ P hasei ∥ Oi ∥ Statusi ∥ Ni ∥ H(Ri−1 )) The use of H(Ri−1 ) is one possible implementation and is not mandatory where an equivalent protected sequence-binding mechanism exists. A.3.14. E03.14 Next-Phase Predicate A general next-phase condition may be: Enable(Pi+1 ) = V alid(Ri ) ∧ M atch(Ri , Pi ) ∧ F resh(Ri ) ∧ P olicyCurrent ∧ RevocationClear ∧ W ithinEnvelope(Pi+1 ) ∧ ApprovalSatisfiedi+1 If any required condition is false: Enable(Pi+1 ) = F ALSE A.3.15. E03.15 Protected State Transition After successful receipt verification: Statei → Statei+1 may occur atomically with: * receipt consumption; * next-phase authority generation; * phase counter increment; Das Expires 4 April 2027 [Page 108] Internet-Draft Reality as a Cryptographic Dependency October 2026 * protected log update; * or equivalent protected state operation. A.3.16. E03.16 Phase Counter Protected state may maintain: i as a monotonically advancing phase index. An attempt to execute: Pi+2 while the protected phase index equals i may be rejected. This prevents skipping mandatory stages. A.3.17. E03.17 Cryptographic Key Progression The authority chain may be derived progressively. For example: K0 = KDF (KR , DA , N0 ) K1 = KDF (KR , DA , H(R0 ), 1) K2 = KDF (KR , DA , H(R1 ), 2) and generally: Ki+1 = KDF (KR , DA , H(Ri ), i + 1) A stronger variant may incorporate the entire receipt history. A.3.18. E03.18 Hardware Key Progression A secure hardware component may hold: KR and expose only the current phase-specific authority. Ordinary application software cannot request Ki+1 unless the hardware has accepted Ri . This creates hardware-enforced progression. A.3.19. E03.19 Hardware Phase Latch A hardware implementation may use a protected state variable: L=i representing the highest completed authorized phase. A command for phase j succeeds only where: j =L+1 and required receipt validation has completed. A.3.20. E03.20 Progressive Communication Workflow A sensitive file transmission may proceed as: Das Expires 4 April 2027 [Page 109] Internet-Draft Reality as a Cryptographic Dependency October 2026 Phase 0 — Endpoint Verification A protected challenge or trailer reaches the real recipient. R0 confirms endpoint identity. Phase 1 — Manifest Encrypted metadata or manifest is transmitted. R1 confirms acceptance. Phase 2 — Initial Payload Segment A limited encrypted file segment is transmitted. R2 confirms protected storage. Phase 3 — Remaining Ciphertext Remaining encrypted data is transmitted. R3 confirms complete ciphertext integrity. Phase 4 — Semantic Release Final decryption authority is released. R4 may confirm completion. Thus network delivery and information disclosure may be independently phased. A.3.21. E03.21 Progressive Payment Workflow A payment may progress as: Phase 0 Destination-account verification. Receipt 0 Protected receiving-institution confirmation. Phase 1 Bounded reservation. Receipt 1 Reservation confirmation. Phase 2 Partial settlement. Receipt 2 Protected settlement confirmation. Phase 3 Remaining settlement. Receipt 3 Final completion confirmation. The precise payment operations depend on the payment infrastructure. Das Expires 4 April 2027 [Page 110] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.3.22. E03.22 Progressive Hardware Workflow Requested total actuator trajectory: 90∘ Possible phases: 5∘ 15∘ 30∘ 40∘ for cumulative: 90∘ Following each movement, a protected sensor generates evidence. If any observed value exceeds the permitted tolerance: Continue = F ALSE A.3.23. E03.23 Cumulative Effect State Let: Ei represent cumulative real effect after phase i. The architecture may require: E0 < E1 < ... < En ≤ EMAX where monotonic progression is applicable. Some systems may instead use non-monotonic or qualitatively different phases. A.3.24. E03.24 Progressive Scope Enlargement Where authority is represented as scope: Scope0 ⊂ Scope1 ⊂ ... ⊆ ScopeMAX Examples: * more recipients; * more devices; * greater financial amount; * more data; * broader network range; * additional privileges; Das Expires 4 April 2027 [Page 111] Internet-Draft Reality as a Cryptographic Dependency October 2026 * larger actuator envelope; * increased deployment population. A.3.25. E03.25 Progressive Credential Authority The credential used by the agent or executor may similarly expand. Phase 0: read-only. Phase 1: write to one object. Phase 2: write to defined namespace. Phase 3: broader authorized transaction. The full reusable credential need never be exposed to the agent. A.3.26. E03.26 Receipt-Quality-Controlled Phase Size Let receipt confidence be: Qi and required threshold: τi If: Qi < τi the next phase may: * remain same size; * become smaller; * require stronger validation; * require human approval; * or terminate. A high-quality receipt does not necessarily require full-scale expansion. A.3.27. E03.27 Risk-Adaptive Phase Size Let current risk be: Riski The next phase scope may satisfy: Scopei+1 = g(Riski , Qi , P olicyi ) A higher risk may produce smaller next-phase scope. A.3.28. E03.28 Taint-Adaptive Progression Where taint or provenance state is relevant: * untainted/high-trust context may permit larger stages; * uncertain provenance may require smaller stages; Das Expires 4 April 2027 [Page 112] Internet-Draft Reality as a Cryptographic Dependency October 2026 * high-risk taint may require human review; * prohibited taint may terminate progression. The proposing AI agent need not control the protected taint state. A.3.29. E03.29 Parallel Trial Sub-Phases A phase may include several parallel bounded operations: Pi,1 , Pi,2 , ..., Pi,k Each produces: Ri,1 , Ri,2 , ..., Ri,k An aggregate protected predicate determines whether the next broader phase may proceed. For example: SuccessRatei ≥ τ and: CriticalF ailurei = F ALSE A.3.30. E03.30 Quorum Confirmation A phase may require confirmation from multiple observers. Let: Ri1 , ..., Rin be receipts. Continuation may require: n ∑ V alid(Rij ) ≥ m j=1 This may be useful where one observer is insufficiently authoritative. A.3.31. E03.31 Nested Phase Structure A global phase may contain sub-phases. For example: Global Deployment Phase 1 contains: * Region A phase; * Region B phase; * Region C phase. Each region may independently progress through: * node canary; Das Expires 4 April 2027 [Page 113] Internet-Draft Reality as a Cryptographic Dependency October 2026 * small cohort; * broad cohort. The parent phase proceeds only after required child receipt conditions are met. A.3.32. E03.32 Partial Success If some targets succeed and others fail: SuccessfulSet ⊂ OriginalSet the next phase may continue only for: SuccessfulSet rather than forcing binary full success/full failure. A.3.33. E03.33 Failure at Intermediate Phase If: Ri = F AILU RE remaining phases: Pi+1 , ..., Pn remain unavailable unless a new protected decision explicitly authorizes an alternative continuation path. Possible responses include: * terminate; * rollback; * compensate; * retry bounded subset; * reduce scope; * select alternative sink; * human escalation; * or replan. A.3.34. E03.34 Indeterminate Intermediate Phase If: Das Expires 4 April 2027 [Page 114] Internet-Draft Reality as a Cryptographic Dependency October 2026 Ri = IN DET ERM IN AT E the system does not assume either success or failure. The protected phase state is frozen. No broader phase is released until reconciliation establishes an acceptable protected state. A.3.35. E03.35 Reconciliation Workflow The system may query: * phase-specific idempotency identifier; * transaction ledger; * sink log; * destination state; * hardware counter; * message identifier; * settlement state; * storage state; * or other protected evidence. Possible reconciliation results: PROVEN_EFFECTED Construct/recover Ri and continue if permitted. PROVEN_NOT_EFFECTED A new protected retry may be authorized. STILL_INDETERMINATE Remain blocked. A.3.36. E03.36 Phase Replay Protection Each phase may use unique: Ni and/or: Ii A consumed authority or receipt cannot be used to repeat the corresponding real effect. A.3.37. E03.37 Receipt Consumption Once: Das Expires 4 April 2027 [Page 115] Internet-Draft Reality as a Cryptographic Dependency October 2026 Ri has caused protected transition to phase i + 1, the PED may record: Consumed(Ri ) = T RU E A replayed Ri must not independently cause another phase-i + 1 effect. A.3.38. E03.38 Policy Change Between Phases If: P olicyEpochnew ≠ P olicyEpochi then prior receipt success need not automatically authorize progression. The PED may require: * revalidation; * reduced scope; * human approval; * or termination. A.3.39. E03.39 Revocation Between Phases At any point: Revoked(A) = T RU E may cause all unused continuation authorities to become invalid. Prior successful phases do not guarantee future completion. A.3.40. E03.40 Human Veto Even in an automatically progressing system, a protected human may have veto authority. After a valid receipt: Ri the system may enter a bounded delay window. If: V eto = T RU E the next phase remains blocked. A.3.41. E03.41 Maximum-Envelope Enforcement Before every phase, the protected system verifies: CumulativeEffectproposed ≤ AuthorizedM aximum A sequence of individually valid receipts must never create cumulative privilege escalation. Das Expires 4 April 2027 [Page 116] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.3.42. E03.42 Alternate-Path Closure The phased architecture requires equivalent control over any path capable of prematurely causing: Pi+1 or the final consequence. This may include: * alternate API; * administrator interface; * direct credential; * raw device interface; * hidden database connection; * recovery route; * alternate message queue; * lower-level OS primitive; * remote control interface; * or other effect-equivalent path. A.3.43. E03.43 Multi-Sink Variation Different phases may use different sinks: Sink0 , Sink1 , ..., Sinkn Receipt validity may bind the expected sink sequence. An unauthorized sink substitution may terminate the progression. A.3.44. E03.44 Same-Sink Variation One protected sink may maintain all phase state internally. For example: Sink0 = Sink1 = ... = Sinkn The sink increments protected phase state only after its required observation conditions succeed. A.3.45. E03.45 Distributed Protected Enforcement Domain Different PED functions may reside at: * originating device; Das Expires 4 April 2027 [Page 117] Internet-Draft Reality as a Cryptographic Dependency October 2026 * cloud; * HSM; * destination; * gateway; * network; * hardware controller; * enterprise service; * human approval device. The architecture does not require one physical PED. A.3.46. E03.46 Final Completion When the final required phase: Pn has been successfully completed and verified, protected state may become: F U LLY _EF F ECT ED or equivalent terminal state. A.3.47. E03.47 Final Receipt The final receipt may commit to the entire effectuation chain: RF = P rotect(DA , H(R0 ), H(R1 ), ..., H(Rn ), F inalState) For very large receipt sets, a Merkle root or other aggregate commitment may be used. A.3.48. E03.48 Required Invariants Invariant 1 At least two real effectuation phases exist. Invariant 2 The initial effect is bounded relative to the maximum authorized consequence. Invariant 3 At least one later phase depends technically upon accepted evidence from a previous real phase. Invariant 4 Mandatory phase order cannot be silently skipped. Invariant 5 No phase may exceed the authorized maximum envelope. Das Expires 4 April 2027 [Page 118] Internet-Draft Reality as a Cryptographic Dependency October 2026 Invariant 6 Failure or indeterminate state at a required phase prevents unauthorized broader progression. Invariant 7 Automatic approval, human approval, or hybrid approval may govern phase advancement. Invariant 8 The architecture may be software-enforced, hardware- enforced, or jointly enforced. Invariant 9 Equivalent alternate effect paths are subjected to corresponding phase-control requirements where needed to preserve non-bypassability. FROZEN RELATIONSHIP BETWEEN E01, E02 AND E03 The three primary workflows may be summarized as follows. E01 V alidate → Authorize → 100% Effect E02 V alidate → Bounded Real Effect → Receipt → Remaining/F ull Effect E03 V alidate → P0 → R0 → P1 → R1 → ... → Pn → Rn The protected system may choose among E01, E02 and E03 according to policy, risk, act class, destination certainty, reversibility, latency, human preference, infrastructure capability, or another protected criterion. The principal conceptual progression is therefore: Single P hase | T rial T hen F ull | T rial T hen P rogressive F ull with the common execution-finality principle that computational proposal alone does not constitute unconditional authority for external effectuation. APPENDIX C - ADDITIONAL DEFINITIONS INTRODUCED BY WORKFLOWS E01-E03 C.1 Non-Repetition Rule This Appendix intentionally defines only terminology introduced, specialized, or materially extended in the E01-E03 workflow disclosure that was not already defined in the preceding Advanced Section 1 definitions. Earlier definitions - including Candidate Act, Bounded Trial Effect (BTE), Trial Effect Descriptor (TED), Effect Confirmation Receipt (ECR), Continuation Authority, Protected Enforcement Domain (PED), Finality Sink, Effect Observer, Protected State, Single-Phase Effectuation, Multi-Phase / Progressive Effectuation, Receipt-Gated Effectuation, Cryptographic Causal Dependency, Missing Execution Material, Fail-Closed, Fail- Limited, Indeterminate State, Reconciliation, Receipt Consumption, Alternative-Path Closure, Policy Epoch, Revocation Epoch, and related established terms - retain their previously stated meanings and are not repeated here. Unless a workflow expressly states that a Das Expires 4 April 2027 [Page 119] Internet-Draft Reality as a Cryptographic Dependency October 2026 property is mandatory, the terms below identify functional roles and do not require a particular component name, software package, protocol, cryptographic primitive, operating system, processor, or physical separation. C.2 Candidate Act Source Candidate Act Source means the computational or human-operated component that forms, proposes, selects, schedules, prepares, or submits a Candidate Act. Examples include an AI agent, foundation model, autonomous agent, application, workflow engine, operating system, cloud controller, telecom controller, payment application, database application, robotic controller, embedded controller, or human-operated software. Merely originating the Candidate Act does not by itself confer effectuation authority. C.3 Candidate Act Representation Component Candidate Act Representation Component means a component or function that creates a machine-processable representation of a proposed Candidate Act and, where applicable, identifies parameters such as act type, command, target, destination, recipient, resource, payload, amount, object, API, device, requested consequence, permitted scope, identity context, purpose, timing, jurisdiction, and authority context. The representation may be structured, serialized, canonicalized, hashed, signed, referenced, or otherwise protected according to implementation. C.4 Canonicalization / Exact-Act Binding Component Canonicalization / Exact-Act Binding Component means a component or function that produces a deterministic or otherwise stable protected representation of an act, phase, authority, or relevant parameters so that later validation can determine whether the effect-capable operation corresponds to the authorized operation. Canonicalization is one possible mechanism and is not mandatory where another deterministic act-identification or protected equivalence mechanism performs the same technical function. C.5 Validation Predicate and Validation Predicate Set A Validation Predicate means a protected test, condition, rule, or state assertion evaluated when determining whether an act or phase may proceed. A Validation Predicate Set means the collection of one or more such predicates applicable to a Candidate Act or phase. Predicates may evaluate to binary or multi-state outcomes including TRUE, FALSE, UNKNOWN, IN- DETERMINATE, or an equivalent protected result. Examples include user authority, destination allowance, policy validity, revocation status, resource scope, sink trust, risk, provenance, taint, timing, and device state. Das Expires 4 April 2027 [Page 120] Internet-Draft Reality as a Cryptographic Dependency October 2026 C.6 Approval Mode Approval Mode means the protected rule selecting how required approval for an act or phase is satisfied. Approval modes may include automatic protected approval, protected human approval, hybrid approval requiring both automatic and human conditions, multi-authority approval, or execution within a previously authorized envelope. Approval mode may differ between phases of the same Candidate Act. C.7 Protected Approval Object Protected Approval Object means a machine-verifiable object or protected state representation binding an approval decision to defined act or phase context. It may bind the Candidate Act digest, operation, recipient, destination, amount, payload, consequence, scope, nonce, expiration, policy epoch, risk state, sink identity, prior receipt, approving authority, or other protected fields. The object need not be a transferable bearer token and may exist only as protected state. C.8 Authorized Envelope / Maximum Effect Envelope Authorized Envelope, Maximum Authorized Envelope, or Maximum Effect Envelope means the greatest effect, scope, consequence, privilege, amount, target population, resource range, actuator range, destination set, deployment size, or other bounded authority that a protected decision permits for the Candidate Act. Successful trial or intermediate phases may permit progression within that envelope but do not, by themselves, enlarge the envelope. C.9 Stage Planner / Protected Phase Planner Stage Planner or Protected Phase Planner means a protected component or function that determines whether effectuation proceeds in one phase or multiple phases and, for a staged act, defines or selects the sequence, scope, ordering, receipt conditions, approval conditions, sink conditions, and failure behavior of the phases. The planner may establish all phases in advance or determine later phases adaptively from protected observations and policy. C.10 Phase Plan Phase Plan means the protected representation of the ordered, partially ordered, nested, parallel, or adaptive set of effectuation phases applicable to a Candidate Act. A Phase Plan may define phase scopes, phase-specific authorities, expected sinks, receipt requirements, approval rules, progression rules, termination conditions, rollback conditions, and the maximum authorized envelope. C.11 Fixed Phase Plan Fixed Phase Plan means a Phase Plan whose sequence or progression is substantially determined before the relevant phases begin, for example a predetermined rollout of 1%, 10%, 25%, 50%, and 100%, subject to the required receipts and protected stop conditions. Das Expires 4 April 2027 [Page 121] Internet-Draft Reality as a Cryptographic Dependency October 2026 C.12 Adaptive Phase Plan Adaptive Phase Plan means a Phase Plan in which at least one later phase scope, timing, destination, approval requirement, or other phase property is determined or modified after protected observation of an earlier phase. The adaptive decision may depend on receipt validity or quality, risk, policy, current state, human approval, failure rate, taint, provenance, or other protected inputs. C.13 Phase Counter Phase Counter means protected state identifying the current, highest completed, next permitted, or otherwise relevant phase index. It may be represented by a monotonic counter, protected integer, hardware state, secure register, authenticated database value, transaction state, or equivalent protected sequencing mechanism. It may be used to prevent unauthorized skipping or replay of mandatory phases. C.14 Protected State Advancement Protected State Advancement means the protected transition by which the system records that required conditions for one phase have been satisfied and the Candidate Act has moved to a later permitted execution state. Advancement may occur atomically with receipt consumption, phase-counter update, authority generation, protected logging, or another finality operation. C.15 Cumulative Effect State Cumulative Effect State means protected state representing the effect, scope, consequence, or authorized progression accumulated through completed phases of a multi-phase Candidate Act. It may be quantitative, set-based, state-based, privilege-based, or otherwise represented. Cumulative Effect State is constrained not to exceed the applicable Maximum Authorized Envelope. C.16 Maximum-Envelope Enforcement Maximum-Envelope Enforcement means protected verification performed before or during phase progression to ensure that the proposed cumulative or next-phase consequence remains within the Candidate Act’s authorized maximum scope. A series of individually valid receipts does not authorize cumulative privilege or consequence beyond that envelope. C.17 Sink-Side Verification Sink-Side Verification means verification performed by, at, or under protected control of the effect-capable boundary before the corresponding effect is allowed. It may include act matching, capability or authority validity, nonce and freshness checks, destination and recipient checks, phase matching, sink identity, policy and revocation state, hardware identity, resource state, amount, payload, or other local protected conditions. Das Expires 4 April 2027 [Page 122] Internet-Draft Reality as a Cryptographic Dependency October 2026 C.18 Receipt Verification Predicate Set Receipt Verification Predicate Set means the collection of protected conditions used to determine whether an ECR or other receipt is acceptable for a subsequent state transition. Such conditions may include authenticity, act matching, phase matching, destination matching, nonce matching, freshness, policy validity, revocation status, observed-effect acceptance, sink identity, and applicable approval state. C.19 Progressive Envelope Authorization Progressive Envelope Authorization means an authorization in which a human or protected authority approves a maximum overall consequence while requiring the PED and Finality Sink architecture to release that consequence progressively under protected phase and receipt conditions. The approving authority need not separately approve each phase unless policy requires it. C.20 Local Symbol Overload Rule Where a symbol in E01-E03 is intentionally reused with a local meaning different from a symbol used elsewhere in Advanced Section 1, the local subsection meaning controls within that subsection only. The additional notation Appendix below identifies the material overloads so that no broader mathematical equivalence is implied. APPENDIX D - ADDITIONAL AND LOCALLY SPECIALIZED NOTATION FOR E01-E03 D.1 Non-Repetition Rule This Appendix intentionally lists only notation that is newly introduced in E01-E03, uses a more specialized meaning than the preceding Advanced Section 1 notation appendix, or creates a local symbol overload that could otherwise be ambiguous. Earlier notation retains its previously stated meaning and is not repeated. D.2 Candidate-Act Representation and Predicate Notation * AC - canonical or otherwise deterministically stabilized representation of Candidate Act A, as used in E01.2C. The example relation is AC = Canon(A). * ΠA - the validation predicate set applicable to Candidate Act A. * p1 , p2 , ... , pm - individual validation predicates belonging to ΠA ; the index m denotes the number of predicates in the applicable set. * DecisionA - protected approval/validation decision associated with Candidate Act A, illustrated by values such as ALLOW, DENY, HOLD, or INDETERMINATE. Das Expires 4 April 2027 [Page 123] Internet-Draft Reality as a Cryptographic Dependency October 2026 * P haseCount - number of effectuation phases selected for the Candidate Act in the illustrated mode; P haseCount = 1 denotes the E01 single-phase case. * Aauthorized - the authorized act or authorized subset/envelope of Candidate Act A after protected validation. * Authority(x) - generic notation for authority associated with act or object x. Thus Authority(A) ⇏ Authority(B) states that authority for one act does not necessarily authorize a materially different act. * CA - authority/capability associated with Candidate Act A in the E01 authority-consumption example; Consumed(CA ) = T RU E indicates protected consumption where single use is required. D.3 Two-Stage Workflow Notation * EF - intended full effect of the Candidate Act in E02.3. It is conceptually related to the previously defined Full Candidate Effect but is the local symbol used in the E02 workflow. * Envelopemax - maximum authorized effect/scope envelope bound to the E02 staged act. Successful trial operation cannot by itself expand authority beyond this envelope. * T ED0 - Trial Effect Descriptor for Phase 0. * d(O0 , X0 ) - implementation-defined difference, distance, mismatch, or deviation function comparing observed trial state O0 with expected trial state X0 . The acceptance example d(O0 , X0 ) ≤ ε does not require a particular metric unless separately specified. * V erifySignature(R0 ) - predicate verifying the required cryptographic signature or equivalent authentication on receipt R0 . * M atchAct(R0 , DA ) - predicate requiring receipt R0 to correspond to Candidate Act digest DA . * M atchP hase(R0 , P0 ) - predicate requiring receipt R0 to correspond to Phase 0. * M atchDestination(R0 ) - predicate requiring the receipt’s destination context to match the protected authorized destination condition. Das Expires 4 April 2027 [Page 124] Internet-Draft Reality as a Cryptographic Dependency October 2026 * M atchN once(R0 ) - predicate requiring the receipt nonce to match the expected protected nonce. * P olicyCurrent(R0 ) - predicate requiring the receipt to remain acceptable under the currently applicable policy state. * N otRevoked(A) - predicate indicating that Candidate Act A or its relevant authority has not been revoked under the applicable protected revocation state. * ObservedEffectAcceptable(O0 ) - predicate indicating that observed trial effect O0 satisfies the applicable protected acceptance condition. * ReceiptV alid0 - Boolean or protected state result indicating that the required Phase-0 receipt verification predicates have succeeded. * P olicyP ass - protected policy result sufficient, together with the other required predicates, for automatic continuation in the illustrated E02 branch. * AutoP olicyP ass - protected automatic-policy result used in the hybrid continuation branch. * HumanApproval - protected human-approval predicate in the illustrated hybrid continuation expression; it is not an ordinary unprotected chat response merely because the label is written as a Boolean predicate. * Statei - generic protected workflow state at step/phase i in E02/ E03 state-advancement expressions, distinct from any specifically enumerated S0 , S1 , ... state-machine labels defined elsewhere. * Effect1 - observed or protected final/remaining effect associated with Phase 1 in the E02 completion-receipt example. * F inalState - terminal protected state or state commitment included in a completion receipt. D.4 Communication-Trailer Local Notation and Symbol Collision * M in E02.33 only - the full intended message/communication. This is a local overload. Elsewhere in the preceding Advanced Section 1 notation, M may denote a total payment amount. The two uses are unrelated; subsection context controls. Das Expires 4 April 2027 [Page 125] Internet-Draft Reality as a Cryptographic Dependency October 2026 * T in E02.33 - bounded real trailer or pre-release communication object transmitted before the complete communication. * RT - receipt generated in response to trailer object T , used to authorize or enable later availability of the full intended communication. D.5 Multi-Phase Planning and Scope Notation * EMAX - maximum permitted consequence associated with the multi- phase Candidate Act in E03. It is the local maximum-envelope symbol used by the workflow and is distinct only notationally from previously described maximum-authorized effect concepts. * P - Phase Plan, illustrated as the set or ordered collection {P0 , P1 , ... , Pn }. The actual plan may be ordered, partially ordered, adaptive, nested, or parallel as described in the workflow. * Si+1 in E03.5 only - the next permitted scope selected by the adaptive Phase Planner. This is a local overload and must not be confused with the previously defined state-machine notation S0 , S1 , .... Within E03.5, Si+1 means next permitted scope. * CurrentStatei - protected current system/workflow state supplied as an input to adaptive next-scope selection. * ReceiptV alidi - phase-indexed protected result indicating that receipt Ri has passed the required receipt verification predicates. * RiskAcceptablei - phase-indexed protected result indicating that risk for continuation after phase i is within the policy-permitted condition. * P olicyV alidi - phase-indexed protected result indicating that the relevant policy state for phase i remains valid. * N otRevokedi - phase-indexed protected revocation-clear result. * EffectScope - current or proposed effect scope used in the illustrative hybrid-approval threshold rule. * T hreshold - implementation-defined protected threshold used to select automatic versus human approval in the illustrated hybrid rule. Das Expires 4 April 2027 [Page 126] Internet-Draft Reality as a Cryptographic Dependency October 2026 * P hasei - identifier or protected representation of phase i when included as a field in a receipt/protected construction. * M atch(Ri , Pi ) - predicate requiring receipt Ri to correspond to the actual authorized phase Pi . * P olicyCurrent - protected Boolean/predicate that current policy permits progression; where written without arguments it denotes current-policy validity generally. * RevocationClear - protected Boolean/predicate that no applicable revocation prevents progression. * W ithinEnvelope(Pi+1 ) - predicate requiring proposed next phase Pi+1 to remain within the maximum authorized envelope. * ApprovalSatisfiedi+1 - predicate requiring all approvals applicable to phase i + 1 to be satisfied. D.6 Hardware and Progressive-State Notation * L in E03.19 - protected hardware phase-state variable representing the highest completed or currently authorized phase index in the illustrated latch implementation. This local unsubscripted L is distinct from any receipt-tree leaf notation used elsewhere. * j in E03.19 - requested phase index; the condition j = L + 1 permits only the immediately next phase in the illustrated sequential hardware state machine. * Continue - Boolean/protected continuation result in the hardware workflow; Continue = F ALSE means no broader phase is released under that branch. * Scope0 , Scope1 , ... , ScopeMAX - progressive authority scopes. The inclusion chain states that later scope may expand while remaining within the maximum authorized scope. * Qi - receipt confidence/quality value associated with phase i in E03.26. It is the phase-indexed counterpart of previously described receipt-quality notation. * τi - protected quality threshold applicable to phase i. D.7 Parallel, Quorum, and Partial-Success Notation Das Expires 4 April 2027 [Page 127] Internet-Draft Reality as a Cryptographic Dependency October 2026 * Ri1 , ... , Rin - receipts from multiple observers or confirmation sources for phase i. Superscripts identify the observer/source instance in this subsection and are not exponentiation. * SuccessfulSet - subset of original phase targets whose required success/receipt conditions were satisfied. * OriginalSet - original target set considered by the partial- success phase. D.8 Policy, Revocation, Veto, and Envelope Notation * P olicyEpochnew - newly applicable policy epoch after a policy- state change between phases. * P olicyEpochi - policy epoch associated with phase i. * Revoked(A) - protected predicate indicating that Candidate Act A, its remaining authority, or the relevant authorization has been revoked. * V eto - protected human or supervisory veto state; V eto = T RU E blocks the next phase under the illustrated rule. * CumulativeEffectproposed - cumulative effect that would result if the proposed next phase were allowed. * AuthorizedM aximum - maximum cumulative effect permitted by the protected authorization envelope. D.9 Final Receipt Alias * RF - final or completion receipt in E02/E03 workflow notation. It performs the same general role as previously defined final- completion receipt notation such as Rfinal ; the local symbol RF is used here for compactness. D.10 Word-Like Predicate Convention for This Workflow Word-like expressions appearing in equations - including UserAuthorized, DestinationAllowed, PolicyCurrent, RevocationClear, ResourceWithinScope, SinkTrusted, RiskAcceptable, AUTO_PASS, HUMAN_PASS, ReceiptValid, PolicyPass, AutoPolicyPass, HumanApproval, WithinEnvelope, ApprovalSatisfied, Continue, Veto, PROVEN_EFFECTED, PROVEN_NOT_EFFECTED, STILL_INDETERMINATE, and FULLY_EFFECTED - denote protected predicates, decisions, status labels, or state values according to context. They are descriptive mathematical labels and do not require literal programming-language identifiers or wire- format strings. Das Expires 4 April 2027 [Page 128] Internet-Draft Reality as a Cryptographic Dependency October 2026 D.11 Interpretation of Reused and Specialized Symbols The workflows deliberately reuse some generic mathematical symbols in local contexts. Such reuse does not imply that the underlying objects are identical. In particular: 1. M in E02.33 means a full intended communication, whereas M in a payment embodiment elsewhere may mean total payment amount. 2. Si+1 in E03.5 means next permitted scope, whereas S0 , S1 , ... elsewhere may denote enumerated state-machine states. 3. L in E03.19 means protected hardware phase state, whereas Lj elsewhere may denote a Merkle leaf or another locally defined object. 4. RF and Rfinal are local notation variants for a final/completion receipt unless a specific subsection assigns a narrower meaning. These local meanings are provided to remove ambiguity without narrowing the disclosed technical function. A.4. E04 — Verified Demonstration Effect, Protected Human Approval, Then Broader or Full Effectuation A.4.1. E04.1 Purpose E04 defines a protected staged-effectuation workflow in which a human approval required for broader or full effectuation is obtained after a bounded real effect has occurred and after machine-verifiable evidence of that effect has been returned and validated. The central relationship is: Candidate Act → P rotected V alidation → Bounded Real Effect → V erified Receipt → P rotected Human Review → Human Approval Artifact → Continuation Authority → Broader/F ull Effect The human is therefore not limited to approving a predicted consequence. The protected approval may be made with reference to evidence that a defined real effect already occurred at an effect- capable boundary. A.4.2. E04.2 Inheritance from E02 and E03 E04 may inherit from E02 or E03: * Candidate Act formation; * canonical or equivalent exact-act binding; * maximum authorized envelope; * Trial Effect Descriptor (TED); Das Expires 4 April 2027 [Page 129] Internet-Draft Reality as a Cryptographic Dependency October 2026 * Phase-0 authority; * Bounded Trial Effect (BTE); * Finality Sink verification; * effect observation; * Effect Confirmation Receipt (ECR); * receipt validation; * protected state advancement; * receipt consumption; * indeterminate-state reconciliation; * replay protection; * alternate-path closure; * and completion-receipt generation. E04 adds a protected human- decision dependency between validated effect evidence and later effectuation authority. A.4.3. E04.3 Candidate Act and Human-Approval Requirement A Candidate Act A is formed. Protected policy determines whether a human continuation decision is required. The requirement may depend upon: * consequence magnitude; * payment amount; * data sensitivity; * recipient class; * destination confidence; * infrastructure privilege; * actuator range; * geographic scope; Das Expires 4 April 2027 [Page 130] Internet-Draft Reality as a Cryptographic Dependency October 2026 * model or agent risk state; * taint or provenance state; * policy epoch; * regulatory or enterprise requirement; * irreversibility; * prior failure history; * or another protected predicate. Where human continuation is required, the system records a protected condition such as: HumanRequiredi = T RU E for the relevant later phase i. The proposing agent or application cannot satisfy this condition merely by generating text equivalent to an approval. A.4.4. E04.4 Human Approval May Be Required at Different Locations in the Sequence E04 primarily covers approval after a verified real effect, but the broader workflow may additionally require human approval: * before the trial effect; * after the trial effect; * before a selected intermediate phase; * after every phase; * before only the final irreversible phase; * after an anomaly; * when automatic policy cannot resolve uncertainty; * or when scope exceeds a protected threshold. The principal E04 dependency is that at least one required human continuation decision may be made after receipt of protected evidence from an earlier real phase. Das Expires 4 April 2027 [Page 131] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.4.5. E04.5 Bounded Real Effect The PED authorizes a bounded real effect P0 substantially according to E02. The BTE may be bounded by: * amount; * destination; * recipient; * resource; * time; * data subset; * privilege; * device set; * network scope; * geographic region; * actuator range; * deployment population; * or another consequence dimension. A successful BTE does not itself authorize the broader effect. A.4.6. E04.6 Effect Confirmation Receipt Following actual Phase-0 effectuation, an effect observer, Finality Sink, destination, protected sensor, transaction system, receiving endpoint, or other protected component generates or provides an ECR R0 . The ECR may bind: * Candidate Act digest; * TED digest; * actual observed effect; * sink identity; * destination identity; Das Expires 4 April 2027 [Page 132] Internet-Draft Reality as a Cryptographic Dependency October 2026 * recipient identity; * device identity; * transaction identifier; * measured hardware state; * timestamp or protected time; * nonce; * policy epoch; * revocation epoch; * success/failure/indeterminate state; * and any other protected evidence relevant to the human decision. A.4.7. E04.7 Protected Receipt Verification Before Human Presentation The system may prevent an unverified receipt from being presented as trusted execution evidence. Before the receipt is designated as verified evidence, a protected verifier may evaluate: ReceiptAccept0 = V erify(R0 ) ∧ M atch(R0 , P0 ) ∧ M atchDestination(R0 ) ∧ F resh(R0 ) ∧ P olicyCurrent ∧ RevocationClear If a required term fails: ReceiptAccept0 = F ALSE and the system may refuse to represent the receipt to the human as successful protected evidence. A.4.8. E04.8 Protected Human Review Object After receipt validation, the PED or a protected approval component may form a Protected Human Review Object (PHRO). The PHRO may bind or display information sufficient to support an informed continuation decision, including: * the original Candidate Act; * the authorized maximum envelope; * the bounded effect that was attempted; * the bounded effect actually observed; Das Expires 4 April 2027 [Page 133] Internet-Draft Reality as a Cryptographic Dependency October 2026 * the ECR status; * the recipient or destination; * the effect-capable sink; * time of effect; * transaction or device identifier; * receipt digest; * current risk state; * current taint/provenance state; * scope proposed for the next phase; * whether the next phase is reversible; * the consequence of approval; * the consequence of denial; * remaining amount or remaining effect; * policy epoch; * revocation state; * and an approval nonce or challenge. A PHRO may be a data object, protected UI state, signed message, hardware display object, secure-element record, remote approval object, or equivalent protected representation. A.4.9. E04.9 Separation from the Proposing Agent The protected human review surface may be separated from the proposing AI agent or application. Separation may be implemented using: * an operating-system security prompt; * privileged system UI; * secure mobile application; * trusted display; Das Expires 4 April 2027 [Page 134] Internet-Draft Reality as a Cryptographic Dependency October 2026 * hardware display; * enterprise security console; * secure element; * HSM-backed approval service; * out-of-band authenticated device; * remote protected service; * or another authority surface not controllable by the proposing agent. The protected human approval need not occur inside the conversational interface in which the agent proposed the act. A.4.10. E04.10 Human Authentication Before accepting a continuation decision, the protected approval component may authenticate the human or human role. Authentication may use: * passcode; * password; * biometric verification; * hardware security key; * secure element; * device-bound key; * enterprise identity; * cryptographic credential; * threshold or multi-party identity; * trusted-presence signal; * or another protected authentication mechanism. Human identity may be represented directly, pseudonymously, by role, by authority class, or by a protected credential. Das Expires 4 April 2027 [Page 135] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.4.11. E04.11 Human Presence and Anti-Synthetic Approval Where policy requires actual human participation, the system may require one or more protected presence conditions. Examples include: * local secure-input event; * trusted-display acknowledgement; * biometric presence; * security-key touch; * device-unlock state; * protected challenge response; * proximity proof; * liveness verification; * or other presence evidence. A textual statement generated by the proposing AI agent such as “approved” is not equivalent to protected human approval unless the architecture explicitly and securely binds that input to the required authority state. A.4.12. E04.12 Human Decision Set The human need not be restricted to a binary approve/deny choice. The protected decision may include: * approve the proposed next phase; * deny; * approve a smaller scope; * approve a different destination; * approve only one additional phase; * require another bounded test; * require additional evidence; * require a different sink; * postpone; Das Expires 4 April 2027 [Page 136] Internet-Draft Reality as a Cryptographic Dependency October 2026 * terminate the Candidate Act; * or escalate to another authority. A human decision that changes material act parameters creates a new protected scope that must be bound into later authority. A.4.13. E04.13 Human Approval Artifact A successful human decision may produce a Human Approval Artifact, denoted locally as HAi for phase i. The artifact may be a: * digital signature; * MAC-protected approval record; * secure-element signature; * device-bound attestation; * protected database state transition; * threshold signature share; * HSM-backed authorization; * hardware-latch state; * or equivalent protected authority evidence. The artifact need not be transferable or bearer-usable. A.4.14. E04.14 Cryptographic Binding of Human Approval to Prior Effect Evi- dence A preferred embodiment binds the human decision to the prior receipt. For example: HA1 = SignKH (DA ∥ H(R0 ) ∥ Scope1 ∥ Ep ∥ NH ) where KH is a protected signing key associated with the approving human or human-approval authority and NH is an approval-specific nonce. This construction is illustrative. Equivalent protected binding may be used. The functional property is: HA1 (R0 ) ⇏ HA1 (R0′ ) where R0′ represents a materially different prior effect receipt. Das Expires 4 April 2027 [Page 137] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.4.15. E04.15 Exact Scope Binding A human approval may be bound to a specific next scope: ApprovedScope1 ⊆ Envelopemax The approval of one scope does not necessarily authorize a broader scope. For example, approval of: * one recipient does not automatically authorize ten recipients; * INR 1,000 does not automatically authorize INR 10,000; * one device does not automatically authorize an entire fleet; * 10 degrees of movement does not automatically authorize 90 degrees; * one file does not automatically authorize a full dataset. A.4.16. E04.16 Approval Freshness A human approval may expire. The system may require: Tnow ≤ Tapproval_expiry and may revalidate: * current policy; * current revocation state; * destination identity; * sink identity; * risk; * taint; * system state; * and relevant receipt state before using the approval. A.4.17. E04.17 Policy Change Between Receipt and Human Approval If policy changes after the bounded real effect but before human approval, the PED may refuse to continue under stale policy. For example: Epcurrent ≠ Epreceipt ⇒ Revalidate The human may be shown updated conditions or required to make a new decision. Das Expires 4 April 2027 [Page 138] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.4.18. E04.18 Revocation Between Receipt and Approval A valid ECR does not override a later revocation. If: Revoked(A) = T RU E then a previously successful demonstration may remain insufficient for broader effectuation. Unused human approval artifacts may also be revoked or invalidated where supported. A.4.19. E04.19 Human Approval After Evidence, Not Merely Before Evidence A key E04 embodiment has the sequence: P0 → R0 → HA1 → P1 rather than: HA → P0 → P1 This permits the human to make a continuation decision using verified evidence about an already observed bounded effect. A.4.20. E04.20 Continuation Predicate A representative continuation predicate may be: Enable(P1 ) = V alid(R0 ) ∧ V alid(HA1 ) ∧ M atchApproval(HA1 , R0 , P1 ) ∧ P olicyCurrent ∧ RevocationClear ∧ W ithinEnvelope(P1 ) Where any required term is false: Enable(P1 ) = F ALSE A.4.21. E04.21 Continuation Authority Generation After successful human approval verification, the PED may generate, derive, unseal, release, or activate the continuation authority C1 . The continuation authority may bind: * DA ; * H(R0 ); * H(HA1 ); * next-phase identifier; * sink identity; * scope; * policy epoch; Das Expires 4 April 2027 [Page 139] Internet-Draft Reality as a Cryptographic Dependency October 2026 * revocation epoch; * nonce; * expiration; * and destination or device identity. A.4.22. E04.22 Receipt-and-Approval-Derived Key A hardware-rooted or software-protected embodiment may derive: K1 = KDF (KR , DA , H(R0 ), H(HA1 ), 1) The next-phase key therefore depends on both the protected effect receipt and protected human approval. A.4.23. E04.23 Split-Key Human Approval Variation Instead of signing an approval object, the human-authority device may hold a missing cryptographic share. For example: Kfinal = Combine(KP ED , KH ) where KH or a derived share is released only after the protected human reviews the verified receipt and approves continuation. The human interface therefore participates directly in making later effectuation cryptographically possible. A.4.24. E04.24 Human Approval Through Hardware A hardware approval implementation may use: * secure element; * hardware security key; * trusted display; * TPM; * HSM; * secure enclave; * mobile secure processor; * isolated MCU; Das Expires 4 April 2027 [Page 140] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or another protected hardware component. The hardware may verify the receipt digest before enabling its approval function. A.4.25. E04.25 Human Approval Through Software PED A software implementation may use: Agent Runtime -> PED / Receipt Verifier -> Protected Approval UI -> Human Decision Artifact -> PED -> Continuation Authority -> Finality Sink. The agent runtime may have no direct access to the protected approval private key, approval state, or final effect credential. A.4.26. E04.26 Remote Human Approval The human may approve from a different device or security domain. The remote approval request may cryptographically bind: * Candidate Act digest; * prior ECR digest; * requested next scope; * destination; * policy epoch; * nonce; * and expiration. The approving device returns a protected human approval artifact. A relay between the PED and approval device need not be trusted to modify the approved contents. A.4.27. E04.27 Multi-Human Approval Some phases may require approvals from multiple people or roles. For example: n ∑ V alid(HAji ) ≥ m j=1 where m of n required human authorities must approve. Different approvers may represent: * user; * enterprise administrator; * safety officer; Das Expires 4 April 2027 [Page 141] Internet-Draft Reality as a Cryptographic Dependency October 2026 * financial controller; * device owner; * compliance authority; * guardian; * or another protected role. A.4.28. E04.28 Human Approval Can Reduce But Not Silently Expand Scope A protected human may approve a smaller scope than originally proposed. For example: Scopeapproved ⊂ Scopeproposed A human-facing UI or intermediary must not silently transform a restricted approval into broader effectuation authority. If scope is materially increased after approval, fresh approval or another protected authorization may be required. A.4.29. E04.29 Human Denial If the human denies continuation: HumanDecision = DEN Y then unused continuation authority remains unavailable. The architecture may: * terminate; * rollback the bounded effect where possible; * compensate; * retain the bounded effect without further expansion; * request a different bounded trial; * or preserve evidence for later review. A.4.30. E04.30 Human Requests Another Trial The human may decide that one trial is insufficient. The PED may create a new bounded phase P0′ or P1 having a scope approved by the human. The new phase produces a new ECR before another human decision. Thus a human-controlled progressive chain may be: Das Expires 4 April 2027 [Page 142] Internet-Draft Reality as a Cryptographic Dependency October 2026 P0 → R0 → HA1 → P1 → R1 → HA2 → P2 A.4.31. E04.31 Human Approval of Final Irreversible Phase A particularly useful high-assurance embodiment allows earlier reversible or limited phases automatically, but requires human approval immediately before an irreversible or high-consequence phase. Example: recipient verification -> bounded transfer -> settlement confirmation -> human approval -> irreversible final settlement. A.4.32. E04.32 Communication Embodiment An AI agent proposes sending a sensitive file. 1. The PED authorizes a bounded protected trailer to the intended recipient. 2. The real recipient endpoint receives it. 3. The endpoint returns signed ECR R0 . 4. The PED verifies R0 . 5. A protected UI presents recipient identity, receipt status, file digest, proposed full release, and destination. 6. The human approves or denies. 7. Approval produces HA1 . 8. The PED derives or releases C1 . 9. The Finality Sink transmits the full file or releases the final decryption material. 10. A completion receipt records the final result. A.4.33. E04.33 Payment Embodiment A payment application or agent proposes a larger payment. 1. Protected policy permits a bounded verification transfer or reversible authorization. 2. The real payment infrastructure processes the bounded phase. 3. The receiving institution or settlement component returns protected evidence. 4. The PED verifies recipient account, institution, transaction identifier, currency, amount, and status. 5. The protected human approval UI displays the verified result and remaining proposed amount. 6. The human approves the final amount or a smaller amount. 7. The approval artifact binds the accepted amount and receipt digest. 8. The full settlement authority becomes available only within the approved scope. A.4.34. E04.34 Hardware Actuator Embodiment A robot requests a 90-degree movement. 1. The PED authorizes 5 degrees. 2. The motor physically moves. 3. A protected encoder reports the observed movement. 4. The receipt verifier confirms the movement is within tolerance. 5. A trusted display shows the requested remaining motion and verified trial result. 6. The authenticated human approves a further 20 degrees, the remaining 85 degrees, or another bounded scope. 7. The secure controller releases only the approved command envelope. Das Expires 4 April 2027 [Page 143] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.4.35. E04.35 Cloud / Deployment Embodiment A deployment agent proposes a large software rollout. 1. The PED permits a bounded canary deployment. 2. Real target nodes execute the software. 3. Protected health and attestation evidence is returned. 4. The PED verifies the evidence. 5. A human operator sees actual canary measurements and target identity. 6. The human approves broader rollout. 7. The next-stage deployment credential is issued only for the approved cohort. A.4.36. E04.36 Indeterminate Receipt Before Human Approval If receipt state is indeterminate, the protected UI may display the state as indeterminate rather than treating it as successful. A policy may prohibit approval of broader effectuation until reconciliation resolves the prior effect. Where policy permits human handling of indeterminate state, the human decision must not erase the protected record of uncertainty; any exceptional override should be separately bound and auditable. A.4.37. E04.37 Crash After Human Approval But Before Continuation If human approval is generated but the system crashes before Phase 1 occurs, protected state may preserve whether HA1 was: * generated; * received; * validated; * consumed; * or unused. A replayed approval must not cause duplicate effectuation where single-use semantics apply. A.4.38. E04.38 Approval Consumption The PED may mark: Consumed(HA1 ) = T RU E atomically with generation or consumption of the corresponding continuation authority. A consumed approval cannot independently authorize another full effect. Das Expires 4 April 2027 [Page 144] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.4.39. E04.39 Alternate-Path Closure The staged human-approval path is insufficient if another route allows the agent to directly invoke full effectuation. Accordingly, equivalent effect-capable paths may be: * disabled; * mediated; * hardware-locked; * credential-restricted; * sink-verified; * destination-verified; * kernel-mediated; * or placed under equivalent protected approval requirements. A.4.40. E04.40 Agent Non-Authority Invariant The proposing agent may: * recommend approval; * explain the act; * summarize receipt evidence; * or request user confirmation. However, where protected human approval is required, the agent does not become the approving authority merely because it can generate or display such content. A.4.41. E04.41 Required Invariants Invariant 1 A bounded real effect occurs before at least one protected human continuation decision. Invariant 2 Protected evidence of that effect is validated before it is relied upon as the required continuation evidence. Invariant 3 The protected human decision is associated with the relevant Candidate Act, prior receipt, or authorized next scope. Das Expires 4 April 2027 [Page 145] Internet-Draft Reality as a Cryptographic Dependency October 2026 Invariant 4 The proposing agent cannot satisfy the protected human- approval requirement merely through self-generated output. Invariant 5 A human approval does not silently enlarge the Candidate Act beyond its authorized maximum envelope. Invariant 6 Failure, denial, expiration, revocation, or required uncertainty prevents unauthorized broader effectuation. Invariant 7 The human-approval dependency may be enforced in software, hardware, or a combined PED. PROTECTED DECISION -> RECEIPT-GATED CONTINUA- TION A.5. E05 — Verified Demonstration Effect, Automatic Protected Decision, Then Receipt-Gated Continuation A.5.1. E05.1 Purpose E05 defines a staged-effectuation workflow in which later effectuation is authorized automatically by a protected authority after machine-verifiable evidence of a prior real effect has been validated. Human interaction is not required where policy permits automatic continuation. The principal chain is: Candidate Act → Bounded Real Effect → V erified Receipt → P rotected Automatic Decision → Continuation Authority → Broader/F ull Effect The protected automatic decision is distinct from the proposing agent’s own desire or generated output. A.5.2. E05.2 Automatic Does Not Mean Unprotected An automatic continuation path may operate without a human while still requiring: * protected policy state; * receipt validity; * sink identity; * destination matching; * risk conditions; * taint/provenance conditions; Das Expires 4 April 2027 [Page 146] Internet-Draft Reality as a Cryptographic Dependency October 2026 * revocation checks; * maximum-envelope enforcement; * freshness; * and protected state transition. The proposing agent cannot necessarily modify these conditions. A.5.3. E05.3 Automatic Decision Authority The automatic decision may be made by an Automatic Continuation Authority (ACA). The ACA may be implemented by: * protected policy engine; * privileged daemon; * kernel component; * TEE; * HSM; * secure element; * hardware controller; * transaction engine; * network gateway; * distributed protected service; * rule engine operating under protected state; * formally verified state machine; * or another protected component. The ACA may be part of the PED or a separately protected component. A.5.4. E05.4 Inputs to Automatic Decision The ACA may receive protected inputs including: * Ri ; * Candidate Act digest; Das Expires 4 April 2027 [Page 147] Internet-Draft Reality as a Cryptographic Dependency October 2026 * phase identifier; * actual observed effect; * risk state; * taint state; * provenance state; * policy epoch; * revocation epoch; * sink identity; * destination identity; * device measurement; * transaction state; * cumulative effect; * remaining authorized envelope; * historical phase outcomes; * error rate; * health state; * time; * or another protected input. A.5.5. E05.5 Automatic Predicate Set Let the protected automatic decision predicate set for phase i be: Γi = {gi,1 , gi,2 , ... , gi,m } Illustrative predicates include: gi,1 = ReceiptV alidi gi,2 = RiskAcceptablei Das Expires 4 April 2027 [Page 148] Internet-Draft Reality as a Cryptographic Dependency October 2026 gi,3 = P olicyV alidi gi,4 = RevocationCleari gi,5 = W ithinEnvelopei gi,6 = SinkExpectedi The implementation need not use every listed predicate. A.5.6. E05.6 Deterministic Automatic Decision A deterministic ACA may evaluate a fixed protected rule set. For example: m AutoP assi = ⋀ gi,k k=1 If: AutoP assi = T RU E then the system may proceed to next-phase authority generation. If: AutoP assi = F ALSE then progression is blocked, reduced, rerouted, or escalated according to policy. A.5.7. E05.7 Multi-State Automatic Decision The ACA need not use binary allow/deny logic. Possible protected outcomes include: * ALLOW; * DENY; * HOLD; * REDUCE_SCOPE; * RETRY_TRIAL; * REQUIRE_STRONGER_RECEIPT; * REQUIRE_HUMAN; * REQUIRE_QUORUM; * RECONCILE; Das Expires 4 April 2027 [Page 149] Internet-Draft Reality as a Cryptographic Dependency October 2026 * TERMINATE; * or another protected state. Thus automatic decision does not imply unconditional automatic execution. A.5.8. E05.8 Automatic Decision Record The ACA may generate an Automatic Decision Record (ADR), denoted locally as ADi . The ADR may bind: * Candidate Act digest; * phase; * prior receipt digest; * decision result; * authorized next scope; * policy epoch; * revocation epoch; * risk state; * relevant predicate outcomes; * destination; * sink; * nonce; * expiry; * and ACA identity or measurement. The ADR may be signed, MACed, attested, committed to protected state, or represented as an internal protected transition. A.5.9. E05.9 Automatic Decision Cryptographic Binding An illustrative ADR may be: ADi = P rotectKACA (DA ∥ H(Ri ) ∥ Decisioni ∥ Scopei+1 ∥ Ep ∥ NA,i ) where KACA is a protected key associated with the automatic authority and NA,i is a decisionspecific nonce. Das Expires 4 April 2027 [Page 150] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.5.10. E05.10 Independence from Agent-Controlled State Where higher assurance is required, the ACA may rely on state not writable by the proposing agent. Examples include: * kernel-protected state; * TEE state; * HSM state; * secure database state; * hardware counters; * protected network observations; * independent destination receipts; * enterprise policy service; * or signed configuration. The agent may supply evidence but need not be trusted to assert final predicate truth. A.5.11. E05.11 Model-Assisted Evidence Without Model Authority An AI model may contribute: * risk classification; * semantic analysis; * anomaly score; * predicted consequence; * content classification; * or recommendation. Such output may be treated as one input to the protected automatic decision. The architecture may still require independent protected predicates before later effectuation becomes possible. A.5.12. E05.12 Receipt Validation Before automatic continuation, the PED/ACA may verify: V alid(Ri ) = T RU E and may reject: Das Expires 4 April 2027 [Page 151] Internet-Draft Reality as a Cryptographic Dependency October 2026 * forged receipt; * stale receipt; * wrong-destination receipt; * wrong-phase receipt; * wrong-sink receipt; * replayed receipt; * revoked receipt context; * or an indeterminate result where success is required. A.5.13. E05.13 Automatic Next-Phase Predicate A representative protected predicate is: Enable(Pi+1 ) = V alid(Ri ) ∧ AutoP assi ∧ M atch(ADi , Ri , Pi+1 ) ∧ P olicyCurrent ∧ RevocationClear ∧ W ithinEnvelope(Pi+1 ) A.5.14. E05.14 Receipt-Plus-Automatic-Decision Key Derivation A protected implementation may derive next-phase material from both receipt and automatic decision: Ki+1 = KDF (KR , DA , H(Ri ), H(ADi ), i + 1) Accordingly, the proposing agent cannot obtain the next-phase key solely from the receipt if the protected automatic decision has not succeeded. A.5.15. E05.15 Internal Protected State Variation The ACA need not emit a separate ADR object. It may instead atomically update protected state: Statei → AU T O_AP P ROV EDi+1 and the Finality Sink may require that protected state before allowing the next phase. The term ADR therefore denotes a functional decision record and does not require a portable artifact. A.5.16. E05.16 Low-Latency Hot-Path Variation For low-latency systems, expensive reasoning may occur before the hot finality path. The hot path may verify compact protected values such as: Das Expires 4 April 2027 [Page 152] Internet-Draft Reality as a Cryptographic Dependency October 2026 * receipt digest; * phase index; * nonce; * policy epoch; * revocation epoch; * sink identity; * precomputed risk class; * ADR digest; * and scope. The hot path need not execute a large model or complex policy analysis where a prevalidated protected decision can be verified compactly. A.5.17. E05.17 Preauthorized Automatic Envelope A human or enterprise authority may establish an envelope in advance. Within that envelope, the ACA may progress automatically after each verified receipt. For example: Automatically deploy up to 10,000 devices, but progress only when each protected phase meets health, attestation, and error-rate conditions. The original envelope remains a ceiling. A.5.18. E05.18 Risk-Adaptive Automatic Progression Let protected risk after phase i be Riski . The ACA may compute a next scope: Scopei+1 = f(Ri , Riski , P olicyi , Historyi ) Higher risk may result in: * smaller next phase; * stronger receipt requirements; * additional destination verification; * human escalation; * or termination. Das Expires 4 April 2027 [Page 153] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.5.19. E05.19 Receipt-Quality-Adaptive Progression Where receipt quality is represented by Qi , the ACA may require: Qi ≥ τi before ordinary continuation. If the threshold is not met, the ACA may require a stronger observer or a human decision. A.5.20. E05.20 Error-Rate-Controlled Rollout For fan-out deployment, let: F ailedT argetsi Erri = AttemptedT argetsi The ACA may require: Erri ≤ τerr before increasing the rollout population. This may be combined with critical-failure conditions that block continuation even where aggregate error rate is low. A.5.21. E05.21 Automatic Communication Embodiment A communication agent proposes sending a file. 1. A protected trailer reaches the actual destination. 2. The receiver returns signed ECR R0 . 3. The ACA verifies endpoint identity, receipt freshness, destination, policy, and sensitivity class. 4. Policy permits automatic continuation for the defined communication class. 5. The ACA creates AD0 . 6. The PED derives or releases the full- send capability. 7. The Finality Sink sends the remaining payload or releases its decryption key. No human action is required. A.5.22. E05.22 Automatic Payment Embodiment A preauthorized enterprise workflow may allow automatic staged payments within a limit. 1. A bounded verification transaction or reservation is performed. 2. The payment rail returns protected evidence. 3. The ACA verifies recipient, institution, currency, amount, policy, spending limit, and receipt. 4. If all protected predicates pass, the next settlement phase is automatically authorized. 5. If a threshold is exceeded, the ACA returns REQUIRE_HUMAN rather than continuing automatically. A.5.23. E05.23 Automatic Hardware Embodiment A robotic system requests a motion trajectory. 1. A bounded movement is executed. 2. Protected sensors return measured state. 3. The ACA checks tolerance, safety envelope, hardware identity, and policy. 4. If valid, a secure controller automatically enables the next bounded trajectory segment. 5. A deviation causes immediate hold or safe- state behavior. Das Expires 4 April 2027 [Page 154] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.5.24. E05.24 Automatic Telecom Embodiment A network controller proposes a configuration change. A limited effect is applied to one cell, slice, route, subscriber class, or bounded traffic population. Protected telemetry is collected. The ACA automatically authorizes the next rollout phase only where health, policy, security, and receipt predicates remain valid. A.5.25. E05.25 Automatic Cloud Rollout Embodiment A protected deployment controller may progressively expand: 1 node → 10 nodes → 100 nodes → full authorized cohort after each phase returns validated health and attestation evidence. The agent cannot directly jump to the final cohort if the ACA-controlled phase state has not advanced. A.5.26. E05.26 Automatic Credential Escalation A trial credential may permit only a narrow operation. Successful endpoint use produces protected evidence. The ACA may automatically release a broader credential scope if policy permits. The broader credential may remain: * audience-bound; * act-bound; * sink-bound; * short-lived; * phase-bound; * non-bearer; * or hardware-bound. A.5.27. E05.27 Automatic Denial and Safe-Limited Outcome A failed automatic decision need not cause complete termination. The ACA may select: * reduced scope; * local-only mode; * read-only mode; Das Expires 4 April 2027 [Page 155] Internet-Draft Reality as a Cryptographic Dependency October 2026 * reversible mode; * another trial; * quarantine; * delayed continuation; * or protected human escalation. A.5.28. E05.28 Indeterminate Prior Effect Where: Statusi = IN DET ERM IN AT E and policy requires proof of prior outcome, the ACA returns RECONCILE or HOLD. It must not infer success solely because a timeout occurred. A.5.29. E05.29 Reconciliation Before Automatic Retry The ACA/PED may query authoritative state using: * idempotency key; * transaction identifier; * device counter; * destination state; * protected journal; * settlement record; * database commit state; * or other evidence. Only a protected conclusion of PROVEN_NOT_EFFECTED may allow an ordinary retry when duplicate effect would otherwise be unsafe. A.5.30. E05.30 Automatic Decision Freshness An ADR or internal automatic decision may have an expiry. Before the next effect: F resh(ADi ) = T RU E may be required. Policy or revocation changes can invalidate an otherwise valid older decision. Das Expires 4 April 2027 [Page 156] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.5.31. E05.31 Automatic Decision Consumption Where a decision is single-use: Consumed(ADi ) = T RU E may be recorded when next-phase authority is released or consumed. Replay of the ADR must not independently cause repeated broader effectuation. A.5.32. E05.32 Hardware ACA The ACA may be implemented in secure hardware. A secure processor can: 1. verify Ri ; 2. evaluate compact protected predicates; 3. advance phase state; 4. derive Ki+1 ; 5. release a hardware command authenticator; 6. or set a protected latch. Ordinary software may be unable to bypass that decision. A.5.33. E05.33 Distributed ACA Automatic authority may be distributed among multiple protected components. For example: * device PED validates local state; * cloud authority validates enterprise policy; * destination validates endpoint state; * HSM releases key material only after both decisions. A threshold or conjunction rule may combine their outputs. A.5.34. E05.34 Policy Rollback Protection The ACA may bind decisions to monotonic policy or revocation epochs. A rollback to an older permissive policy must not silently reactivate previously prohibited automatic continuation. Protected counters, signed policy versions, secure boot, anti-rollback state, or equivalent mechanisms may be used. A.5.35. E05.35 Alternate-Path Closure An automatically gated path must not coexist with an unrestricted equivalent path that can cause the same broader effect without ACA approval. Equivalent routes may be disabled or placed under corresponding protected control. Das Expires 4 April 2027 [Page 157] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.5.36. E05.36 Required Invariants Invariant 1 At least one later phase is gated by protected automatic evaluation of evidence from a prior real effect. Invariant 2 Automatic approval is not merely the proposing agent asserting that its own action should continue. Invariant 3 The receipt and applicable protected state are validated before broader authority is released. Invariant 4 Automatic continuation remains within the maximum authorized envelope. Invariant 5 Required failure, revocation, stale state, or indeterminate conditions block or limit continuation. Invariant 6 Automatic authority may be represented by an ADR, protected state transition, key release, hardware latch, capability, or equivalent technical enablement condition. Invariant 7 The architecture supports software-only, hardware-rooted, and distributed automatic enforcement. CONTINUATION A.6. E06 — Hybrid Human and Automatic Receipt-Gated Continuation A.6.1. E06.1 Purpose E06 defines a protected staged-effectuation architecture in which human authority and automatic protected authority are combined to govern progression after one or more real bounded effects. The combination may be: * conjunctive; * disjunctive where policy permits; * threshold-based; * sequential; * hierarchical; * escalatory; * veto-based; Das Expires 4 April 2027 [Page 158] Internet-Draft Reality as a Cryptographic Dependency October 2026 * scope-dependent; * risk-dependent; * or cryptographically split. A representative high-assurance chain is: Pi → Ri → Automatic P rotected Decision → P rotected Human Decision → Hybrid Continuation Authority → Pi+1 A.6.2. E06.2 Inheritance from E04 and E05 E06 may inherit: * verified real-effect receipt; * PHRO; * Human Approval Artifact HAi ; * ACA; * Automatic Decision Record ADi ; * protected state advancement; * maximum-envelope enforcement; * continuation authority; * receipt and approval consumption; * crash recovery; * indeterminate-state handling; * and alternate-path closure. E06 specifies how human and automatic authority interact. A.6.3. E06.3 Conjunctive Hybrid Approval A high-assurance mode requires both automatic and human approval. For phase i + 1: HybridP assi+1 = AutoP assi ∧ HumanP assi Continuation is permitted only if: Das Expires 4 April 2027 [Page 159] Internet-Draft Reality as a Cryptographic Dependency October 2026 HybridP assi+1 = T RU E This mode prevents either the automated policy engine or human approval alone from causing the broader effect. A.6.4. E06.4 Representative Conjunctive Predicate A representative next-phase condition may be: Enable(Pi+1 ) = V alid(Ri ) ∧ V alid(ADi ) ∧ V alid(HAi ) ∧ M atch(ADi , Ri , Pi+1 ) ∧ M atchApproval(HAi , Ri , Pi+1 ) ∧ P olicyCurrent ∧ RevocationClear ∧ W ithinEnvelope(Pi+1 ) A.6.5. E06.5 Automatic-First, Human-Second Sequence One variation uses: Ri → ADi → HAi → Ci+1 The human is asked to decide only after automatic checks have passed. This can reduce unnecessary human prompts for acts that would be automatically denied anyway. A.6.6. E06.6 Human-First, Automatic-Second Sequence Another variation uses: Ri → HAi → ADi → Ci+1 A human expresses approval, but the automatic protected authority performs final policy, revocation, sink, destination, and scope checks before effectuation authority becomes usable. Thus human approval cannot override mandatory technical policy where policy is configured as non-overridable. A.6.7. E06.7 Parallel Human and Automatic Decisions Human and automatic evaluation may occur in parallel after receipt validation. The PED waits until required results converge. For example: DecisionReadyi = Received(HAi ) ∧ Received(ADi ) Only then does the PED evaluate the hybrid rule. A.6.8. E06.8 Disjunctive Hybrid Approval For selected lower-risk act classes, protected policy may permit either of two authority paths: HybridP assi = HumanP assi ∨ HighAssuranceAutoP assi The disjunctive mode is not assumed by default; its availability is itself protected policy. A lower-assurance automatic result may still require human approval. Das Expires 4 April 2027 [Page 160] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.6.9. E06.9 Threshold-Based Approval The system may combine multiple human and automatic authorities using a threshold. Let protected approval votes be: Vi = {v1 , v2 , ... , vn } Continuation may require: n ∑ w j vj ≥ Θ i j=1 where wj is a protected weight and Θi is the required threshold for phase i. Weights may reflect authority class, assurance level, or role. A.6.10. E06.10 Role-Separated Hybrid Approval Different authorities may be responsible for different predicates. Example: * ACA verifies technical safety and receipt validity; * human verifies business intent; * enterprise authority verifies budget; * hardware verifies device state; * destination verifies endpoint state. The final continuation condition may require all mandatory roles. A.6.11. E06.11 Human Cannot Override Certain Automatic Denials Protected policy may classify some failures as non-overridable. For example: * invalid signature; * revoked authority; * wrong sink; * wrong destination; * stale policy epoch; * exceeded maximum envelope; * hardware safety violation; Das Expires 4 April 2027 [Page 161] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or cryptographic mismatch. Even if a human selects APPROVE, the PED may require: M andatoryT echnicalP ass = T RU E before continuation. A.6.12. E06.12 Automatic Authority Cannot Fabricate Human Approval Where human approval is mandatory, the ACA cannot replace it merely by outputting a Boolean that says the user would probably approve. The protected human artifact must originate from the required human- authority path. A.6.13. E06.13 Human Scope Reduction A human may reduce the scope recommended by the ACA. If the ACA recommends: Scopeauto and the human approves: Scopehuman then the final permitted scope may be: Scopefinal = Scopeauto ∩ Scopehuman or another protected intersection/equivalence rule. A.6.14. E06.14 Automatic Scope Reduction Conversely, a human may approve a broad scope but the ACA may limit it. The final effect remains within the narrower protected outcome. For scalar scopes: Scopefinal = min(Scopehuman , Scopeauto ) where a scalar interpretation is meaningful. A.6.15. E06.15 Conflict State Where human and automatic decisions conflict, the system may enter: State = CON F LICT Protected policy may then: * deny; * hold; * reduce scope; * request additional evidence; Das Expires 4 April 2027 [Page 162] Internet-Draft Reality as a Cryptographic Dependency October 2026 * require another human; * require another automatic authority; * require a new bounded trial; * or escalate. Conflict is not silently interpreted as approval. A.6.16. E06.16 Escalation from Automatic to Human A common hybrid flow is: AutoDecisioni = IN DET ERM IN AT E ⇒ HumanReviewRequired The human may inspect verified evidence and make a protected decision within an allowed override envelope. Some technical failures may remain non- overridable. A.6.17. E06.17 Escalation from Human to Additional Automatic Verification A human may request stronger technical validation before deciding. For example: * hardware attestation; * destination re-verification; * second receipt source; * policy refresh; * transaction status query; * device measurement; * or another bounded trial. The result returns to the protected human review flow. A.6.18. E06.18 Human Veto over Automatic Continuation A system may permit automatic progression unless a protected human veto is received within a defined window. For example: V alid(Ri ) ∧ AutoP assi ∧ ¬V etoi ⇒ Enable(Pi+1 ) The veto mechanism may be authenticated and isolated from the proposing agent. Das Expires 4 April 2027 [Page 163] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.6.19. E06.19 Automatic Veto over Human Approval The ACA may block continuation despite human approval where mandatory technical predicates fail. For example: HumanP assi ∧ ¬M andatoryT echnicalP assi ⇒ Enable(Pi+1 ) = F ALSE A.6.20. E06.20 Two-Key Hybrid Authority Human and automatic authorities may each control separate key material. For example: Ki+1 = KDF (Combine(KH , KA ), DA , H(Ri ), i + 1) where KH and KA are protected key shares or derived secrets associated with human and automatic authorities. No single authority can independently produce the next-phase key. A.6.21. E06.21 Threshold-Key Hybrid Authority A later phase may require m of n protected shares from: * human approval device; * PED; * HSM; * enterprise authority; * destination; * network authority; * device secure element; * or another protected participant. Receipt validation may be required before any share becomes releasable. A.6.22. E06.22 Receipt + Human + Automatic Cryptographic Binding A representative high-assurance continuation object may be: Ci+1 = P rotectKP ED (DA ∥ H(Ri ) ∥ H(HAi ) ∥ H(ADi ) ∥ Scopefinal ∥ Sinki+1 ∥ Expiryi+1 ) This explicitly binds the next-phase authority to all required components of the hybrid decision. Das Expires 4 April 2027 [Page 164] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.6.23. E06.23 Hybrid Protected State Machine Representative states may include: * RECEIPT_VERIFIED; * AUTO_PENDING; * AUTO_PASSED; * HUMAN_PENDING; * HUMAN_PASSED; * CONFLICT; * HYBRID_AUTHORIZED; * DENIED; * INDETERMINATE; * TERMINATED. A protected state transition may require the expected preceding states rather than accepting out-of-order approvals. A.6.24. E06.24 Human Approval Expiry and Automatic Decision Expiry Human and automatic decisions may have different freshness windows. For example: F resh(HAi ) ∧ F resh(ADi ) may be required at the time of next-phase effectuation. If one expires, the PED may require that decision to be refreshed without necessarily repeating the other decision, depending on protected policy. A.6.25. E06.25 Policy Change During Hybrid Approval If policy changes after one authority approves but before the second authority approves, the PED may require revalidation. For example: EpHA ≠ Epcurrent ⇒ Revalidate(HAi ) and similarly for ADi . A.6.26. E06.26 Revocation During Hybrid Approval Revocation may invalidate: Das Expires 4 April 2027 [Page 165] Internet-Draft Reality as a Cryptographic Dependency October 2026 * the Candidate Act; * receipt eligibility; * human approval; * automatic decision; * continuation authority; * or sink authority. A later revocation may prevent use of previously created but unconsumed approval artifacts. A.6.27. E06.27 Consumption of Hybrid Artifacts Where single-use semantics apply, the system may atomically record: Consumed(Ri ) = T RU E Consumed(HAi ) = T RU E Consumed(ADi ) = T RU E when Ci+1 is consumed or generated. This prevents one hybrid authorization bundle from causing repeated broader effects. A.6.28. E06.28 Partial Consumption and Crash Recovery If the system crashes after one artifact is marked consumed but before the next phase completes, protected transaction state should permit reconciliation without silently authorizing duplication. The PED may maintain a protected transaction identifier linking: * receipt; * human approval; * automatic decision; * continuation authority; * and effectuation result. A.6.29. E06.29 Human-Optional Hybrid Mode The same architecture may dynamically select between: AutoOnly Das Expires 4 April 2027 [Page 166] Internet-Draft Reality as a Cryptographic Dependency October 2026 HumanOnly and: Human + Auto based on protected policy. Thus a deployment need not impose human approval on every act. A.6.30. E06.30 Risk-Threshold Hybrid Mode Illustratively: Risk < T1 ⇒ AutoOnly T1 ≤ Risk < T2 ⇒ Auto + EnhancedV erification Risk ≥ T2 ⇒ Human + Auto The thresholds and categories are non- limiting and may depend on multiple protected dimensions. A.6.31. E06.31 Consequence-Threshold Hybrid Mode Approval mode may depend on consequence magnitude. Examples: * low-value payment -> automatic; * medium-value payment -> automatic plus stronger receipt; * high-value payment -> human plus automatic; * one-device rollout -> automatic; * fleet-wide rollout -> human plus automatic; * bounded movement -> automatic; * irreversible actuator action -> human plus automatic. A.6.32. E06.32 Taint / Provenance Hybrid Mode Protected taint or provenance state may select approval mode. For example: T rusted ⇒ AutoOnly U ncertain ⇒ Human + Auto P rohibited ⇒ DEN Y The agent cannot clear a protected taint state merely by requesting broader authority. Das Expires 4 April 2027 [Page 167] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.6.33. E06.33 Multi-Human + Automatic Hybrid A high-assurance system may require: n AutoP assi ∧ (∑ V alid(HAji ) ≥ m) j=1 before continuation. This supports board, enterprise, financial, safety, or multi-role approvals combined with machineverifiable technical policy. A.6.34. E06.34 Multi-Automatic + Human Hybrid Multiple independent automatic authorities may also be required. Example: HumanP assi ∧ AutoSecurityi ∧ AutoP olicyi ∧ AutoHardwarei The automatic authorities may run in separate security domains. A.6.35. E06.35 Communication Embodiment A sensitive message or file is proposed. 1. The recipient receives a bounded protected trailer. 2. The endpoint returns R0 . 3. The ACA validates destination, policy, taint, scope, and receipt and creates AD0 . 4. The human sees verified recipient/effect information and produces HA0 . 5. The PED requires both artifacts. 6. The full-send capability or decryption key is released. 7. The communication Finality Sink performs the full effect. A.6.36. E06.36 Payment Embodiment A high-value payment is proposed. 1. A bounded real payment verification phase occurs. 2. The receiving institution returns protected confirmation. 3. Automatic policy checks account, amount, limit, currency, sanctions/enterprise rules where applicable, receipt, and transaction state. 4. A protected human sees the verified beneficiary and bounded transaction result. 5. Human and automatic decisions are both required. 6. The settlement key/share or completion capability becomes available only after both pass. A.6.37. E06.37 Hardware / Robotics Embodiment A robot proposes a consequential movement. 1. A small real movement is executed. 2. Trusted sensors return R0 . 3. Automatic safety logic verifies tolerance and safety envelope. 4. A human supervisor reviews the actual movement and requested next range. 5. Both approvals unlock the next actuator command envelope. 6. Hardware enforces the approved limit. Das Expires 4 April 2027 [Page 168] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.6.38. E06.38 Cloud / Infrastructure Embodiment A deployment agent proposes a large infrastructure change. 1. Canary deployment occurs. 2. Protected health receipts return. 3. Automatic security and reliability rules evaluate the canary. 4. Human operator reviews verified canary evidence. 5. The next deployment cohort is restricted to the intersection of the automatic and humanapproved scopes. A.6.39. E06.39 Telecom Embodiment A network configuration change is applied first to a bounded slice, cell, beam, route, or subscriber set. Protected telemetry produces effect evidence. Automatic network-safety rules and a human operator may jointly authorize expansion to broader network scope. A.6.40. E06.40 Destination-Side Hybrid Enforcement The destination itself may require proof of both human and automatic approval before accepting the broader effect. For example, the destination may verify: * receipt-chain binding; * ACA decision signature; * human approval signature; * phase identifier; * destination identity; * and scope. This can reduce dependence on sender-side path integrity. A.6.41. E06.41 Hardware-Rooted Hybrid Enforcement A secure hardware component may hold the final completion secret. It verifies: * Ri ; * ADi ; * HAi ; * current phase; Das Expires 4 April 2027 [Page 169] Internet-Draft Reality as a Cryptographic Dependency October 2026 * policy epoch; * sink identity; * and scope. Only then does hardware unseal or derive the next- phase execution material. A.6.42. E06.42 Distributed Hybrid PED Hybrid functions may be distributed across: * user device; * cloud policy engine; * HSM; * network gateway; * destination; * hardware controller; * and enterprise approval service. No one component must implement every function, provided the required causal dependency remains protected and non-bypassable. A.6.43. E06.43 Fail-Closed and Fail-Limited Hybrid Behavior If a required human or automatic decision is unavailable, the system may: * fail closed; * remain in bounded state; * reduce scope; * use local-only mode; * use reversible mode; * delay; * require another trial; * or terminate. The absence of one mandatory approval is not silently interpreted as approval. Das Expires 4 April 2027 [Page 170] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.6.44. E06.44 Alternate-Path Closure Where hybrid approval is mandatory, an alternate credential, admin API, device interface, network route, payment path, storage path, or other effect-equivalent route cannot lawfully satisfy the protected architecture merely by omitting one required authority. Equivalent paths may be disabled or subjected to equivalent hybrid enforcement. A.6.45. E06.45 Required Invariants Invariant 1 The hybrid architecture combines protected human authority and protected automatic authority according to a defined rule. Invariant 2 Where conjunction is required, neither human approval nor automatic approval alone enables the broader effect. Invariant 3 The hybrid decision is associated with verified evidence from the applicable prior real effect. Invariant 4 The final scope remains within the authorized maximum envelope and may be restricted by either authority. Invariant 5 Conflicts, stale decisions, revocation, and indeterminate states are represented explicitly rather than silently converted to approval. Invariant 6 Required artifacts or equivalent protected states may be single-use and replay-resistant. Invariant 7 The hybrid causal chain may be enforced through software, hardware, cryptographic key shares, destination-side verification, or distributed protected components. FROZEN RELATIONSHIP BETWEEN E04, E05 AND E06 Bounded Real Effect → Receipt → Human Approval → Continuation Bounded Real Effect → Receipt → P rotected Automatic Decision → Continuation Bounded Real Effect → Receipt → Human+Automatic P rotected Decision → Continuation The common principle is that the evidence produced by real bounded effectuation participates in the protected authority chain for broader effectuation, while the required approving authority may be human, automatic, or hybrid according to protected policy. Das Expires 4 April 2027 [Page 171] Internet-Draft Reality as a Cryptographic Dependency October 2026 APPENDIX E - NEW DEFINITIONS INTRODUCED BY E04- E06 ONLY E.1 Non- Repetition Rule This Appendix intentionally omits terminology already defined in Advanced Section 1 and in the E01-E03 delta glossary. Earlier definitions retain their previously stated meanings. The following definitions are included only because E04-E06 introduce or materially specialize these terms. E.2 Protected Human Review Object (PHRO) Protected Human Review Object (PHRO) means a protected representation prepared for an authenticated human decision after one or more relevant execution facts have been obtained. It may bind the Candidate Act, prior ECR, observed effect, destination, sink, proposed next scope, remaining consequence, risk state, policy epoch, revocation state, approval nonce, and other decision context. A PHRO may exist as protected UI state, a signed data object, a secure-device prompt, hardware-display state, or another protected representation and need not be portable. E.3 Human Approval Artifact Human Approval Artifact means machine- verifiable evidence that the required protected human authority approved, denied, restricted, or otherwise decided a defined continuation scope. It may be implemented as a digital signature, MAC-protected record, secure-element output, HSM-backed state, protected database transition, threshold share, hardware state, or equivalent protected evidence. It is not limited to a bearer token. E.4 Automatic Continuation Authority (ACA) Automatic Continuation Authority (ACA) means a protected component or distributed protected function that evaluates verified effect evidence and applicable protected predicates to decide whether and how a Candidate Act may progress without requiring a human decision for that phase. The ACA may be implemented by software, firmware, hardware, a TEE, HSM, policy engine, transaction engine, kernel component, network component, destination-side component, or equivalent protected mechanism. E.5 Automatic Decision Record (ADR) Automatic Decision Record (ADR) means a protected representation of an ACA decision and its relevant context. It may bind the Candidate Act, prior receipt, decision result, next scope, policy and revocation epochs, risk state, predicate outcomes, sink, destination, nonce, expiry, and ACA identity. An ADR may be explicit or may exist only as a protected internal state transition. Das Expires 4 April 2027 [Page 172] Internet-Draft Reality as a Cryptographic Dependency October 2026 E.6 Hybrid Continuation Authority Hybrid Continuation Authority means the technical authority enabling a later effectuation phase where that authority depends upon a protected combination of human and automatic decisions. The combination may be conjunctive, threshold- based, sequential, hierarchical, disjunctive where policy permits, or cryptographically split. E.7 Conjunctive Hybrid Approval Conjunctive Hybrid Approval means an approval rule requiring both a defined protected human condition and a defined protected automatic condition before continuation. E.8 Disjunctive Hybrid Approval Disjunctive Hybrid Approval means a protected rule under which one of multiple permitted approval paths may satisfy continuation, for example protected human approval or a specifically defined high-assurance automatic approval. Availability of the disjunctive rule is itself protected policy and is not implied for all act classes. E.9 Conflict State Conflict State means protected state indicating that required approval authorities produced inconsistent or incompatible outcomes, scopes, or conditions. Conflict does not itself mean approval. Protected policy determines whether the result is denial, hold, scope reduction, revalidation, additional evidence collection, or escalation. E.10 Mandatory Technical Pass Mandatory Technical Pass means a protected technical condition that cannot be overridden merely by human approval where policy designates the condition as non- overridable. Examples may include valid cryptographic binding, revocation clearance, correct sink, correct destination, hardware safety constraints, or maximum-envelope compliance. E.11 Hybrid Scope Intersection Hybrid Scope Intersection means the final scope formed from the common permitted region of multiple approval authorities, such that later effectuation does not exceed the scope allowed by either required authority. Set intersection, scalar minimum, policy-defined meet operations, or equivalent protected narrowing functions may implement this role. E.12 Automatic Decision Predicate Set Automatic Decision Predicate Set means the collection of protected predicates evaluated by an ACA for a defined act or phase. It may include receipt validity, risk, policy, revocation, sink, destination, envelope, taint, provenance, hardware, transaction, timing, or other protected conditions. Das Expires 4 April 2027 [Page 173] Internet-Draft Reality as a Cryptographic Dependency October 2026 E.13 Human Veto Window Human Veto Window means a bounded protected interval during which an authenticated human or supervisory authority may prevent an otherwise automatically eligible continuation. The veto mechanism may itself require protected authentication and act/ phase binding. APPENDIX F - NEW NOTATION INTRODUCED BY E04-E06 ONLY F.1 Non- Repetition Rule Notation already defined in the Advanced Section 1 notation appendix or the E01-E03 delta notation appendix is intentionally not repeated. Symbols below are included only where E04- E06 introduce a new symbol or a materially specialized local meaning. F.2 Human-Approval Notation * HumanRequiredi - protected Boolean or policy state indicating that human approval is required for the relevant phase i. * HAi - Human Approval Artifact associated with phase i or the transition to the next phase, according to local context. * KH - protected key or key share associated with the human-approval authority in an illustrative cryptographic embodiment. * NH - approval-specific nonce or freshness value used in the illustrative human approval construction. * ApprovedScopei / Scopeapproved - scope expressly permitted by the protected human decision for the relevant phase. * Tnow - current protected or policy-relevant time used in a freshness check. * Tapproval_expiry - expiry time associated with the human approval. * Epcurrent - currently applicable policy epoch. * Epreceipt - policy epoch associated with the relevant receipt. * HumanDecision - protected human decision state such as APPROVE, DENY, RESTRICT, HOLD, or another permitted outcome. * P0′ - a newly authorized or revised bounded trial phase distinguished from an earlier P0 . F.3 Automatic-Decision Notation Das Expires 4 April 2027 [Page 174] Internet-Draft Reality as a Cryptographic Dependency October 2026 * ACA - Automatic Continuation Authority, the protected automatic decision function/component defined in Appendix E. * Γi - Automatic Decision Predicate Set applicable to phase i. * gi,k - the kth protected automatic-decision predicate applicable to phase i. * AutoP assi - protected Boolean result indicating that all automatic conditions required by the applicable rule for phase i have passed. * ADi - Automatic Decision Record associated with phase i or next- phase transition. * KACA - protected cryptographic key associated with the ACA in an illustrative ADR construction. * NA,i - automatic-decision nonce associated with phase i. * Decisioni - protected decision result produced by the ACA for phase i. * Historyi - protected representation of relevant prior phase outcomes used by an adaptive automatic decision. * Erri - measured or protected error rate for phase i in the rollout example. * F ailedT argetsi - number or protected measure of failed targets in phase i. * AttemptedT argetsi - number or protected measure of targets attempted in phase i. * τerr - protected maximum error-rate threshold in the illustrated automatic rollout rule. F.4 Hybrid-Approval Notation * HumanP assi - protected Boolean indicating that the required human condition applicable to phase i has passed. * HybridP assi - protected Boolean indicating that the applicable hybrid approval rule has been satisfied. Das Expires 4 April 2027 [Page 175] Internet-Draft Reality as a Cryptographic Dependency October 2026 * HighAssuranceAutoP assi - automatic approval result meeting a policy-defined higher assurance level that may satisfy a permitted disjunctive rule. * DecisionReadyi - protected state indicating that all decision artifacts required before hybrid evaluation have been received. * Vi - set or vector of protected approval votes/decisions considered by the threshold rule for phase i. * vj - protected vote or decision contribution from authority j in the threshold example. * wj - protected weight assigned to authority j in the threshold example. * Θi - protected aggregate approval threshold for phase i in the weighted-threshold example. This symbol is local and distinct from actuator-angle notation used elsewhere. * M andatoryT echnicalP assi - protected Boolean indicating that all non-overridable technical predicates applicable to phase i have passed. * Scopeauto - scope permitted by the protected automatic authority. * Scopehuman - scope permitted by the protected human authority. * Scopefinal - final scope permitted after applying the protected hybrid-combination rule. * KA - protected automatic-authority key share or secret in the illustrative two-key hybrid construction. * CON F LICT - protected state indicating incompatible human and automatic decisions requiring a policy-defined resolution path. * V etoi - protected human veto state applicable to phase i. * EpHA - policy epoch bound to a Human Approval Artifact. Das Expires 4 April 2027 [Page 176] Internet-Draft Reality as a Cryptographic Dependency October 2026 F.5 Word-Like Predicate Convention for E04-E06 The following word- like mathematical expressions denote protected predicates, decision states, status values, or functions rather than required programming- language identifiers: ReceiptAccept, MatchDestination, MatchApproval, HumanRequired, HumanPass, AutoPass, HybridPass, HighAssuranceAutoPass, MandatoryTechnicalPass, DecisionReady, HumanReviewRequired, Received, Revalidate, Fresh, Valid, WithinEnvelope, RevocationClear, PolicyCurrent, CONFLICT, REQUIRE_HUMAN, REQUIRE_QUORUM, RECONCILE, and related labels. F.6 Local Interpretation Rule Where a symbol appearing in E04-E06 was previously defined, the previous meaning remains controlling unless the local subsection expressly states a narrower specialized use. New notation is illustrative and may be replaced by equivalent protected representations without changing the disclosed functional dependency. A.7. E07 — Software Protected Enforcement Domain A.7.1. E07.1 Purpose E07 defines a Protected Enforcement Domain implemented primarily through software-enforced isolation, privilege separation, protected operating-system state, protected services, trusted software components, or combinations thereof. The central relationship is: Candidate Act → Software P ED Intake → P rotected Software V alidation → Scoped Effectuation Authority → Software Effectuation Gate → External Effect → P rotected Receipt/State The proposing agent or ordinary application may execute in a less- trusted software domain while the authority to cause the external effect remains in a separate software protection domain. A.7.2. E07.2 Software PED Functional Boundary The Software PED may be implemented as one or more of: * a privileged daemon; * an operating-system security service; * a kernel module; * a kernel security hook; * an eBPF-based enforcement program; Das Expires 4 April 2027 [Page 177] Internet-Draft Reality as a Cryptographic Dependency October 2026 * a Linux Security Module or analogous mandatory-access-control layer; * a syscall mediation layer; * a seccomp-like filter combined with a privileged broker; * a namespace or cgroup controller; * a container-runtime security hook; * a microVM monitor; * a hypervisor-resident software service; * a service-mesh proxy; * a network forward proxy; * a reverse proxy; * an API gateway; * a database proxy; * a storage gateway; * a transaction manager; * a message broker; * a credential broker; * a signing service; * a key-management service; * a policy decision point; * a policy enforcement point; * a confidential-computing service; * a remote protected service; Das Expires 4 April 2027 [Page 178] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or a composition of such components. No particular software name is required. The relevant property is that the protected software path retains authority or missing execution material that the proposing domain cannot freely bypass. A.7.3. E07.3 Candidate Act Intake The Candidate Act enters the Software PED through a defined protected interface. The interface may receive: * the Candidate Act itself; * a canonical representation; * a Candidate Act digest; * a Trial Effect Descriptor; * a requested phase identifier; * a prior receipt; * an approval artifact; * a credential request; * a destination descriptor; * a device or process identity; * or another bound representation sufficient to evaluate the requested effect. The interface may be an IPC endpoint, system call, local socket, protected message queue, sharedmemory channel, remote authenticated API, hypercall, device-control request, or equivalent interface. A.7.4. E07.4 Caller Attribution The Software PED may determine which software principal requested the act. Attribution may include: * process identifier; * executable measurement; * user identifier; * service identity; Das Expires 4 April 2027 [Page 179] Internet-Draft Reality as a Cryptographic Dependency October 2026 * container identity; * namespace identity; * cgroup identity; * VM identity; * application identity; * signed workload identity; * agent session identity; * or a cryptographically authenticated principal. The PED may reject a request where the caller identity does not match the authority context bound to the Candidate Act. A.7.5. E07.5 Protected Software State The Software PED may maintain protected state denoted locally by: ZSW where ZSW may include: * policy state; * revocation state; * nonce state; * consumed-authority state; * receipt state; * phase state; * rate-limit state; * spending-limit state; * destination state; * taint/provenance state; * approval state; * transaction state; Das Expires 4 April 2027 [Page 180] Internet-Draft Reality as a Cryptographic Dependency October 2026 * protected counters; * and other enforcement-relevant state. The proposing agent should not be able to arbitrarily rewrite ZSW . A.7.6. E07.6 Software Validation Predicate A representative software validation result may be expressed as: SW P assi = ActM atchi ∧ CallerV alidi ∧ P olicyV alidi ∧ RevocationCleari ∧ F reshi ∧ W ithinEnvelopei ∧ ApprovalSatisfiedi ∧ SinkP ermittedi where each term represents a protected predicate applicable to phase i. The particular predicate set is implementation-dependent. A.7.7. E07.7 Automatic Approval Integration Where E05 automatic continuation applies, the Software PED may perform or invoke the automatic decision function internally. A successful automatic decision may transition protected software state from: P EN DIN Gi to: AU T HORIZEDi without exposing a reusable unrestricted credential to the agent. A.7.8. E07.8 Human Approval Integration Where E04 human continuation applies, the Software PED may: 1. validate the prior ECR; 2. form the protected human review object; 3. transmit it to a protected approval surface; 4. receive the Human Approval Artifact; 5. verify its act, receipt, scope, nonce, and expiry binding; and 6. advance the protected phase state only after successful verification. The ordinary conversational output of the AI agent need not constitute the protected approval channel. A.7.9. E07.9 Hybrid Approval Integration Where E06 applies, the Software PED may combine automatic and human decision artifacts using the protected combination rule selected by policy. The Software PED may implement: * conjunction; * threshold approval; * automatic low-risk continuation with human escalation; Das Expires 4 April 2027 [Page 181] Internet-Draft Reality as a Cryptographic Dependency October 2026 * human veto; * scope intersection; * split authorization; * or another protected rule. A.7.10. E07.10 Scoped Software Capability After validation, the Software PED may create a software-enforced capability Ci . The capability may be: * non-bearer; * single-use; * process-bound; * destination-bound; * phase-bound; * time-bound; * transaction-bound; * resource-bound; * or otherwise constrained. A representative construction may be: Ci = P rotectKSW (Di ∥ P rincipali ∥ Sinki ∥ Scopei ∥ Expiryi ) where KSW is protected from ordinary untrusted application access. A.7.11. E07.11 Capability Without Exposed Token A separate serialized token is not required. The PED may instead maintain an internal protected state transition such as: AuthorizeState(Di , P rincipali , Sinki ) = T RU E and the effectuation gate may consult that protected state directly. This embodiment avoids requiring an externally transferable authority object. Das Expires 4 April 2027 [Page 182] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.7.12. E07.12 Credential Brokerage The agent may possess only a surrogate, restricted, or non- authoritative credential. The Software PED may retain the real effect-capable credential. Flow: Agent request -> Software PED -> protected validation -> real credential use at boundary -> external effect The real credential may never be returned to the agent. A.7.13. E07.13 Late Credential Injection In one variation, a request is constructed without the real credential. After protected validation, the Software PED injects or applies the real credential only at or near the external boundary. This may include: * Authorization header insertion; * request signing; * TLS client authentication; * API-key insertion; * payment credential use; * database credential use; * signing-key use; * or another protected authority application. A.7.14. E07.14 Network Egress Gate A Software PED may mediate network egress. The agent’s environment may be unable to reach external destinations except through the protected gate. The gate may evaluate: * destination; * protocol; * port; * application identity; * process identity; * payload class; Das Expires 4 April 2027 [Page 183] Internet-Draft Reality as a Cryptographic Dependency October 2026 * Candidate Act digest; * phase authority; * receipt state; * human/automatic approval state; * and policy. Only matching traffic is permitted to exit. A.7.15. E07.15 Kernel-Level Software Gate The effectuation boundary may be implemented at the kernel or syscall layer. Examples include mediation of: * connect; * send/sendmsg; * file writes; * exec/spawn; * ioctl; * IPC; * device access; * mount operations; * namespace operations; * or other effect-capable primitives. The kernel-side gate may consult protected PED state before permitting the operation. A.7.16. E07.16 eBPF / Security-Hook Variation An eBPF program, security hook, or equivalent kernel extension may: * attribute the request to a process or cgroup; * observe or gate network operations; * observe file/device operations; Das Expires 4 April 2027 [Page 184] Internet-Draft Reality as a Cryptographic Dependency October 2026 * consult protected maps or policy state; * enforce phase state; * deny unmatched operations; * or generate evidence for later protected processing. Naming eBPF is illustrative and does not require any particular kernel program type or hook arrangement. A.7.17. E07.17 LSM / Mandatory-Access-Control Variation An LSM-like or mandatory-access-control layer may deny effect-capable objects unless the applicable process, resource, and phase state satisfy protected rules. The effect may therefore be blocked by access-control semantics even if the agent constructs the low-level operation itself. A.7.18. E07.18 Proxy-Based Effectuation Gate A protected proxy may be the first component possessing unrestricted external reach or the real credential. The proxy may verify: * exact request binding; * destination; * method; * payload digest; * approval state; * phase state; * receipt state; * nonce; * expiry; * and scope. The proxy may then cause the external effect on behalf of the less-trusted agent. Das Expires 4 April 2027 [Page 185] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.7.19. E07.19 Database Gate A database proxy, stored procedure, transaction service, or protected commit component may deny direct production commits unless the protected state indicates authorization. A staged workflow may allow a shadow or provisional write first and promote it only after ECR validation. A.7.20. E07.20 Storage Gate A storage gateway or protected filesystem service may restrict: * object creation; * object publication; * namespace promotion; * deletion; * overwrite; * external sharing; * or key release. The storage object may remain inaccessible or non-public until the applicable phase becomes authorized. A.7.21. E07.21 Message-Broker Gate A message queue or broker may refuse publication to effect-capable topics unless the publisher presents or is associated with valid protected phase authority. The broker may generate a durable receipt identifying: * topic; * partition; * offset; * message digest; * publisher identity; * and committed status. Das Expires 4 April 2027 [Page 186] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.7.22. E07.22 Transaction Manager Variation A transaction manager may hold a transaction in a non-final or provisional state until protected predicates are satisfied. The transaction manager itself may be the Software PED, the Finality Sink, or both. A.7.23. E07.23 Remote Software PED The Software PED need not execute on the same machine as the agent. A remote protected service may receive a bound Candidate Act and return only a scoped continuation decision or execute the effect itself. Remote implementations may be useful where: * endpoint software cannot be trusted; * enterprise policy is centralized; * secrets are held in a remote vault; * or multiple devices share a policy authority. A.7.24. E07.24 Software Attestation Input A Software PED may consume platform attestation, workload identity, signed measurements, or confidential-computing evidence as inputs. However, E07 does not require the PED itself to be hardware-rooted. A.7.25. E07.25 Receipt Generation in Software The Software PED or downstream software sink may generate an ECR after effectuation. The receipt may be protected using: * a software-held signing key; * HSM-backed key accessed by software; * MAC; * authenticated transaction log; * append-only log; * signed service response; * or another integrity mechanism. Das Expires 4 April 2027 [Page 187] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.7.26. E07.26 Durable Software State Protected software state may be persisted using: * append-only journal; * write-ahead log; * replicated database; * secure local database; * transactional key-value store; * remote protected state service; * or equivalent durable storage. Crash recovery should not silently erase consumed receipt or phase state. A.7.27. E07.27 Crash Recovery If the Software PED crashes after effectuation but before recording completion, the system may enter an indeterminate state and reconcile using the mechanisms of E02/E03. The PED may compare: * idempotency identifier; * transaction identifier; * sink log; * broker offset; * database commit identifier; * or destination receipt. A.7.28. E07.28 Software Rollback Resistance Where software state may be restored from an old snapshot, the architecture may require protected epoch or external monotonic evidence so that an old permissive state cannot automatically revive consumed authority. Possible mechanisms include: * remote monotonic service; * append-only external ledger; Das Expires 4 April 2027 [Page 188] Internet-Draft Reality as a Cryptographic Dependency October 2026 * hardware monotonic counter used as an input; * replicated consensus state; * or protected revocation epoch. A.7.29. E07.29 Alternate-Path Closure The Software PED embodiment should account for effect-capable paths that avoid the designated broker. Examples include: * direct network namespace access; * raw socket access; * alternate API clients; * local privileged credentials; * direct database connections; * device files; * alternate message brokers; * debug endpoints; * administrator endpoints; * recovery interfaces; * and local secret files. Such paths may be disabled, isolated, credential-starved, redirected through the PED, or independently subjected to equivalent finality control. A.7.30. E07.30 Software PED Fail-Closed Mode Where required protected state is unavailable or corrupted: SW P assi = F ALSE ⇒ Effectuationi = BLOCKED unless policy expressly permits a fail-limited reduced effect. A.7.31. E07.31 Software PED Fail-Limited Mode A software system may permit only a reduced consequence where full verification is unavailable. Examples: * local-only write; Das Expires 4 April 2027 [Page 189] Internet-Draft Reality as a Cryptographic Dependency October 2026 * read-only operation; * sandbox-only execution; * reduced recipient set; * reduced payment limit; * no external network release; * or a human-review hold. A.7.32. E07.32 SEND Example An AI agent prepares a message and attachment. The agent runtime has no unrestricted egress credential. The Software PED: 1. receives the bound SEND Candidate Act; 2. validates recipient, attachment digest, phase, policy, and approval state; 3. uses the protected outbound credential; 4. sends the bounded or full authorized payload through the protected proxy; 5. receives a destination acknowledgement; 6. generates or validates the ECR; and 7. advances protected state as required. A.7.33. E07.33 Payment Example The AI agent proposes a payment but lacks the bank/payment signing secret. The Software PED validates: * beneficiary; * amount; * currency; * transaction nonce; * spending limit; * human/automatic approval state; * and phase state. The PED invokes the payment API using protected credentials only after approval. Das Expires 4 April 2027 [Page 190] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.7.34. E07.34 Required Invariants The frozen conceptual invariants of E07 are: 1. the proposing software domain need not possess unrestricted effectuation authority; 2. protected software state participates in the final authority decision; 3. an effect-capable software gate verifies or is technically dependent upon the protected decision; 4. required receipt, phase, approval, or revocation state cannot be satisfied merely by agent assertion; 5. alternate effect-capable software paths are controlled where needed to preserve nonbypassability; and 6. failure of mandatory protected software validation prevents unauthorized broader effectuation. 3 E08 - HARDWARE PROTECTED ENFORCEMENT DOMAIN A.8. E08 — Hardware Protected Enforcement Domain A.8.1. E08.1 Purpose E08 defines an embodiment in which one or more critical authority, state, key, verification, observation, or effectuation functions are enforced by hardware or hardware-rooted components. The central relationship is: Candidate Act → P rotected Hardware Intake → Hardware State/Identity V erification → Hardware Scoped Authority → Hardware Effectuation Gate → Real Effect → Hardware or HardwareBound Receipt The critical property is not a particular chip type. It is that ordinary software cannot freely synthesize, modify, or bypass the protected hardware state or secret required for the consequential effect. A.8.2. E08.2 Hardware PED Components A Hardware PED may comprise one or more of: * TPM; * secure element; * secure enclave; * Trusted Execution Environment; * HSM; * security coprocessor; Das Expires 4 April 2027 [Page 191] Internet-Draft Reality as a Cryptographic Dependency October 2026 * isolated MCU; * secure monitor; * DPU; * SmartNIC; * NIC security controller; * storage controller; * SSD controller; * memory controller; * GPU security processor; * GPU command processor; * FPGA; * ASIC; * SoC security island; * baseband security processor; * modem security processor; * automotive ECU; * industrial PLC; * motor controller; * actuator controller; * flight controller; * robotic safety controller; * cryptographic accelerator; * PUF-backed identity logic; * or equivalent protected hardware. Das Expires 4 April 2027 [Page 192] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.8.3. E08.3 Hardware Root of Authority The Hardware PED may retain a root secret or protected state unavailable to ordinary software. Let: KHW represent a hardware-protected root secret, key, or equivalent authority root. The root may be used directly or indirectly to derive phase-specific authority. A.8.4. E08.4 Hardware Protected State Let: ZHW represent hardware-protected state. It may include: * phase counter; * consumed-receipt state; * policy epoch; * revocation epoch; * monotonic counter; * device identity; * key version; * measured-boot state; * sink identity; * approval digest; * receipt digest; * safe operating envelope; * or another authority-relevant value. A.8.5. E08.5 Hardware Identity The Hardware PED may possess a device-bound or component-bound identity established by: * fused key; Das Expires 4 April 2027 [Page 193] Internet-Draft Reality as a Cryptographic Dependency October 2026 * PUF-derived key; * manufacturer certificate; * device certificate; * secure element key; * attestation key; * provisioned HSM key; * or equivalent hardware-rooted identity. The identity may bind a receipt or capability to the specific hardware component. A.8.6. E08.6 Platform Measurement A hardware component may verify a measurement: Mplat against an expected or policy-permitted measurement set: Mplat ∈ Mallowed before releasing phase authority. Measurements may represent firmware, boot state, software image, configuration, secure monitor state, or another protected platform property. A.8.7. E08.7 Hardware Attestation The Hardware PED may generate or verify attestation evidence denoted: AttHW The attestation may bind: * device identity; * software/firmware measurement; * boot state; * nonce; * policy epoch; * phase state; * key version; Das Expires 4 April 2027 [Page 194] Internet-Draft Reality as a Cryptographic Dependency October 2026 * and sink identity. A.8.8. E08.8 Hardware Validation Predicate A representative hardware authorization condition may be: HW P assi = AttestationV alidi ∧ M easurementAllowedi ∧ P olicyV alidi ∧ RevocationCleari ∧ P haseStateV alidi ∧ ReceiptStateV alidi ∧ W ithinEnvelopei Additional human or automatic approval predicates may be included where required. A.8.9. E08.9 Hardware Phase Key A phase-specific key may be derived as: Kiphase = KDF (KHW , DA , i, Ni , Ep , Er ) or by another protected derivation. The key may authenticate only the permitted phase. A.8.10. E08.10 Receipt-Derived Hardware Key For receipt-gated progression: phase Ki+1 = KDF (KHW , DA , H(Ri ), i + 1) The next-phase key therefore depends on accepted evidence from the previous real phase. A.8.11. E08.11 Hardware Unsealing Variation Instead of derivation, next-phase authority may be sealed in hardware. The hardware unseals the authority only where: * receipt digest matches; * phase index matches; * measurement is allowed; * policy epoch is current; * revocation is clear; * and required approval evidence is present. Das Expires 4 April 2027 [Page 195] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.8.12. E08.12 Protected Hardware Latch A protected latch may represent whether the next phase is enabled. Let: LHW i+1 ∈ {0, 1} with initial state: LHW i+1 = 0 and transition: V alid(Ri ) ∧ HW P assi ⇒ LHW i+1 ← 1 The next effect remains electrically, logically, cryptographically, or microarchitecturally unavailable while the latch remains zero. A.8.13. E08.13 Monotonic Counter A hardware monotonic counter may track phase or authority consumption. If current counter is ctri , the hardware may require: ctrrequest = ctri + 1 before accepting the next protected transition. This can resist rollback to an older permissive state. A.8.14. E08.14 Secure-Element Embodiment A secure element may: * store the root key; * verify Candidate Act digests; * verify receipt digests; * verify human approval signatures; * maintain a phase counter; * derive phase keys; * and sign completion receipts. Ordinary application software may receive only the narrow result needed for the current phase. Das Expires 4 April 2027 [Page 196] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.8.15. E08.15 HSM Embodiment An HSM may refuse to perform a signing, decryption, key-wrap, transaction-signing, or key-release operation unless the bound phase state and receipt evidence satisfy protected policy. The HSM may therefore be the authority gate even where network execution occurs elsewhere. A.8.16. E08.16 TEE / Secure-Enclave Embodiment A TEE or secure enclave may hold: * policy state; * receipt state; * Candidate Act digest; * phase keys; * approval state; * and protected counters. The enclave may expose a narrow command interface to ordinary software. A.8.17. E08.17 DPU / SmartNIC Network Embodiment A DPU or SmartNIC may enforce network release independently of the host agent runtime. The host may construct packets or requests, but the DPU/SmartNIC releases them externally only if protected phase authority validates. The hardware may bind: * destination; * flow; * tenant; * VM; * process/workload identity; * payload digest or descriptor; * phase; * and receipt state. Das Expires 4 April 2027 [Page 197] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.8.18. E08.18 Storage-Controller Embodiment A storage controller may hold a write, publish, erase, or key-release command until the protected authority state is satisfied. The controller may generate a signed or MACed persistence receipt after successful effectuation. A.8.19. E08.19 GPU / Accelerator Embodiment A GPU security processor or command controller may restrict: * DMA transfer; * model-output egress; * memory export; * command submission; * device-to-network transfer; * or protected model-state release. The next transfer phase may require a receipt from the DPU, host protected service, destination, or another protected observer. A.8.20. E08.20 Motor / Actuator Controller Embodiment A motor controller may receive a requested full trajectory but execute only the authorized phase. Protected sensor feedback may be evaluated locally. For expected movement Xi and observed movement Oi : |Oi − Xi | ≤ εi may be required before enabling the next movement phase. A.8.21. E08.21 Vehicle / Flight Controller Embodiment A vehicle or flight controller may maintain a protected movement envelope and permit only the current segment. Receipt evidence may include: * position; * velocity; * orientation; Das Expires 4 April 2027 [Page 198] Internet-Draft Reality as a Cryptographic Dependency October 2026 * altitude; * sensor state; * geofence state; * or actuator response. A failed protected measurement may cause hold or safe-state transition. A.8.22. E08.22 Radio / Baseband Embodiment A baseband or radio controller may restrict transmission by: * power; * frequency; * duration; * beam; * destination; * geographic region; * recipient set; * or message class. Protected receiver evidence or local telemetry may unlock broader transmission authority. A.8.23. E08.23 Hardware Human-Approval Verification A hardware component may verify a Human Approval Artifact directly. The hardware may require the approval to bind: * Candidate Act digest; * receipt digest; * phase; * scope; * nonce; * expiry; Das Expires 4 April 2027 [Page 199] Internet-Draft Reality as a Cryptographic Dependency October 2026 * and approving authority. This prevents compromised host software from merely asserting that the human approved. A.8.24. E08.24 Hardware Automatic-Decision Verification A hardware component need not run the entire automatic policy engine. Instead, it may verify a protected Automatic Decision Record produced by an authorized decision service, provided the record is bound to the act and current protected state. Alternatively, a simplified deterministic policy may execute directly in hardware. A.8.25. E08.25 Hardware Receipt Generation A hardware sink may generate an ECR using: * device signing key; * MAC key; * attestation key; * hardware counter; * secure timestamp; * sensor measurement; * or another protected evidence source. The receipt may be stronger than ordinary software acknowledgement where the relevant effect is physically or microarchitecturally observable only inside the device. A.8.26. E08.26 Hardware Receipt Verification The Hardware PED may verify a remote or local ECR before updating protected phase state. The verification may be performed entirely inside hardware or through a hardware-rooted trusted software component. A.8.27. E08.27 Hardware Anti-Replay A receipt or phase authority may be bound to: * nonce; * phase counter; * device identity; Das Expires 4 April 2027 [Page 200] Internet-Draft Reality as a Cryptographic Dependency October 2026 * Candidate Act digest; * transaction identifier; * monotonic counter; * and expiry. Consumed state may be retained in protected NVRAM or equivalent protected memory. A.8.28. E08.28 Hardware Crash / Power-Loss Recovery Protected hardware state may survive power loss using: * secure NVRAM; * monotonic counter; * sealed storage; * TPM NV index; * secure flash; * HSM persistent object; * or replicated protected state. Where state cannot be resolved after recovery, the hardware may remain fail-closed until reconciliation. A.8.29. E08.29 Hardware Rollback Protection The Hardware PED may compare a stored anti-rollback value with firmware or state version. An older snapshot or firmware image must not silently restore previously consumed authority. A.8.30. E08.30 Hardware Alternate-Path Closure Where the hardware controller is intended to be non-bypassable, direct lower-level paths may be unavailable without the protected controller. Examples include: * actuator power stage requiring authenticated command; * NIC transmit queue requiring protected descriptor authorization; * storage encryption key retained in controller; * HSM signing key never exported; Das Expires 4 April 2027 [Page 201] Internet-Draft Reality as a Cryptographic Dependency October 2026 * device register access restricted to secure world; * or hardware routing that forces traffic through the protected gate. A.8.31. E08.31 Fail-Closed Hardware Mode If hardware attestation, state, key, receipt, or policy verification fails: HW P assi = F ALSE ⇒ Effectuationi = BLOCKED unless a separately authorized safe or reduced mode exists. A.8.32. E08.32 Fail-Safe Physical Mode For cyber-physical systems, failure may cause transition to: * stop; * brake; * neutral; * hold position; * reduce power; * safe altitude; * safe route; * local-only operation; * or another protected safe state. A.8.33. E08.33 SEND Example A secure element or HSM retains the message-signing/decryption- release key. The host AI agent prepares the message but cannot make it valid for external delivery without hardware authorization. The hardware verifies act/phase state and produces the current-phase signing or release material only after the required protected predicates pass. Das Expires 4 April 2027 [Page 202] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.8.34. E08.34 Payment Example A payment-signing key remains inside an HSM or secure element. The AI agent can construct the payment instruction but cannot authorize settlement. The hardware signs only the exact authorized payment or current payment phase after checking bound policy and approval evidence. A.8.35. E08.35 Required Invariants The frozen conceptual invariants of E08 are: 1. at least one authority-critical state, key, verification, observation, or effectuation function is hardware-protected; 2. ordinary software cannot freely synthesize the protected hardware authority; 3. hardware may bind authority to exact act, phase, destination, device, receipt, approval, or policy state; 4. required later phases may remain unavailable until protected hardware accepts prior evidence; 5. replay and rollback can be constrained using protected hardware state; and 6. unauthorized alternate paths are controlled where necessary to preserve the intended hardwarerooted dependency. 4 E09 - SPLIT SOFTWARE/HARDWARE PROTECTED EN- FORCEMENT DOMAIN A.9. E09 — Split Software/Hardware Protected Enforcement Domain A.9.1. E09.1 Purpose E09 defines a split architecture in which software performs one or more higher-level validation or orchestration functions while hardware retains one or more authority-critical secrets, state transitions, enforcement decisions, or effectuation controls. The central relationship is: Candidate Act → Software V alidation/P lanning → Bound Authorization Digest → Hardware V erification → HardwareRooted P hase Authority → Real Effect → Receipt → Software/Hardware Revalidation → N ext P hase The split arrangement can preserve rich software policy while preventing compromised application software from independently producing full effectuation authority. A.9.2. E09.2 Functional Separation A representative split may assign: 4.2.1 Software side * Candidate Act parsing; Das Expires 4 April 2027 [Page 203] Internet-Draft Reality as a Cryptographic Dependency October 2026 * canonicalization; * policy evaluation; * risk evaluation; * taint/provenance analysis; * human-review preparation; * automatic decision logic; * phase planning; * receipt parsing; * complex business rules; * and audit preparation. 4.2.2 Hardware side * root-key custody; * phase-key derivation; * protected counters; * approval-digest verification; * receipt-digest verification; * anti-replay state; * final capability generation; * command authentication; * credential release; * or direct effectuation gating. Functions may be redistributed without departing from the split concept. A.9.3. E09.3 Software Decision Record The software PED may produce a bound authorization record or digest. Let: Das Expires 4 April 2027 [Page 204] Internet-Draft Reality as a Cryptographic Dependency October 2026 ADRi denote an Authorization Decision Record for phase i. It may bind: * Candidate Act digest; * phase; * permitted scope; * policy epoch; * revocation epoch; * destination; * sink; * receipt digest; * human approval digest; * automatic decision digest; * risk state; * and expiry. A.9.4. E09.4 Authorization Digest A compact digest may be formed: AuthDigesti = H(Canon(ADRi )) or by an equivalent deterministic protected representation. The hardware may verify the signature or MAC over ADRi or receive the record through an authenticated channel. A.9.5. E09.5 Hardware Does Not Blindly Trust Software The hardware may independently verify a mandatory subset of conditions rather than accepting every software assertion. For example: SplitP assi = SoftwareDecisionV alidi ∧ ActDigestM atchi ∧ P haseM atchi ∧ CounterV alidi ∧ ReceiptDigestM atchi ∧ RevocationEpochV alidi ∧ HardwareEnvelopeV alidi The hardware may reject the request even where software reports ALLOW. Das Expires 4 April 2027 [Page 205] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.9.6. E09.6 Software Scope and Hardware Scope Software may compute a permitted scope: ScopeSW ,i while hardware maintains an independent maximum: ScopeHW ,i The effective scope may be: Scopeeff,i = ScopeSW ,i ∩ ScopeHW ,i or another protected narrowing operation. Thus software cannot expand effectuation beyond the hardware envelope. A.9.7. E09.7 Hardware Root Secret The hardware retains KHW or another non-exportable root of authority. Software may never receive the root secret. The hardware may derive: Kiphase = KDF (KHW , AuthDigesti , Ni ) only after verifying the bound decision record. A.9.8. E09.8 Receipt-Gated Split Progression Following Phase i, receipt Ri is validated by software and/or hardware. A next-phase key may be: phase Ki+1 = KDF (KHW , AuthDigesti+1 , H(Ri ), i + 1) The later effect therefore depends on both software policy output and hardware acceptance of prior effect evidence. A.9.9. E09.9 Software-First Receipt Verification In one variation: 1. software receives Ri ; 2. software performs complex verification; 3. software forms a receipt-validation record; 4. hardware verifies the receipt digest, signature of the trusted software verifier, phase, and antireplay state; and 5. hardware unlocks the next phase. This reduces hardware complexity while retaining a hardware-rooted final transition. A.9.10. E09.10 Hardware-First Receipt Verification In another variation, hardware verifies the ECR directly. Software may receive only a hardware result such as: Das Expires 4 April 2027 [Page 206] Internet-Draft Reality as a Cryptographic Dependency October 2026 ReceiptAcceptedi = T RU E and may then proceed with higher-level workflow state. A.9.11. E09.11 Dual Verification A high-assurance embodiment requires both software and hardware verification: ReceiptAccepti = ReceiptAcceptSW i ∧ ReceiptAcceptHW i A disagreement enters a protected conflict or hold state. A.9.12. E09.12 Human Approval Split The software side may prepare and present the human review object. The resulting Human Approval Artifact may then be verified by hardware before full authority is released. Thus compromised software cannot merely fabricate the approval result if hardware independently checks the approval signature/digest and its binding. A.9.13. E09.13 Automatic Approval Split The software may execute the complex automatic policy engine. Hardware may verify a signed Automatic Decision Record and independently enforce: * act digest; * phase; * scope ceiling; * freshness; * revocation epoch; * counter; * and receipt dependency. A.9.14. E09.14 Hybrid Approval Split Human and automatic approval artifacts may be combined in software, hardware, or both. One strong form requires hardware to verify both independently before deriving the phase key. For example: HybridHW P assi = V alid(HAi ) ∧ V alid(ADi ) ∧ M atchActi ∧ M atchReceipti Das Expires 4 April 2027 [Page 207] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.9.15. E09.15 Split Key Shares The authority may require both software-held and hardware-held shares. Let: ShareSW ,i and: ShareHW ,i represent required shares. The final phase authority may be reconstructed only where both are available: Kiphase = Combine(ShareSW ,i , ShareHW ,i ) This is illustrative; threshold or multi-party constructions may be used. A.9.16. E09.16 Software Cannot Use Hardware Share for Another Act The hardware share may be bound to: * Candidate Act digest; * phase; * sink; * destination; * expiry; * nonce; * and receipt chain. Therefore a valid hardware response for one act does not authorize an unrelated act. A.9.17. E09.17 Hardware Cannot Independently Expand Software Policy Conversely, hardware may possess the root authority but lack permission to exceed the softwareapproved envelope. The split therefore may enforce mutual restriction rather than simply hardware dominance. Das Expires 4 April 2027 [Page 208] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.9.18. E09.18 Split Transaction Atomicity The software and hardware protected-state updates may be coordinated so that authority is not duplicated if one side crashes. A protected transaction may conceptually perform: V erify → Consume → AdvanceSW → AdvanceHW → Release with recovery rules for partially completed transitions. A.9.19. E09.19 Two-Record Commit Variation Software may persist a pending phase-transition record before requesting hardware release. Hardware then records its own monotonic transition. Software marks the transaction complete only after hardware acknowledgement. If a crash occurs between steps, reconciliation uses both records rather than blindly repeating the effect. A.9.20. E09.20 Hardware Receipt of Software State A hardware component may require a digest of protected software state: DSW state,i = H(Canon(ZSW ,i )) or a narrower software-state commitment. This can bind the phase key to the software decision context without exposing all software state to hardware. A.9.21. E09.21 Software Receipt of Hardware State The hardware may return an attested state record identifying: * hardware phase counter; * key version; * receipt digest; * consumed state; * measurement; * and hardware identity. Software can reject progression if the hardware state does not match the expected workflow. Das Expires 4 April 2027 [Page 209] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.9.22. E09.22 Local Split Embodiment Software and hardware may exist in one physical device. Example: Agent process -> privileged software PED -> secure enclave/HSM -> NIC or actuator The protected channel between software and hardware may use authenticated IPC, secure monitor calls, device commands, or another trusted interface. A.9.23. E09.23 Remote Hardware Split Embodiment Software may run locally while hardware authority resides remotely, such as a network HSM or cloud confidential-computing service. The remote hardware may release only scoped cryptographic results and never export the root key. A.9.24. E09.24 DPU Split Embodiment Host software may evaluate policy while a DPU or SmartNIC enforces the final network release. Flow: 1. host software forms authorization digest; 2. DPU verifies digest and protected workload identity; 3. DPU checks phase/receipt state; 4. DPU releases only matching flow or packet class; 5. DPU generates protected transmission evidence. A.9.25. E09.25 Storage Split Embodiment Software may decide that a file/object is eligible for publication. A storage controller retains the encryption key or publication capability. The controller releases or promotes the object only when the software decision record and protected receipt state match. A.9.26. E09.26 Payment Split Embodiment Software performs beneficiary, amount, policy, and human-review logic. An HSM retains the payment signing key. The HSM signs only the exact transaction digest and phase permitted by the software decision plus independent hardware checks. For staged payment, the HSM may require H(Ri ) before signing the next settlement phase. A.9.27. E09.27 SEND Split Embodiment The software PED verifies recipient, content digest, approval, and taint/provenance state. A secure hardware component retains the signing/decryption-release or network release authority. The full SEND operation becomes possible only after software and hardware conditions align. Das Expires 4 April 2027 [Page 210] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.9.28. E09.28 Robotics Split Embodiment High-level software determines path/intent while the hardware safety controller enforces local motion envelope. Software may request a movement segment, but the hardware controller refuses any segment exceeding: * safe acceleration; * actuator limit; * geofence; * phase limit; * sensor-confirmed state; * or authorization envelope. A.9.29. E09.29 Cloud/Accelerator Split Embodiment Host software evaluates policy and workload state. A GPU security processor, DPU, or confidential-computing device enforces output release or DMA egress. The hardware may require an authorization digest and valid prior receipt before enabling broader transfer. A.9.30. E09.30 Software Compromise Scenario If the agent or ordinary host software is compromised, the attacker may attempt to create an unauthorized software decision. The hardware independently limits the resulting request using: * signature verification; * fixed scope ceiling; * phase counter; * receipt dependency; * device identity; * and protected revocation state. A forged or out-of-envelope request is denied. Das Expires 4 April 2027 [Page 211] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.9.31. E09.31 Hardware Compromise / Failure Containment Where policy assumes hardware failure is possible, software may independently require: * valid attestation; * expected key version; * expected measurement; * phase counter match; * and receipt consistency. An unexpected hardware state may place the workflow in HOLD rather than accepting the effect as valid. A.9.32. E09.32 Version and Upgrade Binding Software and hardware policy versions may be bound to compatible epochs. Let: V ersionM atchi = Compatible(VSW ,i , VHW ,i ) If compatibility fails, progression may be denied or routed to protected migration. A.9.33. E09.33 Revocation Synchronization The software and hardware sides may each track revocation state. Continuation may require: ErSW = ErHW = Ercurrent or another rule establishing that neither side is operating under stale revocation state. A.9.34. E09.34 Policy Synchronization Similarly, a hardware-enforced policy epoch may constrain software decisions. Software cannot revive authority based solely on an older policy snapshot. A.9.35. E09.35 Split Anti-Rollback Hardware monotonic state may anchor software rollback resistance. If software returns to an old snapshot with phase index i − 1 while hardware records phase i, the mismatch is detected and the old software state cannot automatically reissue the consumed phase. Das Expires 4 April 2027 [Page 212] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.9.36. E09.36 Alternate-Path Closure A split architecture should account for bypass both around software and around hardware. Examples include: * direct host network path bypassing DPU; * alternate key outside HSM; * raw actuator path bypassing safety controller; * direct storage key accessible to host; * debug interface to secure hardware; * recovery API that ignores software policy; * or shadow credentials enabling the same consequence. The architecture may remove, disable, mediate, cryptographically prevent, or equivalently govern such paths. A.9.37. E09.37 Fail-Closed Split Rule A representative condition may be: SplitP assi = F ALSE ⇒ Effectuationi = BLOCKED where failure may result from either software or hardware mandatory checks. A.9.38. E09.38 Fail-Limited Split Rule Where one side is unavailable, policy may permit only a reduced safe mode. Examples: * no external SEND; * local read-only operation; * reduced actuator envelope; * no payment settlement; * no key release; * or manual recovery. Das Expires 4 April 2027 [Page 213] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.9.39. E09.39 Indeterminate Split State If software believes Phase i occurred but hardware state is uncertain, or vice versa, the system enters an indeterminate reconciliation state. Reconciliation may compare: * hardware monotonic counter; * software journal; * sink receipt; * transaction identifier; * device state; * destination state; * and attestation. No broader phase is released merely because one side assumes success. A.9.40. E09.40 Completion Receipt A completion receipt may bind both software and hardware evidence. For example: RFsplit = P rotect (DA , H(R0 ), ... , H(Rn ), DSW state , AttHW , F inalState) The exact format is illustrative. A.9.41. E09.41 Required Invariants The frozen conceptual invariants of E09 are: 1. software and hardware each contribute at least one authority-relevant function; 2. at least one authority-critical secret, state, or effectuation gate remains outside ordinary agent control; 3. software approval alone need not be sufficient for full effectuation; 4. hardware authority may be bounded by software-provided act and scope information rather than being globally permissive; 5. prior receipt evidence can be bound into the software/hardware transition for staged execution; 6. rollback, replay, disagreement, and partial state transitions are reconciled rather than silently ignored; and 7. alternate paths around either side are controlled where necessary to preserve the split dependency. 5 FROZEN RELATIONSHIP BETWEEN E07, E08 AND E09 5.1 E07 - Software PED Agent/Application → P rotected Software Authority → Software Effectuation Gate → Effect Das Expires 4 April 2027 [Page 214] Internet-Draft Reality as a Cryptographic Dependency October 2026 5.2 E08 - Hardware PED Software Request → P rotected Hardware Authority → Hardware Effectuation Gate → Effect 5.3 E09 - Split Software/Hardware PED Software P olicy/P lanning → Bound Decision → Hardware V erification/Authority → Effectuation The three embodiments may be used with E01 single-phase effectuation, E02 demonstration-thenfull effectuation, E03 progressive effectuation, E04 protected human continuation, E05 automatic continuation, E06 hybrid continuation, or combinations thereof. 6 APPENDIX G - NEW DEFINITIONS INTRODUCED BY E07- E09 ONLY 6.1 G.1 Non-Repetition Rule Definitions already supplied in the Advanced Section 1 master definition appendix or the E01-E06 workflow appendices are not repeated. The definitions below are included only where E07-E09 introduce a new term or a materially specialized meaning. 6.2 G.2 Software Protected Enforcement Domain Software Protected Enforcement Domain means a software-implemented or software- controlled protected authority region that evaluates, retains, derives, applies, or enforces effectuation authority using privilege separation, isolation, protected state, protected credentials, policy enforcement, or equivalent software mechanisms. It may be local, remote, distributed, kernel-resident, proxybased, transaction-based, or service-based. 6.3 G.3 Software Effectuation Gate Software Effectuation Gate means a software component positioned such that the relevant external effect cannot ordinarily occur through the governed path unless the gate permits, performs, or cryptographically enables it. Examples include a kernel gate, proxy, API gateway, database commit service, storage gateway, transaction manager, message broker, or credential broker. 6.4 G.4 Protected Software State Protected Software State means software-maintained state that ordinary proposing code is not authorized to arbitrarily alter and that participates in an effectuation decision. It may include phase, nonce, receipt, approval, policy, revocation, capability, rate-limit, or transaction state. 6.5 G.5 Late Credential Injection Late Credential Injection means applying, inserting, or using a real effect-capable credential only after protected validation and at or near the effectuation boundary, while withholding that credential from the less-trusted proposing runtime. Das Expires 4 April 2027 [Page 215] Internet-Draft Reality as a Cryptographic Dependency October 2026 6.6 G.6 Hardware Protected Enforcement Domain Hardware Protected Enforcement Domain means a hardware or hardware-rooted authority region that protects one or more effectuation-critical keys, states, measurements, verification functions, counters, latches, or effectuation gates from ordinary software modification or extraction. 6.7 G.7 Hardware Root of Authority Hardware Root of Authority means a non-exportable or hardware-protected secret, identity, state, key, counter, or trust anchor from which protected phase authority or verification is derived. 6.8 G.8 Hardware Phase Key Hardware Phase Key means a phase-specific cryptographic key or equivalent hardware-protected authority derived, unsealed, or activated for a particular effectuation phase and bounded to applicable act, receipt, policy, sink, device, or scope state. 6.9 G.9 Protected Hardware Latch Protected Hardware Latch means a hardware, microarchitectural, secure-firmware, or equivalent protected state element whose value controls whether a subsequent effectuation operation can become available. 6.10 G.10 Hardware Effectuation Gate Hardware Effectuation Gate means hardware or hardware-rooted logic whose protected state, key, command authentication, register control, queue control, or physical placement makes it necessary for producing the governed effect through the intended path. 6.11 G.11 Split Software/Hardware PED Split Software/Hardware PED means an architecture in which software and hardware separately perform authority-relevant functions such that effectuation depends on protected contributions from both sides or on hardware verification of a software-bound decision. 6.12 G.12 Authorization Decision Record Authorization Decision Record (ADR) means a protected software-generated or jointly generated record describing a phase-specific authorization decision and binding act identity, phase, scope, policy, receipt, approval, destination, or other protected state for hardware verification or downstream enforcement. 6.13 G.13 Authorization Digest Authorization Digest means a deterministic digest or commitment representing an Authorization Decision Record or equivalent protected software decision context for later verification by hardware or another protected component. Das Expires 4 April 2027 [Page 216] Internet-Draft Reality as a Cryptographic Dependency October 2026 6.14 G.14 Hardware Envelope Hardware Envelope means the maximum or otherwise protected effectuation scope that the hardware side permits independently of a broader software request. Software may narrow but cannot validly enlarge the effect beyond this envelope without a protected hardware policy change. 6.15 G.15 Split Key Share Split Key Share means one of multiple cryptographic shares, secrets, or authority contributions held by separate software/hardware or multi-party components and required to form a later effectuation authority. 6.16 G.16 Dual Verification Dual Verification means a workflow in which both software and hardware independently validate a required item, such as an ECR, approval artifact, or act binding, and continuation is permitted only under the applicable combination rule. 6.17 G.17 Split Indeterminate State Split Indeterminate State means a protected condition in which software and hardware state disagree or cannot establish whether a relevant phase transition or effectuation occurred, causing broader progression to remain blocked pending reconciliation. 7 APPENDIX H - NEW NOTATION INTRODUCED BY E07-E09 ONLY 7.1 H.1 Non- Repetition Rule Notation previously defined in Advanced Section 1 or the E01-E06 delta notation appendices is intentionally not repeated. Symbols below are included only where E07-E09 introduce a new symbol or materially specialized local meaning. 7.2 H.2 Software PED Notation * ZSW - protected software state maintained by the Software PED. * SW P assi - protected Boolean or equivalent decision state indicating that the mandatory Software PED predicates for phase i have passed. * KSW - protected software-side key used in an illustrative capability-protection construction. * P rincipali - caller/process/workload principal bound to phase i in the illustrative software capability construction. * AuthorizeState(⋅) - illustrative protected software-state function indicating whether the specified act/principal/sink tuple is currently authorized. * P EN DIN Gi / AU T HORIZEDi - illustrative software phase states before and after protected authorization. Das Expires 4 April 2027 [Page 217] Internet-Draft Reality as a Cryptographic Dependency October 2026 7.3 H.3 Hardware PED Notation * KHW - hardware-protected root secret, key, or equivalent authority root. * ZHW - hardware-protected state participating in effectuation decisions. * Mplat - measured platform/firmware/software state evaluated by hardware or hardware-rooted verification. * Mallowed - policy-permitted set of platform measurements. * AttHW - hardware or hardware-rooted attestation evidence. * HW P assi - protected Boolean or equivalent result indicating that required hardware predicates for phase i have passed. phase * Ki - hardware-derived, unsealed, or protected phase-specific key/ authority for phase i. * LHW i+1 - protected hardware latch controlling availability of phase i + 1. * ctri - hardware-protected monotonic counter value associated with phase or authority progression. * ctrrequest - counter value presented or expected for a requested protected transition. * εi - phase-specific allowed tolerance in the hardware measurement example. 7.4 H.4 Split PED Notation * ADRi - Authorization Decision Record for phase i. Distinct from the earlier Automatic Decision Record abbreviation AD_i. * AuthDigesti - cryptographic digest or commitment of the phase-i Authorization Decision Record. * SplitP assi - protected result indicating that the mandatory split software/hardware predicates for phase i have passed. * ScopeSW ,i - maximum scope permitted by the software decision for phase i. Das Expires 4 April 2027 [Page 218] Internet-Draft Reality as a Cryptographic Dependency October 2026 * ScopeHW ,i - maximum scope independently permitted by hardware for phase i. * Scopeeff,i - effective phase scope after protected combination/ narrowing of software and hardware scopes. * ReceiptAcceptSW i - software-side acceptance result for receipt Ri . HW * ReceiptAccepti - hardware-side acceptance result for receipt Ri . * HybridHW P assi - illustrative hardware-side result for a hybrid human/automatic approval check. * ShareSW ,i - software-side cryptographic or authority share for phase i. * ShareHW ,i - hardware-side cryptographic or authority share for phase i. * DSW state,i - digest/commitment of protected software state relevant to phase i. * AdvanceSW / AdvanceHW - illustrative protected software-side and hardware-side phase-state advancement operations. * VSW ,i / VHW ,i - software and hardware policy/version identifiers used in the compatibility example. * V ersionM atchi - result of the illustrative software/hardware policy-version compatibility check. * ErSW / ErHW / Ercurrent - software-side, hardware-side, and currently authoritative revocation epochs in the synchronization example. split * RF - final completion receipt binding split software and hardware evidence. 7.5 H.5 Local Operator and Function Convention The following word- like expressions are functional or predicate notation, not required programming identifiers: ActMatch, CallerValid, SinkPermitted, Protect, AuthorizeState, AttestationValid, MeasurementAllowed, PhaseStateValid, ReceiptStateValid, Compatible, Combine, Advance, ReceiptAccepted, SoftwareDecisionValid, HardwareEnvelopeValid, MatchReceipt, MatchAct, and related labels. Das Expires 4 April 2027 [Page 219] Internet-Draft Reality as a Cryptographic Dependency October 2026 7.6 H.6 Local Interpretation Rule Where E07-E09 reuse a symbol already defined in earlier sections, the prior meaning remains controlling unless the local subsection expressly narrows the meaning. The notation is illustrative and may be replaced by equivalent data structures, protected state machines, hardware registers, cryptographic objects, or protocol fields while preserving the disclosed technical dependency. A.10. E10 — Receipt-Conditioned Hardware Cryptographic Key-Chain Effectuation A.10.1. E10.1 Purpose E10 defines an effectuation workflow in which protected hardware retains a root secret, root authority state, sealed continuation secret, or equivalent non-exportable authority and makes later effectuation material available only after the protected conditions for the preceding phase have been satisfied. A representative causal relationship is: Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND Candidate Act → Hardware Root Authority → P hase 0 Authority → Real P hase 0 Effect → V erified Receipt R0 → Hardware State Advance → P hase 1 Authority →⋯ → F inal Effectuation. The important property is not the particular KDF shown below. The important property is that the protected material enabling a later effect is unavailable, unusable, unsealed, inactive, or invalid until the required prior receipt or equivalent protected evidence has been accepted. A.10.2. E10.2 Hardware Root of Authority Protected hardware may retain a root authority denoted locally by: KRA The root authority may be: * a symmetric root key; * a private key; * a sealed secret; * a hardware wrapping key; * a secure-element key; * an HSM key; Das Expires 4 April 2027 [Page 220] Internet-Draft Reality as a Cryptographic Dependency October 2026 * a PUF-derived secret; * a root state in secure NVRAM; * a protected monotonic state combined with a key; * a threshold share retained by hardware; * or another hardware-protected value. The root authority preferably is not directly exportable to the proposing agent or ordinary application software. A.10.3. E10.3 Candidate Act Binding Before deriving phase authority, the hardware or a protected software/hardware combination may obtain the Candidate Act digest DA , the phase identifier, sink identity, maximum authorized envelope, receipt requirements, approval state, and other protected context. A hardware-bound act context may be represented by: Bi = H(DA ∥ i ∥ Sinki ∥ Scopei ∥ Ep ∥ Er ) . Bi is illustrative. Equivalent structured binding may be used without hashing all fields into one value. A.10.4. E10.4 Initial Phase Authority For an initial bounded real effect, hardware may derive or unseal an initial phase authority: K0chain = KDF (KRA , DA , N0 , B0 ) . The authority may instead be represented as: * a command authenticator; Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND * device-specific MAC value; * signing permission; * decryption key; * storage unwrap key; * DMA authorization; * network-transmit enable value; Das Expires 4 April 2027 [Page 221] Internet-Draft Reality as a Cryptographic Dependency October 2026 * motor-control authorization; * transaction completion value; * or equivalent hardware-bound material. A.10.5. E10.5 Narrow Phase Scope Where E02 or E03 staged effectuation applies, the initial authority must remain bounded to the permitted first phase. A representative requirement is: Scope(K0chain ) ⊆ Scope(P0 ). The initial phase key or authority must not validly authorize the complete broader effect merely because the holder possesses it. A.10.6. E10.6 Phase-0 Verification at Hardware Boundary Before hardware enables Phase 0, it may verify: * Candidate Act binding; * phase identifier; * destination or sink identity; * nonce; * policy epoch; * revocation epoch; * caller or workload identity; * hardware measurement; * authorization envelope; * human or automatic approval where required; * and protected local state. The hardware may maintain a phase state: qHW = 0 indicating that no later phase has yet been unlocked. Das Expires 4 April 2027 [Page 222] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.10.7. E10.7 Real Initial Effect The Phase-0 authority is used only at the applicable effect-capable boundary. Examples include: * transmitting a bounded SEND object through a SmartNIC or protected NIC path; * executing a limited actuator movement through a motor controller; * releasing a limited decryption key through a secure element; * committing a bounded storage operation through a storage controller; * authorizing a bounded payment operation through an HSM-backed transaction service; * allowing one bounded DMA transfer through a DPU or IOMMU- associated controller; * or performing another real effectuation event. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND A.10.8. E10.8 Receipt Acquisition Following the real effect, the applicable protected observer produces or supplies receipt R0 according to the earlier ECR definitions. The receipt may be received directly by the hardware or may first be received by a software PED and then presented to hardware with protected binding evidence. A.10.9. E10.9 Hardware Receipt Validation Hardware may validate one or more of: V alid(R0 ), M atchAct(R0 , DA ), M atchP hase(R0 , P0 ), M atchSink(R0 , Sink0 ), F resh(R0 ), N otConsumed(R0 ). Where the receipt is generated by a remote or destination component, hardware may additionally verify a certificate chain, public key, attestation, shared MAC key, or another protected trust relationship. A.10.10. E10.10 Receipt-Conditioned Key Derivation After successful receipt validation, a next-phase key may be derived: Das Expires 4 April 2027 [Page 223] Internet-Draft Reality as a Cryptographic Dependency October 2026 chain Ki+1 = KDF (KRA , DA , H(Ri ), i + 1, Bi+1 ) . This construction makes the accepted receipt digest an input to the next protected authority. An implementation may additionally bind: * prior phase key identifier; * monotonic counter; * hardware measurement; * destination identity; * approval artifact digest; * current policy version; * or receipt-chain root. A.10.11. E10.11 Receipt-Conditioned Unsealing Variation A later authority need not be mathematically derived from Ri . Instead, the hardware may store a sealed secret: Seali+1 and unseal it only where: ReceiptAcceptedi = T RU E and all mandatory protected predicates pass. This variation covers TPM-style sealed state, secure-enclave keybags, HSM objects, device key slots, secure firmware key vaults, and other hardware mechanisms. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND A.10.12. E10.12 Wrapped-Key Variation A later phase key may exist in wrapped form before the previous phase completes: Wi+1 = W rapKRA (Ki+1 , Contexti+1 ). Hardware refuses to unwrap Wi+1 until receipt Ri and the applicable protected state are accepted. Thus physical storage of wrapped ciphertext does not imply executable availability of the underlying phase authority. A.10.13. E10.13 Hardware Latch Coupling Key availability may be coupled to a protected hardware latch. For example: Das Expires 4 April 2027 [Page 224] Internet-Draft Reality as a Cryptographic Dependency October 2026 Lchain i+1 =0 before prior receipt acceptance, and: V erify(Ri ) = T RU E ⇒ Lchain i+1 ← 1. The key slot, command path, DMA descriptor, transmit queue, signing operation, or actuator command remains disabled while the latch is zero. A.10.14. E10.14 Monotonic Phase State Hardware may maintain a non-decreasing phase state: qHW ∈ {0, 1, ... , n}. A request for Phase j may be permitted only where: j = qHW + 1. After successful receipt acceptance and protected advancement: qHW ← qHW + 1. This prevents software from requesting a later phase while silently skipping an earlier mandatory phase. A.10.15. E10.15 Atomic Receipt Consumption and State Advance To avoid replay, hardware may perform the following as one protected transition: V erify(Ri ) ∧ Consume(Ri ) ∧ Advance(qHW ) chain ∧ Enable(Ki+1 ). If the protected transition fails before commitment, the system remains in a recoverable prior or indeterminate state rather than assuming successful progression. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND A.10.16. E10.16 Key Separation Across Phases Phase keys should preferably be cryptographically or operationally separated. Possession of: Kichain should not automatically reveal: chain Ki+1 . This may be accomplished through one-way derivation, independent sealed keys, hardware key slots, threshold shares, or equivalent protected separation. A.10.17. E10.17 Compromise Containment If a phase-specific authority is compromised, the system may revoke or terminate the affected Candidate Act without exposing the root authority. A representative desired property is: Das Expires 4 April 2027 [Page 225] Internet-Draft Reality as a Cryptographic Dependency October 2026 Compromise(Kichain ) ⇏ Compromise(KRA ). No absolute cryptographic guarantee is implied for every implementation; the hardware and primitive selection determine the actual security strength. A.10.18. E10.18 Key Zeroization After phase authority is consumed, hardware may: * zeroize volatile key material; * disable the key slot; * increment a monotonic counter; * invalidate the wrapped object; * mark the capability consumed; * rotate the derivation context; * or otherwise make replay ineffective. A phase authority may remain available only where retry semantics expressly require controlled reuse. A.10.19. E10.19 Human Approval Integration Where E04 applies, human approval after a verified trial may become an additional key-release condition. A representative relation is: chain Enable(Ki+1 ) = V alid(Ri ) ∧ V alid(HAAi ) ∧ OtherM andatoryP redicatesi . The human approval artifact may itself be verified by secure hardware or may be verified by software and bound into an ADR presented to hardware under E09. A.10.20. E10.20 Automatic Approval Integration Where E05 applies: chain Enable(Ki+1 ) = V alid(Ri ) ∧ AutoP assi ∧ OtherM andatoryP redicatesi . The automatic authority component need not possess the root hardware secret. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND A.10.21. E10.21 Hybrid Approval Integration Where E06 applies, hardware may require both human and automatic decision evidence or an applicable threshold rule. For conjunction: Das Expires 4 April 2027 [Page 226] Internet-Draft Reality as a Cryptographic Dependency October 2026 chain Enable(Ki+1 ) = V alid(Ri ) ∧ HumanP assi ∧ AutoP assi . Other protected combination rules remain possible. A.10.22. E10.22 Single-Phase Compatibility E10 can also support E01 single-phase effectuation. In that case, hardware may derive a single final authority: KFchain = KDF (KRA , DA , SinkF , ScopeF , NF ) without a prior trial receipt where protected policy expressly selects single-phase execution. Thus E10 does not require staged execution for every Candidate Act. A.10.23. E10.23 Multi-Phase Key Chain For E03 progressive effectuation: K0chain → R0 → K1chain → R1 → ⋯ → Knchain . Each phase may require a distinct sink or may use the same protected hardware sink. A.10.24. E10.24 Entire-History Binding Variation Instead of deriving Phase i + 1 from only the immediately preceding receipt, the hardware may bind the entire receipt history: CumulativeReceipti = H(R0 ∥ R1 ∥ ⋯ ∥ Ri ) and: chain Ki+1 = KDF (KRA , DA , CumulativeReceipti , i + 1). A Merkle root or receipt-chain accumulator may replace direct concatenation for large sequences. A.10.25. E10.25 Multiple-Sink Variation Where Phase i and Phase i + 1 occur at different sinks, the next key may bind both: chain Ki+1 = KDF (KRA , DA , H(Ri ), Sinki , Sinki+1 ). This can prevent a valid receipt from Sink A from being used to unlock authority intended for an unrelated Sink B. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND A.10.26. E10.26 Device-Bound Variation Hardware may also bind device identity: chain Ki+1 = KDF (KRA , DA , H(Ri ), DeviceID, i + 1). The resulting authority may be unusable on another device. Das Expires 4 April 2027 [Page 227] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.10.27. E10.27 SEND Example An AI agent proposes sending a protected file to Recipient X. A hardware-rooted gateway or secure element first enables transmission of a bounded trailer object using K0chain . The recipient endpoint returns signed receipt R0 proving acceptance of the trailer at the intended endpoint. The hardware verifies R0 and only then enables the full-payload authority K1chain or the final decryption-key release. If R0 is absent, invalid, stale, or bound to a different recipient, the full SEND remains unavailable. A.10.28. E10.28 Payment Example A protected payment component authorizes a bounded verification transaction or reservation using the initial phase authority. The receiving institution returns protected confirmation R0 . Only after hardware validates the destination, transaction identifier, amount class, nonce, and receipt does it enable the key or signing authority necessary for the next settlement phase. A successful bounded transaction does not by itself allow an amount beyond the previously authorized maximum envelope. A.10.29. E10.29 Actuator Example A secure motor controller stores KRA and initially permits only a small movement. A protected encoder generates receipt R0 corresponding to the observed motion. If the encoder measurement is inside the authorized tolerance and the receipt is valid, the secure controller advances its protected phase state and enables a larger movement key or command authenticator. The ordinary application processor never receives the unrestricted root command authority. A.10.30. E10.30 Network / SmartNIC Example A SmartNIC may retain the hardware root authority and enforce phased network egress. Phase 0 may allow only a bounded destination challenge or low-information object. After the remote endpoint returns a valid receipt, the SmartNIC or associated DPU may unlock broader transmit scope, a higher bandwidth envelope, or a key required to encrypt the remaining payload. A.10.31. E10.31 Storage Controller Example A storage controller may first permit writing a bounded object to protected staging storage. Following a verified persistence receipt, hardware may release the key or controller state needed to promote, replicate, decrypt, or expose the broader object. Das Expires 4 April 2027 [Page 228] Internet-Draft Reality as a Cryptographic Dependency October 2026 Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND A.10.32. E10.32 Policy Epoch Change A valid receipt does not override a newer restrictive policy. A representative condition is: Epcurrent ≠ Epreceipt ⇒ Revalidate. The hardware may refuse to derive the next key until the current policy state is confirmed. A.10.33. E10.33 Revocation Between Key Stages If the Candidate Act, destination, user, device, or credential is revoked after Ri but before key release: chain Revoked = T RU E ⇒ Enable(Ki+1 ) = F ALSE. A.10.34. E10.34 Receipt Replay Protection A previously accepted receipt must not automatically unlock the same or another next-phase key more than permitted. Hardware may bind receipt consumption to: * nonce; * phase; * Candidate Act digest; * monotonic counter; * transaction identifier; * or stored receipt digest. A.10.35. E10.35 Rollback Protection An attacker should not be able to restore an older hardware state in which a consumed receipt or phase authority becomes valid again. Anti-rollback mechanisms may include: * monotonic hardware counters; * secure NVRAM epochs; * signed state checkpoints; Das Expires 4 April 2027 [Page 229] Internet-Draft Reality as a Cryptographic Dependency October 2026 * hardware fuses; * trusted time; * remote continuity state; * or equivalent protected techniques. A.10.36. E10.36 Crash and Power-Loss Recovery A power loss may occur after the real effect but before the next key is derived. Protected recovery may reconcile: * stored phase counter; * receipt digest; * sink idempotency state; * hardware journal; * destination state; * and monotonic counter. The system should not blindly replay a physical, financial, or communicative effect solely because volatile key state was lost. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND A.10.37. E10.37 Invalid Receipt Handling Where a receipt is invalid, hardware may: * remain at the current phase; * zeroize temporary material; * require a new bounded trial; * require human review; * enter an indeterminate state; * or terminate the Candidate Act. It must not derive the broader key merely because a receipt-like object was supplied. Das Expires 4 April 2027 [Page 230] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.10.38. E10.38 Root-Key Rotation The hardware root authority may be rotated without changing the logical staged-effectuation model. Migration may use a protected transition that binds: * old root state; * new root state; * active Candidate Acts; * current phase counters; * consumed receipts; * and applicable revocation state. A.10.39. E10.39 Anti-Bypass Requirement The value of the hardware key chain is reduced if an equivalent full- effect credential or physical path remains outside the protected hardware dependency. Accordingly, implementations may control: * shadow keys; * debug interfaces; * raw device commands; * alternate network paths; * recovery keys; * secondary payment signers; * duplicate storage keys; * or other equivalent authority paths. A.10.40. E10.40 Completion Evidence After final effectuation, a completion receipt may commit to the hardware chain state: RFchain = P rotect(DA , qHW , H(R0 ), ... , H(Rn ), F inalState) . Das Expires 4 April 2027 [Page 231] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.10.41. E10.41 Required Invariants The frozen conceptual invariants of E10 are: 1. at least one effectuation-critical root authority, sealed secret, or protected state is retained by hardware or hardware-rooted logic; 2. where staged mode applies, authority for a later phase is unavailable or invalid until required prior effect evidence is accepted; 3. a phase- specific key or authority does not by itself grant unbounded authority outside its permitted act, phase, sink, device, or scope; 4. receipt replay, phase rollback, and state rollback are controlled where required; 5. human, automatic, or hybrid approval can be incorporated without giving the proposing agent control of the root authority; 6. single-phase and multi-phase modes are both supported; and Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND 7. equivalent authority paths are controlled where necessary to preserve the receipt-conditioned hardware dependency. TINUATION A.11. E11 — Threshold / Multi-Party Cryptographic Continuation A.11.1. E11.1 Purpose E11 defines a continuation architecture in which authority for a later effectuation phase is distributed across multiple protected participants, such that one participant alone need not possess sufficient authority to cause the broader effect. The general relation is: V erified P rior Effect → P articipant V alidation → P rotected Authority Contributions → T hreshold Satisfaction → Combined Continuation Authority → N ext Effectuation P hase. This embodiment may be implemented cryptographically through secret sharing, threshold signatures, multi-signatures, multiple key-encryption keys, split command authorization, multiple independent latches, or equivalent protected multi-party controls. A.11.2. E11.2 Participant Set Let the protected continuation participants be represented by: U = {U1 , U2 , ... , Un }. Participants may include: * the originating device PED; Das Expires 4 April 2027 [Page 232] Internet-Draft Reality as a Cryptographic Dependency October 2026 * an HSM; * a remote enterprise authority; * the Finality Sink; * the receiving endpoint; * a user approval device; * a hardware secure element; * a network authority; * a payment institution; * a cloud security service; * an independent audit authority; * a device owner; * or another protected participant. The participants need not all be operated by different organizations. Separation may be logical, physical, administrative, cryptographic, or jurisdictional. A.11.3. E11.3 Threshold Rule A protected threshold may require at least t acceptable authority contributions from n eligible participants: 1 ≤ t ≤ n. Continuation is permitted only where: Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND V alidShareCounti ≥ ti . The threshold may be fixed or may vary by phase, risk, amount, recipient, act class, or protected policy. A.11.4. E11.4 Distinction from Receipt Quorum A quorum of receipts and a threshold of authority shares are related but distinct concepts. A receipt quorum answers whether enough observers confirm the prior effect. A continuation threshold answers whether enough protected authority holders contribute to enabling the next effect. An implementation may require either or both. Das Expires 4 April 2027 [Page 233] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.11.5. E11.5 Per-Phase Authority Share Participant Uj may hold or generate a phase-specific authority share: σj,i . The share may be: * a threshold-signature share; * secret-share contribution; * partial MAC; * wrapped-key share; * approval signature; * hardware unlock contribution; * policy authorization fragment; * decryption share; * signing share; * or another protected contribution. A.11.6. E11.6 Share Binding A share may be bound to: DA , i, H(Ri−1 ), Sinki , Scopei , Ep , Er , Ni . A representative share may be expressed as: σj,i = P rotectKU (DA , i, H(Ri−1 ), Sinki , Scopei , Ni ) . j This is illustrative and does not require all listed fields in every implementation. A.11.7. E11.7 Receipt-Conditioned Share Release Where the workflow follows E02 or E03, participant Uj may refuse to contribute its share until the required prior ECR is valid. A representative predicate is: Release(σj,i ) = V alid(Ri−1 ) ∧ LocalP olicyP assj,i . Das Expires 4 April 2027 [Page 234] Internet-Draft Reality as a Cryptographic Dependency October 2026 Thus the threshold cannot be satisfied merely from the original proposal when prior real-effect evidence is mandatory. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND A.11.8. E11.8 Local Independent Validation Each participant may independently verify different predicates. For example: * the HSM verifies cryptographic binding; * the receiving endpoint verifies destination identity; * the human approval device verifies human consent; * the enterprise service verifies policy; * the payment institution verifies account/settlement state; * the hardware controller verifies device state. The architecture therefore permits distributed authority based on heterogeneous evidence. A.11.9. E11.9 Authority Contribution Set For phase i, let the set of accepted authority shares be: Σi = {σj,i ∶ Accept(σj,i ) = T RU E}. Threshold satisfaction occurs where: |Σi | ≥ ti . Where specific named participants are mandatory, mere cardinality is insufficient and policy may additionally require those participants. A.11.10. E11.10 Mandatory-Participant Variation For example, continuation may require: HumanSharei ∧ HardwareSharei ∧ (EnterpriseSharei ∨ SinkSharei ) . This is a policy expression, not a limitation to a particular threshold scheme. A.11.11. E11.11 Combined Continuation Authority After threshold satisfaction, a continuation authority may be reconstructed or validated: Das Expires 4 April 2027 [Page 235] Internet-Draft Reality as a Cryptographic Dependency October 2026 Cithr = Combine(Σi ). The combined authority may be: * a threshold signature; * reconstructed secret; * combined key; * set of individually verified signatures; * multi-authorization transaction; * hardware unlock state; * or an accepted policy state indicating that the threshold has been met. A.11.12. E11.12 No-Reconstruction Variation Some implementations need not reconstruct a single secret. The Finality Sink may independently verify at least ti valid signatures or approval artifacts and execute only if the threshold predicate is satisfied. This avoids creating a combined bearer secret. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND A.11.13. E11.13 Human Share Variation A protected human approval device may contribute one threshold share only after displaying the exact continuation context. The human share may bind: * Candidate Act digest; * prior receipt digest; * next phase; * destination; * scope; * amount; * expiry; Das Expires 4 April 2027 [Page 236] Internet-Draft Reality as a Cryptographic Dependency October 2026 * and protected approval-session nonce. The AI agent cannot manufacture the human share merely by generating approval-like text. A.11.14. E11.14 Automatic Authority Share A protected automatic decision component may contribute another share after policy evaluation. The automatic share may be withheld where: * risk exceeds threshold; * receipt quality is insufficient; * destination state changed; * taint or provenance state is prohibited; * or current policy requires escalation. A.11.15. E11.15 Hardware Share A hardware PED may hold one non-exportable share. The hardware share may be released, applied internally, or used in a threshold signing operation only where: * device measurement is acceptable; * receipt is valid; * monotonic phase state is correct; * and the requested effect remains within the hardware envelope. A.11.16. E11.16 Destination Share The intended destination may supply a continuation contribution after confirming the bounded demonstration effect. For a SEND operation, the recipient endpoint may prove possession of the correct receiving key or session state. For a payment operation, a receiving institution may contribute protected acceptance evidence. For a hardware operation, a local safety controller may contribute a sensor-confirmed share. Das Expires 4 April 2027 [Page 237] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.11.17. E11.17 Sink Share The Finality Sink itself may hold one authority share, preventing upstream components from assembling the final effectuation authority without sink participation. This can bind the threshold to the actual effect-capable boundary. A.11.18. E11.18 Phase-Specific Threshold The threshold may change as consequence increases. For example: Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND t0 = 1, t1 = 2, t2 = 3. A low-consequence demonstration may require one protected authority while a large irreversible final phase requires three. A.11.19. E11.19 Risk-Adaptive Threshold A protected controller may select: ti = h(Riski , Scopei , Reversibilityi , P olicyi ). A higher risk may require a greater number or stronger class of participants. A.11.20. E11.20 Role-Constrained Threshold Participants may belong to role classes. A phase may require, for example: * at least one human authority; * at least one hardware authority; * and at least one destination or transaction authority. This prevents three shares from the same trust class from satisfying a rule intended to require cross-domain agreement. A.11.21. E11.21 Geographic / Jurisdictional Split Shares may be distributed across geographic or jurisdictional domains. For sensitive cross-border data release, continuation may require approval from the originating jurisdiction, destination jurisdiction, and device or enterprise authority. The architecture does not require such a regulatory arrangement; it merely supports it technically. Das Expires 4 April 2027 [Page 238] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.11.22. E11.22 Multi-Organization Split A cloud provider, enterprise customer, and user device may each contribute authority. No single provider then possesses unilateral ability to release the full effect where policy requires the distributed threshold. A.11.23. E11.23 SEND Workflow A sensitive file is proposed for transmission. Phase 0 sends a bounded protected trailer to the intended recipient. Receipt R0 returns from the recipient endpoint. For full semantic release, the system may require: 1. recipient endpoint share; 2. enterprise policy share; and 3. either a human approval share or hardware PED share. Only when the protected rule is satisfied is the final decryption key or remaining payload authority released. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND A.11.24. E11.24 Payment Workflow A payment may require: * user-device approval share; * bank/HSM transaction share; * enterprise or account-policy share; * and receipt evidence from the bounded destination-verification phase. A higher payment amount may increase the threshold or require a mandatory human share. A.11.25. E11.25 Robotic / Industrial Workflow A hazardous actuator command may require contributions from: * autonomous planner policy; * safety controller; * protected sensor subsystem; * and optionally a human supervisor. The actuator Finality Sink executes only where the required multi-party condition is met. Das Expires 4 April 2027 [Page 239] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.11.26. E11.26 Threshold Key Release A final key may be represented conceptually as: Kithr = Reconstructt (Σi ). Where fewer than ti valid shares are available: |Σi | < ti ⇒ Kithr unavailable. A.11.27. E11.27 Threshold Signature Variation Instead of reconstructing a key, participants may create a threshold signature: Sigithr = T hresholdSignt (DA , H(Ri−1 ), i, Scopei ). The sink verifies the final threshold signature before effectuation. A.11.28. E11.28 Multi-Signature Variation Each participant may provide an ordinary independent signature and the sink verifies that the required set is present. This may be operationally simpler than cryptographic threshold-signature schemes while preserving distributed approval semantics. A.11.29. E11.29 Share Freshness Each share may bind a phase-specific nonce and expiry. A share created for one transaction or phase must not automatically remain valid for another. A.11.30. E11.30 Share Replay Protection After phase i is completed, previously used shares may be marked consumed or rendered invalid by phase advancement. A representative rule is: Consumed(σj,i ) = T RU E ⇒ RejectReplay(σj,i ). Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND A.11.31. E11.31 Participant Revocation If participant Uj is revoked, compromised, or no longer trusted, future shares from that participant may be refused. The policy may: * substitute another participant; * increase threshold; Das Expires 4 April 2027 [Page 240] Internet-Draft Reality as a Cryptographic Dependency October 2026 * re-share secrets; * require human recovery; * or terminate the Candidate Act. A.11.32. E11.32 Dynamic Membership The eligible participant set may change between phases under protected policy. A new set: Ui+1 may replace the previous set only through a protected membership transition. The proposing agent should not be able to add arbitrary favorable participants merely to satisfy the threshold. A.11.33. E11.33 Re-Sharing / Key Rotation Long-lived systems may redistribute shares without changing the underlying authorization envelope. Protected re-sharing should preserve: * active Candidate Act state; * phase index; * receipt history; * revocation state; * and threshold policy. A.11.34. E11.34 Participant Failure If one participant is unavailable but the threshold can still be satisfied, the system may continue where policy permits. If the threshold cannot be satisfied: |Σi | < ti ⇒ Effectuationi = BLOCKED. A fail-limited mode may permit a reduced consequence if separately authorized. A.11.35. E11.35 Conflicting Participant Decisions Participants may disagree. A negative decision from a mandatory participant may override positive shares even where the numeric threshold otherwise appears satisfied. The policy must therefore distinguish: * absent share; Das Expires 4 April 2027 [Page 241] Internet-Draft Reality as a Cryptographic Dependency October 2026 * positive share; * explicit veto; * indeterminate state; * and revoked participant. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND A.11.36. E11.36 Human Veto Variation A protected human may hold a veto capability without supplying a positive share for routine phases. If the human veto is valid and timely: V etoi = T RU E ⇒ Effectuationi = BLOCKED. A.11.37. E11.37 Indeterminate Receipt Before Threshold If the prior phase receipt is indeterminate, participants that require verified prior effect should not release their shares. The architecture therefore prevents a threshold from being assembled based only on upstream optimism about whether the trial succeeded. A.11.38. E11.38 Share Confidentiality Where shares contain sensitive key material, protected transport and storage may be used. Shares need not be visible to the AI agent or ordinary application. A.11.39. E11.39 Collusion Consideration Threshold distribution reduces unilateral authority only to the extent that the selected participants and threshold preserve meaningful independence. The disclosure does not assume that an arbitrary t-of-n choice is secure against all collusion. Implementations may select participants, hardware isolation, organizational separation, or policy constraints appropriate to the threat model. A.11.40. E11.40 Alternate-Path Closure A threshold architecture may be bypassed if an unrestricted credential or direct effect path remains available to one participant. Accordingly, equivalent effectuation paths may be required to honor the same distributed authority rule or a formally equivalent protected control. Das Expires 4 April 2027 [Page 242] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.11.41. E11.41 Completion Receipt A completion receipt may commit to the threshold evidence without exposing secret shares: RFthr = P rotect(DA , i, T hresholdP olicyi , AuthorityCommitmenti , F inalState) . AuthorityCommitmenti may be a digest of the accepted participant identities, signatures, threshold signature, or equivalent evidence. A.11.42. E11.42 Required Invariants The frozen conceptual invariants of E11 are: 1. broader effectuation requires protected contributions from more than one authority source where threshold mode is selected; 2. the required number and/or classes of contributions are protected policy rather than agentcontrolled values; 3. shares or approval contributions are bound to the relevant act, phase, scope, destination, receipt, or equivalent context as required; 4. where prior real-effect evidence is mandatory, participants do not validly authorize the next phase without acceptable evidence; Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND 5. missing, stale, replayed, revoked, or conflicting shares are handled according to protected policy; 6. a threshold may be fixed, dynamic, role-constrained, or phase-specific; and 7. equivalent unilateral bypass paths are controlled where necessary to preserve distributed continuation authority. FULL EFFECTUATION A.12. E12 — Message-SEND Demonstration / Trailer-Then-Full Effectuation A.12.1. E12.1 Purpose E12 provides a concrete communication embodiment in which a computational system proposes a message, file, attachment, data package, command communication, or other SEND operation, but the complete intended communication does not immediately become externally effective. A bounded real communication object first traverses the actual intended effectuation path. Protected return evidence from the intended recipient path is then used as a condition for releasing the remaining or full communication effect. A representative workflow is: Das Expires 4 April 2027 [Page 243] Internet-Draft Reality as a Cryptographic Dependency October 2026 P roposed SEN D → Recipient/Content Binding → Bounded T railer Authority → Real T railer T ransmission → Recipient Receipt R0 → P rotected Receipt V erification → Human/Automatic/Hybrid Continuation → F ull P ayload or Key Release → Completion Receipt. A.12.2. E12.2 Communication Candidate Act The Candidate Act may specify: * sender or sending authority; * intended recipient; * recipient account; * recipient device; * destination service; * conversation/thread identifier; * message type; * payload; * attachments; * content classification; * permitted disclosure scope; * timing; * expiration; * and effectuation policy. The message proposal itself does not constitute completed SEND authority. A.12.3. E12.3 Full Communication Object For this embodiment, let the full intended communication object be denoted: MsgF . Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND Das Expires 4 April 2027 [Page 244] Internet-Draft Reality as a Cryptographic Dependency October 2026 MsgF may include text, files, images, structured data, media, tool output, attachments, or combinations thereof. The notation is local to E12 and avoids overloading the earlier symbol M . A.12.4. E12.4 Bounded Trailer Object A bounded real demonstration object is denoted: Tr0 . The trailer may contain: * recipient challenge; * cryptographic manifest; * payload commitment; * harmless bounded text; * encrypted fragment; * file metadata; * content hash; * nonce; * sender proof; * destination challenge; * protocol negotiation data; * or another limited object. The trailer must be sufficiently bounded that successful transmission does not itself disclose or effectuate the complete intended communication unless that is expressly acceptable. A.12.5. E12.5 Real SEND Requirement The trailer is not merely displayed locally. A real communication effect occurs when, for example: * bytes cross the actual egress interface; * the intended remote service accepts the trailer; Das Expires 4 April 2027 [Page 245] Internet-Draft Reality as a Cryptographic Dependency October 2026 * the recipient application receives the object; * the recipient device stores it; * the remote endpoint decrypts a bounded protected fragment; * or another externally observable state transition occurs on the actual intended path. A.12.6. E12.6 Full-Payload Commitment Before the trailer is sent, the system may bind it to the full intended payload through a commitment: DMsg = H(Canon(MsgF )). The trailer may include or bind DMsg so that the recipient receipt can refer to the same intended full communication without receiving the full content. A.12.7. E12.7 Trailer Descriptor A trailer descriptor may bind: * Candidate Act digest; * DMsg ; * recipient identity; * recipient device or service; * trailer digest; * permitted trailer content; Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND * expiry; * nonce; * expected receipt issuer; * expected protocol; * next permitted phase; Das Expires 4 April 2027 [Page 246] Internet-Draft Reality as a Cryptographic Dependency October 2026 * and maximum full disclosure envelope. The earlier TED definition may be used; no separate mandatory descriptor format is required. A.12.8. E12.8 Recipient Binding The trailer authority may be bound to the intended recipient: Recipient(Tr0 ) = Recipient(MsgF ). If policy permits forwarding, delegation, distribution lists, aliases, or multi-recipient delivery, the allowed transformation is bound into the authorized envelope. A.12.9. E12.9 Account and Device Binding Where higher assurance is required, recipient identity may include: * account identifier; * device public key; * secure-element identity; * application instance; * session identifier; * endpoint certificate; * organization/tenant; * or protected service identity. A receipt from another account or device does not automatically authorize full release. A.12.10. E12.10 Phase-0 SEND Authority The PED forms authority sufficient to send only Tr0 or another bounded first-stage object. The authority may be: * destination-bound network capability; * short-lived API token; * process-bound proxy permission; * DPU/SmartNIC phase key; * HSM signing authority; * protected message-broker permission; Das Expires 4 April 2027 [Page 247] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or another bounded SEND capability. A.12.11. E12.11 Egress Boundary Verification Before transmitting the trailer, the communication Finality Sink verifies: * Candidate Act binding; * recipient/destination; * trailer scope; * nonce; * expiry; * current policy; * revocation state; * phase state; * and applicable approval conditions. An attempt to substitute the full payload for the trailer at Phase 0 is rejected. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND A.12.12. E12.12 Trailer Transmission The sink performs the real bounded SEND. The event may traverse: * network socket; * email transport; * messaging service; * collaboration platform; * enterprise message bus; * API call; * device-to-device channel; * radio/telecom path; Das Expires 4 April 2027 [Page 248] Internet-Draft Reality as a Cryptographic Dependency October 2026 * satellite channel; * or another communication transport. No particular protocol is required. A.12.13. E12.13 Recipient Processing The recipient or receiving service may: * verify sender authenticity; * check the nonce; * verify DMsg ; * validate protocol state; * verify destination account; * store the trailer; * decrypt the bounded fragment; * prove possession of an expected private key; * or perform another required receiving-side operation. A.12.14. E12.14 Recipient Effect Confirmation Receipt The receiving endpoint generates or causes generation of receipt: R0send . The receipt may bind: * Candidate Act digest; * DMsg ; * trailer digest; * recipient identity; * recipient endpoint identity; * account/session identity; * receive time; * nonce; Das Expires 4 April 2027 [Page 249] Internet-Draft Reality as a Cryptographic Dependency October 2026 * acceptance status; * protocol transcript digest; * and applicable attestation. A.12.15. E12.15 Receipt Authentication R0send may be protected by: * digital signature; * MAC; * TLS/channel-bound evidence; * device attestation; * secure-element signature; * application signature; Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND * server-side signed receipt; * threshold signature; * or another protected mechanism. A.12.16. E12.16 Receipt Verification The sender-side PED verifies the return evidence. A representative condition is: SendReceiptP ass0 = V alid(R0send ) ∧ M atchM essage(R0send , DMsg ) ∧ M atchRecipient(R0send ) ∧ M atchN once(R0send ) ∧ F resh(R0send ). Additional predicates may be required. A.12.17. E12.17 Wrong-Recipient Receipt If the trailer was received by an unauthorized or mismatched endpoint: M atchRecipient(R0send ) = F ALSE then broader release remains blocked. This directly addresses the case in which a syntactically valid communication reaches the wrong account, device, tenant, service, or cryptographic endpoint. Das Expires 4 April 2027 [Page 250] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.12.18. E12.18 Human Review After Trailer Where E04 applies, the protected UI may display: * intended recipient; * verified recipient endpoint; * trailer acceptance status; * trailer time; * message/attachment digest; * expected full disclosure; * and any changed risk or destination state. The human then approves, denies, reduces, or delays the broader SEND. A.12.19. E12.19 Automatic Continuation After Trailer Where E05 applies, a protected automatic authority may continue if: SendReceiptP ass0 ∧ P olicyP ass ∧ RiskAcceptable = T RU E. No human interaction is mandatory for such policy classes. A.12.20. E12.20 Hybrid Continuation Where E06 applies: SendReceiptP ass0 ∧ HumanP ass ∧ AutoP ass may be required before the full payload or full decryption authority is released. Threshold continuation under E11 may also be used. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND A.12.21. E12.21 Trailer-Then-Full Payload Variation The simplest variation is: Tr0 → R0send → MsgF . After the receipt is accepted, the remaining full message or file is transmitted through the protected egress boundary. Das Expires 4 April 2027 [Page 251] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.12.22. E12.22 Trailer-Then-Phased Payload Variation For a large or sensitive payload: Tr0 → R0 → Segment1 → R1 → ⋯ → Segmentn . Each segment or group of segments may require a fresh protected receipt before broader disclosure. A.12.23. E12.23 Ciphertext-First Variation The system may transmit encrypted full payload ciphertext before semantic release. Let: CTF = EncKF (MsgF ). CTF may reach the recipient before full authorization, provided the recipient lacks sufficient material to recover MsgF . After receipt verification, the PED releases KF , a missing key share, or equivalent decryption authority. A.12.24. E12.24 Partial-Decryption Trailer Variation The full ciphertext may be present, while only a bounded portion is decryptable initially. A first-stage key may reveal only: * title; * manifest; * selected non-sensitive fields; * low-information preview; * recipient challenge; * or another bounded subset. The full decryption material is released only after protected receipt validation. A.12.25. E12.25 Key-Chain SEND Variation E12 may use E10 directly: K0chain → Tr0 → R0send → K1chain → F ull SEN D. This makes the final SEND key cryptographically dependent on the protected return evidence. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND Das Expires 4 April 2027 [Page 252] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.12.26. E12.26 Threshold SEND Variation E12 may use E11 such that final disclosure requires, for example: * recipient receipt; * enterprise share; * hardware share; * and human approval share for high-risk content. No single agent or broker need possess unilateral authority to release the complete content. A.12.27. E12.27 File Attachment Variation A message may contain a short body and a large attachment. The body or a protected trailer may be sent first. After receipt confirmation, the attachment may be: * uploaded; * transmitted; * decrypted; * linked through a protected access grant; * or progressively released. A.12.28. E12.28 Link / Object-Store Variation Instead of transmitting the full file through the messaging transport, the message may contain a reference to an object stored elsewhere. The initial message may deliver a non-usable or bounded reference. After recipient confirmation, the PED may enable: * access token; * signed URL; * decryption key; * object capability; * or destination-bound retrieval authority. Das Expires 4 April 2027 [Page 253] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.12.29. E12.29 Multi-Recipient Variation For recipients: R = {r1 , r2 , ... , rk }, the system may first send trailers to a protected subset: Rtrial ⊆ R. Broader distribution may be authorized only after the required receipt predicate over the trial subset succeeds. A.12.30. E12.30 Recipient-Specific Semantic Release Different recipients may receive the same ciphertext but different decryption capabilities. A recipient-specific receipt may unlock only that recipient’s semantic access without automatically granting access to other recipients. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND A.12.31. E12.31 Group / Distribution-List Variation A group address may resolve to multiple endpoints. Protected policy may require confirmation of: * group identity; * current membership version; * intended audience class; * or bounded sample recipients before broader delivery. A.12.32. E12.32 Thread / Conversation Binding The SEND may be bound to a protected conversation or thread identifier. A valid receipt from the correct recipient but an unrelated conversation need not authorize release if thread binding is mandatory. A.12.33. E12.33 Reply-Path Verification The trailer may test the return path as well as forward delivery. The receipt can therefore prove that the intended endpoint can receive and return protected evidence through the expected session or account context. Das Expires 4 April 2027 [Page 254] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.12.34. E12.34 Protocol-Downgrade Protection An attacker should not satisfy the trial using a weaker unprotected communication mode where stronger protected transport was required. The trailer descriptor or policy may bind: * transport class; * cryptographic session; * endpoint assurance; * or minimum protocol property. A.12.35. E12.35 Content Substitution Protection The full payload released after the trailer should remain the same authorized payload or remain within the authorized transformation envelope. A representative predicate is: H(Canon(Msgreleased )) = DMsg for exact-content release. Where edits are permitted, policy may require a new digest, revalidation, or renewed approval. A.12.36. E12.36 Attachment Substitution Protection If the trailer receipt was generated for attachment digest DAtt , a different attachment must not be silently substituted during full SEND. The full release authority may bind all relevant attachment digests. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND A.12.37. E12.37 Recipient Redirection Protection A trailer receipt from Recipient A must not authorize the final message to Recipient B unless redirection is expressly authorized. A representative requirement is: Recipient(R0send ) = Recipient(F inalSend). A.12.38. E12.38 Expiry and Stale Receipt A recipient may have changed devices, account state, membership, or key state after the trial. A stale receipt may therefore require a new trailer rather than authorizing delayed full disclosure. Das Expires 4 April 2027 [Page 255] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.12.39. E12.39 Revocation Between Trailer and Full SEND If the sender revokes the communication after receipt but before full release: Revoked(MsgF ) = T RU E ⇒ F ullSend = BLOCKED. A.12.40. E12.40 Destination-State Change Even with a valid receipt, continuation may be denied if destination state materially changes. Examples include: * recipient account disabled; * device key rotated; * tenant changed; * policy changed; * data-class rule changed; * or endpoint attestation no longer valid. A.12.41. E12.41 Crash After Trailer SEND The trailer may be delivered while the sender crashes before storing the receipt. The trailer should preferably use an idempotency identifier or unique nonce so the system can determine whether it was already received before retransmitting. A.12.42. E12.42 Duplicate Full-SEND Protection A valid trailer receipt should not cause duplicate full messages merely because the sender retries after a timeout. The full SEND may use a protected final-send identifier: IFsend = H(DA ∥ DMsg ∥ H(R0send ) ∥ NF ). The sink or destination may record the identifier atomically with the full effect where appropriate. A.12.43. E12.43 Indeterminate Full SEND If the system cannot determine whether the full payload was delivered, it enters an indeterminate state rather than assuming non- delivery. Reconciliation may use: Das Expires 4 April 2027 [Page 256] Internet-Draft Reality as a Cryptographic Dependency October 2026 * recipient receipt; Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND * server transaction identifier; * message ID; * object-store access state; * delivery log; * or destination query. A.12.44. E12.44 Negative Receipt The recipient may explicitly reject the trailer. A protected negative receipt may cause: * cancellation; * human review; * corrected recipient selection; * reduced content; * new session establishment; * or denial. Negative receipt does not authorize full SEND. A.12.45. E12.45 Privacy-Preserving Trailer The trailer may disclose very little information while still proving endpoint correctness. For example, it may contain only: * random challenge; * payload commitment; * encrypted manifest; * destination nonce; * or zero-knowledge proof request. This reduces the consequence of a mistaken Phase-0 delivery. Das Expires 4 April 2027 [Page 257] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.12.46. E12.46 Sensitive-Content Variation For highly sensitive content, the trailer may reveal no substantive content at all. The actual protected effect is then recipient/ session verification rather than partial semantic disclosure. A.12.47. E12.47 Low-Risk Message Variation For low-risk communications, protected policy may select E01 single- phase SEND rather than a trailer workflow. Thus the system need not impose trial latency on every communication. A.12.48. E12.48 Hardware-Enforced SEND A DPU, SmartNIC, secure NIC, modem security processor, secure element, or hardware gateway may retain the final payload key or network release authority. The agent can prepare the message but cannot cause full egress until hardware verifies the required receipt/approval state. A.12.49. E12.49 Software-Enforced SEND A privileged network proxy, message broker, OS service, kernel gate, API gateway, or credential broker may perform the same logical workflow in software. The ordinary agent process need not possess the effect-capable messaging credential. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND A.12.50. E12.50 Split Software/Hardware SEND Software may perform content classification, policy, and human interaction while hardware retains the final egress key or transmit capability. A bound software ADR and the recipient receipt may be required before hardware permits full transmission. A.12.51. E12.51 Telecom / Radio SEND Variation A message may traverse a cellular, radio, satellite, or other communications system. The initial transmission may be bounded by: * payload size; * time; * beam; * frequency; Das Expires 4 April 2027 [Page 258] Internet-Draft Reality as a Cryptographic Dependency October 2026 * recipient; * power; * or protocol state. Protected receiver confirmation may enable the broader transmission. A.12.52. E12.52 Machine-to-Machine SEND No human recipient is required. A machine endpoint, API, robot, vehicle, cloud service, or infrastructure controller may receive the bounded trailer and return protected machine evidence before the full command, file, configuration, or data object is released. A.12.53. E12.53 SEND Versus Payment Analogy The same staged-finality principle can apply to both communications and payments. For SEND: Bounded M essage Effect → Recipient Receipt → F ull Disclosure. For payment: Bounded F inancial Effect → Institution/Settlement Receipt → Broader Settlement. The underlying effect domains differ, but both preserve the distinction between authority to begin and authority to complete the consequence. A.12.54. E12.54 Anti-Bypass Requirement Where protected trailer-first SEND is mandatory, the system should account for equivalent fullsend paths such as: * direct SMTP/API credentials; * raw network socket; * alternate messaging account; * file-sharing link outside the broker; * direct object-store access grant; * hidden administrator route; * recovery credential; Das Expires 4 April 2027 [Page 259] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or another path capable of the same disclosure. Such paths may be disabled, mediated, credential-restricted, cryptographically locked, or brought under equivalent protected finality controls. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND A.12.55. E12.55 Completion Receipt After the final communication becomes effective, a completion receipt may bind: RFsend = P rotect(DA , DMsg , H(R0send ), RecipientID, F inalDeliveryState) . For multi-phase transfer, the receipt may bind the receipt chain or its aggregate commitment. A.12.56. E12.56 Required Invariants The frozen conceptual invariants of E12 are: 1. in trailer-first mode, a bounded real communication effect occurs on the actual intended effectuation path before broader/full communication effectuation; 2. protected return evidence is tied to the intended message context and recipient/destination as required; 3. the broader message, attachment, semantic content, decryption authority, or equivalent communication consequence remains unavailable until the required continuation conditions are satisfied; 4. human, automatic, hybrid, hardware-key-chain, and threshold continuation may each be used; 5. a valid trailer receipt does not authorize content, recipient, destination, or scope outside the previously authorized envelope; 6. crash, duplicate-send, stale-receipt, wrong-recipient, and indeterminate states are handled without assuming that absence of acknowledgement means absence of effect; and 7. equivalent full-SEND bypass paths are controlled where needed to preserve the staged communication dependency. FROZEN RELATIONSHIP BETWEEN E10, E11 AND E12 K0chain → R0 → K1chain → R1 → ⋯ → Knchain . The principal technical emphasis is protected hardware authority progression. Ri−1 → {σ1,i , ... , σn,i } → T hreshold Satisfaction → Cithr . The principal technical emphasis is distributed continuation authority. Tr0 → R0send → P rotected Continuation → MsgF . Das Expires 4 April 2027 [Page 260] Internet-Draft Reality as a Cryptographic Dependency October 2026 The principal technical emphasis is real recipient-path verification before broader communication effectuation. The embodiments may be combined. For example, an E12 trailer SEND may produce R0send , E11 may require threshold approval after that receipt, and E10 hardware may then derive or unseal the final SEND key. A composite relation is: Tr0 → R0send → T hreshold Authority E11 → Hardware Key Release E10 → F ull SEN D E12. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND APPENDIX I - NEW DEFINITIONS INTRODUCED BY E10-E12 ONLY I.1 Non- Repetition Rule Definitions already supplied in the Advanced Section 1 master definitions or E01-E09 workflow appendices are intentionally not repeated. The definitions below cover only new terms or materially specialized meanings introduced by E10-E12. I.2 Receipt-Conditioned Hardware Key Chain Receipt-Conditioned Hardware Key Chain means a hardware-rooted authority progression in which a later phase key, secret, key slot, command authenticator, unseal operation, latch state, or equivalent protected authority becomes available or valid only after required protected evidence from an earlier phase has been accepted. I.3 Hardware Root Authority Hardware Root Authority means a hardware- protected key, secret, state, trust anchor, sealed object, or equivalent protected source from which phase-specific authority can be derived, unsealed, validated, or activated. It is narrower here than the general hardware root-of-authority definition only in emphasizing its role in a receipt-conditioned chain. I.4 Receipt-Conditioned Derivation Receipt-Conditioned Derivation means deriving a later protected authority using an accepted receipt, receipt digest, receipt-chain commitment, or equivalent prior-effect evidence as an input or protected prerequisite. I.5 Receipt-Conditioned Unsealing Receipt-Conditioned Unsealing means making a pre-existing sealed or wrapped later-phase secret usable only after the required prior receipt and protected state have been accepted. I.6 Phase-Key Chain Phase-Key Chain means a sequence of phase- specific protected cryptographic authorities associated with successive effectuation phases. The term does not require every later key to be mathematically derived from the immediately prior key. Das Expires 4 April 2027 [Page 261] Internet-Draft Reality as a Cryptographic Dependency October 2026 I.7 Threshold Continuation Threshold Continuation means a continuation rule under which a required number, class, or combination of protected authority contributions from multiple participants must be satisfied before the next effectuation phase becomes available. I.8 Threshold Authority Share Threshold Authority Share means a participant-specific protected contribution used toward satisfying a threshold continuation condition. It may be a cryptographic secret share, signature share, ordinary signature, key-encryption contribution, hardware unlock contribution, approval artifact, or equivalent authority fragment. I.9 Authority Contribution Set Authority Contribution Set means the set of accepted participant contributions applicable to a particular act and phase for determining whether the continuation threshold has been satisfied. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND I.10 Role-Constrained Threshold Role-Constrained Threshold means a threshold rule that requires not only a number of positive contributions but also specified participant categories, such as at least one human authority and one hardware authority. I.11 Trailer Object Trailer Object means a bounded real communication object transmitted through the intended communication path before broader/full communication release. A Trailer Object may contain a challenge, manifest, commitment, bounded content, encrypted fragment, or other limited information and is not limited to audiovisual media terminology. I.12 Trailer-Then-Full Effectuation Trailer-Then-Full Effectuation means a communication workflow in which a real bounded Trailer Object is first delivered or processed and protected return evidence from that stage is required before a broader message, file, attachment, key, access capability, or semantic content becomes available. I.13 Semantic Release Semantic Release means making protected content intelligible, decryptable, usable, viewable, executable, or otherwise meaningfully available to the intended recipient, even where encrypted bytes may have been transported earlier. I.14 Ciphertext-First SEND Ciphertext-First SEND means a staged communication mode in which all or part of encrypted payload data may reach the destination before the destination possesses sufficient protected authority to obtain the complete plaintext or semantic content. Das Expires 4 April 2027 [Page 262] Internet-Draft Reality as a Cryptographic Dependency October 2026 I.15 Recipient-Path Verification Recipient-Path Verification means protected verification, using a real bounded communication effect and returned evidence, that an intended recipient account, endpoint, application, device, session, service, or equivalent destination path is operating within the required conditions before broader release. I.16 Full-SEND Identifier Full-SEND Identifier means an act-specific protected identifier or idempotency value associated with the final communication effect and used to detect or prevent unintended duplicate full transmission. APPENDIX J - NEW NOTATION INTRODUCED BY E10-E12 ONLY J.1 Non- Repetition Rule Notation already defined in the Advanced Section 1 master notation appendix or E01-E09 delta notation appendices is not repeated. The symbols below are new to E10-E12 or have a materially specialized local meaning. Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND J.2 E10 Notation * KRA - hardware Root Authority used locally in E10 as the protected source for phase authority. * Bi - illustrative bound act/context digest for phase i. * Kichain - phase-specific authority/key in the E10 receipt- conditioned hardware key chain. * Seali - sealed later-phase protected object or secret in the unsealing variation. * Wi - wrapped phase key/object stored before its protected release condition is satisfied. * Lchain i - protected latch associated specifically with the E10 hardware key chain. * qHW - protected hardware phase index/state for the E10 progression. * CumulativeReceipti - illustrative commitment to receipt history through phase i. chain * RF - final completion receipt binding the E10 key-chain progression. J.3 E11 Notation Das Expires 4 April 2027 [Page 263] Internet-Draft Reality as a Cryptographic Dependency October 2026 * U - eligible protected participant set for threshold continuation. * Uj - protected participant j. * ti - required continuation threshold for phase i; distinct from earlier timing notation Ti . * σj,i - authority share/contribution from participant Uj for phase i. * Σi - set of accepted authority contributions for phase i. * |Σi | - cardinality, i.e., number of accepted contributions in Σi . * Cithr - continuation authority resulting from threshold satisfaction for phase i. * Kithr - reconstructed or otherwise threshold-enabled phase key in the key-reconstruction variation. * Sigithr - threshold signature or equivalent combined signature evidence for phase i. * Ui+1 - updated eligible participant set for a later phase following a protected membership transition. thr * RF - final completion receipt binding threshold-policy evidence. * AuthorityCommitmenti - non-secret commitment to the accepted threshold evidence for phase i. J.4 E12 Notation * MsgF - full intended communication object in E12; used instead of the earlier locally overloaded symbol M . * Tr0 - bounded real Trailer Object used for the initial SEND demonstration. * DMsg - digest/commitment of the full intended communication object. * R0send - protected receipt for the initial E12 trailer SEND. * SendReceiptP ass0 - illustrative protected predicate indicating that the initial SEND receipt satisfies the required checks. Das Expires 4 April 2027 [Page 264] Internet-Draft Reality as a Cryptographic Dependency October 2026 * CTF - encrypted full payload ciphertext in the ciphertext-first variation. * KF - final payload decryption key or equivalent semantic-release authority in E12. * DAtt - digest of an attachment when attachment binding is required. * R - authorized recipient set in the multi-recipient SEND variation. * Rtrial - bounded trial-recipient subset. send * IF - protected idempotency identifier for the final SEND effect. send * RF - final SEND completion receipt. J.5 New Function / Predicate Labels The following word-like expressions are illustrative functional or predicate notation rather than required programming identifiers: MatchSink, NotConsumed, Enable, Release, Accept, Reconstruct_t, ThresholdSign_t, MatchMessage, MatchRecipient, MatchNonce, FullSend, Recipient, FinalSend, Canon, Wrap, and related labels introduced in E10-E12. J.6 Threshold Symbol Clarification The symbol ti in E11 denotes an authority threshold and should not be confused with prior symbols used for time, timestamp, or protected timing. The participant count n retains its ordinary Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND mathematical meaning as the size of the eligible participant set in the local threshold context. J.7 Local Interpretation Rule Where E10-E12 reuse a symbol already defined in earlier Advanced Section 1 materials, the prior meaning remains controlling unless the local subsection expressly assigns a narrower meaning. The equations are functional disclosure and may be realized through equivalent cryptographic objects, hardware state, protocol fields, policy engines, distributed signatures, message- broker state, or protected state machines. A.13. E13 — Receipt-Gated File Transfer and Progressive File Release Das Expires 4 April 2027 [Page 265] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.13.1. E13.1 Purpose E13 defines a file-transfer workflow in which a file, file set, object, archive, model artifact, executable image, media object, document, or other byte-addressable or object-addressable payload is not necessarily released as an immediately complete externally usable consequence. A protected system may first cause a bounded real transfer, bounded storage commit, bounded recipient-path verification, bounded decryption event, or other limited real file effect. Protected evidence from that event may then become a prerequisite for broader transfer or full semantic release. A representative relationship is: Candidate F ile T ransfer → P rotected F ile Descriptor → Bounded Real F ile Effect → F ile Effect Receipt → P rotected Receipt V erification → N ext F ile Authority → Broader/F ull F ile Effect. A.13.2. E13.2 File Candidate Act The Candidate Act may request one or more of: * sending a file; * copying a file; * uploading a file; * downloading a file; * publishing a file; * exporting a file; * replicating an object; * sharing an object-store reference; * decrypting a protected file; * promoting a staged object into a production namespace; * releasing a model checkpoint; * making an attachment visible to a recipient; Das Expires 4 April 2027 [Page 266] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or another file-related external consequence. The file operation is treated as an effect-capable act rather than merely as local computation. A.13.3. E13.3 Full File Object and Authorized Envelope Let the complete intended file object be denoted: Ffull . A protected digest or commitment may be: DF = H(CanonF ile(Ffull )) . The authorized envelope may additionally bind: * permitted recipient; * permitted destination; * permitted storage class; * permitted object path; * maximum file size; * file type or class; * confidentiality classification; * integrity requirement; * allowed expiry; * allowed geographic region; * allowed application or account; * allowed number of recipients; * and any transformation that is permitted before or during transfer. A.13.4. E13.4 File Manifest A protected File Transfer Manifest may describe the file without requiring the entire payload to be interpreted by the enforcement component. A manifest may include: Das Expires 4 April 2027 [Page 267] Internet-Draft Reality as a Cryptographic Dependency October 2026 * file digest; * file size; * object identifier; * MIME or media type; * chunk count; * per-chunk digests; * Merkle root; * encryption state; * key identifier; * destination; * recipient; * intended storage or application; * retention requirement; * and permitted transformation rules. Denote such a manifest locally by: MF . A.13.5. E13.5 Transfer Session Binding A protected transfer session may receive a session identifier: SIDF . The PED may bind SIDF to: DA , DF , MF , Recipient, Destination, Ep , Er . A file receipt generated for another session must not automatically authorize continuation of the present session. A.13.6. E13.6 Selection of File-Release Mode Protected policy may select among: Das Expires 4 April 2027 [Page 268] Internet-Draft Reality as a Cryptographic Dependency October 2026 Mode A - Single-Phase File Release The full file is released according to E01. Mode B - Trial Segment Then Full File A bounded real segment or verification object is first transferred. Mode C - Progressive Chunk Release Multiple chunks are released sequentially or in protected groups. Mode D - Ciphertext First, Key Later The ciphertext may arrive before semantic access authority is released. Mode E - Staged Storage Then Promotion The file is first committed into a restricted namespace and later promoted to a broader or externally usable namespace. Mode F - Multi-Recipient Progressive Release A protected subset of recipients receives the file before broader distribution. A.13.7. E13.7 Bounded File Effect The bounded first file effect may comprise one or more of: * a small content segment; * a non-sensitive trailer object; * an encrypted prefix; * a manifest; * a cryptographic challenge object; * one block or range of the file; * one object in a multi-object set; * a low-information representation; * a staging write; * an object-store commit that is not yet externally readable; * or another real but limited file consequence. The first-stage object need not reveal sensitive semantic content. Das Expires 4 April 2027 [Page 269] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.13.8. E13.8 Segment Representation Where the file is segmented: n Ffull = ⋃ Fj . j=0 The union notation is illustrative; implementation may use ordered concatenation, object lists, ranges, erasure-coded fragments, sparse regions, or other file structures. A per-segment digest may be: dj = H(Fj ). A.13.9. E13.9 Trial Segment Descriptor The protected system may identify an initial real transfer segment: trial F0 . Its descriptor may bind: * DF ; * SIDF ; * byte range or object identity; * d0 ; * recipient; * destination; * encryption state; * expected storage or processing result; * nonce; * expiry; * and permitted next action. A.13.10. E13.10 Initial File Authority The PED may create a phase-specific authority: C0file whose valid scope is limited to the initial file effect. A representative scope relation is: Scope(C0file ) ⊂ Scope(Ffull ). Das Expires 4 April 2027 [Page 270] Internet-Draft Reality as a Cryptographic Dependency October 2026 The authority may be represented by a scoped credential, signed transfer descriptor, key share, storage capability, network capability, destination-side permission, or equivalent protected condition. A.13.11. E13.11 Real Transfer Through Intended Path The bounded object is transmitted through the actual effect-capable route intended for later file transfer. Examples include: * actual HTTPS upload endpoint; * real object-storage API; * real file-sharing service; * enterprise content gateway; * secure messaging attachment path; * secure copy service; * remote storage controller; * destination application; * device-to-device transfer path; * or another real file effect path. A local preview does not satisfy this embodiment merely because it resembles the target file. A.13.12. E13.12 Destination-Side Processing The destination may perform one or more protected operations on the bounded file effect: * receive bytes; * validate session identifier; * validate file or segment digest; * persist the segment; * commit metadata; * decrypt a bounded portion; Das Expires 4 April 2027 [Page 271] Internet-Draft Reality as a Cryptographic Dependency October 2026 * confirm available storage; * verify permitted file type; * perform malware or content policy evaluation where applicable; * bind the received object to the intended recipient/account; * or enter a protected staging state. A.13.13. E13.13 File Effect Receipt The destination, storage system, gateway, sink, or other protected observer may generate: R0file . The receipt may bind: * Candidate Act digest; * DF ; * SIDF ; * segment digest; * destination identity; * recipient identity; * storage commit identifier; * protected status; * nonce; * timestamp or protected time; * object version; * encryption state; * and applicable policy epoch. A.13.14. E13.14 Receipt Semantics R0file may establish a technical fact narrower than “the recipient understood the file.” For example, it may establish that: Das Expires 4 April 2027 [Page 272] Internet-Draft Reality as a Cryptographic Dependency October 2026 * the intended endpoint received the segment; * the endpoint validated its digest; * the destination durably stored it; * the intended secure application accepted it; * the recipient device proved possession of required decryption capability; * the staging namespace accepted it; * or another defined file effect occurred. A.13.15. E13.15 File Receipt Verification A protected verifier may evaluate: V alid(R0file ), M atchF ile(R0file , DF ), M atchSession(R0file , SIDF ), M atchRecipient(R0file ), M atchSegment(R0file , d0 ), and: F resh(R0file ). If any mandatory predicate fails, broader file release remains blocked. A.13.16. E13.16 Human Continuation Variation After the real bounded file effect, an independent protected human approval interface may display: * file identity; * file digest or recognizable descriptor; * recipient; * destination; * trial result; * storage or endpoint confirmation; Das Expires 4 April 2027 [Page 273] Internet-Draft Reality as a Cryptographic Dependency October 2026 * remaining file scope; * and any relevant confidentiality warning. A protected approval artifact may then authorize the next file stage. A.13.17. E13.17 Automatic Continuation Variation Protected policy may automatically release additional file scope where: F ileReceiptP ass0 ∧ P olicyP ass ∧ RiskAcceptable = T RU E. A.13.18. E13.18 Hybrid Continuation Variation A later stage may require both a valid file receipt and human or multi-party authority. For example: F ileReceiptP ass0 ∧ HumanApproval ∧ AutoP olicyP ass ⇒ Enable(F ileStage1 ). A.13.19. E13.19 Progressive Chunk Transfer The file may be released through multiple actual transfer phases: file F0 → R 0 → F1 → R1file → ⋯ → Fn . Each required receipt may authorize only the next chunk or bounded group of chunks. A.13.20. E13.20 Chunk-Chain Binding For phase j, the protected file receipt may include the preceding receipt digest: Rjfile = P rotect(DF , SIDF , dj , H(Rj−1 file ), Statusj ) . This may create a tamper-evident transfer chain. A.13.21. E13.21 Merkle-Root Variation For large files, the manifest may include a root: RootF = M erkleRoot(d0 , d1 , ... , dn ). A destination may verify individual chunks against RootF without requiring the receipt to restate the entire file. A.13.22. E13.22 Ciphertext-First File Transfer The complete encrypted file may be transferred before full semantic access is permitted. Let: Das Expires 4 April 2027 [Page 274] Internet-Draft Reality as a Cryptographic Dependency October 2026 CTF = EncK file (Ffull ). data file The destination may store CTF but remain unable to obtain the plaintext because Kdata or a required key share remains withheld. A.13.23. E13.23 Semantic File Release Following protected receipt verification, the PED or protected hardware may release, reconstruct, or authorize use of: file Kdata . Thus: T ransported Bytes ⇏ Semantic F ile Release. This variation can reduce latency while preserving staged semantic effectuation. A.13.24. E13.24 Partial Decryption Variation The system may permit decryption of only a bounded initial region or object class. After valid protected evidence, additional decryption ranges or keys become available. This may be implemented with: * independently encrypted chunks; * hierarchical keys; * envelope encryption; * per-object keys; * threshold key shares; * hardware key slots; * or equivalent protected key segmentation. A.13.25. E13.25 Staged Storage Promotion A file may first be placed in: * quarantine storage; * private staging bucket; * non-indexed namespace; * read-restricted object class; * temporary protected filesystem; Das Expires 4 April 2027 [Page 275] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or another bounded storage state. A protected persistence receipt may then enable promotion into: * production storage; * public or shared namespace; * searchable index; * downloadable state; * model registry; * deployment repository; * or another broader state. A.13.26. E13.26 Promotion Receipt A storage engine may generate: RFpromote binding the transition from staging to broader storage visibility. Where the promotion itself is consequential, it may be treated as a separate Candidate Act and separately gated. A.13.27. E13.27 File-Type Transformation Variation The destination may transform the file before broader release, for example: * decompress; * transcode; * convert format; * strip metadata; * sanitize active content; * generate a derivative; * or re-encrypt. The manifest may bind permitted transformation rules so that an unauthorized transformation cannot silently substitute for the authorized file effect. Das Expires 4 April 2027 [Page 276] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.13.28. E13.28 Deduplication Variation A destination may determine that the file or chunk already exists. A valid receipt may therefore indicate: * new bytes stored; * existing object matched; * content-addressed object reused; * or no additional physical write required. The receipt should still bind the current transfer session and authorized file identity where the later continuation depends upon it. A.13.29. E13.29 Sparse or Range-Based File Variation A file need not be divided into contiguous chunks. The protected system may authorize ranges: Bj = [aj , bj ] and verify receipt evidence for those ranges before additional ranges become available. A.13.30. E13.30 Resume After Interruption If transfer stops after chunk j, protected state may record the highest verified phase: qF = j. A resumed transfer may continue only from a state consistent with: * verified receipts; * manifest; * current policy; * current recipient; * current destination; * and non-revoked authority. Das Expires 4 April 2027 [Page 277] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.13.31. E13.31 Crash After Chunk Commit If a destination commits Fj but crashes before returning the receipt, the sender should not blindly resend if duplicate write or duplicate processing would be unsafe. A protected idempotency value may be: Ijfile = H(DF ∥ SIDF ∥ j ∥ Nj ). file The destination may store Ij atomically with the corresponding file state. A.13.32. E13.32 Receipt Loss file If Rj is lost after generation, the destination may retransmit the same authenticated receipt without re-performing the file effect. A replayed receipt must not authorize multiple independent releases of the same next phase. A.13.33. E13.33 Wrong-Recipient Protection A receipt for Recipient A must not enable file release to Recipient B unless a protected policy expressly authorizes that substitution. A representative invariant is: Recipient(Rjfile ) = Recipientauthorized . A.13.34. E13.34 Wrong-File Protection A receipt for a different file or different file version must not authorize the current transfer. Therefore: Digest(Rjfile ) = DF or an equivalent protected binding is required. A.13.35. E13.35 Versioned Object Variation Where a file changes after trial effectuation, the system may compute a new file digest and require a new trial or protected revalidation. A prior receipt for version v should not automatically authorize version v + 1. A.13.36. E13.36 Multi-File Bundle Variation A Candidate Act may concern a bundle: (1) (k) F = {F , ... , F }. The system may: Das Expires 4 April 2027 [Page 278] Internet-Draft Reality as a Cryptographic Dependency October 2026 * trial one representative object; * require one receipt per object; * use a manifest root over the bundle; * or progressively release subsets. The required strategy is protected policy. A.13.37. E13.37 Multi-Recipient File Release For authorized recipient set: RF , a bounded subset may receive the real file effect first: Rtrial F ⊂ RF . Protected receipts from the bounded subset may permit broader distribution where policy allows. A.13.38. E13.38 Recipient-Specific Keys Each recipient may receive a distinct wrapped content key. A valid receipt from one recipient need not authorize release of another recipient’s key unless the policy explicitly couples those releases. A.13.39. E13.39 Network and Storage Split Enforcement The network path may permit transport only after a network-specific capability while the destination storage system separately controls commit or visibility. Thus a file may cross multiple finality boundaries: Sender → N etwork Sink → Storage Sink → Semantic Release Sink. Each boundary may generate or verify protected evidence. A.13.40. E13.40 Hardware Enforcement Variation Hardware enforcement may use: * secure element; * TPM; * TEE; * HSM; Das Expires 4 April 2027 [Page 279] Internet-Draft Reality as a Cryptographic Dependency October 2026 * DPU; * SmartNIC; * storage controller; * SSD controller; * secure DMA engine; * hardware-backed filesystem key; * or another protected hardware component. file The hardware may hold Kdata or a key-encryption key and release it only after required file receipts are accepted. A.13.41. E13.41 Software Enforcement Variation Software enforcement may use: * kernel mediation; * proxy; * API gateway; * storage gateway; * content service; * secure daemon; * object-store policy engine; * message broker; * or another protected software boundary. A.13.42. E13.42 Alternative-Path Closure The protected file workflow may close or equivalently mediate: * direct object-store credentials; * alternate upload APIs; * raw filesystem paths; Das Expires 4 April 2027 [Page 280] Internet-Draft Reality as a Cryptographic Dependency October 2026 * sync clients; * backup paths; * administrative copy operations; * temporary links; * alternate network routes; * and other paths capable of producing the same broader file effect. A.13.43. E13.43 Indeterminate File State If the system cannot establish whether a chunk, object, or promotion occurred: F ileState = IN DET ERM IN AT E. Broader release may remain blocked while the PED reconciles storage state, object version, transfer identifier, or destination receipt. A.13.44. E13.44 Completion Receipt After full file effectuation, a completion receipt may bind: RFfile = P rotect(DA , DF , SIDF , RootF , F inalF ileState) . For progressive transfer, it may additionally bind the receipt-chain root or final verified phase. A.13.45. E13.45 Required Invariants The frozen conceptual invariants of E13 are: 1. a file-related Candidate Act is distinguishable from completed file effectuation; 2. where staged mode is selected, at least one real bounded file effect occurs before broader/full file consequence; 3. protected evidence from the bounded effect is validated before required later file authority is enabled; 4. file, version, session, recipient, destination, and scope bindings prevent receipt substitution where those attributes are material; 5. ciphertext transport may be separated from semantic file release; 6. crash, resume, deduplication, duplicate-transfer, and indeterminate states do not automatically create authority for broader release; and 7. equivalent alternate file-effect paths are controlled where needed to preserve the staged dependency. FULL / PROGRESSIVE PAYMENT Das Expires 4 April 2027 [Page 281] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.14. E14 — Payment Demonstration and Receipt-Gated Full / Progressive Payment A.14.1. E14.1 Purpose E14 defines a protected payment workflow in which an intended transfer of value need not become fully effective immediately after an initial computational or policy decision. Where supported by the applicable financial infrastructure, the system may first perform a bounded real financial operation such as: * a small verification transfer; * a reversible or cancellable authorization; * a bounded account hold; * a reservation; * a partial payment; * a protected beneficiary-verification transaction; * a zero-value or nominal-value authorization supported by the rail; * or another real payment-rail state transition. Protected evidence from that operation may then be required before broader or full payment authority is released. A.14.2. E14.2 Rail-Dependent Operation Not every payment rail supports every type of bounded operation. Accordingly, E14 does not require a rail to support a feature that it does not implement. The PED may select a technically supported staged operation from the capabilities of the actual rail, institution, wallet, ledger, card network, bank-transfer system, payment processor, settlement system, or other payment environment. A.14.3. E14.3 Full Intended Payment Let the total intended authorized value be: VF . The payment Candidate Act may additionally bind: * beneficiary; * beneficiary account or address; Das Expires 4 April 2027 [Page 282] Internet-Draft Reality as a Cryptographic Dependency October 2026 * amount; * currency or asset; * source account; * payment rail; * purpose or reference where relevant; * fee policy; * execution window; * jurisdiction; * and maximum authorized consequence. A.14.4. E14.4 Payment Descriptor A protected Payment Effect Descriptor may be represented locally by: Dpay . It may bind: DA , VF , Beneficiary, Asset, Rail, Ep , Er , Expiry. A.14.5. E14.5 Payment Identifier A protected payment session or transaction family identifier may be: P IDF . Individual rail transaction identifiers may remain distinct. A.14.6. E14.6 Selection of Payment Mode Protected policy may select: Mode A - Single-Phase Full Payment The complete authorized amount proceeds under E01. Mode B - Bounded Demonstration Then Full Payment A real bounded payment operation is completed or accepted first. Mode C - Progressive Partial Payments The total amount is released through multiple value phases. Das Expires 4 April 2027 [Page 283] Internet-Draft Reality as a Cryptographic Dependency October 2026 Mode D - Authorization / Reservation Then Capture or Settlement Where the rail supports separate authorization and later capture or settlement, the earlier state is used as the bounded real effect. Mode E - Escrow / Conditional Holding The flow transitions into E15. A.14.7. E14.7 Bounded Trial Value Where a bounded monetary amount is appropriate, define: 0 < v0 < V F . v0 is not a universal required amount. It is selected according to policy, minimum rail constraints, fees, reversibility, user preference, legal constraints, and risk. A.14.8. E14.8 Non-Monetary Trial State A bounded financial effect need not transfer a positive monetary amount. Where supported by the payment rail, the first real effect may be: * zero-value account verification; * account-name or beneficiary confirmation; * authorization without capture; * token validation; * reversible reservation; * wallet challenge; * settlement-account handshake; * or another protected rail-native state transition. A.14.9. E14.9 Trial Payment Authority The PED may issue: C0pay whose scope is restricted to the selected bounded payment operation. A representative requirement is: Scope(C0pay ) ⊂ Scope(VF ). Das Expires 4 April 2027 [Page 284] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.14.10. E14.10 Binding to Beneficiary and Asset The initial authority and subsequent receipts may bind: * beneficiary identity; * beneficiary account/address; * currency; * token or asset identifier; * source account; * and rail. A successful bounded payment to one beneficiary must not automatically authorize the full payment to another beneficiary. A.14.11. E14.11 Real Payment-Rail Effect The bounded operation is submitted to the actual payment infrastructure. This may cause: * authorization state; * funds reservation; * beneficiary verification; * partial transfer; * settlement entry; * ledger state transition; * escrow placement; * or another real financial-system effect. A.14.12. E14.12 Payment Effect Observer Protected payment evidence may originate from: * bank; * payment processor; * card acquirer or issuer system; Das Expires 4 April 2027 [Page 285] Internet-Draft Reality as a Cryptographic Dependency October 2026 * wallet provider; * settlement network; * ledger node; * transaction HSM; * receiving institution; * beneficiary-controlled endpoint where appropriate; * or another protected financial component. A.14.13. E14.13 Payment Effect Receipt The bounded financial effect may produce: R0pay . The receipt may bind: * P IDF ; * Candidate Act digest; * beneficiary; * amount or authorization scope; * asset or currency; * rail; * transaction reference; * acceptance state; * settlement or reservation state; * nonce; * protected time; * and current policy state. A.14.14. E14.14 Payment Receipt Status A payment receipt may represent states such as: Das Expires 4 April 2027 [Page 286] Internet-Draft Reality as a Cryptographic Dependency October 2026 * AUTHORIZED; * RESERVED; * ACCEPTED; * PARTIALLY_SETTLED; * SETTLED; * DECLINED; * REVERSED; * EXPIRED; * CANCELLED; * REJECTED; * or INDETERMINATE. The meaning is rail-specific and should be interpreted according to the underlying system rather than assumed to imply final settlement. A.14.15. E14.15 Receipt Verification A protected verifier may evaluate: V alid(R0pay ), M atchP ayment(R0pay , P IDF ), M atchBeneficiary(R0pay ), M atchAsset(R0pay ), W ithinT rialScope(R0pay ), and: F resh(R0pay ). A.14.16. E14.16 Human Approval After Demonstration After the bounded financial effect, a protected approval interface may show: * beneficiary; * verified account or destination information; Das Expires 4 April 2027 [Page 287] Internet-Draft Reality as a Cryptographic Dependency October 2026 * bounded trial result; * amount already affected; * remaining intended amount; * fees; * currency/asset; * current payment state; * and whether continuation is reversible or final. A fresh human approval may then authorize broader payment authority. A.14.17. E14.17 Automatic Continuation Protected automatic continuation may occur where: P aymentReceiptP ass0 ∧P olicyP ass∧RiskAcceptable∧W ithinAuthorizedEnvelope = T RU E. A.14.18. E14.18 Hybrid Continuation The system may require both protected automatic validation and human approval before a larger payment phase. Threshold authority under E11 may also be used, for example requiring enterprise approval plus hardware authority. A.14.19. E14.19 Full Payment Continuation Authority After accepted trial evidence, the system may generate or release: C1pay for the remaining or full authorized payment consequence. C1pay may be: * transaction signature; * HSM signing authorization; * API capability; * payment token; * capture authorization; * settlement instruction; Das Expires 4 April 2027 [Page 288] Internet-Draft Reality as a Cryptographic Dependency October 2026 * key share; * hardware-unsealed signing key slot; * or another protected payment enablement condition. A.14.20. E14.20 Receipt-Conditioned Payment Key Using E10, a hardware component may derive: K1pay = KDF (KRA , DA , H(R0pay ), P IDF , 1) . The protected property is receipt-conditioned authority, not the specific KDF syntax. A.14.21. E14.21 Progressive Payment Phases Where the total authorized value can be safely divided: n V F = ∑ vi . i=0 A staged sequence may be: v0 → R0pay → v1 → R1pay → ⋯ → vn . A.14.22. E14.22 Cumulative Payment Bound Let cumulative value after phase i be: i Vicum = ∑ vj . j=0 The PED may require: Vicum ≤ VF . Successful prior receipts cannot increase the maximum authorized payment. A.14.23. E14.23 Dynamic Phase Amount The next permitted value may be selected according to protected state: vi+1 = fpay (Ripay , Riski , P olicyi , Approvali , Remainingi ). The function may reduce or terminate the next phase if conditions deteriorate. Das Expires 4 April 2027 [Page 289] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.14.24. E14.24 Authorization-Then-Capture Variation Where a payment system supports authorization and capture as separate states: 1. Phase 0 obtains a real bounded or full-value authorization without final capture; 2. the system verifies the authorization result and beneficiary/payment context; 3. protected continuation authority is then required for capture; 4. capture or settlement occurs only after the continuation predicate succeeds. This variation is used only where the underlying rail implements such states. A.14.25. E14.25 Reservation / Hold Variation A payment system may first place a bounded reservation or hold. The hold receipt confirms that the actual financial rail accepted the reservation. Later protected authority may: * capture it; * increase it within the authorized envelope; * partially capture; * release it; * or expire it according to rail rules. A.14.26. E14.26 Small Verification Transfer Variation Where permitted, a small real transfer may verify the beneficiary path. A receiving institution or protected beneficiary endpoint may return evidence linked to the verification transfer. Only then may the larger payment be authorized. The system should account for the fact that a successful small transfer does not prove that a larger transfer will necessarily settle; it provides a verified prior-effect predicate, not a guarantee of future success. A.14.27. E14.27 Refund / Reversal Variation If a bounded trial value should not remain with the beneficiary, protected policy may authorize a refund or reversal where the rail supports it. The reversal is itself a consequential act and may be separately receipt-gated. Das Expires 4 April 2027 [Page 290] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.14.28. E14.28 Fee-Aware Staging The system may consider fees when choosing staged payments. A technically valid implementation may avoid economically irrational micro-phases where fixed fees would dominate. Protected policy may therefore choose authorization, reservation, or another rail-native bounded effect instead of repeated monetary transfers. A.14.29. E14.29 Currency and Asset Binding A receipt for one currency or token must not authorize payment in another unless the conversion is expressly included in the authorized envelope. The payment descriptor may bind: AssetID, CurrencyCode, or T okenID. A.14.30. E14.30 Foreign-Exchange Variation Where conversion is part of the intended payment, the protected workflow may separately bind: * source asset; * destination asset; * conversion provider; * maximum rate slippage; * fee ceiling; * and expiry. A trial result may verify destination path while a fresh continuation check verifies the current exchange state before full effectuation. A.14.31. E14.31 Recurring Payment Variation A recurring authorization may define a protected envelope for repeated payments. Each occurrence may still require: * current policy check; * beneficiary check; * period limit; * receipt state; Das Expires 4 April 2027 [Page 291] Internet-Draft Reality as a Cryptographic Dependency October 2026 * and optional staged verification. A prior successful occurrence does not automatically authorize unlimited future amounts. A.14.32. E14.32 Batch Payment Variation For beneficiary set: B = {B1 , ... , Bk }, protected policy may first execute a bounded subset: Btrial ⊂ B. Receipts from the subset may permit broader batch release, subject to per-beneficiary and aggregate limits. A.14.33. E14.33 Beneficiary Confirmation Variation The receiving side may return a protected acknowledgement proving control of an accountspecific challenge or transaction reference. This may strengthen destination binding before the remaining amount is released. A.14.34. E14.34 Payment Idempotency A phase may use: Iipay = H(P IDF ∥ i ∥ Beneficiary ∥ vi ∥ Ni ). The payment gateway or protected sink may record the identifier with the financial state to reduce unintended duplicate submissions. A.14.35. E14.35 Crash After Financial Effect If the payment rail accepts or settles a phase but the local system crashes before receiving confirmation, the PED enters an indeterminate state rather than assuming failure. The system may reconcile using: * rail transaction reference; * bank query; * wallet query; * ledger state; * HSM transaction journal; * beneficiary receipt; * or another authoritative financial record. Das Expires 4 April 2027 [Page 292] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.14.36. E14.36 Indeterminate Payment State A representative state is: P aymentState = IN DET ERM IN AT E. While unresolved, the remaining payment authority may stay blocked. A.14.37. E14.37 Proven-Effected Reconciliation If reconciliation proves the phase occurred, the system may recover or reconstruct the missing receipt without repeating the payment. A.14.38. E14.38 Proven-Not-Effected Reconciliation If reconciliation proves the financial effect did not occur, a fresh protected retry may be authorized according to current policy. A.14.39. E14.39 Settlement-Finality Awareness The workflow may distinguish among: * request accepted; * payment authorized; * funds reserved; * payment posted; * clearing completed; * settlement completed; * irreversible or rail-defined final state. A receipt should not be interpreted as stronger finality than the underlying rail actually provides. A.14.40. E14.40 Payment State Machine A protected local representation may use rail-specific states, for example: P ROP OSED → T RIAL_AU T HORIZED → T RIAL_EF F ECT ED → RECEIP T _V ERIF IED → CON T IN U AT ION _AU T HORIZED → F U LL_P AY M EN T _EF F ECT ED. Failure, reversal, cancellation, and indeterminate branches may exist at each appropriate state. Das Expires 4 April 2027 [Page 293] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.14.41. E14.41 Hardware Payment Enforcement An HSM, secure element, TEE, payment security module, hardware wallet, secure processor, or other protected component may retain signing or release authority. The proposing AI or application may receive no reusable unrestricted payment secret. A.14.42. E14.42 Software Payment Enforcement A protected payment broker, transaction service, payment gateway, bank-side policy service, or enterprise payment controller may enforce phase state and receipt gating. A.14.43. E14.43 Split Software / Hardware Payment Enforcement Software may evaluate policy while hardware retains signing material. A representative sequence is: Software P olicy P ass → Hardware T rial Signature → R0pay → Hardware F ull Signature Enable. A.14.44. E14.44 Threshold Payment Continuation Using E11, a larger payment may require m-of-n protected authorities after the trial receipt. Examples include: * two enterprise officers; * human + hardware; * enterprise + bank; * device owner + financial controller; * or another policy-defined combination. A.14.45. E14.45 Revocation Between Payment Phases A valid trial does not guarantee later payment. If: Revoked(A) = T RU E, unused payment continuation authority becomes invalid. A.14.46. E14.46 Risk Change Between Payment Phases If protected risk increases after the bounded operation, the PED may: * reduce next value; Das Expires 4 April 2027 [Page 294] Internet-Draft Reality as a Cryptographic Dependency October 2026 * require human review; * require threshold approval; * change rail; * place funds into E15 conditional holding; * or deny continuation. A.14.47. E14.47 Alternative-Path Closure Where staged payment is mandatory, equivalent payment paths may be controlled, including: * direct bank API; * payment processor credential; * raw signing key; * wallet export key; * administrative payment path; * alternate service account; * fallback rail; * or another path capable of completing the same protected payment consequence. A.14.48. E14.48 Full Payment Receipt After completion, a receipt may bind: RFpay = P rotect(DA , P IDF , Beneficiary, VF , AssetID, F inalP aymentState) . For progressive payment, the receipt may additionally bind the phase-receipt chain or aggregate commitment. A.14.49. E14.49 Required Invariants The frozen conceptual invariants of E14 are: 1. staged payment uses only bounded operations actually supported by the underlying rail; 2. the initial financial effect is real and narrower than the complete authorized consequence in amount, state, reversibility, scope, or another material dimension; 3. protected evidence of the bounded financial effect is verified before required later authority is Das Expires 4 April 2027 [Page 295] Internet-Draft Reality as a Cryptographic Dependency October 2026 enabled; 4. beneficiary, asset, rail, amount, session, and transaction bindings prevent receipt substitution where material; 5. a successful bounded payment does not itself expand the maximum authorized amount; 6. indeterminate payment states are reconciled rather than blindly retried where duplicate effect is unsafe; 7. the workflow distinguishes authorization, reservation, posting, clearing, settlement, and other rail-specific states where relevant; and 8. alternate full-payment paths are controlled where needed to preserve receipt-gated continuation. GATED RELEASE A.15. E15 — Escrow / Conditional Settlement and Receipt-Gated Release A.15.1. E15.1 Purpose E15 defines a protected conditional-holding workflow in which value, an asset, data-release authority, cryptographic key material, transaction authority, or another protected item is first placed into a technically controlled intermediate state and is not released to its ultimate destination until defined protected conditions are satisfied. The term escrow is used functionally in this technical disclosure. It does not by itself assert that a particular implementation constitutes legal, regulated, fiduciary, or licensed escrow under any jurisdiction. A regulated deployment may require an appropriately authorized provider and applicable legal controls. A.15.2. E15.2 Core Relationship A representative sequence is: Candidate Settlement → P rotected Holding Authority → Real Conditional Holding State → Holding Receipt → Condition Evidence → P rotected Release Decision → F ull/P artial Release → Settlement Receipt. A.15.3. E15.3 Conditional Holding Object Let the item subject to conditional release be denoted: Xhold . It may represent: * funds; Das Expires 4 April 2027 [Page 296] Internet-Draft Reality as a Cryptographic Dependency October 2026 * tokenized value; * a payment authorization; * a key; * a signed transaction; * data-access authority; * credential authority; * file decryption authority; * software deployment authority; * or another protected consequence. A.15.4. E15.4 Escrow / Holding Identifier A protected holding instance may be assigned: EscID. The identifier may bind the Candidate Act, parties, asset, maximum amount, expiry, release conditions, and protected policy. A.15.5. E15.5 Holding Descriptor A Conditional Holding Descriptor may be represented locally by: Desc . It may identify: * depositor/source; * intended beneficiary; * held value or asset; * release conditions; * refund conditions; * deadline; * dispute state; * governing technical policy; * required authorities; Das Expires 4 April 2027 [Page 297] Internet-Draft Reality as a Cryptographic Dependency October 2026 * receipt requirements; * and permissible partial releases. A.15.6. E15.6 Release Condition Set Let the protected release-condition set be: Γ = {γ1 , γ2 , ... , γm }. Each γj may represent a protected predicate such as: * beneficiary verified; * bounded trial payment confirmed; * delivery event confirmed; * destination device attested; * human approval received; * automatic policy passed; * threshold authority satisfied; * protected time reached; * no revocation present; * required external evidence accepted; * or another defined condition. A.15.7. E15.7 Condition Semantics The PED should not assume that a textual claim that a condition occurred is sufficient. Where a condition is required to be machine- verifiable, the system obtains evidence from an authorized protected source or applies another trusted verification mechanism. A.15.8. E15.8 Real Holding Effect The first stage causes a real state transition into conditional holding. Examples include: * funds reserved in a protected account or ledger state; * tokenized value locked by a protected transaction condition; Das Expires 4 April 2027 [Page 298] Internet-Draft Reality as a Cryptographic Dependency October 2026 * payment authority placed into a non-settleable pending state; * decryption key wrapped under a protected release condition; * signing key share sealed in an HSM; * data object encrypted and held without release key; * deployment command staged but non-executable; * or another technically enforceable intermediate state. A.15.9. E15.9 Holding Receipt The system may obtain: esc Rhold confirming that the item entered the defined protected holding state. The receipt may bind: * EscID; * source; * beneficiary; * asset; * amount or scope; * holding component; * expiry; * condition-set digest; * and protected state. A.15.10. E15.10 No Release Before Holding Confirmation Where policy requires actual holding before later actions proceed: esc V alid(Rhold ) = F ALSE ⇒ ReleaseDisabled. This prevents a system from acting as if funds or authority were secured when the real holding step did not occur. Das Expires 4 April 2027 [Page 299] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.15.11. E15.11 Release Condition Evaluation A release predicate may be represented as: ReleaseReady = ⋀ V alid(γj ). γj ∈Γreq Different conditions may be required for different release phases. A.15.12. E15.12 Human Approval Condition A protected human approval may itself be one release condition: γH = HumanApprovalV alid. The human may review the holding receipt and subsequent condition evidence before approving release. A.15.13. E15.13 Automatic Condition A protected policy engine may automatically satisfy a condition when machine-verifiable evidence meets policy. For example: γA = ReceiptV alid ∧ P olicyCurrent ∧ RiskAcceptable. A.15.14. E15.14 Hybrid Release Condition A release may require both human and automatic conditions: ReleaseReady = γH ∧ γA ∧ γR , where γR may represent required receipt evidence. A.15.15. E15.15 Threshold Release Condition Using E11, release may require: |Σesc | ≥ tesc and optionally required authority classes. A.15.16. E15.16 Conditional Payment Escrow Variation A payment workflow may first transfer or reserve value into the holding state rather than directly to the final beneficiary. After the required evidence is accepted, the protected system authorizes release from holding to the beneficiary. A.15.17. E15.17 Trial-Payment Then Holding Variation E14 and E15 may combine: T rial P ayment → R0pay → Conditional Holding → Rhold esc → Release Conditions → F inal Settlement. Das Expires 4 April 2027 [Page 300] Internet-Draft Reality as a Cryptographic Dependency October 2026 This can separately verify beneficiary path and secure the larger value before final release. A.15.18. E15.18 Holding Then Trial Release Variation A held amount may itself be released in a bounded first tranche. Let total held value be: Vhold . A bounded release may satisfy: 0 < u0 < Vhold . The beneficiary or settlement system may return a receipt before the remaining amount becomes eligible for release. A.15.19. E15.19 Progressive Tranche Release A held value may be released through phases: n Vhold = ∑ ui . i=0 Each release may require evidence from the preceding phase: ui → Riesc → ui+1 . A.15.20. E15.20 Cumulative Release Bound Let cumulative release be: i Uicum = ∑ uj . j=0 The protected system requires: Uicum ≤ Vhold . A.15.21. E15.21 Release Authority Object After conditions are satisfied, the PED may generate: esc Crel representing bounded release authority. It may be a transaction signature, HSM operation, key share, smart-contract invocation authority, bank API capability, decryption key, or equivalent protected enablement. A.15.22. E15.22 Receipt-Conditioned Release Key A hardware-rooted implementation may derive: Das Expires 4 April 2027 [Page 301] Internet-Draft Reality as a Cryptographic Dependency October 2026 esc esc Krel = KDF (KRA , EscID, H(Rhold ), H(EvidenceΓ )) . EvidenceΓ denotes a protected commitment to the accepted condition evidence. A.15.23. E15.23 Destination Binding The holding descriptor may bind the final beneficiary or destination. A release receipt or condition from another beneficiary must not silently redirect the held item. A.15.24. E15.24 Asset Binding The release authority may be bound to the held asset or item. A condition satisfied for one asset must not automatically authorize release of a different asset. A.15.25. E15.25 Expiry and Timeout The holding state may define: texpiry esc . If release conditions are not satisfied by expiry, protected policy may: * refund; * return authority to source; * extend the hold through fresh approval; * enter dispute state; * or terminate according to the authorized workflow. A.15.26. E15.26 Refund Path A refund or return is itself a consequential act. The system may therefore generate a protected refund authority: esc Crefund . It may require its own approval, destination binding, and receipt. A.15.27. E15.27 Refund Receipt After return to the source, the system may obtain: esc Rrefund . Das Expires 4 April 2027 [Page 302] Internet-Draft Reality as a Cryptographic Dependency October 2026 This receipt may close the holding state without final beneficiary release. A.15.28. E15.28 Cancellation Before Release A protected authorized party may cancel the transaction before release where policy permits. Cancellation invalidates unused release authority and may trigger refund or continued hold depending on protected rules. A.15.29. E15.29 Revocation A revocation event may cause: ReleaseReady = F ALSE even if earlier release conditions were satisfied. This may require revalidation or refund according to policy. A.15.30. E15.30 Condition Change If a condition changes after it was previously satisfied, the PED may determine whether the evidence remains valid. For volatile conditions, freshness may be mandatory at the moment of release. A.15.31. E15.31 Delivery-Evidence Variation For a transaction involving delivery of a digital or physical item, an authorized source may provide protected delivery evidence. The system must define what that evidence proves. For example, it may prove: * a digital object was delivered to a specified endpoint; * a device entered a required state; * a carrier-generated event occurred; * or another machine-verifiable event. The architecture does not assume that a generic “delivered” label proves legal acceptance or semantic satisfaction. A.15.32. E15.32 Data-for-Payment Atomicity-Like Variation A protected system may coordinate: * data/key release on one side; and Das Expires 4 April 2027 [Page 303] Internet-Draft Reality as a Cryptographic Dependency October 2026 * payment/settlement release on the other. The system may use conditional holding so that neither complete data access nor complete payment release occurs until the defined reciprocal evidence exists. This is not required to be perfectly atomic across all infrastructures; the workflow may instead expose explicit intermediate and indeterminate states. A.15.33. E15.33 Key Escrow / Key-Holding Variation Instead of holding money, protected hardware may hold a decryption or signing key. The key remains sealed until release conditions are satisfied. The same receipt-gated logic therefore applies to semantic data release or command authority. A.15.34. E15.34 Command Escrow Variation A consequential command may be pre-staged but non-executable. Protected holding may comprise: * encrypted command; * disabled queue entry; * hardware-locked command buffer; * pending transaction; * or another non-effective state. Condition satisfaction then enables execution. A.15.35. E15.35 Storage-Promotion Holding Variation A file may be placed into protected staging storage and treated as a held object. Release means promotion into externally accessible storage after required receipt and policy conditions. This combines E13 and E15. A.15.36. E15.36 Smart-Contract / Ledger Variation Where a programmable ledger supports conditional holding, the holding and release logic may be implemented partly by on-ledger state. Protected off-ledger components may still verify: * user authority; * external evidence; * destination binding; Das Expires 4 April 2027 [Page 304] Internet-Draft Reality as a Cryptographic Dependency October 2026 * policy; * and hardware state. No particular ledger or consensus protocol is required. A.15.37. E15.37 Bank / Custodial Service Variation A bank, payment institution, wallet, custodian, or other authorized service may implement the holding state using its native reserved, pending, blocked, segregated, or equivalent transaction state. The technical architecture may rely on service-provided protected transaction evidence rather than assume direct control of funds. A.15.38. E15.38 Multi-Party Holding Control Different parties may hold different authority shares. Examples include: * source + beneficiary; * source + enterprise controller; * human + hardware; * bank + enterprise; * buyer + seller + neutral protected authority; * or another policy-defined set. Threshold continuation may determine release. A.15.39. E15.39 Dispute State A protected state may be: EscrowState = DISP U T ED. While disputed, ordinary release and refund paths may remain blocked until a specifically authorized resolution path succeeds. A.15.40. E15.40 Dispute Resolution Authority A dispute-resolution action may require a distinct authority class and may not be satisfiable by the proposing agent itself. The resulting decision may authorize: * full release; * partial release; Das Expires 4 April 2027 [Page 305] Internet-Draft Reality as a Cryptographic Dependency October 2026 * refund; * split settlement; * continued hold; * or termination. A.15.41. E15.41 Split Settlement A held value may be divided among multiple destinations according to protected resolution. Let: {u(1) , u(2) , ... , u(k) } be authorized release amounts such that: k ∑ u(r) ≤ Vhold . r=1 A.15.42. E15.42 Hardware Enforcement An HSM, secure element, TEE, hardware wallet, secure processor, transaction module, or other protected hardware may retain the release key or transaction-signing authority. A validated holding receipt and condition evidence may be required before hardware enables release. A.15.43. E15.43 Software Enforcement A protected transaction service, bank-side policy service, payment broker, escrow service, secure daemon, database transaction manager, or policy engine may maintain the holding state. A.15.44. E15.44 Split Software / Hardware Enforcement Software may evaluate complex conditions while hardware enforces final release authority. For example: Software Conditions P ass → Hardware V erifies Evidence Commitment → Hardware Release Authority. A.15.45. E15.45 Condition-Evidence Commitment A compact protected commitment may be: DΓ = H(CanonEvidence(γ1 , ... , γm )) . Hardware need not necessarily process every high-level condition itself if it can verify a protected decision and the required commitment under the selected trust model. Das Expires 4 April 2027 [Page 306] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.15.46. E15.46 Crash After Release If release occurs but the local orchestrator crashes before receiving the settlement receipt, the system enters an indeterminate state. It should reconcile the authoritative holding/settlement state before issuing another release. A.15.47. E15.47 Release Idempotency A release phase may use: Iiesc = H(EscID ∥ i ∥ Destination ∥ ui ∥ Ni ). The release sink may record this identifier atomically with the effect where technically supported. A.15.48. E15.48 Indeterminate Holding State If the system cannot establish whether value entered holding, it must not assume the value is secured. Similarly, if it cannot establish whether release occurred, it must not assume release failed. Explicit states may include: * HOLDING_INDETERMINATE; * RELEASE_INDETERMINATE; * REFUND_INDETERMINATE. A.15.49. E15.49 Reconciliation The PED may query: * holding service; * bank; * ledger; * HSM journal; * destination; * transaction database; * object store; Das Expires 4 April 2027 [Page 307] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or other authoritative state source. The result may be PROVEN_HELD, PROVEN_NOT_HELD, PROVEN_RELEASED, PROVEN_NOT_RELEASED or STILL_INDETERMINATE. A.15.50. E15.50 Alternative-Path Closure Where conditional holding is mandatory, alternate paths capable of bypassing the hold or release conditions may be disabled or equivalently mediated. Examples include: * direct payment credential; * alternate bank API; * direct decryption key; * raw signing key; * administrative release endpoint; * bypass settlement route; * direct object-store publication; * or other equivalent effect path. A.15.51. E15.51 Final Settlement Receipt After authorized final release, a receipt may be: RFesc = P rotect(DA , EscID, H(Rhold esc ), DΓ , F inalSettlementState) . A.15.52. E15.52 Refund Completion Receipt If the workflow ends by return rather than beneficiary settlement, a separate terminal receipt may bind the refund path. Thus the system can distinguish: * COMPLETED_RELEASE; * COMPLETED_REFUND; * CANCELLED; * DISPUTED; * or another terminal protected state. Das Expires 4 April 2027 [Page 308] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.15.53. E15.53 Privacy-Preserving Condition Evidence A release condition need not expose unnecessary underlying data. The system may accept protected evidence proving a predicate while withholding raw information, using commitments, selective disclosure, zero-knowledge proof, or another privacypreserving technique where appropriate. A.15.54. E15.54 Multi-Jurisdiction / Policy Variation A holding/release workflow may bind jurisdiction-specific policy, but the technical architecture does not itself determine legal compliance. Fresh legal or policy state may be a protected release predicate where required by deployment. A.15.55. E15.55 Required Invariants The frozen conceptual invariants of E15 are: 1. the held item or authority enters a real technically controlled intermediate state before conditional release where holding is required; 2. the system obtains protected evidence that the holding state exists; 3. later release, partial release, refund, or other disposition is conditioned on protected policy and defined evidence; 4. human, automatic, hybrid, threshold, software, hardware, and split enforcement may each be used; 5. successful condition evidence cannot enlarge the release beyond the authorized held envelope; 6. expiry, revocation, dispute, crash, refund, and indeterminate states are represented explicitly rather than silently treated as successful release; 7. the term escrow is functional and does not by itself assert a particular legal status; and 8. alternate paths capable of bypassing the required conditional-holding dependency are controlled where needed to preserve the architecture. FROZEN RELATIONSHIP BETWEEN E13, E14 AND E15 Bounded F ile Effect → R0file → Broader F ile T ransfer/Release. The principal technical emphasis is receipt-gated progression from a real bounded file effect to broader transport, storage visibility, or semantic access. Bounded F inancial Effect → R0pay → Broader/F ull P ayment Authority. The principal technical emphasis is rail-supported bounded financial effect before broader value transfer. esc Holding Effect → Rhold → Condition Evidence → P rotected Release. The principal technical emphasis is real protected intermediate holding followed by evidence-conditioned release, partial release, Das Expires 4 April 2027 [Page 309] Internet-Draft Reality as a Cryptographic Dependency October 2026 refund, or other authorized disposition. The embodiments may be composed. A file may be staged under E13, payment may be verified under E14, and the remaining payment or key may be held under E15 until both sides’ required evidence is satisfied. A representative composite relation is: F ile T rial E13 → R0file P ayment T rial E14 → R0pay {R0file , R0pay } → Conditional Holding/Release E15. APPENDIX K - NEW DEFINITIONS INTRODUCED BY E13- E15 ONLY K.1 Non- Repetition Rule Definitions already supplied in the Advanced Section 1 master definitions or E01-E12 workflow appendices are intentionally not repeated. The definitions below cover only new terms or materially specialized meanings introduced by E13-E15. K.2 File Transfer Manifest File Transfer Manifest means a protected machine-processable description of a file or file set that may bind file digest, size, chunk structure, recipients, destination, encryption state, object identity, allowed transformation, and other transfer-relevant attributes without requiring every enforcement component to interpret the complete file payload. K.3 File Effect Receipt File Effect Receipt means protected evidence that a defined real file-related effect occurred, such as receipt, storage commit, bounded decryption, staging, destination acceptance, or promotion state. It does not necessarily prove human reading or semantic acceptance of the file. K.4 Semantic File Release Semantic File Release means making file content intelligible, decryptable, executable, viewable, importable, or otherwise meaningfully usable, even where ciphertext bytes or a non-usable object may have been transported earlier. K.5 Staged Storage Promotion Staged Storage Promotion means transitioning a file or object from a restricted, quarantined, temporary, non-indexed, non-public, or otherwise bounded storage state into a broader durable, discoverable, production, shared, or externally accessible state after protected conditions are satisfied. K.6 Payment Effect Receipt Payment Effect Receipt means protected evidence from an authorized financial component that a defined rail- specific financial state occurred, such as authorization, reservation, acceptance, partial settlement, settlement, reversal, cancellation, or another defined state. Its meaning is limited to the status actually represented by the underlying rail. Das Expires 4 April 2027 [Page 310] Internet-Draft Reality as a Cryptographic Dependency October 2026 K.7 Bounded Financial Effect Bounded Financial Effect means a real but intentionally limited financial-system state transition performed before a broader payment consequence, including where supported a small transfer, reversible authorization, reservation, hold, beneficiary verification operation, partial settlement, or other limited rail-native effect. K.8 Payment Demonstration Payment Demonstration means use of a Bounded Financial Effect and protected return evidence to establish a verified prior payment-path or financial-state predicate before broader/full payment authority is released. It does not imply that a small successful payment guarantees later settlement. K.9 Conditional Holding State Conditional Holding State means a technically controlled intermediate state in which value, an asset, cryptographic material, transaction authority, data-release authority, command authority, or another consequential item is withheld from final release pending protected conditions. K.10 Functional Escrow Functional Escrow means a Conditional Holding State used as an intermediate technical control. The term does not by itself represent or guarantee legal, fiduciary, regulated, licensed, or jurisdiction-specific escrow status. K.11 Conditional Holding Descriptor Conditional Holding Descriptor means a protected representation of a holding arrangement that may bind source, beneficiary, asset, amount or scope, release conditions, refund conditions, expiry, dispute state, authorities, and applicable receipt requirements. K.12 Release Condition Set Release Condition Set means the protected set of predicates whose required members must be satisfied before a specified release phase becomes eligible. K.13 Release Authority Object Release Authority Object means a bounded protected capability, signature authority, key share, transaction authorization, decryption authority, hardware enable value, or other technical condition enabling release from a Conditional Holding State. K.14 Progressive Tranche Release Progressive Tranche Release means releasing held value or authority in multiple bounded phases, with one or more later tranches depending on protected evidence from preceding releases or other protected conditions. Das Expires 4 April 2027 [Page 311] Internet-Draft Reality as a Cryptographic Dependency October 2026 K.15 Refund Authority Refund Authority means protected authority to return a held item, value, or equivalent consequence to an authorized source or alternative destination according to the applicable conditionalholding policy. K.16 Dispute State Dispute State means a protected holding state in which ordinary release and/or refund paths are suspended pending a specifically authorized resolution path. K.17 Condition-Evidence Commitment Condition-Evidence Commitment means a cryptographic or otherwise tamper-evident commitment to the evidence or verified results used to determine satisfaction of one or more release conditions. APPENDIX L - NEW NOTATION INTRODUCED BY E13-E15 ONLY L.1 Non- Repetition Rule Notation already defined in the Advanced Section 1 master notation appendix or E01-E12 delta notation appendices is not repeated. Symbols below are new to E13-E15 or have a materially specialized local meaning. L.2 E13 Notation * Ffull - complete intended file object or protected file payload. * DF - protected digest/commitment of the full file object. * MF - File Transfer Manifest. * SIDF - protected file-transfer session identifier. * Fj - file segment, chunk, range object, or protected subdivision indexed by j. * dj - digest of file segment Fj . trial * F0 - bounded initial real file effect used as the trial segment/ object. file * Cj - file-specific phase authority for stage j. file * Rj - File Effect Receipt for file phase j. * RootF - Merkle or equivalent aggregate integrity root for file segments. Das Expires 4 April 2027 [Page 312] Internet-Draft Reality as a Cryptographic Dependency October 2026 * CTF - ciphertext representation of the complete file in the ciphertext-first variation; the same symbol family appeared in E12 for message ciphertext but is specialized here to the file object. file * Kdata - protected file data-decryption key or equivalent semantic- release authority. promote * RF - receipt evidencing protected storage promotion. * Bj = [aj , bj ] - locally defined byte/range interval for range- based transfer. * qF - highest protected verified file-transfer phase/index in a resumable transfer. file * Ij - file-phase idempotency identifier. * F - protected set/bundle of files in a multi-file Candidate Act. * RF - authorized recipient set for file release. * Rtrial F - trial-recipient subset for file release. file * RF - final file completion receipt. L.3 E14 Notation * VF - total intended authorized payment value in E14. * Dpay - protected Payment Effect Descriptor. * P IDF - protected identifier for the payment transaction family/ session. * vi - bounded payment value associated with payment phase i. pay * Ci - payment-specific continuation authority for phase i. pay * Ri - protected Payment Effect Receipt for phase i. pay * K1 - illustrative receipt-conditioned payment authority/key for a later payment phase. * Vicum - cumulative value effected through payment phase i. * fpay (⋅) - illustrative protected function selecting a next payment phase amount. Das Expires 4 April 2027 [Page 313] Internet-Draft Reality as a Cryptographic Dependency October 2026 * AssetID - protected identifier for the currency, token, security, balance class, or other transferred asset. pay * Ii - phase-specific payment idempotency identifier. pay * RF - final payment completion receipt. * B - beneficiary set in the E14 batch-payment context. This local use of B is distinct from E13 byte-range notation Bj . * Btrial - bounded trial subset of beneficiaries in batch payment. L.4 E15 Notation * Xhold - item, value, authority, key, asset, or other protected consequence placed into conditional holding. * EscID - protected identifier for the conditional-holding instance. * Desc - Conditional Holding Descriptor. * Γ - Release Condition Set. * γj - individual protected release condition/predicate. * Γreq - subset of release conditions required for a particular release decision. * γH - locally defined protected human-approval condition. * γA - locally defined automatic protected-policy condition. * γR - locally defined required receipt-evidence condition. esc * Rhold - protected receipt proving the defined conditional-holding state. * Σesc - accepted authority-contribution set used for E15 threshold release. * tesc - threshold required for the E15 release context; distinct from timestamp notation. * Vhold - total value or quantitatively measurable scope held for later release. * ui - bounded release tranche for phase i. Das Expires 4 April 2027 [Page 314] Internet-Draft Reality as a Cryptographic Dependency October 2026 * Riesc - protected receipt for release tranche i. * Uicum - cumulative amount/scope released through tranche i. esc * Crel - Release Authority Object for conditional settlement. esc * Krel - illustrative protected release key/authority in a hardware- rooted variation. * EvidenceΓ - protected evidence or commitment representing satisfaction of required release conditions. expiry * tesc - expiry time associated with the holding state; locally a time value, not an authority threshold. esc * Crefund - protected Refund Authority. esc * Rrefund - protected refund completion receipt. * DΓ - Condition-Evidence Commitment. * Iiesc - release-phase idempotency identifier. esc * RF - final conditional-settlement receipt. L.5 New Function / Predicate Labels The following word-like expressions are illustrative functional or predicate notation rather than required programming identifiers: CanonFile, MatchFile, MatchSession, MatchSegment, FileReceiptPass, MatchPayment, MatchBeneficiary, MatchAsset, WithinTrialScope, PaymentReceipt- Pass, WithinAuthorizedEnvelope, CanonEvidence, ReleaseReady, Valid, FinalFileState, Final- PaymentState, FinalSettlementState, and related labels introduced in E13-E15. L.6 Local Symbol Collision Clarifications * CTF was used in E12 for a full communication ciphertext and is used in E13 specifically for full file ciphertext. The local section controls. * B in E14 denotes a beneficiary set, while Bj in E13 denotes a file byte/range interval. These are intentionally local uses and should not be conflated. expiry * tesc in E15 is an authority threshold, whereas tesc is a time/ expiry value. Das Expires 4 April 2027 [Page 315] Internet-Draft Reality as a Cryptographic Dependency October 2026 * VF denotes payment value in E14; it is not the same as earlier generic effect magnitude symbols. L.7 Local Interpretation Rule Where E13-E15 reuse a symbol already defined in earlier Advanced Section 1 materials, the earlier meaning remains controlling unless the local subsection expressly provides a specialized meaning. All equations are functional disclosure and may be realized through equivalent cryptographic objects, transaction states, hardware state, protocol fields, storage states, financial- rail states, distributed signatures, or protected state machines. A.16. E16 — Receipt-Gated Database Commit, Provisional Persistence, and Promotion A.16.1. E16.1 Purpose E16 applies staged effectuation to database, persistent-state, record-management, object-state, index-state, replicated-state, and transaction-commit operations. The central technical distinction is that a proposed database mutation need not proceed directly from authorization to fully visible, globally replicated, or irreversible production state. Instead, the system may first cause a bounded real persistent state transition in a protected provisional location, obtain machine-verifiable evidence of the resulting state, and only then authorize promotion, expansion, replication, visibility, or completion. A representative causal chain is: Candidate Mutation → Protected Validation → Bounded Persistent Commit → Commit Evidence → Receipt Validation → P The first commit is not merely a simulation. It changes real persistent state, but the resulting consequence is bounded by namespace, row set, replica set, visibility, tenant, index, transaction scope, version, or another protected dimension. A.16.2. E16.2 Technical problem addressed An autonomous or AI-mediated system may generate a syntactically valid database mutation that is nevertheless unsafe to expose immediately because: * the wrong row, tenant, namespace, or object may have been selected; * a stale record version may be used; * a schema change may not behave as expected; Das Expires 4 April 2027 [Page 316] Internet-Draft Reality as a Cryptographic Dependency October 2026 * a trigger, stored procedure, replication rule, or index update may create secondary effects; * the mutation may be valid locally but inconsistent with distributed state; * the mutation may succeed at one node but fail at another; * the mutation may be irreversible after broad replication or publication; * authorization may be valid but current policy may change before commit; * the proposed operation may be influenced by tainted or uncertain input; * or the effect may need confirmation before external visibility is permitted. E16 separates permission to create bounded persistent state from permission to promote that state into the complete authorized database consequence. A.16.3. E16.3 Functional components An implementation may include one or more of the following logical functions: 1. Mutation Source - AI agent, application, database client, orchestration system, administrator tool, workflow engine, or another source that proposes a state change. 2. Mutation Representation Component - forms a deterministic representation of the proposed mutation and its intended effect. 3. PED - evaluates protected authority, policy, scope, current state, taint/provenance, and phase requirements. 4. Provisional Persistence Target - receives the bounded real mutation. 5. Database Finality Sink - controls whether a mutation becomes persistent, visible, replicated, indexed, externally queryable, or otherwise effective. 6. Persistence Observer - measures the resulting database state. 7. Receipt Generator - generates protected evidence of the bounded commit. 8. Promotion Gate - controls promotion from provisional state to broader production state. 9. Completion Observer - confirms the final promoted consequence. One physical database engine may implement several of these functions. Alternatively, they may be distributed across database proxy, transaction coordinator, storage layer, HSM, cloud control plane, application service, or hardware controller. A.16.4. E16.4 Proposed database mutation Let the proposed database mutation be denoted locally by: Das Expires 4 April 2027 [Page 317] Internet-Draft Reality as a Cryptographic Dependency October 2026 W The mutation may comprise, for example: * INSERT; * UPDATE; * DELETE; * MERGE; * schema alteration; * index operation; * object-store metadata change; * vector-state update; * graph mutation; * key-value update; * ledger-state change; * access-control modification; * replication instruction; * stored-procedure execution; * or a compound transaction. A deterministic representation may be formed and bound to the existing Candidate Act digest or to a mutationspecific digest. For example: DW = H(Canon(W )) where the canonical representation may additionally include target database, tenant, table or collection, row/object identifiers, predicates, expected previous version, proposed values, transaction class, and permitted consequence. Das Expires 4 April 2027 [Page 318] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.16.5. E16.5 Baseline-state binding Before issuing the bounded mutation, the PED or database sink may capture a protected representation of relevant pre-effect state. Let: Vb denote an expected baseline version, generation, commit sequence, row version, object generation, consensus index, or equivalent protected state reference. The bounded mutation may be permitted only if current state matches the authorized baseline or satisfies another accepted concurrency predicate: BaselineV alid(W ) = 1 This prevents an approval generated for one database state from being silently applied to a materially different state. A.16.6. E16.6 Selection of bounded persistence mode The PED may determine whether the mutation may proceed directly under E01 or whether E16 staged persistence is required. E16 may be selected based upon: * destructive character; * number of affected records; * database sensitivity; * privilege level; * downstream trigger behavior; * replication breadth; * user or tenant impact; * uncertainty of generated query semantics; * rollback cost; * external visibility; * regulatory or enterprise policy; * model provenance or taint; Das Expires 4 April 2027 [Page 319] Internet-Draft Reality as a Cryptographic Dependency October 2026 * database consistency risk; * or another protected predicate. A.16.7. E16.7 Provisional commit target The initial real effect may be directed to a bounded persistence target such as: * shadow row; * provisional transaction record; * staging table; * versioned object; * branch or snapshot; * temporary namespace; * canary partition; * isolated tenant; * limited replica; * non-public index; * unpublished vector namespace; * protected write-ahead structure; * quarantine database; * or another real persistent target. The provisional target must be sufficiently real that the system can test or observe the actual persistence path, constraints, serialization, triggers, schema behavior, storage behavior, and/or downstream processing relevant to the intended full mutation. A.16.8. E16.8 Bounded mutation descriptor The protected descriptor for the first persistent phase may bind: * Candidate Act digest; * DW ; Das Expires 4 April 2027 [Page 320] Internet-Draft Reality as a Cryptographic Dependency October 2026 * baseline state Vb ; * allowed table, collection, object, graph, vector namespace, or database; * permitted rows or object identifiers; * permitted fields; * permitted value ranges; * transaction class; * maximum affected row count; * provisional namespace; * expected constraints; * expected trigger class; * expected receipt issuer; * durability level; * replication limit; * visibility limit; * expiration; * nonce; * policy epoch; * revocation epoch; * and permitted promotion class. A.16.9. E16.9 Approval before provisional commit The bounded commit may be: * automatically approved by protected policy; * explicitly approved by a human; * allowed within a pre-authorized database envelope; Das Expires 4 April 2027 [Page 321] Internet-Draft Reality as a Cryptographic Dependency October 2026 * approved by both automatic and human authority; * or subject to threshold/multi-party approval. A human approval may show the exact bounded mutation, affected objects, previous values, proposed values, and intended later production consequence. A.16.10. E16.10 Phase-0 database authority The PED forms authority restricted to the provisional effect. The authority may permit, for example: * write to staging but not production; * write one row but not the table; * create an unpublished object version; * commit to one replica but not the replication group; * build a non-public index; * append a provisional event but not publish it; * or write a vector entry to an isolated namespace. The same authority must not permit direct promotion unless policy expressly allows it. A.16.11. E16.11 Real provisional persistence The Database Finality Sink verifies the authority and performs the bounded mutation. The provisional effect is real because persistent database or storage state changes. For example: W0 ∶ V b → V t where Vt denotes a resulting trial/provisional persistent version. The transition may be durable according to the chosen persistence guarantee, including local durable storage, replicated durability, consensus commit, append-only log, or another database-specific guarantee. A.16.12. E16.12 Persistence observation The Persistence Observer may confirm one or more of: * row/object content; Das Expires 4 April 2027 [Page 322] Internet-Draft Reality as a Cryptographic Dependency October 2026 * version number; * commit sequence; * transaction identifier; * write-ahead log position; * replication acknowledgement; * index state; * constraint satisfaction; * trigger output; * storage durability; * schema compatibility; * object checksum; * vector consistency; * graph consistency; * or another protected state property. The observation may compare expected and actual results. A.16.13. E16.13 Database Effect Confirmation Receipt The bounded commit produces an ECR containing or binding the resulting database evidence. The ECR may include: * Candidate Act digest; * DW ; * baseline version Vb ; * provisional version Vt ; * transaction ID; * target namespace; * affected object identifiers; Das Expires 4 April 2027 [Page 323] Internet-Draft Reality as a Cryptographic Dependency October 2026 * row count; * observed values or protected digests thereof; * constraint result; * trigger result; * durability evidence; * replica acknowledgements; * database sink identity; * nonce; * time; * policy epoch; * and status. Raw database values need not be exposed if hashes, commitments, selective disclosure, or protected attestations are sufficient. A.16.14. E16.14 Receipt validation The PED or protected verifier may require: V alid(R0 ) ∧ M atch(R0 , DW ) ∧ BaselineM atch(R0 , Vb ) ∧ Durable(R0 ) ∧ W ithinScope(R0 ) before production promotion is considered. Where replication or quorum is required, additional receipt predicates may be applied. A.16.15. E16.15 Human review after provisional persistence A human may review the actual bounded database result before promotion. The protected UI may display: * intended mutation; * prior value/state; * resulting provisional value/state; * number of affected rows; * constraint results; Das Expires 4 April 2027 [Page 324] Internet-Draft Reality as a Cryptographic Dependency October 2026 * destination database; * proposed production consequence; * and receipt status. The human approval may bind directly to the ECR and production promotion descriptor. A.16.16. E16.16 Automatic promotion decision Automatic policy may permit promotion where the receipt proves the bounded commit behaved as expected. For example: P romoteAllowed = V alidReceipt ∧ ConstraintP ass ∧ P olicyCurrent ∧ RevocationClear ∧ RiskAcceptable The proposing AI does not self-certify these protected predicates. A.16.17. E16.17 Promotion authority After receipt validation and any required approval, the PED generates, derives, unseals, or activates authority permitting production promotion. The promotion authority may be implemented as: * transaction token; * signed commit instruction; * database role capability; * protected stored procedure invocation; * missing key material; * HSM-backed signature; * write-enablement state; * protected replication instruction; * or equivalent bounded enablement. A.16.18. E16.18 Promotion to production Promotion may comprise one or more of: * copying or merging provisional state into production; * switching a version pointer; Das Expires 4 April 2027 [Page 325] Internet-Draft Reality as a Cryptographic Dependency October 2026 * changing namespace visibility; * enabling index visibility; * committing the transaction’s final branch; * publishing an event; * replicating the state more broadly; * releasing a decryption or access key; * changing an object from quarantined to active; * or another state transition that makes the consequence complete. Promotion itself is a protected effectuation step and may be verified by a Finality Sink. A.16.19. E16.19 Multi-phase database progression The database consequence may be progressively broadened. Example: 1 row → 10 rows → 1 partition → all authorized partitions or: 1 replica → regional replicas → global replicas or: hidden version → internal visibility → tenant visibility → public/ production visibility Each phase may generate its own ECR before broader promotion. A.16.20. E16.20 Atomic promotion variation Where possible, receipt validation, receipt consumption, and promotion authorization may be committed atomically within protected transaction state. A representative invariant is: P romoted(W ) ⇒ V alidRequiredReceipts(W ) and, for single-use receipts: P romoted(W ) ⇒ Consumed(R0 ) = T RU E Das Expires 4 April 2027 [Page 326] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.16.21. E16.21 Optimistic concurrency variation If current database state no longer matches the authorized baseline: Vcurrent ≠ Vb the system may deny, hold, recompute, or seek fresh approval rather than automatically apply the prior mutation. A.16.22. E16.22 Pessimistic/locked variation A protected lock, lease, reservation, or transaction fence may preserve a state envelope between trial and promotion. The lock may be scoped and time-limited to avoid indefinite resource capture. A.16.23. E16.23 Trigger-aware variation The bounded commit may test not only the direct write but also database-triggered side effects. Promotion may remain blocked until protected evidence confirms required trigger behavior. If a trigger produces an unexpected external effect, the system may enter HOLD or INDETERMINATE rather than treating the base write as successful. A.16.24. E16.24 Replication-aware variation A database write may be locally durable but not yet sufficiently replicated. The PED may require: AckCount ≥ q for a protected quorum threshold q before promotion or external visibility. The quorum can be implementation-specific and need not correspond to a particular consensus algorithm. A.16.25. E16.25 Database schema migration variation A schema migration may first be applied to: * shadow schema; * one replica; * one partition; * one tenant; Das Expires 4 April 2027 [Page 327] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or one bounded dataset. Protected evidence may measure migration success, query compatibility, index state, and data integrity before broader migration authority is released. A.16.26. E16.26 Vector database / AI memory variation An AI agent may propose writing persistent memory, embeddings, retrieval data, or learned state. The first write may enter an isolated vector namespace or provisional memory store. Receipt evidence may confirm: * object identity; * embedding/model version; * tenant scope; * provenance binding; * index insertion; * and visibility state. Only then may the entry be promoted into shared or durable retrieval state. A.16.27. E16.27 Delete / destructive mutation variation For destructive operations, the first stage may move data into protected tombstone, quarantine, recycle, or reversible state rather than immediately causing irreversible deletion. A verified receipt may then enable final deletion, cryptographic erasure, or broader removal. A.16.28. E16.28 Database hardware-rooted variation Protected authority may be enforced by: * HSM-backed database signing keys; * secure storage controller; * encrypted database keys; * TEE-protected transaction service; * trusted storage firmware; * DPU/SmartNIC controlling storage/network path; Das Expires 4 April 2027 [Page 328] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or another protected component. The application may be unable to produce the production mutation without cryptographic material held by the protected component. A.16.29. E16.29 Crash before provisional commit If the system crashes before the bounded commit becomes durable, protected recovery may establish that no real effect occurred and permit a fresh authorized attempt. A.16.30. E16.30 Crash after provisional commit but before receipt delivery The provisional commit may be identified by an idempotency identifier and durable transaction record. After recovery, the system queries the database sink rather than blindly repeating the mutation. If the prior bounded commit is proven: State = P ROV EN _EF F ECT ED then the receipt may be reconstructed or retransmitted without duplicating the mutation. A.16.31. E16.31 Indeterminate database state If the system cannot prove whether the bounded or promoted commit occurred: State = IN DET ERM IN AT E broader effect remains blocked until reconciliation. Reconciliation may use commit IDs, WAL position, consensus index, object version, database audit state, replicated state, storage controller state, or equivalent evidence. A.16.32. E16.32 Rollback and compensating transaction If the bounded state is unacceptable, it may be: * deleted; * rolled back; * quarantined; * left invisible; * reverted to prior version; Das Expires 4 April 2027 [Page 329] Internet-Draft Reality as a Cryptographic Dependency October 2026 * compensated by another transaction; * or otherwise remediated. The rollback/compensation itself may be a protected Candidate Act with its own receipt. A.16.33. E16.33 Anti-bypass closure Equivalent production mutation paths may include: * direct database credentials; * administrator consoles; * replication channels; * bulk loaders; * backup/restore tooling; * maintenance interfaces; * privileged stored procedures; * alternate APIs; * direct storage access; * migration tools; * or service-account credentials. Where these paths can create the same material consequence, they may be disabled, narrowed, mediated, or subjected to equivalent finality controls. A.16.34. E16.34 SEND analogue A message draft may first be written to a protected outbox/staging record, and only after the record and destination binding are verified does a protected promotion operation place it into the actual send queue. This demonstrates that the database-promotion concept can protect communication state as well as ordinary database records. A.16.35. E16.35 Payment analogue A payment instruction may first become a provisional transaction record or reservation state. Receipt-confirmed validation of that state can then enable actual settlement or irreversible posting. Das Expires 4 April 2027 [Page 330] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.16.36. E16.36 Required invariants 1. The provisional persistence step is a real state change, not merely a simulation. 2. The bounded state is narrower than the complete production consequence in at least one relevant dimension. 3. Protected evidence is obtained from the actual persistence path or an authoritative observer. 4. Production promotion depends on accepted protected evidence and any required approval. 5. Promotion cannot exceed the originally authorized mutation envelope. 6. Stale baseline state, invalid receipts, revocation, or indeterminate state can prevent promotion. 7. Replay of a prior receipt does not independently authorize duplicate production effects. 8. Equivalent direct production paths are controlled where needed to preserve non- bypassability. SIVE INFRASTRUCTURE ROLLOUT A.17. E17 — Receipt-Gated Cloud Deployment and Progressive Infrastructure Rollout A.17.1. E17.1 Purpose E17 applies receipt-gated staged effectuation to software deployment, infrastructure configuration, service rollout, container activation, virtual-machine deployment, serverless release, edge deployment, and cloud/cluster control. The architecture distinguishes authority to deploy or expose a bounded real target set from authority to expand the deployment to the complete authorized target set. A representative chain is: Deployment Proposal → Artifact/Config Binding → Protected Trial Deployment → Measured Real Operation → Deployment A.17.2. E17.2 Deployment target model Let the complete authorized target population be represented by: Tmax A trial or intermediate target set is: Ti ⊆ Tmax The sets may represent: * containers; * VMs; Das Expires 4 April 2027 [Page 331] Internet-Draft Reality as a Cryptographic Dependency October 2026 * physical nodes; * availability zones; * regions; * tenants; * users; * edge devices; * functions; * service instances; * API versions; * Kubernetes workloads; * network slices; * or another deployable population. A.17.3. E17.3 Deployment descriptor A protected deployment descriptor may bind: * software artifact digest; * container image digest; * binary digest; * infrastructure-as-code digest; * configuration digest; * environment variables or protected digest thereof; * target set; * network policy; * credentials/capabilities; * service identity; Das Expires 4 April 2027 [Page 332] Internet-Draft Reality as a Cryptographic Dependency October 2026 * dependency versions; * permitted ingress/egress; * maximum rollout scope; * health predicates; * rollback artifact; * receipt requirements; * policy and revocation epochs; * phase identifier; * expiration; * and Finality Sink identity. The descriptor may be signed, MACed, committed, or otherwise protected. A.17.4. E17.4 Artifact integrity binding Let the deployable artifact or artifact bundle be: B and its protected digest: DB = H(B) A phase authority for deployment may be bound to DB so that a valid authorization for one build cannot be silently substituted for another build. Where configuration materially affects behavior, configuration may be included in the bound digest or separately authenticated. A.17.5. E17.5 Initial trial target selection A Phase-0 target may be selected as: * one container; * one VM; * one host; * one pod; Das Expires 4 April 2027 [Page 333] Internet-Draft Reality as a Cryptographic Dependency October 2026 * one availability zone; * one tenant; * one edge node; * one canary cohort; * one internal user group; * or another bounded target. The trial target may be chosen deterministically, randomly under protected policy, by risk classification, by geography, by tenant class, or by human selection. A.17.6. E17.6 Protected approval before trial deployment Trial deployment may proceed under: * automatic protected policy; * human approval; * hybrid approval; * threshold approval; * or a previously approved deployment envelope. The proposing agent itself does not create protected deployment authority merely by requesting deployment. A.17.7. E17.7 Trial deployment authority The PED issues authority that is restricted to T0 , the selected trial set. The authority may be enforced through: * orchestrator capability; * signed deployment manifest; * cloud control-plane credential; * short-lived service token; * image-pull authorization; * network exposure permit; Das Expires 4 April 2027 [Page 334] Internet-Draft Reality as a Cryptographic Dependency October 2026 * cluster admission policy; * HSM-backed release signature; * or equivalent protected state. A.17.8. E17.8 Real trial deployment The software is actually instantiated, activated, or exposed on the bounded real target set. This can include: * image pull; * process start; * VM boot; * container scheduling; * serverless function activation; * network route insertion; * service registration; * configuration application; * key release; * or controlled traffic exposure. The trial is therefore a real effectuation event. A.17.9. E17.9 Installation versus exposure separation A useful variation separates deployment from traffic exposure. The software artifact may be installed but not receive production traffic. After protected boot/attestation evidence succeeds, a later phase may authorize limited traffic exposure. A further receipt may then authorize broader traffic. This creates multiple effectuation boundaries: Install → Attest → Limited Exposure → Measure → Broad Exposure A.17.10. E17.10 Deployment health evidence The system may collect protected evidence including: * successful boot; Das Expires 4 April 2027 [Page 335] Internet-Draft Reality as a Cryptographic Dependency October 2026 * artifact digest; * runtime measurement; * crash rate; * restart rate; * error rate; * latency; * resource use; * memory pressure; * network behavior; * dependency health; * service registration; * policy compliance; * attestation; * security events; * response correctness indicators; * rollback readiness; * or another protected metric. The metric set need not be identical for every deployment type. A.17.11. E17.11 Health vector and protected predicate Let a phase-specific measured health vector be represented locally by: hi A protected health predicate may be expressed as: HealthAcceptable(hi ) = 1 Das Expires 4 April 2027 [Page 336] Internet-Draft Reality as a Cryptographic Dependency October 2026 The function may include multiple thresholds, Boolean conditions, statistical tests, safety constraints, or formally specified invariants. A model may recommend a health assessment, but the protected continuation decision may remain outside the proposing model. A.17.12. E17.12 Deployment receipt Following actual bounded deployment and observation, the system generates an ECR that may bind: * DB ; * target set Ti ; * runtime identities; * artifact measurements; * configuration measurements; * health vector or protected digest thereof; * security events; * traffic level; * phase number; * sink identity; * time; * nonce; * policy epoch; * and outcome status. A.17.13. E17.13 Automatic rollout continuation A protected automatic decision may require: V alid(Ri ) ∧ HealthAcceptable(hi ) ∧ P olicyCurrent ∧ RevocationClear ∧ W ithinDeploymentEnvelope before issuing authority for Ti+1 . Das Expires 4 April 2027 [Page 337] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.17.14. E17.14 Human rollout continuation A human reviewer may be shown: * build identity; * trial target; * actual target count; * health results; * error/crash information; * security observations; * intended next rollout set; * rollback status; * and cryptographic receipt validity. Human approval may be required before expansion. A.17.15. E17.15 Hybrid rollout continuation Early phases may proceed automatically while larger scopes require human confirmation. Example: |Ti | < Th ⇒ Auto |Ti | ≥ Th ⇒ HumanApproval where Th is a protected deployment threshold. A.17.16. E17.16 Fixed progressive rollout A deployment may progress through predetermined populations: 1 → 10 → 100 → 1000 → |Tmax | or through topological stages: one node → one zone → one region → authorized global set A.17.17. E17.17 Adaptive rollout The next target set may depend on measured evidence: Das Expires 4 April 2027 [Page 338] Internet-Draft Reality as a Cryptographic Dependency October 2026 Ti+1 = f(Ti , Ri , hi , Riski , P olicyi ) The function may enlarge, hold, reduce, redirect, or terminate rollout. A.17.18. E17.18 Cohort-isolated continuation If only some nodes or tenants satisfy protected health criteria, continuation may be restricted to the successful subset rather than expanding all targets uniformly. A failing region can remain blocked while another verified region proceeds, provided the authorized policy allows such divergence. A.17.19. E17.19 Configuration-only rollout E17 applies not only to binaries but also to configuration changes, feature flags, policy bundles, routing changes, certificates, secrets, firewall rules, IAM settings, network policies, and service- mesh configuration. A bounded configuration may be applied first to a limited target and expanded only after receipt-confirmed behavior. A.17.20. E17.20 Infrastructure-as-code variation An infrastructure-as-code plan may be bound to its source digest, rendered plan digest, provider identity, and permitted resource envelope. The first real resource creation or modification may be bounded. The resulting cloud state can generate protected evidence before the system is authorized to create or modify the complete infrastructure set. A.17.21. E17.21 Kubernetes/container orchestration variation The enforcement point may include: * admission controller; * controller manager; * operator; * API server policy layer; * node agent; * service mesh; * network policy enforcement; Das Expires 4 April 2027 [Page 339] Internet-Draft Reality as a Cryptographic Dependency October 2026 * image policy service; * secret broker; * or another orchestration control. The architecture is not limited to Kubernetes or any named orchestrator. A.17.22. E17.22 Virtual-machine variation The bounded phase may boot one or more VMs with measured image, firmware, configuration, and protected identity. Attestation and health evidence may be required before broader VM deployment or production traffic release. A.17.23. E17.23 Serverless variation A new function version may be activated for a bounded request class or tenant group. Receipt-confirmed execution metrics can enable broader invocation routing. A.17.24. E17.24 Edge/fleet variation Software may first be deployed to a bounded device cohort. Each device or a protected aggregation service may provide receipts confirming: * artifact digest; * successful installation; * boot state; * health state; * device identity; * and rollback capability. Expansion to the wider fleet depends on protected aggregate criteria. A.17.25. E17.25 Hardware attestation variation Where supported, runtime evidence may include TEE, TPM, secure boot, confidential-computing, measured VM, DPU, or device-rooted attestation. A receipt may therefore prove not merely that software responded but that it operated in an expected measured environment. Das Expires 4 April 2027 [Page 340] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.17.26. E17.26 Network exposure as Finality Sink The deployment may already exist, while the true consequential boundary is the network exposure point. A load balancer, API gateway, service mesh, DPU, SmartNIC, switch, firewall, or routing controller may function as a Finality Sink controlling whether real production traffic reaches the new deployment. A.17.27. E17.27 Credential-expansion variation The trial deployment may initially possess restricted credentials. Successful protected operation may enable broader service permissions only after receipt validation. Thus deployment scale and privilege scale may progress independently. A.17.28. E17.28 Database/storage dependency variation A deployment receipt may require confirmation that dependent database migrations, storage mounts, or secret versions match expected protected state before expansion. A.17.29. E17.29 Rollback authority If health criteria fail, a rollback may be automatically or human- authorized. Rollback may comprise: * traffic withdrawal; * version pointer reversal; * instance termination; * configuration reversion; * credential revocation; * route removal; * or restoration of prior artifact. Rollback may itself generate a protected receipt. A.17.30. E17.30 Freeze-on-indeterminate rule If the system cannot establish whether a deployment phase completed correctly, broader rollout remains blocked. Examples include: * control-plane timeout; Das Expires 4 April 2027 [Page 341] Internet-Draft Reality as a Cryptographic Dependency October 2026 * partial target response; * missing attestation; * uncertain traffic state; * region partition; * or ambiguous rollback state. A.17.31. E17.31 Crash and recovery Protected rollout state may survive controller restart. The system reconstructs current target state from protected control-plane data, target attestations, deployment IDs, and receipts before issuing any further expansion authority. Blindly repeating a rollout phase is not required. A.17.32. E17.32 Revocation during rollout A newly discovered vulnerability, revoked artifact, compromised key, policy change, or human veto may stop further rollout even if prior phases succeeded. Unused future phase authorities may become invalid. A.17.33. E17.33 Multi-region progression A global deployment may be hierarchical: node → zone → region → multi-region Each parent phase may depend on protected receipts from one or more child phases. A.17.34. E17.34 Quorum/aggregate health variation For a target set containing multiple instances, continuation may depend on an aggregate protected predicate, for example: HealthyT argetsi ≥ τh ObservedT argetsi with no protected critical-failure predicate present. τh is deployment-specific and need not be fixed globally. A.17.35. E17.35 Anti-bypass closure Equivalent deployment or exposure paths may include: Das Expires 4 April 2027 [Page 342] Internet-Draft Reality as a Cryptographic Dependency October 2026 * direct cloud administrator credentials; * alternate CI/CD system; * emergency console; * cluster-admin path; * direct node access; * alternate load balancer; * secondary API gateway; * raw infrastructure provider API; * image registry override; * secret injection path; * or recovery tooling. Where such a path can create the same material rollout consequence, it may be mediated or placed under equivalent protected control. A.17.36. E17.36 SEND analogue A communication service release may first route real messages for one controlled recipient or tenant through a new service version. Verified delivery receipts and health evidence can then permit progressively broader SEND traffic. A.17.37. E17.37 Payment analogue A payment-processing service update may first handle a bounded transaction class or low-value protected cohort. Verified transaction and service-health evidence can enable broader transaction traffic without granting unrestricted authority at the outset. A.17.38. E17.38 Required invariants 1. At least one bounded deployment phase creates a real operational state or real traffic exposure. 2. The bounded target set or privilege scope is narrower than the maximum authorized deployment envelope. 3. Protected evidence is collected from the deployed environment or an authoritative observer. 4. Expansion authority depends on accepted evidence and required approval. 5. Artifact/ Das Expires 4 April 2027 [Page 343] Internet-Draft Reality as a Cryptographic Dependency October 2026 configuration identity remains bound across phases. 6. No rollout phase may exceed the authorized target or privilege envelope. 7. Failure, revocation, or indeterminate state can stop further rollout. 8. Equivalent deployment or exposure paths are controlled where necessary for non-bypassability. TIVATION, AND PROGRESSIVE CONSEQUENCE RELEASE A.18. E18 — Receipt-Gated AI Model Deployment, Model Activation, and Progressive Consequence Release A.18.1. E18.1 Purpose E18 applies staged effectuation to deployment and activation of AI models, model versions, model configurations, agentic systems, model endpoints, tool-enabled models, inference services, persistent model- state systems, and other learned computational components. The architecture distinguishes among: * loading or storing a model; * making the model callable; * exposing it to a bounded real request population; * granting tool or external-action authority; * expanding data access; * expanding recipient/user/tenant scope; * and enabling broader externally consequential behavior. A model may therefore be deployed technically without immediately receiving the full consequence envelope contemplated by the operator. A.18.2. E18.2 Core causal chain A representative E18 workflow is: Model Release Proposal → Model/Runtime Binding → Bounded Real Activation → Protected Runtime Evidence → Receipt A.18.3. E18.3 Model release object The protected release may bind one or more of: * model weights digest; Das Expires 4 April 2027 [Page 344] Internet-Draft Reality as a Cryptographic Dependency October 2026 * model architecture identifier; * model version; * tokenizer/version; * system prompt or protected digest; * tool schema; * tool allowlist; * connector set; * retrieval sources; * memory configuration; * safety/policy configuration; * runtime image; * accelerator environment; * quantization/configuration; * model-routing policy; * inference parameters; * user/tenant scope; * geographic scope; * consequence scope; * and maximum privilege envelope. Let the bound model-release descriptor be denoted locally by: MR and its digest by: DMR = H(Canon(MR )) This notation is local to E18 and is distinct from earlier uses of M in other embodiments. Das Expires 4 April 2027 [Page 345] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.18.4. E18.4 Maximum model release envelope The operator may authorize a maximum release envelope including one or more dimensions: * maximum user population; * maximum tenants; * permitted regions; * permitted APIs; * tool privileges; * token/request budget; * data sensitivity; * context sources; * output classes; * communication authority; * payment authority; * infrastructure authority; * device authority; * or other external consequence classes. The progressive system must not infer additional authority merely from successful earlier phases. A.18.5. E18.5 Bounded model cohort Let the active model cohort at phase i be represented by: Ci where Ci may identify users, tenants, requests, endpoints, tools, regions, workloads, devices, or another bounded activation population. A protected maximum cohort is: Cmax and: Das Expires 4 April 2027 [Page 346] Internet-Draft Reality as a Cryptographic Dependency October 2026 Ci ⊆ Cmax A.18.6. E18.6 Bounded consequence envelope Traffic volume alone may not represent model risk. A model can be broadly used for low-consequence generation while remaining prohibited from payments, SEND, infrastructure changes, device control, or sensitive data export. E18 therefore permits consequence scope to be phased separately from population scope. Let a phase- specific consequence/privilege envelope be: Γi with: Γi ⊆ Γmax where Γmax is the maximum protected consequence envelope authorized for the model release. A.18.7. E18.7 Trial model activation A model release may first be enabled for: * internal test users; * one tenant; * one region; * one API; * one request class; * read-only tool use; * no-tool inference; * low-sensitivity data; * bounded token budget; * one controlled connector; * one protected agent workflow; * or another limited real production condition. The requests are real and the model actually operates in the target environment. Das Expires 4 April 2027 [Page 347] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.18.8. E18.8 Protected model activation authority The trial authority may be enforced through: * model-router policy; * API gateway; * serving-platform authorization; * runtime capability; * deployment signature; * model registry policy; * tool broker; * connector broker; * network egress gate; * GPU/accelerator release control; * protected key; * HSM/TEE state; * or equivalent mechanism. A.18.9. E18.9 Separation of inference from effectuation A model may be allowed to compute outputs without receiving authority to effect external consequences. For example: InferenceAllowed = T RU E while: SEN DAllowed = F ALSE P aymentAllowed = F ALSE InfrastructureW riteAllowed = F ALSE Later phases may expand consequence authority only after protected evidence and policy approval. Das Expires 4 April 2027 [Page 348] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.18.10. E18.10 Runtime evidence collection Protected runtime evidence may include: * model identity; * request class; * error rate; * refusal/allow behavior; * latency; * resource consumption; * tool-use frequency; * tool-use failure rate; * policy violations; * output-format compliance; * data-access events; * connector events; * taint/provenance behavior; * security alerts; * hallucination/error indicators where measurable; * anomalous action proposals; * user escalation rate; * rate-limiting events; * model drift indicators; * or another protected measurement. No single metric is mandatory across all AI deployments. Das Expires 4 April 2027 [Page 349] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.18.11. E18.11 Model evidence vector Let a protected model evidence vector for phase i be represented locally by: mi A protected acceptance predicate may be: M odelEvidenceAcceptable(mi ) = 1 The predicate may be deterministic, rule-based, threshold-based, formally specified, or based on protected aggregate metrics. An AI evaluator may contribute evidence but need not possess final authority to approve its own expansion. A.18.12. E18.12 Model deployment receipt The resulting ECR may bind: * DMR ; * model/runtime identity; * active cohort Ci ; * active consequence envelope Γi ; * evidence vector or protected digest thereof; * serving environment; * accelerator attestation where available; * tool configuration; * connector configuration; * policy version; * sink identities; * phase number; * nonce; * time; Das Expires 4 April 2027 [Page 350] Internet-Draft Reality as a Cryptographic Dependency October 2026 * and outcome status. A.18.13. E18.13 Automatic model expansion A protected automatic continuation may require: V alid(Ri )∧M odelEvidenceAcceptable(mi )∧P olicyCurrent∧RevocationClear∧W ithinM odelReleaseEnvelope before expanding Ci , Γi , or both. A.18.14. E18.14 Human model expansion A human approval interface may show: * exact model version; * trial population; * active tools; * active data classes; * observed protected metrics; * security events; * receipt validity; * intended next cohort; * intended next consequence scope; * and rollback availability. The human may authorize only population expansion, only privilege expansion, both, or neither. A.18.15. E18.15 Hybrid model expansion A policy may automatically expand ordinary inference traffic while requiring human approval for new consequential tool classes. For example: Ci+1 > Ci may be automatically allowed while: Γi+1 ⊃ Γi Das Expires 4 April 2027 [Page 351] Internet-Draft Reality as a Cryptographic Dependency October 2026 requires protected human approval. This prevents user-scale growth from silently becoming authority growth. A.18.16. E18.16 Progressive user/tenant rollout A model may progress through: internal users → one tenant → selected tenants → authorized broad population Each phase can be receipt-gated. A.18.17. E18.17 Progressive tool privilege rollout A model may progress through: no tools → read-only tools → bounded write tools → higher-consequence tools Each expansion may require separate protected evidence and approval. A.18.18. E18.18 Communication/SEND progression An AI model may initially be allowed to draft communications without sending them. A later phase may permit SEND only to: * a protected test endpoint; * the requesting user; * one approved recipient; * or a bounded recipient class. Verified SEND receipts and policy evidence may then enable broader communication authority. The model itself does not obtain unrestricted SEND authority merely because it successfully generated text. A.18.19. E18.19 Payment progression A model may initially be permitted to: * prepare a payment proposal; * validate beneficiary information; * perform a bounded test/verification transaction where supported; Das Expires 4 April 2027 [Page 352] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or create a protected reservation. Broader payment authority remains separately gated by the staged payment workflow and protected receipt evidence. A.18.20. E18.20 Data-access progression A model may start with: * public data only; * one protected dataset; * redacted records; * bounded retrieval scope; * or one tenant’s data. Receipt-confirmed operation and policy validation may later enable broader data access, provided the maximum authorization envelope permits it. A.18.21. E18.21 Connector progression Connectors may be introduced progressively. Example: no connector → read-only connector → bounded write connector → authorized broader connector scope The connector broker can function as a Finality Sink for external effects. A.18.22. E18.22 Agentic workflow progression A model may first execute a bounded workflow having no irreversible effects. After protected evidence confirms acceptable behavior, later phases may allow bounded external tool invocation. Further phases may enlarge tool scope, destination scope, or transaction size. A.18.23. E18.23 Model-routing variation The protected system may route only a bounded request class to the new model while the previous model continues serving other traffic. Expansion authority controls routing rather than model installation. Das Expires 4 April 2027 [Page 353] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.18.24. E18.24 Shadow-model variation A model may initially process real inputs without its outputs being externally authoritative. Its outputs may be compared against production behavior, policy predicates, or protected observations. However, shadow execution alone is not necessarily the real external effect required for a later staged-effectuation claim unless the subsequent architecture uses an actual bounded external effect or another qualifying protected state transition. A.18.25. E18.25 Model-state / memory promotion A model-generated persistent memory item may first enter isolated state. The system may validate provenance, taint, consistency, user scope, and protected receipt evidence before promoting the memory into shared durable state. This can combine E18 with E16. A.18.26. E18.26 GPU/accelerator-rooted variation The model-serving environment may use protected accelerator or host evidence. A GPU security controller, DPU, SmartNIC, TEE, confidential VM, secure boot component, or other hardwarerooted mechanism may participate in confirming: * model digest; * serving binary; * destination; * memory protection state; * output path; * or egress authority. A.18.27. E18.27 Model key-release variation Encrypted model weights or protected model components may remain unusable until a protected release key is provided. A bounded phase key may permit operation only for a limited environment or cohort. Later receipt validation may permit broader serving keys or routing authority. Das Expires 4 April 2027 [Page 354] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.18.28. E18.28 Tool credential withholding The model runtime need not hold the full credential necessary for external action. A protected tool broker may expose only phase- specific authority. Successful bounded operation may lead to a broader but still scoped credential after receipt validation. A.18.29. E18.29 Safety-policy epoch change If model safety policy, enterprise policy, revocation state, or tool policy changes between phases, the prior successful receipt need not authorize further expansion. Fresh protected validation may be required. A.18.30. E18.30 Model revocation A model build, runtime image, tool schema, connector, or policy configuration may be revoked at any phase. Unused continuation authority is invalidated and the model may be: * held; * rolled back; * traffic-isolated; * tool-disabled; * credential-revoked; * or removed. A.18.31. E18.31 Rollback Rollback may return: * traffic to a previous model; * tool permissions to a prior scope; * cohort size to an earlier stage; * data access to a narrower scope; * runtime image to a prior version; * or external authority to a safer state. A rollback may itself generate a protected receipt. Das Expires 4 April 2027 [Page 355] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.18.32. E18.32 Indeterminate model phase If the system cannot determine whether a model expansion actually took effect, further progression remains blocked. Examples include: * uncertain routing state; * partial region update; * missing tool-broker acknowledgement; * ambiguous credential release; * lost deployment receipt; * or inconsistent model registry state. A.18.33. E18.33 Crash and recovery Protected phase state should survive serving-controller, router, or orchestration restart. On recovery, the system reconciles actual model version, active target cohort, tool permissions, credential state, routing state, and receipts before issuing further continuation authority. A.18.34. E18.34 Parallel model cohorts Different cohorts may progress independently. For example, one tenant group may remain at Γ1 while another verified group progresses to Γ2 , provided policy permits such segmented authority. A.18.35. E18.35 Multi-model ensemble variation Where an externally consequential workflow uses multiple models, protected policy may require evidence from or state binding across multiple model components before expanding the overall consequence envelope. This does not require any specific ensemble architecture. A.18.36. E18.36 Threshold evidence variation Expansion may require multiple independent protected evidence sources, for example: * runtime metrics; * security monitor; * tool broker; Das Expires 4 April 2027 [Page 356] Internet-Draft Reality as a Cryptographic Dependency October 2026 * destination receipts; * human approval; * hardware attestation; * or enterprise policy service. The required evidence combination may be threshold-based or conjunctive. A.18.37. E18.37 Consequence-specific Finality Sinks Different external consequences may use different sinks: * SEND sink; * payment sink; * database sink; * storage sink; * device-control sink; * infrastructure sink; * data-export sink. A model release receipt for ordinary inference must not automatically substitute for the required evidence of a different consequential sink. A.18.38. E18.38 Anti-bypass closure Equivalent authority paths may include: * alternate model endpoint; * hidden API; * direct runtime access; * unmediated tool credential; * secondary connector; * privileged orchestration path; * direct GPU output path; * alternate network egress; Das Expires 4 April 2027 [Page 357] Internet-Draft Reality as a Cryptographic Dependency October 2026 * service-account credential; * model alias or router override; * or emergency administrator path. Where such paths can create the same material consequence, they may be placed under equivalent protected finality control. A.18.39. E18.39 Non-self-certification invariant The model being evaluated need not be trusted to authorize its own privilege expansion. A model may produce evidence, explanations, metrics, or recommendations, but the protected authority to enlarge Ci or Γi may remain with the PED, Finality Sink, protected human, hardware root, or another independent protected component. A.18.40. E18.40 Latency-aware progression For low-consequence model requests, the system may use fast-path protected validation. Higher-consequence classes may require staged receipts, stronger approval, or hardware-rooted checks. Thus the architecture need not impose identical latency on every inference. A.18.41. E18.41 Required invariants 1. Model computation or deployment alone does not imply unrestricted consequence authority. 2. At least one bounded real model activation or effectuation phase is narrower than the maximum authorized release envelope. 3. Model identity/configuration is protected against substitution across phases. 4. Protected evidence is collected from the real serving/effectuation environment or authoritative observers. 5. Expansion of cohort, privilege, consequence, data access, or tool authority depends on protected validation and required approval. 6. Population expansion does not inherently imply privilege expansion. 7. No phase may exceed the authorized model-release envelope. 8. Revocation, failure, or indeterminate state can stop future expansion. 9. Equivalent alternate endpoints or credentials are controlled where necessary for non-bypassability. Cross-embodiment relationship: E16, E17, E18 meaningful state. Database state Provisional Persistent State → Verified Commit Evidence → Production Promotion Cloud/infrastructure state Bounded Real Deployment → Verified Runtime Evidence → Broader Rollout Das Expires 4 April 2027 [Page 358] Internet-Draft Reality as a Cryptographic Dependency October 2026 AI-model state and consequence authority Bounded Model Activation → Verified Model Evidence → Broader Cohort/Privilege Effectuation A single real-world system may combine all three. For example, an AI model deployment (E18) may use a cloud rollout (E17) while writing model memory through a receipt-gated database promotion path (E16). Each layer may retain its own effectuation boundary and receipt requirements. Delta definitions - new terms introduced in E16-E18 only The following definitions supplement, rather than replace, definitions previously established in Advanced Section 1. Database Finality Sink A protected component or protected database/ storage function that controls whether a database mutation becomes persistent, promoted, replicated, visible, externally queryable, or otherwise effective at a consequential database boundary. It may be implemented by a database engine, proxy, transaction coordinator, storage controller, protected stored procedure, HSM/TEE-backed service, or another equivalent enforcement mechanism. Provisional Persistence Target A real persistent location or state in which a bounded mutation may be committed without immediately creating the complete intended production consequence. Examples include a shadow row, staging table, versioned object, branch, isolated namespace, canary partition, limited replica, non-public index, or quarantined object state. Provisional Persistent State A real durable or otherwise persistent state created during a bounded database phase that remains restricted in visibility, replication, scope, authority, or consequence until a later protected promotion decision. Promotion Gate A protected logical or physical control that prevents provisional persistent state from becoming broader production state until required evidence and authority conditions are satisfied. Promotion Authority A scoped protected authorization, capability, key, signed command, transaction state, or equivalent enablement condition that permits a previously bounded persistent state to be promoted into a broader or complete authorized database consequence. Production Promotion A protected transition by which provisional state is merged, published, replicated, made visible, activated, indexed, or otherwise converted into the broader production consequence authorized for the Candidate Act. Das Expires 4 April 2027 [Page 359] Internet-Draft Reality as a Cryptographic Dependency October 2026 Deployment Target Set A bounded set of infrastructure or service targets to which a deployment phase applies, including containers, VMs, nodes, zones, regions, tenants, users, devices, service instances, API versions, or other deployable targets. Deployment Health Evidence Protected measurements obtained from a real deployment phase that characterize whether the deployed artifact, configuration, environment, service, or target set satisfies required technical predicates for continuation. Exposure Gate A protected control that determines whether an installed or instantiated service receives real production traffic or becomes externally reachable. Installation and exposure may therefore be separate effectuation phases. Model Release Descriptor A protected representation of the model and operational configuration being released, which may bind model weights/version, runtime, tokenizer, policy, tools, connectors, data access, serving environment, cohort, and maximum consequence envelope. Model Release Envelope The maximum protected scope within which a model may be activated or granted authority, including population, tenant, region, API, data, tool, connector, token, output, or external-consequence dimensions. Model Cohort A bounded set of users, tenants, requests, endpoints, devices, workloads, regions, or other activation population to which a particular model phase applies. Model Consequence Envelope The bounded external-action, privilege, tool, data-access, communication, payment, infrastructure, or devicecontrol authority permitted to a model at a particular phase. Model Expansion Authority Protected authority that permits the active model cohort, model consequence envelope, or both to expand following accepted protected evidence. Protected Model Evidence Machine-verifiable or protected measurements derived from real model operation, serving infrastructure, tool brokers, external sinks, hardware attestations, policy monitors, or equivalent observers and used as an input to the continuation decision. Delta notation - new symbols introduced in E16-E18 only Previously defined notation from Advanced Section 1 is intentionally omitted here. Das Expires 4 April 2027 [Page 360] Internet-Draft Reality as a Cryptographic Dependency October 2026 Symbol Meaning in this document W Proposed database mutation in E16. DW Protected digest of the canonical proposed database mutation W . Vb Baseline database/object/version state expected before the bounded mutation. Vt Trial/provisional persistent version or state resulting from the bounded real database mutation. q Protected minimum acknowledgement/quorum count in a replication-aware database variation. Tmax Maximum authorized deployment target set in E17. Ti Target set authorized/active for deployment phase i. B Deployable software/configuration artifact or artifact bundle in E17. DB Protected digest of artifact/bundle B. hi Protected deployment health-evidence vector for phase i. Th Protected target-size or rollout threshold at which the approval mode may change. τh Protected minimum healthy-target ratio or equivalent aggregate health threshold. MR Model Release Descriptor in E18; local E18 notation and not the earlier generic/message/payment use of M. DMR Protected digest of the canonical Model Release Descriptor. Ci Bounded model cohort active at phase i. Cmax Maximum protected model cohort authorized for the release. Γi Phase-specific model consequence/ privilege envelope. Γmax Maximum authorized model consequence/ privilege envelope. mi Protected model-evidence vector for phase i. New word-like predicates/functions Expression Meaning BaselineV alid(W ) Protected determination that current database state is acceptable for mutation W . BaselineM atch(R0 , Vb ) Receipt confirms the mutation was evaluated/executed against the expected baseline state. Durable(R0 ) Receipt establishes the required level of persistence/durability. P romoteAllowed Protected Boolean indicating whether production promotion is currently permitted. HealthAcceptable(hi ) Protected predicate determining whether deployment-health evidence satisfies continuation requirements. M odelEvidenceAcceptable(mi ) Protected predicate determining whether model-runtime evidence satisfies continuation requirements. W ithinDeploymentEnvelope Protected condition that a proposed rollout remains inside the maximum authorized deployment scope. W ithinM odelReleaseEnvelope Protected condition that cohort/privilege expansion remains inside the authorized model-release envelope. Set/vector conventions newly used here * Calligraphic symbols such as T and C represent sets or bounded populations. * Bold lower-case symbols such as hi and mi represent vectors or structured collections of protected measurements; they do not require a specific numerical dimension. Das Expires 4 April 2027 [Page 361] Internet-Draft Reality as a Cryptographic Dependency October 2026 * |Ti | denotes the number or protected cardinality measure of members in deployment target set Ti . * Γi ⊆ Γmax expresses bounded authority inclusion; it does not require privileges to be represented literally as mathematical sets if an equivalent ordered or policy-bounded representation is used. End of E16-E18 frozen workflows A.19. E19 — Receipt-Gated Tool Use and External Action Invocation A.19.1. E19.1 Purpose E19 applies the staged-effectuation architecture to a computational system, including an AI agent, that proposes use of an external tool, connector, function, service, plug-in, operatingsystem primitive, remote API, local API, database operation, payment function, messaging function, storage function, device function, or other effect-capable execution interface. The principal distinction is that a model or agent may be permitted to select, describe, prepare, or request a tool operation without thereby possessing unrestricted authority to invoke the tool or cause the full external consequence. A representative causal relationship is: tool proposal → protected tool validation → bounded real tool interaction → R0 → continuation authority → broader tool effect. Accordingly, a tool-call representation, function-call object, model- emitted action structure, or ordinary application-level “tool use” event need not itself constitute final authority to invoke the effect-capable operation. A.19.2. E19.2 Tool Selection and Candidate Act Formation The originating computational component may select a tool from a set of tools: T = {T1 , T2 , . . . , Tq }. The selected tool and proposed operation are incorporated into the Candidate Act. The Candidate Act may bind one or more of: * tool identity, version, provider, or endpoint; * operation or method; * argument names and values; Das Expires 4 April 2027 [Page 362] Internet-Draft Reality as a Cryptographic Dependency October 2026 * destination, recipient, account, object, or device; * payload, file, amount, command, or data range; * expected consequence; * permitted scope; * required approval class; * time, nonce, policy epoch, and revocation state; * intended Finality Sink or effect-capable boundary; and * any prior receipt or phase state required for continuation. A tool invocation envelope for phase i may be denoted: Γi . The protected system may require: Γi ⊆ Γmax , where Γmax is the maximum authorized tool-use envelope for the Candidate Act. A.19.3. E19.3 Protected Tool Identity Binding The PED may verify the identity of the tool independently of the agent’s textual assertion. Tool identity may be established using: * registered endpoint identity; * executable or package digest; * service certificate; * remote attestation; * signed tool manifest; * API audience or origin; * process or container measurement; * secure hardware identity; * destination binding; or Das Expires 4 April 2027 [Page 363] Internet-Draft Reality as a Cryptographic Dependency October 2026 * equivalent protected evidence. Where tool identity is material, an unrecognized or substituted tool does not satisfy the protected predicate merely because it accepts the same apparent arguments. A.19.4. E19.4 Tool Contract / Operation-Schema Validation Before effectuation, the PED may validate a machine-readable contract describing permitted tool behavior. The contract may bind: * allowed methods; * permitted parameter types and ranges; * side-effect class; * maximum resource consumption; * destination restrictions; * allowed output classes; * required receipt class; * reversibility; * required user approval; * permitted network or storage targets; and * whether the tool may recursively invoke other tools. The contract may be static, signed, versioned, policy-derived, destination- provided, or generated from protected configuration. A.19.5. E19.5 Tool Proposal Is Not Invocation Authority The architecture may maintain the following invariant: Propose(Tj , A) = 1 ̸⇒ Invoke(Tj , A) = 1. Likewise: ToolCallGenerated = T RU E ̸⇒ ExternalEffectAuthorized = T RU E. A model may therefore emit a syntactically valid tool call while the PED withholds any authority required for actual effectuation. Das Expires 4 April 2027 [Page 364] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.19.6. E19.6 Selection of Single-Phase or Staged Tool Use Protected policy may classify the proposed tool operation into: 1. single-phase protected invocation; 2. bounded tool interaction followed by full invocation; 3. progressive multi-phase tool use; 4. protected human approval; 5. automatic protected continuation; 6. hybrid approval; 7. sandbox- only execution; 8. read-only or reduced-scope execution; 9. hold; or 10. denial. The same tool may use different modes for different operations. A metadata read and a destructive delete operation need not share the same finality path. A.19.7. E19.7 Bounded Real Tool Interaction For staged tool use, Phase 0 may be a real interaction with the actual tool or effect-capable tool path but with bounded consequence. Examples include: * querying the actual destination for object metadata before a destructive update; * requesting a real account capability or endpoint challenge before sending a payment; * creating a provisional record in a restricted namespace; * sending a bounded communication trailer before a complete message; * creating a temporary or reversible reservation before irreversible settlement; * applying a configuration to a single canary target; * invoking a device with a limited movement envelope; * obtaining a remote attestation from the actual tool executor; or * executing another real but bounded operation whose observed result is relevant to later authorization. The initial interaction need not be identical in consequence to the final tool operation, provided protected policy treats its verified result as relevant to continuation. A.19.8. E19.8 Tool Effect Gateway A tool-effect gateway may mediate the path between the proposing process and the actual effectcapable tool. It may be implemented by: Das Expires 4 April 2027 [Page 365] Internet-Draft Reality as a Cryptographic Dependency October 2026 * local privileged broker; * host service; * kernel or syscall mediation; * container or microVM boundary; * API gateway; * service mesh; * connector broker; * network proxy; * database proxy; * message broker; * payment gateway; * credential broker; * secure monitor; * hardware controller; or * destination-side verifier. The gateway may perform the Finality Sink function or may forward to a separate Finality Sink. A.19.9. E19.9 Phase-Specific Tool Authority For each phase, the PED may create a distinct authority Ci bound to Γi . The system may enforce: Scope(Ci ) = Scope(Γi ), or another policy-defined relationship. A Phase-0 authority may therefore be technically incapable of authorizing the broader Phase-1 operation. A.19.10. E19.10 Tool-Side Verification The tool gateway or destination may verify: * Candidate Act binding; * tool identity; * method identity; Das Expires 4 April 2027 [Page 366] Internet-Draft Reality as a Cryptographic Dependency October 2026 * parameter digest; * destination; * authorized scope; * phase; * nonce; * expiry; * policy epoch; * receipt dependency; * human approval artifact where required; * credential audience; and * local protected state. Failure of a required condition results in withholding or reducing the tool effect. A.19.11. E19.11 Tool Result Observation and Receipt After the bounded real tool interaction, a protected observer may form an ECR. The receipt may bind: * tool identity and version; * exact method or operation; * protected argument digest; * destination; * actual result state; * result digest; * side-effect state; * transaction or request identifier; * sink identity; * protected time; Das Expires 4 April 2027 [Page 367] Internet-Draft Reality as a Cryptographic Dependency October 2026 * nonce; * current tool state; and * next-stage eligibility evidence. The receipt may establish a technical fact without asserting that the overall business goal has been achieved. A.19.12. E19.12 Receipt-Gated Full Tool Invocation The protected continuation predicate may be represented by: Enable(Pi+1 ) = V alid(Ri )∧M atchT ool(Ri , Tj )∧M atchOperation(Ri , Γi )∧P olicyCurrent∧RevocationClear. Where human approval is required, the corresponding approval predicate is added. A valid receipt from one tool must not authorize another tool unless protected policy expressly permits such substitution. A.19.13. E19.13 Progressive Tool Privilege Tool privilege may expand in phases. For example: Γ0 ⊂ Γ1 ⊂ · · · ⊆ Γmax . Illustrative progression: * Phase 0: inspect metadata; * Phase 1: create provisional object; * Phase 2: modify one bounded object; * Phase 3: apply broader approved mutation; and * final phase: complete the authorized consequence. The sequence is not limited to read-before-write and may be defined according to the tool’s actual effect model. A.19.14. E19.14 Protected Human Approval A human may be asked to approve: * the initial tool invocation; * continuation after the real bounded interaction; Das Expires 4 April 2027 [Page 368] Internet-Draft Reality as a Cryptographic Dependency October 2026 * expansion to a higher-privilege method; * use of a sensitive destination; * a parameter change; * or the final consequential operation. The approval interface may display the verified tool identity, actual Phase-0 result, exact requested next operation, destination, arguments, receipt status, and consequence scope. The AI agent cannot satisfy a required human predicate merely by generating text indicating that the user approved. A.19.15. E19.15 Automatic Tool Continuation Where protected policy permits, continuation may occur automatically: V alid(Ri ) ∧ T oolP olicyP assi ∧ RiskAcceptablei ⇒ AutoContinuei+1 . The automatic policy engine may be separate from the agent that proposed the tool call. A.19.16. E19.16 Recursive and Chained Tool Calls An external tool may itself request or trigger another tool. The architecture may treat the downstream operation as: * part of the original authorized act-equivalent representation; * a new Candidate Act; * a sub-phase requiring separate authority; or * a prohibited recursive path. Where recursive invocation could create an external consequence outside the authorized envelope, the downstream path may require its own PED/Finality Sink verification. A.19.17. E19.17 Tool Argument Mutation Protection Between approval and effectuation, arguments may be: * serialized; * transformed; * routed; Das Expires 4 April 2027 [Page 369] Internet-Draft Reality as a Cryptographic Dependency October 2026 * normalized; * encrypted; * translated; * split; * reconstructed; or * modified by middleware. The sink may reconstruct or otherwise verify the effect-relevant operation and reject unauthorized material changes. A protected equivalence function may permit transformations that preserve the authorized consequence while rejecting substitutions that change it. A.19.18. E19.18 Credential Withholding During Tool Use The agent may be unable to access the tool’s unrestricted credential. The protected broker may hold the credential and expose only: * surrogate reference; * one-operation capability; * audience-bound token; * short-lived token; * destination-bound authorization; * hardware-generated authenticator; or * another restricted enablement mechanism. The complete credential need not enter the agent’s memory space. A.19.19. E19.19 Tool Crash and Indeterminate Effect If the tool accepts or performs an operation but the caller loses the response, the state may become: IN DET ERM IN AT E. The system may reconcile using: * idempotency identifier; * tool transaction identifier; * destination query; Das Expires 4 April 2027 [Page 370] Internet-Draft Reality as a Cryptographic Dependency October 2026 * protected request log; * resource version; * sink journal; or * other authoritative state. Blind replay may be prohibited where duplicate effect would be unsafe. A.19.20. E19.20 Tool Receipt Consumption Where one receipt authorizes one continuation: Consumed(Ri ) = T RU E may be stored atomically with protected state advancement. A replayed receipt then cannot independently produce a second consequential tool invocation. A.19.21. E19.21 Alternate Tool Path Closure A protected tool path may be ineffective if the agent can bypass it by: * opening a raw network connection; * calling the provider API directly; * invoking a lower-level OS primitive; * accessing a credential store; * using another connector; * calling an administrative endpoint; * using an alternate account; * writing directly to a database; * issuing a device command through a driver; or * using another act-equivalent path. Accordingly, paths capable of producing the same protected consequence may be disabled, mediated, cryptographically restricted, or brought under equivalent finality control. Das Expires 4 April 2027 [Page 371] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.19.22. E19.22 Software Implementation A representative software path may be: Agent → Tool Proposal → PED/Broker → Tool Gateway → External Tool. The agent may receive only result data, while authority, credentials, receipt verification, and protected state remain outside the agent process. A.19.23. E19.23 Hardware Implementation The tool authority may be enforced by: * TEE; * HSM; * secure element; * DPU or SmartNIC; * device controller; * secure processor; * accelerator security controller; or * another hardware trust boundary. Hardware may retain the signing key or next-phase secret and refuse release until the required tool receipt verifies. A.19.24. E19.24 SEND Example An agent proposes: SEND(file, recipient). Phase 0 may transmit a real protected trailer or recipient challenge through the actual communication tool. The recipient returns R0 . Only then may the tool gateway obtain or activate the authority required to transmit the full file or release its decryption key. A.19.25. E19.25 Payment Example An agent proposes: PAY(amount, beneficiary). Das Expires 4 April 2027 [Page 372] Internet-Draft Reality as a Cryptographic Dependency October 2026 The payment tool may first perform a real supported bounded verification, reservation, or reversible authorization. Protected confirmation R0 may then enable the later payment operation within the originally authorized maximum envelope. A.19.26. E19.26 Required Invariants The frozen core of E19 includes: 1. proposal or tool-call generation is distinguishable from effect-capable invocation; 2. the protected tool identity and effect-relevant scope can be bound to authority; 3. staged embodiments obtain protected evidence from a real bounded tool interaction; 4. later tool authority may depend upon accepted prior evidence; 5. the proposing agent cannot self-satisfy protected approval merely by emitting a tool call; 6. receipt replay or duplicate invocation can be controlled where required; and 7. equivalent unprotected tool paths are addressed where non- bypassability is required. 2 E20 – PROGRESSIVE CREDENTIAL RELEASE AND RECEIPT-GATED AU- THORITY EXPANSION A.20. E20 — Progressive Credential Release and Receipt-Gated Authority Expansion A.20.1. E20.1 Purpose E20 provides a staged credential architecture in which a computational system need not receive the maximum credential authority required for a contemplated operation at the outset. Instead, the system may initially expose only a bounded, audience- specific, time-limited, objectspecific, operation-specific, surrogate, non-bearer, single-use, hardware-backed, or otherwise constrained credential. Successful protected use of the bounded credential may produce an ECR. A PED may validate the receipt and then permit a broader credential, stronger capability, additional key material, larger privilege set, or final execution authority. A representative relationship is: Cred0 → real bounded use → R0 → Cred1 → · · · → Credn . A.20.2. E20.2 Credential Object and Scope A phase-specific credential object may be denoted: Credi . Its effective privilege set may be denoted: Σi . Das Expires 4 April 2027 [Page 373] Internet-Draft Reality as a Cryptographic Dependency October 2026 The maximum authority permitted for the Candidate Act may be: Σmax . The PED may enforce: Σi ⊆ Σmax . Progressive release may additionally satisfy: Σ0 ⊂ Σ1 ⊂ · · · ⊆ Σmax , where monotonic privilege expansion is appropriate. A.20.3. E20.3 Credential Forms The credential may comprise or be implemented as: * API token; * capability; * signing permission; * cryptographic key; * key share; * transaction authorization; * session token; * scoped access token; * audience-bound token; * proof-of-possession token; * device-bound authenticator; * hardware-unsealed secret; * certificate; * database credential; * cloud role; * service-account authority; Das Expires 4 April 2027 [Page 374] Internet-Draft Reality as a Cryptographic Dependency October 2026 * temporary elevation; * network capability; * command authorization; * or equivalent machine-verifiable authority. The architecture is not limited to a particular authentication or authorization protocol. A.20.4. E20.4 Credential Surrogate The agent may receive a surrogate or reference that is not independently usable as the underlying credential. The surrogate may identify: * protected credential record; * intended service; * permitted operation; * destination; * phase; * expiration; * nonce; * required receipt state; and * maximum authority ceiling. A protected broker may exchange, resolve, unwrap, or translate the surrogate only after the applicable finality predicates are satisfied. A.20.5. E20.5 No Unrestricted Credential in Agent Memory In one variation, the unrestricted credential is never exposed to: * model context; * agent scratch state; * ordinary process memory; * tool argument text; Das Expires 4 April 2027 [Page 375] Internet-Draft Reality as a Cryptographic Dependency October 2026 * prompt; * application logs; or * untrusted runtime storage. The PED, HSM, TEE, secure element, privileged broker, or destination-side component retains the sensitive credential material. A.20.6. E20.6 Initial Credential Ceiling Before releasing Cred0 , the PED determines an authority ceiling: Σmax . The ceiling may bind: * destination or audience; * methods; * amount; * recipient; * object; * namespace; * data type; * device; * command class; * time window; * total uses; * transaction count; * cumulative value; * geographic region; * purpose; and * other protected conditions. Receipt success cannot enlarge the credential beyond the independently authorized ceiling. Das Expires 4 April 2027 [Page 376] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.20.7. E20.7 Bounded Credential Phase Phase 0 may release a credential having only the authority required for the bounded real interaction. Examples include: * read metadata but not modify; * access one object but not a namespace; * send to one verified recipient but not arbitrary recipients; * authorize a bounded reservation but not full settlement; * operate one device within a limited range; * call one API method but not administrative methods; * access a redacted dataset but not raw data; or * decrypt only a demonstration portion. A.20.8. E20.8 Credential Use at a Protected Boundary The bounded credential may be consumed or presented only through: * tool gateway; * network proxy; * API gateway; * secure monitor; * HSM; * TEE; * device controller; * destination-side verifier; * payment gateway; * database proxy; or * another protected enforcement component. The component may verify both the credential and the exact Candidate Act or authorized scope. Das Expires 4 April 2027 [Page 377] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.20.9. E20.9 Real Use and Credential Receipt After the bounded credential is used, the destination or protected observer may return R0 proving one or more of: * correct destination; * credential acceptance; * correct audience; * expected method; * bounded state transition; * successful protected session establishment; * hardware identity; * transaction state; * storage state; * recipient state; or * another required condition. The receipt may be cryptographically bound to Cred0 without revealing the credential secret itself. A.20.10. E20.10 Credential Upgrade Gate A credential upgrade gate validates whether the next credential state may be made available. A representative predicate is: U pgradei+1 = V alid(Ri ) ∧ CredentialM atch(Ri , Credi ) ∧ W ithinCeiling(Σi+1 , Σmax ) ∧ P olicyCurrent ∧ RevocationClear. Where protected human approval is required, the corresponding approval predicate is conjoined. A.20.11. E20.11 Receipt-Derived Credential Material The next credential or key material may be cryptographically derived from the prior receipt: Ki+1 = KDF (Kroot , DA , H(Ri ), Encode(Σi+1 )). Alternatively, the receipt may cause: Das Expires 4 April 2027 [Page 378] Internet-Draft Reality as a Cryptographic Dependency October 2026 * an HSM to unseal a credential; * a key share to become available; * a broker to mint a scoped token; * a secure element to sign a next-phase assertion; * a destination to activate a privilege bit; or * a protected database to advance credential state. A.20.12. E20.12 Destination-Bound Credential A credential may be valid only for a bound destination: Audience(Credi ) = Ddest . A receipt from Destination A must not enable a credential usable against Destination B unless protected policy explicitly authorizes the change. A.20.13. E20.13 Operation-Bound Credential The credential may bind one method or operation class. For example: M ethod(Cred0 ) = READ_M ET ADAT A, while a later credential may authorize: M ethod(Cred1 ) = W RIT E_OBJECT. The initial credential therefore cannot be repurposed for a higher- consequence operation. A.20.14. E20.14 Single-Use Credential A credential may be one-time: U seCount(Credi ) ≤ 1. Protected state records consumption atomically with effectuation where duplicate use would be unsafe. A.20.15. E20.15 Cumulative-Use Credential Other implementations may permit multiple bounded uses while enforcing: ∑ u Ef f ectk ≤ Limit(Credi ). k=1 Examples include a cumulative spending limit, total number of recipients, total data bytes, or total device operations. A.20.16. E20.16 Time-Bound Credential The credential may be valid only for: tstart ≤ t ≤ texpiry . Das Expires 4 April 2027 [Page 379] Internet-Draft Reality as a Cryptographic Dependency October 2026 A successful old receipt does not necessarily reactivate an expired credential. A.20.17. E20.17 Human Approval of Credential Expansion A protected human may approve an authority expansion after inspecting: * prior real use; * destination receipt; * present credential scope; * requested next scope; * cumulative prior effects; * risk and provenance state; * expiration; * recipient or account; and * consequence of the expanded authority. The approval may bind Σi+1 rather than merely state a generic “approve.” A.20.18. E20.18 Automatic Credential Expansion Where policy permits: V alid(Ri ) ∧ RiskAcceptablei ∧ W ithinCeiling(Σi+1 , Σmax ) ⇒ AutoU pgradei+1 . The protected automatic authority remains independent of the agent’s self-assertion. A.20.19. E20.19 Hybrid Credential Expansion A sensitive expansion may require: AutoP olicyP assi ∧ HumanApprovali ∧ V alid(Ri ). A threshold construction may also require shares from the PED, user device, HSM, destination, or enterprise authority. Das Expires 4 April 2027 [Page 380] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.20.20. E20.20 Credential Downgrade The architecture is not limited to privilege expansion. Protected policy may reduce: Σi+1 ⊂ Σi when: * risk increases; * taint increases; * receipt quality decreases; * policy changes; * destination changes; * anomaly is detected; * time approaches expiry; or * a human restricts scope. A.20.21. E20.21 Credential Revocation At any phase: Revoked(Credi ) = T RU E may prevent both further use of that credential and derivation of later authority. Prior successful receipts do not override current revocation state. A.20.22. E20.22 Credential Rotation A new phase may rotate rather than enlarge authority. The new credential may have the same nominal scope but: * a different key; * different nonce; * new audience; * fresh expiration; * updated device binding; or * updated policy epoch. This may reduce the value of stolen or stale credential material. Das Expires 4 April 2027 [Page 381] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.20.23. E20.23 Split Credential Material A credential may be divided into shares held by separate protected components. Full authority may require: m-of-n shares, or a role- constrained threshold. A validated receipt may cause one missing share to become available without exposing the entire reconstructed credential to the agent. A.20.24. E20.24 Hardware-Rooted Credential Release A secure processor may store the root credential or key and accept only: * authorized Candidate Act digest; * current phase; * valid receipt digest; * destination identity; * current policy epoch; * current revocation epoch; and * optional human approval evidence. If accepted, hardware may produce a one-operation authenticator instead of returning the root credential. A.20.25. E20.25 Software Broker Variation A privileged credential broker may expose an IPC interface to the agent. The agent submits: * Candidate Act identifier; * surrogate; * requested operation; * destination; * phase; and * receipt reference. The broker verifies protected state and either performs the authenticated operation itself or releases only the narrowly scoped authority required. Das Expires 4 April 2027 [Page 382] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.20.26. E20.26 Credential Theft Resistance A stolen phase credential may be made unusable outside its expected context by binding it to: * device; * process; * hardware key; * destination; * nonce; * session; * Candidate Act; * phase; * transaction; * time; or * another protected condition. A.20.27. E20.27 Crash and Unknown Credential Use If a request may have consumed a one-time credential but confirmation is lost, the system may enter an indeterminate state. Before minting a replacement credential, the PED may reconcile: * destination use state; * transaction state; * token nonce; * HSM counter; * protected log; * resource version; or * provider receipt. This prevents replacement authority from accidentally duplicating the prior consequence. Das Expires 4 April 2027 [Page 383] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.20.28. E20.28 SEND Example An agent initially receives or references a capability usable only to send a protected trailer to a specified recipient. The receiving endpoint returns R0 . After verification, the PED may activate a second capability authorizing the complete message or file, but still only to that recipient and within the approved content envelope. A.20.29. E20.29 Payment Example An agent may initially receive authority only for a beneficiary verification, bounded reservation, or limited supported transaction. A protected receipt then permits a later payment credential within: Σmax , which may encode maximum amount, beneficiary, currency, rail, and expiration. A.20.30. E20.30 Required Invariants The frozen core of E20 includes: 1. the system can withhold maximum credential authority at the outset; 2. phase credentials can be bounded to protected scope; 3. successful bounded real use can produce protected evidence; 4. later credential authority may depend upon accepted prior evidence; 5. receipt success cannot exceed the independently authorized maximum authority ceiling; 6. the unrestricted credential need not be exposed to the proposing agent; 7. revocation, expiry, replay, duplicate use, and indeterminate use can be handled by protected state; and 8. software-only, hardware- rooted, and split implementations are all contemplated. 3 E21 – RECEIPT-GATED DATA EXPORT, PROGRESSIVE DISCLOSURE, AND CRYPTOGRAPHIC RELEASE A.21. E21 — Receipt-Gated Data Export, Progressive Disclosure, and Cryptographic Release A.21.1. E21.1 Purpose E21 applies staged effectuation to export, disclosure, transfer, publication, replication, sharing, or release of protected data. The architecture distinguishes: * authority to prepare data; * authority to move ciphertext or a bounded sample; Das Expires 4 April 2027 [Page 384] Internet-Draft Reality as a Cryptographic Dependency October 2026 * authority to disclose a limited subset; * authority to make data usable by a recipient; and * authority to complete the full authorized export. A representative relationship is: X0 → R0 → X 1 → R1 → · · · → X n , where the stages represent progressively broader real disclosure, transfer, or usability within an authorized export envelope. A.21.2. E21.2 Authorized Export Object Let: Xmax denote the maximum protected data object, set, stream, record class, file collection, model artifact, database selection, or information envelope authorized for the Candidate Act. A phase- specific export subset or release may be: Xi . Protected policy may require: Xi ⊆ Xmax . Where progressive disclosure is monotonic: X0 ⊂ X1 ⊂ · · · ⊆ Xmax . A.21.3. E21.3 Export Envelope Formation Before release, the PED may bind an export envelope identifying: * data object or selection; * record set; * schema; * source; * destination; * recipient; * purpose; * allowed transformations; Das Expires 4 April 2027 [Page 385] Internet-Draft Reality as a Cryptographic Dependency October 2026 * sensitivity class; * allowed fields; * maximum record count; * maximum bytes; * jurisdiction; * retention conditions; * encryption requirements; * permitted recipients; * policy epoch; * expiration; and * maximum cumulative disclosure. A.21.4. E21.4 Export Staging Modes Protected policy may choose: 1. single-phase full export; 2. schema or manifest first; 3. redacted sample first; 4. encrypted sample first; 5. bounded record subset first; 6. ciphertext-first full transport with withheld key; 7. progressive chunk release; 8. progressive field release; 9. progressive recipient release; 10. progressive jurisdiction or region release; 11. protected human approval; or 12. automatic/hybrid progression. A.21.5. E21.5 Real Bounded Export Effect The first stage must create a real effectuation-relevant event where the staged architecture requires real bounded effect. Examples include: * actual delivery of a protected sample to the intended destination; * actual storage of ciphertext in the intended recipient environment; * actual transfer of a cryptographic manifest; * actual release of a bounded record subset; * actual destination-side processing of an encrypted test object; Das Expires 4 April 2027 [Page 386] Internet-Draft Reality as a Cryptographic Dependency October 2026 * actual creation of a protected receiving namespace; or * actual recipient verification using the real export path. A sender-local preview alone need not satisfy the trial condition. A.21.6. E21.6 Export Manifest The system may construct a protected manifest containing: * dataset or object identifier; * schema digest; * record-count commitment; * field list or field commitment; * source digest; * chunk hashes; * classification; * encryption metadata; * destination; * recipient identity; * retention or handling policy reference; * policy epoch; and * Candidate Act binding. The manifest may permit a recipient to verify later phases without revealing the entire data content. A.21.7. E21.7 Redacted or Low-Sensitivity Trial A first real export may contain: * redacted fields; * masked identifiers; * aggregate statistics; * synthetic or substituted values; Das Expires 4 April 2027 [Page 387] Internet-Draft Reality as a Cryptographic Dependency October 2026 * low-sensitivity records; * bounded rows; * bounded columns; * schema only; or * another reduced-disclosure representation. The reduction technique is implementation dependent and must not be assumed to provide a particular privacy guarantee unless independently established. A.21.8. E21.8 Ciphertext-First Export The full or partial data object may be transported as ciphertext before semantic release. The destination may receive: EncK (Xmax ) while lacking sufficient key material to decrypt the protected content. After the destination returns a valid receipt R0 , the PED may release: * decryption key; * key share; * unwrap authority; * hardware unseal command; * object-specific capability; or * another cryptographic release condition. This separates transport effect from semantic disclosure. A.21.9. E21.9 Progressive Chunk Export The data may be divided: Xmax = X (1) ∪ X (2) ∪ · · · ∪ X (n) . After protected acceptance of chunk k, a receipt may authorize chunk k + 1. Each chunk may be bound to: * overall manifest; * sequence; * recipient; * destination; Das Expires 4 April 2027 [Page 388] Internet-Draft Reality as a Cryptographic Dependency October 2026 * hash; * encryption context; * phase; and * cumulative disclosure ceiling. A.21.10. E21.10 Progressive Field Release Instead of chunking by bytes, disclosure may be phased by semantic field. For example: * Phase 0: schema and non-sensitive fields; * Phase 1: pseudonymous identifiers; * Phase 2: selected operational fields; * Phase 3: additional protected fields; and * final phase: maximum authorized field set. The later field set may depend upon protected evidence that earlier release reached the intended recipient and policy state remains valid. A.21.11. E21.11 Progressive Record Release For a dataset of records: R = {r1 , r2 , . . . , rN }, the PED may authorize only a subset: R0 ⊂ R. Receipt-confirmed processing may permit: R1 , R2 , . . . until the maximum authorized export set is reached. A.21.12. E21.12 Cumulative Disclosure Fraction Where a quantitative disclosure fraction is useful, define: |Xreleased,i | λi = . |Xmax | The system may require: 0 ≤ λi ≤ 1. For progressive release: λi+1 ≥ λi , unless rollback or revocation causes the usable disclosure state to decrease. The metric may represent bytes, records, fields, objects, or another policy-defined quantity. Das Expires 4 April 2027 [Page 389] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.21.13. E21.13 Destination Receipt A destination receipt may prove one or more of: * correct recipient identity; * correct destination service; * successful ciphertext receipt; * successful integrity verification; * correct storage namespace; * destination attestation; * policy-compatible region; * protected key possession; * processing readiness; * accepted retention configuration; or * other technical state. The receipt need not prove future behavior beyond what the protected evidence actually supports. A.21.14. E21.14 Destination Handling-State Evidence Where technically available, the destination may attest a handling state such as: * encryption enabled; * protected execution environment active; * required storage class active; * expected software measurement; * key isolated in hardware; * access-control state; * destination region; * data-loss-prevention policy present; or Das Expires 4 April 2027 [Page 390] Internet-Draft Reality as a Cryptographic Dependency October 2026 * retention timer configured. Such evidence may be one predicate among several and does not inherently guarantee compliance or future behavior. A.21.15. E21.15 Receipt-Gated Next Export Phase A representative next-phase predicate may be: ExportEnablei+1 = V alid(Ri ) ∧ M atchDestination(Ri ) ∧ W ithinExportEnvelope(Xi+1 ) ∧ P olicyCurrent ∧ RevocationClear. Where human approval is required, the corresponding approval predicate is added. A.21.16. E21.16 Human Approval After Trial Export A protected UI may show: * what was actually exported; * destination identity; * receipt status; * current cumulative disclosure; * requested next data subset; * sensitivity/classification; * recipient; * jurisdiction or region; * encryption state; and * consequence of completing the next phase. The human may approve, restrict, delay, or deny the next release. A.21.17. E21.17 Automatic Export Progression Where protected policy permits: V alid(Ri ) ∧ ExportP olicyP assi ∧ RiskAcceptablei ⇒ AutoExporti+1 . The automatic policy component may use current data classification, destination state, receipt quality, taint/provenance, jurisdiction, cumulative volume, and other protected predicates. Das Expires 4 April 2027 [Page 391] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.21.18. E21.18 Hybrid Export Progression A higher-assurance export may require: V alid(Ri ) ∧ AutoP olicyP assi ∧ HumanApprovali or a multi-authority threshold. Different approval requirements may apply to different data classes within the same export. A.21.19. E21.19 Multi-Recipient Export Where the same data is intended for recipients: D1 , D 2 , . . . , D m , each recipient may have independent: * receipt state; * permitted data subset; * key material; * jurisdiction condition; * policy state; * revocation state; and * completion state. A receipt from one recipient need not authorize release to another. A.21.20. E21.20 Destination Change If the destination changes after Phase 0, prior receipt R0 need not remain sufficient. The protected system may require: * new destination validation; * new trial export; * fresh human approval; * new key material; * new export envelope; or * final denial. A.21.21. E21.21 Jurisdiction-Aware Progression The export envelope may bind a jurisdiction or approved region. If current destination evidence indicates: Das Expires 4 April 2027 [Page 392] Internet-Draft Reality as a Cryptographic Dependency October 2026 Regioncurrent ∈ / Regionallowed , the next export phase remains blocked. This is a technical enforcement predicate; legal classification or legal sufficiency is determined separately. A.21.22. E21.22 Taint and Provenance-Aware Export Taint or provenance may affect: * whether export is allowed; * maximum phase size; * permitted destination; * required approval; * encryption requirement; * recipient class; * logging requirement; or * whether release must remain local-only. A receipt proving successful delivery does not erase or cleanse protected taint state unless policy expressly defines such a transition. A.21.23. E21.23 Export Encryption-Key Progression A recipient may obtain progressively broader decryption authority: K0rel , K1rel , . . . , Knrel . Each release key may be bound to: * data subset; * recipient; * phase; * prior receipt; * policy epoch; * expiry; and Das Expires 4 April 2027 [Page 393] Internet-Draft Reality as a Cryptographic Dependency October 2026 * destination hardware identity. A later key may be derived only after the preceding receipt is validated. A.21.24. E21.24 Object-Specific Keying Different exported objects may have distinct keys. Compromise of one object key need not reveal other objects. For example: Kj = KDF (Kroot , DA , ObjectIDj , Recipientj ). Receipt-gated release may then expose only the key corresponding to an authorized object. A.21.25. E21.25 Hardware-Rooted Data Release A hardware component may: * retain export keys; * verify destination attestation; * verify receipt digest; * enforce phase counter; * decrypt only authorized fields; * encrypt only authorized chunks; * release key shares; or * directly drive network/storage egress. The proposing application cannot bypass the hardware by reading the protected root key. A.21.26. E21.26 Network-Enforced Export A DPU, SmartNIC, secure NIC, firewall, gateway, or service mesh may enforce: * destination; * data amount; * protocol; * recipient; * phase; Das Expires 4 April 2027 [Page 394] Internet-Draft Reality as a Cryptographic Dependency October 2026 * connection identity; * cryptographic authorization; and * receipt-dependent continuation. Direct unmediated egress paths may be restricted where non-bypassability is required. A.21.27. E21.27 Storage-to-Network Export A protected storage controller or data gateway may keep the source object encrypted and release only phase-authorized data to the network path. This may prevent an agent from reading the full plaintext merely because it is authorized to initiate an export. A.21.28. E21.28 Database Export A query may select a maximum authorized result set. The first phase may release: * schema; * count; * aggregate; * limited rows; * masked fields; or * encrypted result segment. Verified destination receipt may then enable larger portions of the result while preserving the maximum query/export envelope. A.21.29. E21.29 Model and Vector-State Export The export object may be: * model weights; * adapter; * embedding collection; * vector database entries; * model memory; * checkpoint; Das Expires 4 April 2027 [Page 395] Internet-Draft Reality as a Cryptographic Dependency October 2026 * activation data; * training subset; * inference trace; or * another protected AI artifact. Release may progress by shard, layer, tenant, object class, or encrypted segment. A.21.30. E21.30 Streaming Export For a stream, the system may authorize bounded windows: W0 , W 1 , . . . , W n . Each window may require continuation evidence before the next window becomes available. The system may terminate mid-stream if policy, revocation, receipt state, destination state, or risk changes. A.21.31. E21.31 Crash and Indeterminate Export If a data phase may have been delivered but confirmation is lost, the system may enter an indeterminate state. Before retransmission, the PED may reconcile using: * chunk identifier; * recipient storage state; * object digest; * transport acknowledgement; * destination receipt; * protected send journal; * transaction identifier; or * cumulative disclosure counter. This reduces accidental duplicate release and protects cumulative limits. A.21.32. E21.32 Receipt Consumption and Replay Where one receipt permits only one next-stage release: Consumed(Ri ) = T RU E Das Expires 4 April 2027 [Page 396] Internet-Draft Reality as a Cryptographic Dependency October 2026 may be committed with the state transition. Replay of a valid old destination receipt must not independently trigger another export phase. A.21.33. E21.33 Revocation During Export If authorization is revoked after some data has already been disclosed, future unreleased phases remain blocked. Where technically possible, the system may additionally: * revoke a pending key; * expire a decryption capability; * delete staged ciphertext; * cancel queued transfers; * disable future stream windows; or * issue a compensating deletion request. The architecture does not assume that already disclosed plaintext can always be recovered. A.21.34. E21.34 Anti-Bypass Protected staged export may be bypassed if the agent can use: * direct socket; * alternate storage bucket; * unprotected object URL; * raw database connection; * clipboard; * file system path; * alternate cloud credential; * debugging interface; * message queue; * alternate network interface; or Das Expires 4 April 2027 [Page 397] Internet-Draft Reality as a Cryptographic Dependency October 2026 * another equivalent data-egress path. Where non-bypassability is required, such paths may be closed, mediated, cryptographically restricted, or subjected to equivalent finality controls. A.21.35. E21.35 SEND Example A sensitive file intended for a recipient may first release: * protected trailer; * manifest; * ciphertext header; * encrypted sample; * or bounded file segment. After the recipient returns valid protected evidence, the remaining file or decryption material is released. A.21.36. E21.36 Payment-Data Example A financial system may export a bounded transaction manifest or beneficiary-verification dataset before releasing a complete settlement instruction dataset or broader payment batch. The receipt-gated mechanism may govern data disclosure independently from the separate authority required to settle funds. A.21.37. E21.37 Required Invariants The frozen core of E21 includes: 1. the maximum authorized export envelope is distinguishable from any individual release phase; 2. staged embodiments perform a real bounded transfer, disclosure, or recipient-side processing event; 3. protected receipt evidence may gate broader release; 4. later disclosure cannot exceed the independently authorized maximum export envelope; 5. transport of ciphertext and semantic disclosure may be separately controlled; 6. destination, recipient, policy, revocation, and cumulative disclosure state may remain bound across phases; 7. already disclosed plaintext is not presumed reversible; and 8. equivalent egress paths are addressed where non-bypassability is required. 4 FROZEN RELATIONSHIP AMONG E19, E20, AND E21 E19, E20, and E21 address three different authority surfaces. Proposal → bounded tool authority → real tool effect → Ri → broader tool authority. Das Expires 4 April 2027 [Page 398] Internet-Draft Reality as a Cryptographic Dependency October 2026 Cred0 → bounded real use → R0 → Cred1 → · · · . X0 → R0 → X1 → · · · → Xmax . The embodiments may operate independently or together. For example, an AI agent may use E19 to request a tool, E20 to obtain a phase- bounded credential for that tool, and E21 to govern what data the tool is permitted to export. The combined architecture need not expose unrestricted credential material, unrestricted data, or unconditional tool authority to the proposing agent. A.22. E22 — Receipt-Gated Storage Release, Provisional Persistence, and Progressive Visibility A.22.1. E22.1 Purpose E22 applies staged effectuation to storage operations in which data, objects, model outputs, files, records, media, encrypted payloads, configuration state, or other persistent material may be written or staged before becoming fully durable, externally visible, retrievable, replicated, indexed, discoverable, decryptable, or otherwise effective for its intended consumers. The storage embodiment distinguishes among at least three logically different events: 1. data reaching a storage-capable component; 2. a bounded or provisional storage state being successfully established; and 3. the object becoming fully promoted, durable, visible, replicated, routable, discoverable, or semantically usable. A representative causal chain is: Candidate Storage Act → Protected Validation → Bounded/Provisional Write → R0store → Promotion Authority → Full Storage Effect. A storage write request, successful transmission of bytes to a storage process, or ordinary acknowledgement from an unprotected application need not itself establish authority for final persistent release. A.22.2. E22.2 Storage Candidate Act Formation The Candidate Act may identify one or more of: * object identifier, key, path, row, block range, volume, bucket, namespace, repository, tenant, account, or storage class; * payload digest or content commitment; * expected length, content type, compression form, encryption form, and encoding; Das Expires 4 April 2027 [Page 399] Internet-Draft Reality as a Cryptographic Dependency October 2026 * intended durability class; * replication factor or replica set; * visibility class; * discoverability or indexing status; * retention policy; * deletion or overwrite behavior; * access-control state; * decryption or unwrap authority; * target region, jurisdiction, device, controller, or service; * intended consumer or downstream application; and * maximum permitted consequence. The protected maximum storage envelope may be denoted: Σmax . A phase-specific permitted storage envelope may be: Σi ⊆ Σmax . A.22.3. E22.3 Storage Effect Dimensions A storage operation may be bounded independently along one or more technical dimensions, including: * number of bytes; * number of objects; * number of rows, pages, extents, or blocks; * namespace scope; * replica count; * geographic region; * retention duration; Das Expires 4 April 2027 [Page 400] Internet-Draft Reality as a Cryptographic Dependency October 2026 * access-control scope; * indexing visibility; * external publication state; * decryption state; * storage tier; * tenant visibility; * cache propagation; * backup propagation; or * downstream processing eligibility. Thus a “partial storage effect” need not mean only a smaller byte count. It may instead mean a complete object stored under deliberately restricted visibility or usability conditions. A.22.4. E22.4 Provisional Storage State A first phase may establish a real but bounded storage state, including: * quarantine namespace; * provisional bucket; * temporary object identifier; * non-indexed record; * non-public object version; * isolated replica; * encrypted object with withheld unwrap material; * short-retention object; * write-only object; * shadow index entry; * immutable staging area; Das Expires 4 April 2027 [Page 401] Internet-Draft Reality as a Cryptographic Dependency October 2026 * protected local persistent state not yet promoted globally; or * another storage state whose consequence is narrower than the full requested release. The provisional state is a real persistent or storage-system-recognized effect. It is not merely a simulation of writing the object. A.22.5. E22.5 Storage Effect Descriptor The PED may form a protected storage-phase descriptor binding the Candidate Act to the permitted phase. The descriptor may include: * Candidate Act digest; * object digest; * object identifier; * destination storage component; * namespace; * permitted byte range; * permitted replica set; * visibility state; * required persistence semantics; * retention state; * encryption state; * permitted promotion target; * required ECR issuer; * nonce and expiry; * policy epoch and revocation state; and * the next permitted storage transition. A.22.6. E22.6 Real Bounded Write The storage sink performs the bounded write. Examples include: Das Expires 4 April 2027 [Page 402] Internet-Draft Reality as a Cryptographic Dependency October 2026 * writing the complete object into a quarantine namespace; * writing only the first protected fragment; * writing a complete ciphertext while withholding the decryption key; * writing one replica before wider replication; * persisting a candidate model-state update in an isolated vector namespace; * writing a media object but withholding external publication; * committing a configuration artifact into protected storage but not making it active; or * persisting an export package in a non-routable storage class. A.22.7. E22.7 Persistence Evidence The storage system or protected observer may produce evidence of the actual stored state. Such evidence may include: * durable log sequence number; * object version ID; * storage transaction ID; * object digest verified after write; * block checksum set; * Merkle root; * replica acknowledgement set; * fsync or equivalent durable-write confirmation; * device-level flush confirmation; * storage-controller attestation; * secure-element or HSM-backed object state; * immutable-log reference; Das Expires 4 April 2027 [Page 403] Internet-Draft Reality as a Cryptographic Dependency October 2026 * object-lock state; * encryption-state confirmation; or * destination-side protected acknowledgement. Let the protected storage observation at phase i be: Oistore . The corresponding receipt may be: Ristore . A.22.8. E22.8 Persistence Acceptance Predicate Continuation may require: StorageAccepti = V alid(Ristore ) ∧ M atchObjecti ∧ M atchDestinationi ∧ Integrityi ∧ Durabilityi ∧ P olicyCurrenti ∧ RevocationCleari . Where a particular storage class does not require durability, the relevant predicate may instead verify another protected state such as correct quarantine, encryption, or destination placement. A.22.9. E22.9 Promotion Authority After successful validation, the PED may derive or release authority to promote the stored object. Promotion may comprise: * moving or relabeling the object into a production namespace; * expanding access controls; * making an object externally retrievable; * publishing an object URL; * indexing the object; * replicating it to additional nodes or regions; * promoting a vector or model-state record into shared memory; * releasing a decryption or unwrap key; * enabling downstream processing; * increasing retention; or Das Expires 4 April 2027 [Page 404] Internet-Draft Reality as a Cryptographic Dependency October 2026 * changing a provisional object into a final durable object. A promotion capability may be denoted: Ciprom . The capability may bind: H(Ristore ) so that another object’s receipt cannot authorize promotion. A.22.10. E22.10 Progressive Replication A large storage operation may progress through replica stages: 1 → 2 → 3 → · · · → rmax . Let: Ri denote the set of replicas confirmed after phase i. Protected policy may require: Ri ⊆ Ri+1 ⊆ Rmax . Each replication stage may produce its own receipt or aggregate receipt. A.22.11. E22.11 Progressive Visibility Storage visibility may progress through states such as: quarantine → internal → tenant-visible → authorized external → public. No particular progression is required. The important property is that a broader visibility state may depend upon protected evidence from a narrower real storage state. A.22.12. E22.12 Ciphertext-First Storage A full object may be physically present in storage while semantic usability remains blocked because required decryption material is withheld. Let the stored ciphertext be: CTF = EncKF (F ). The storage system may persist CTF before KF or an unwrap capability becomes available. Following valid storage receipt and any additional protected approval: V alid(R0store ) → Release(KF ) or an equivalent key-unwrapping condition may occur. This variation reduces transfer latency while preserving staged semantic release. Das Expires 4 April 2027 [Page 405] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.22.13. E22.13 Human Approval After Storage Confirmation A human may approve promotion only after reviewing protected evidence that the intended object is actually present at the expected destination. The protected interface may show: * object identity and digest; * storage destination; * actual stored size; * encryption state; * jurisdiction or region; * retention and access state; * requested promotion consequence; and * the validated storage receipt. The approval artifact may be bound to H(Ristore ). A.22.14. E22.14 Automatic Promotion Where policy permits, valid persistence evidence may automatically enable promotion: V alid(Ristore ) ∧ StorageP olicyP assi ∧ RiskAcceptablei ⇒ P romotei+1 . A.22.15. E22.15 Hybrid Promotion A higher-assurance storage class may require both automated verification and human approval: StorageAccepti ∧ HumanApprovali ⇒ P romotei+1 . A.22.16. E22.16 Hardware-Enforced Storage Variation The Finality Sink may be implemented at or below a storage controller, SSD controller, secure storage processor, DPU, SmartNIC, DMA controller, memory controller, trusted I/O path, storage HSM, or equivalent hardware component. The hardware may enforce: * permitted object ranges; * namespace selection; Das Expires 4 April 2027 [Page 406] Internet-Draft Reality as a Cryptographic Dependency October 2026 * phase-specific key use; * replica authorization; * secure erase or retention state; * write-once state; * anti-rollback state; * authenticated promotion command; and * release of cryptographic material only after receipt validation. A.22.17. E22.17 Storage Controller Receipt A storage controller may sign or MAC a receipt containing: Ristore = P rotect(DA , ObjectID, ObjectDigest, V ersioni , StorageStatei , Counteri , Ni , Statusi ). The receipt may be generated only after the storage controller has reached the protected state identified in the receipt. A.22.18. E22.18 Crash After Provisional Write If a provisional write succeeds but the caller crashes before receiving confirmation, the system enters an indeterminate state rather than blindly repeating the write where duplication or overwrite would be harmful. A storage idempotency identifier may be: Iistore = H(DA ∥ ObjectID ∥ i ∥ Ni ). The storage sink may atomically associate Iistore with the persisted state. Recovery may establish whether the write: * was committed; * was not committed; * was committed under a particular object version; or * remains indeterminate. A.22.19. E22.19 Overwrite and Destructive Storage Operations For overwrite, deletion, truncation, or lifecycle transition, the trial phase may preserve reversibility by: Das Expires 4 April 2027 [Page 407] Internet-Draft Reality as a Cryptographic Dependency October 2026 * creating a new version rather than replacing the old one; * retaining a protected snapshot; * moving the object into quarantine; * marking for deletion without immediate erasure; * performing tombstone creation before physical deletion; or * requiring an additional receipt before irreversible destruction. A destructive final phase may remain unavailable until the reversible protected state is confirmed. A.22.20. E22.20 Storage Anti-Substitution A receipt for Object A must not authorize promotion of Object B. The PED or sink may verify: Digest(Ristore .Object) = Digest(Objectcandidate ). Likewise, a receipt for one namespace, region, tenant, or replica class must not be silently reused for another where those properties are material. A.22.21. E22.21 Alternate-Path Closure Equivalent storage-effect paths may include: * direct object-store API; * local filesystem path; * raw block device; * database BLOB path; * backup/restore path; * replication service; * admin console; * lifecycle engine; * CDN origin path; * cache promotion path; Das Expires 4 April 2027 [Page 408] Internet-Draft Reality as a Cryptographic Dependency October 2026 * direct storage credential; and * privileged driver or controller interface. Where non-bypassable staged storage finality is required, such paths are disabled, constrained, or subjected to equivalent protected controls. A.22.22. E22.22 SEND Example A sensitive file intended for a recipient may first be stored in a non-public encrypted staging object. The storage service returns a protected receipt proving object digest, destination, and persistence. Only then may the system generate or release a recipient-scoped retrieval capability or decryption material. Accordingly, persistence of the bytes does not itself complete the SEND consequence. A.22.23. E22.23 Payment Example A payment instruction file, settlement batch, or signed payment artifact may first be committed to protected staging storage. A storage receipt proves the exact batch digest and destination. Only after verification may the settlement system consume or expose the artifact to the paymentexecution path. Thus storage finality and payment finality may be chained without treating them as identical events. A.22.24. E22.24 Required Invariants Invariant 1. A storage request is distinguishable from the protected storage consequence. Invariant 2. A bounded or provisional storage state may be real and externally persisted without granting full promotion or visibility. Invariant 3. Where staged storage is required, broader promotion depends on protected evidence of the preceding storage state. Invariant 4. The receipt is bound to the relevant object and storage context. Invariant 5. Alternate storage paths cannot trivially bypass required promotion control. Invariant 6. Crash or receipt loss does not require blind duplicate writing. Invariant 7. Software, hardware, destination-side, or combined enforcement may implement the architecture. 2 E23 – RECEIPT-GATED ROBOTIC ACTUATION AND PROGRESSIVE PHYS- ICAL EFFECTUATION A.23. E23 — Receipt-Gated Robotic Actuation and Progressive Physical Effectuation Das Expires 4 April 2027 [Page 409] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.23.1. E23.1 Purpose E23 applies staged effectuation to robots, autonomous machines, industrial manipulators, mobile robots, drones, vehicles, machine tools, medical or laboratory automation, warehouse systems, construction equipment, home automation, and other cyber-physical systems capable of producing physical consequences. The principal architecture separates: 1. computational generation of a motion or device command; 2. authority to initiate a bounded physical effect; 3. protected observation of what actually happened; and 4. authority to continue or enlarge the physical consequence. A representative flow is: Proposed Physical Act → PED Validation → Bounded Actuation → Protected Physical Observation → R0phys → Continuation Authority. A.23.2. E23.2 Candidate Physical Act A robotic Candidate Act may bind: * actuator or joint identifier; * requested trajectory; * velocity, acceleration, jerk, torque, force, pressure, power, or energy envelope; * route, waypoint, position, or orientation; * gripper or tool state; * payload state; * proximity constraints; * geofence; * collision envelope; * time interval; * sensor requirements; * emergency-stop state; * expected effect; * maximum consequence envelope; and Das Expires 4 April 2027 [Page 410] Internet-Draft Reality as a Cryptographic Dependency October 2026 * required receipt or human approval class. Let the maximum authorized physical envelope be: Ωmax . A phase-specific physical envelope is: Ωi ⊆ Ωmax . A.23.3. E23.3 Physical Effect Is Not Command Acceptance A controller accepting a command does not necessarily establish that the physical consequence occurred as requested. The architecture may therefore distinguish: CommandAccepted ̸= P hysicalEf f ectConf irmed. For example, a motor controller may accept a 5◦ movement command while a jammed actuator moves only 0.5◦ . Accordingly, a protected continuation decision may depend upon physical observation rather than only software acknowledgement. A.23.4. E23.4 Phase-0 Physical Effect Selection The initial bounded act may be limited by: * angle; * displacement; * velocity; * duration; * torque; * force; * altitude; * route segment; * energy; * payload change; * number of actuators; * machine cell; Das Expires 4 April 2027 [Page 411] Internet-Draft Reality as a Cryptographic Dependency October 2026 * operating zone; * or another measurable physical dimension. The bounded phase should be sufficiently real to exercise the relevant physical execution path while remaining within a policy-selected consequence envelope. A.23.5. E23.5 Protected Physical Observer Physical-effect evidence may be obtained from one or more protected observers, including: * rotary or linear encoder; * inertial measurement unit; * force or torque sensor; * current or voltage sensor; * pressure sensor; * proximity sensor; * lidar, radar, sonar, camera, or depth sensor; * limit switch; * motor-controller telemetry; * wheel odometry; * GNSS or protected location source; * actuator internal state; * safety PLC; * independent supervisory controller; * or a remote trusted observer. The observer need not itself decide policy. It may produce authenticated evidence for protected evaluation. Das Expires 4 April 2027 [Page 412] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.23.6. E23.6 Expected and Observed Physical State Let the expected bounded physical state after phase i be: Xiphys and the protected observed state be: Oiphys . A generalized physical acceptance predicate may be: dphys (Oiphys , Xiphys ) ≤ εi , where dphys is a protected comparison function and εi is the allowed phase-specific tolerance. The function may evaluate multiple variables rather than a single scalar. A.23.7. E23.7 Multi-Dimensional Safety Envelope For a state vector: xi = [x1 , x2 , . . . , xk ]T , a protected safe set may be: Sisaf e . Continuation may require: xobs i ∈ Sisaf e . The safe set may incorporate position, velocity, temperature, force, load, current, proximity, or other measured variables. A.23.8. E23.8 Robotic Effect Confirmation Receipt A protected robotic receipt may bind: Riphys = P rotect(DA , ActuatorID, P hasei , Xiphys , Oiphys , SensorSeti , Ti , Ni , Statusi ). The receipt may be generated by a motor controller, safety processor, secure sensor hub, PLC, TEE, secure MCU, vehicle ECU, flight controller, robotic safety controller, or another protected component. A.23.9. E23.9 Automatic Continuation Where policy permits: V alid(Riphys ) ∧ Saf ei ∧ P olicyCurrenti ∧ RevocationCleari ⇒ Enable(Pi+1 ). The next phase may increase motion, velocity, distance, duration, payload interaction, or another physical consequence. Das Expires 4 April 2027 [Page 413] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.23.10. E23.10 Human Continuation Approval For sensitive physical acts, an authenticated human may review the protected result of the bounded movement before allowing broader operation. The approval interface may display: * requested action; * actual measured movement; * sensor confidence; * current physical state; * destination or route; * collision/safety status; * next proposed phase; and * consequence envelope. Human approval may be bound to the receipt digest and next-phase descriptor. A.23.11. E23.11 Hybrid Safety Approval A robotic system may require: V alid(Riphys ) ∧ AutomaticSaf etyP assi ∧ HumanApprovali ⇒ Continuei . This may be appropriate for high-consequence industrial, transportation, or human-proximate operations. A.23.12. E23.12 Progressive Motion A total requested trajectory Θ may be partitioned into: Θ = θ0 + θ1 + · · · + θn . Each component is a real effectuation phase. A valid receipt may be required before the next component becomes executable. Alternatively, the trajectory may be represented parametrically by q(t) and divided into protected time intervals: [t0 , t1 ], [t1 , t2 ], . . . , [tn−1 , tn ]. Continuation into interval i + 1 may depend upon protected evidence from interval i. Das Expires 4 April 2027 [Page 414] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.23.13. E23.13 Mobile Robot Route Segmentation A mobile robot route may be divided into waypoint or geofence segments: W0 → W1 → · · · → Wn . At each waypoint, protected evidence may confirm: * location; * orientation; * speed; * obstacle state; * route integrity; * communications status; * payload state; and * policy status. Only then may authority for the next route segment become available. A.23.14. E23.14 Drone / UAV Variation A UAV may be authorized initially for a bounded altitude, distance, speed, or waypoint. Protected telemetry and onboard attestation may determine whether subsequent segments are enabled. Examples include: * 2 meter climb before a larger ascent; * one waypoint before mission continuation; * a low-speed approach before final landing; * bounded sensor activation before broader collection; * bounded radio emission before extended communication; or * a return-to-safe-state phase after an indeterminate condition. A.23.15. E23.15 Vehicle Variation A vehicle-control Candidate Act may be phased by: Das Expires 4 April 2027 [Page 415] Internet-Draft Reality as a Cryptographic Dependency October 2026 * steering angle; * speed increase; * acceleration interval; * braking interval; * lane-change segment; * route segment; * geofence; or * subsystem activation. Protected vehicle state may be used to prevent later phases where observed behavior diverges materially from expected state. A.23.16. E23.16 Industrial Process Variation An industrial process may phase: * valve opening; * pressure increase; * heating; * flow rate; * motor speed; * conveyor activation; * machine-cell activation; * load switching; or * chemical dosing. Protected process measurements may gate broader operation. A.23.17. E23.17 Multiple Sensor Confirmation A phase may require a sensor quorum. Let sensor observations be: phys phys phys Oi,1 , Oi,2 , . . . , Oi,s . Protected continuation may require: Das Expires 4 April 2027 [Page 416] Internet-Draft Reality as a Cryptographic Dependency October 2026 ∑ s phys Accept(Oi,j ) ≥ ms . j=1 Different sensors may also be assigned different trust weights or mandatory roles. A.23.18. E23.18 Sensor Disagreement Where protected sensors disagree beyond a permitted threshold, the phase may enter: P HY SICAL_IN DET ERM IN AT E. The architecture may: * hold position; * reduce energy; * stop further actuation; * request another sensor reading; * engage a safety controller; * require human review; or * execute a protected safe-state act. A.23.19. E23.19 Bounded Safe-State Actuation A safe-state response may itself be a protected Candidate Act. Examples include: * brake; * power reduction; * controlled stop; * gripper release where safe; * return to known pose; * retreat from a hazard zone; * hover; * land; * close valve; or Das Expires 4 April 2027 [Page 417] Internet-Draft Reality as a Cryptographic Dependency October 2026 * isolate machinery. The architecture need not assume that “do nothing” is always the safest response. A.23.20. E23.20 Crash After Physical Effect A difficult state occurs where the physical effect occurs but the controlling software crashes before receipt processing. A blind reissue may duplicate motion. Recovery may therefore use: * actuator phase counter; * encoder position; * controller journal; * secure monotonic counter; * trajectory identifier; * hardware command sequence number; * sensor snapshot; or * independently observed machine state. The system resolves whether the phase was effected before authorizing retry or continuation. A.23.21. E23.21 Physical Rollback and Compensation Physical actions may be: * reversible; * partially reversible; * compensable; or * irreversible. Where reversal is possible, rollback may itself be receipt-gated. Where reversal is impossible, a compensating act may be used, such as braking, counter-motion, isolation, release, refund of consumed resource, or human escalation. A.23.22. E23.22 Energy-Bounded Effectuation The architecture may bind authority to a maximum energy envelope: Ei ≤ Emax . Das Expires 4 April 2027 [Page 418] Internet-Draft Reality as a Cryptographic Dependency October 2026 A phase may end when the permitted energy, force, duration, or movement budget is exhausted, even if the originating agent continues requesting action. A.23.23. E23.23 Hardware and Software Enforcement Robotic staged finality may be enforced by one or more of: * application controller; * ROS or equivalent middleware gate; * operating-system privileged service; * real-time controller; * safety PLC; * motor-control MCU; * secure element; * vehicle ECU; * flight controller; * FPGA/ASIC; * TEE/HSM; * independent safety processor; or * actuator-local control logic. A software PED may plan the phase while protected hardware retains the missing actuation authority. A.23.24. E23.24 Alternate-Path Closure The system may constrain bypass through: * raw motor commands; * debug interfaces; * maintenance mode; * direct CAN or fieldbus commands; * alternate radio controller; Das Expires 4 April 2027 [Page 419] Internet-Draft Reality as a Cryptographic Dependency October 2026 * direct GPIO/PWM access; * privileged robotics middleware; * actuator vendor API; * manual remote-control channel; or * recovery interface. Where such paths remain effect-capable, they may be placed under equivalent finality control. A.23.25. E23.25 SEND Example An autonomous robot may propose sending a location, image, or telemetry package. The SEND operation may independently use the communication staged-finality chain: bounded trailer, recipient receipt, then full payload. Physical actuation and communication therefore may each have their own protected continuation state. A.23.26. E23.26 Payment Example A delivery robot may propose a payment, toll, charging purchase, or service settlement. The payment Candidate Act remains distinct from the motion Candidate Act. Completion of a route segment does not itself authorize arbitrary payment; a protected receipt may instead become one predicate in the payment-specific finality decision. A.23.27. E23.27 Required Invariants Invariant 1. Command generation or command acceptance does not necessarily prove physical effect. Invariant 2. A bounded real physical effect is observed using protected evidence where such evidence is required. Invariant 3. Broader actuation remains unavailable until the required preceding physical state is accepted. Invariant 4. Continued actuation stays within the authorized maximum physical envelope. Invariant 5. Sensor disagreement or indeterminate physical state does not automatically authorize broader motion. Invariant 6. Crash recovery avoids blind duplicate physical action where duplication is unsafe. Invariant 7. The enforcement point may be software, firmware, hardware, or distributed. 3 E24 – HARDWARE ACTUATOR, PROTECTED SENSOR CONFIRMATION, AND RECEIPT-DERIVED MOTION AUTHORITY Das Expires 4 April 2027 [Page 420] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.24. E24 — Hardware Actuator, Protected Sensor Confirmation, and Receipt-Derived Motion Authority A.24.1. E24.1 Purpose E24 provides a more concrete hardware-rooted embodiment of E23 in which the effectuation chain is enforced at or near the actuator itself. The embodiment is intended to demonstrate technical feasibility in a form where later physical motion can be electrically, cryptographically, logically, or microarchitecturally unavailable until a protected sensor-confirmed receipt from the preceding motion phase has been accepted. A representative architecture is: Application/Agent → PED or Safety Controller → C0act → Actuator Controller → Bounded Motion → Protected Sensor Hub → R0act → Secure Continuation Logic → C1act . A.24.2. E24.2 Example Hardware Components A non-limiting implementation may contain: * host CPU or application processor; * AI accelerator; * safety processor or secure MCU; * motor-control MCU; * power stage; * actuator or motor; * encoder; * current sensor; * limit switch; * inertial sensor; * secure element, TPM, TEE, or HSM; * protected NVRAM or monotonic counter; * authenticated internal bus; and * hardware emergency-stop or safety interlock. Several functions may be integrated into one SoC or distributed among components. Das Expires 4 April 2027 [Page 421] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.24.3. E24.3 Root of Actuation Authority A protected hardware component may retain a root secret: act KR . The host application need not possess this secret. A phase-specific actuator authority may be derived as: Kiact = KDF (KR act , DA , ActuatorID, P hasei , act Envelopei , Ni , Epochi , H(Ri−1 )). For the initial phase, the prior-receipt field may be omitted or replaced by an initialization value. A.24.4. E24.4 Actuation Capability A bounded actuation capability may be: Ciact = P rotectKiact (Di , ActuatorID, Envelopei , Expiryi ). The motor controller accepts a phase command only if the protected capability verifies and the requested act lies within the authorized envelope. A.24.5. E24.5 Hardware Latch A protected hardware latch may represent next-phase availability: i+1 ∈ {0, 1}. Lact Initially: Lact i+1 = 0. Only after protected validation of the preceding effect receipt may the secure controller cause: i+1 ← 1. Lact While Lact i+1 = 0, the next-phase command is not executable through the protected actuator path. A.24.6. E24.6 Concrete 90-Degree Example Assume a requested movement of: Θreq = 90◦ . The first bounded phase permits: θ0 = 5 ◦ . The protected encoder measures: θ0obs = 4.98◦ . Let the permitted tolerance be: ε0 = 0.10◦ . The observation satisfies: |θ0obs − θ0 | = 0.02◦ ≤ 0.10◦ . Das Expires 4 April 2027 [Page 422] Internet-Draft Reality as a Cryptographic Dependency October 2026 If all other protected predicates are also satisfied, the hardware may generate or accept: R0act = V ALID and enable a continuation phase. The remaining authorized trajectory is: Θrem = 85◦ , which may be released in one phase or further partitioned. A.24.7. E24.7 Progressive Hardware Motion A progressive sequence may be: 5◦ → 15◦ → 30◦ → 40◦ , for a cumulative total of 90◦ . Each phase has its own: * phase identifier; * command envelope; * nonce; * hardware authority; * protected sensor observation; * receipt; and * consumption state. A.24.8. E24.8 Multiple Measurement Channels The controller may require both position and electrical measurements. For example:   |θi − θi | ≤ εθ,i , obs cmd Ii ≤ Ii , obs max   obs Ti ≤ Timax , where Iiobs is observed current and Tiobs is observed temperature. A later phase may remain locked if any mandatory channel violates its bound. A.24.9. E24.9 Sensor-Hub Receipt Generation A protected sensor hub may generate: Riact = SignKsens (DA , ActuatorID, P hasei , θicmd , θiobs , Iiobs , Tiobs , Counteri , Ni , Statusi ). Das Expires 4 April 2027 [Page 423] Internet-Draft Reality as a Cryptographic Dependency October 2026 The receipt may instead be MACed, attested, threshold-signed, or cryptographically protected by another mechanism. A.24.10. E24.10 Sensor Authenticity The system may bind the sensor to the actuator or machine using: * device-specific key; * secure element identity; * authenticated bus address; * calibration certificate; * measured boot state; * hardware attestation; * PUF-derived identity; * protected pairing state; or * equivalent evidence. A valid receipt from an unrelated sensor does not satisfy the actuator’s continuation predicate where device binding is required. A.24.11. E24.11 Command/Sensor Pairing A phase receipt may bind both the command digest and the observation digest: Riact ⊃ H(Commandi ) ∥ H(Observationi ). This prevents a valid observation from one command from being substituted for another. A.24.12. E24.12 Counter-Based Anti-Replay The actuator controller may maintain a monotonic counter: cact i . A capability is valid only where its expected counter equals protected local state. After consumption: cact act i+1 = ci + 1. A replayed phase capability using an old counter is rejected. Das Expires 4 April 2027 [Page 424] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.24.13. E24.13 Receipt Consumption in Hardware The secure continuation controller may atomically: 1. verify Riact ; 2. verify current phase and counter; 3. mark Riact consumed; 4. advance the protected phase index; act 5. derive or unseal Ki+1 ; and 6. enable the next hardware latch or command envelope. This reduces the possibility that a single successful movement receipt authorizes multiple later movements. A.24.14. E24.14 Missing-Execution-Material Variation Instead of exposing a next-phase key, the actuator may require missing execution material retained entirely inside protected hardware. Examples include: * PWM enable mask; * motor-driver gate state; * command authenticator; * secure DMA descriptor; * protected bus authorization; * key share; * encrypted microcode block; * register unlock value; or * secure-monitor transition. The missing material becomes available only after validated receipt state. A.24.15. E24.15 Secure Boot and Measured Controller State The actuator controller or sensor hub may require an approved software/firmware measurement before participating in receipt generation or next-phase authority derivation. A phase capability may therefore bind: M easurementctrl and/or: M easurementsensor . If the measured state changes unexpectedly, later phases may be denied or require reattestation. Das Expires 4 April 2027 [Page 425] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.24.16. E24.16 Power-Stage Enforcement In one variation, final enforcement occurs below the ordinary motor- control software at the power-stage enable path. A protected gate controls whether the driver may energize the actuator beyond the current phase envelope. Thus compromise of higher-level application software does not by itself create full physical authority. A.24.17. E24.17 Bus-Level Enforcement A secure CAN, SPI, I2C, Ethernet, industrial fieldbus, PCIe, or proprietary bus controller may mediate phase-specific commands. The bus enforcement component may reject: * commands lacking a valid phase authenticator; * commands for the wrong actuator; * commands exceeding the phase envelope; * stale counters; * wrong policy epochs; or * commands that skip mandatory phases. A.24.18. E24.18 Human Approval in the Hardware Chain For sensitive phases, a human approval artifact may become an input to hardware continuation authority: act act Ki+1 = KDF (KR , DA , H(Riact ), H(Ahuman i ), i + 1). The secure controller need not trust an ordinary UI assertion that approval occurred; it can require a protected approval artifact or equivalent authenticated state. A.24.19. E24.19 Automatic Hardware Continuation For approved autonomous operation, the secure controller may automatically derive the next phase where: V alid(Riact ) ∧ InT olerancei ∧ Saf etyP assi ∧ P olicyV alidi ⇒ HardwareContinuei . No human is required where protected policy permits automatic continuation. Das Expires 4 April 2027 [Page 426] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.24.20. E24.20 Hybrid Hardware Continuation A higher-assurance implementation may require both protected automatic checks and human approval: V alid(Riact ) ∧ Saf etyP assi ∧ HumanApprovali ⇒ HardwareContinuei . A.24.21. E24.21 Sensor Failure If the required sensor is unavailable, stale, unauthenticated, or inconsistent, the architecture may: * hold the current phase; * reduce the permitted envelope; * use an approved redundant sensor set; * request protected human review; * move to a safe state; or * deny further effectuation. Absence of mandatory observation does not automatically count as successful effectuation. A.24.22. E24.22 Mechanical Backlash and Tolerance Modeling The permitted comparison need not require exact equality where physical systems exhibit backlash, compliance, delay, or sensor noise. Protected policy may specify: εi = f (ActuatorClass, Loadi , V elocityi , Calibrationi , Saf etyClass). The tolerance function is protected policy rather than an unrestricted value supplied by the proposing agent. A.24.23. E24.23 Time-Bounded Physical Confirmation A receipt may be valid only if the observation is obtained within a protected time window: 0 ≤ Tireceipt − Ticommand ≤ ∆tmax,i . A stale position reading must not be reused as confirmation of a new command. Das Expires 4 April 2027 [Page 427] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.24.24. E24.24 Power Loss During Phase Protected NVRAM, monotonic counters, controller logs, or actuator position sensing may permit reconciliation after power loss. Possible states include: * phase proven not started; * phase started but incomplete; * phase completed and receipt recoverable; * physical state measurable but cryptographic state incomplete; or * still indeterminate. The recovery workflow avoids assuming that power loss implies no physical motion occurred. A.24.25. E24.25 Alternate Hardware Path Closure The protected architecture may control or disable: * debug headers; * vendor maintenance ports; * direct motor-driver registers; * unprotected PWM paths; * bootloader commands; * raw fieldbus frames; * secondary control CPUs; * alternate wireless control paths; * factory test mode; or * direct power-stage enable lines. Where a path can create an equivalent broader physical effect, it is treated as an effect- capable path for finality purposes. A.24.26. E24.26 Multi-Actuator Coordination For coordinated machines, phase i may involve a set of actuators: Ai = {a1 , a2 , . . . , ak }. Das Expires 4 April 2027 [Page 428] Internet-Draft Reality as a Cryptographic Dependency October 2026 Continuation may require every mandatory actuator to report acceptable state: ∧ act Accept(Ri,a ) = T RU E. a∈Ai Alternatively, protected policy may permit threshold or role-specific completion. A.24.27. E24.27 Independent Safety Controller A separate safety controller may retain veto authority over every phase even after receiptderived continuation authority exists. Therefore: ContinuationAuthorityi = T RU E ̸⇒ Actuationi = T RU E where a mandatory safety interlock remains false. This preserves the distinction between staged continuation authority and independent safety interlocks. A.24.28. E24.28 SEND Example A robotic system that captures a sensor image may stage physical and communication effects independently. A verified actuator position may authorize image capture, while SEND of the image may still require recipient-bound trailer/receipt control before full communication. Thus the physical receipt does not automatically substitute for a communication receipt. A.24.29. E24.29 Payment Example A machine may consume power, charging service, toll access, or a physical commodity. A sensorconfirmed physical event may become one protected input to a payment Candidate Act, but the payment remains separately gated by its own destination, amount, credential, and receipt conditions. A.24.30. E24.30 Required Invariants Invariant 1. The later physical phase may be technically unavailable at hardware level until protected receipt validation. Invariant 2. Phase authority is bound to the intended actuator, command envelope, and protected phase state. Invariant 3. Protected sensor evidence corresponds to the commanded physical phase rather than merely an unrelated device reading. Invariant 4. Replay, stale receipt, stale command, and phase skipping are rejected where required. Invariant 5. Failure or loss of mandatory sensor evidence prevents unauthorized progression. Invariant 6. Hardware crash or power loss is reconciled against actual physical and protected state rather than presumed safe by default. Invariant 7. Human approval, automatic approval, or hybrid approval may be incorporated without giving the proposing agent authority to forge the approval state. Invariant 8. Das Expires 4 April 2027 [Page 429] Internet-Draft Reality as a Cryptographic Dependency October 2026 Alternate hardware paths capable of equivalent actuation are controlled where non-bypassability is required. 4 FROZEN RELATIONSHIP BETWEEN E22, E23 AND E24 E22, E23, and E24 apply the same staged-effectuation principle to progressively more physical enforcement boundaries. Provisional Real Storage → Ristore → Promotion/Visibility Authority. Bounded Physical Effect → Riphys → Broader Physical Authority. Hardware-Bounded Motion → Riact → Receipt-Derived Hardware Continuation. The common invariant remains that a computational proposal or initial approval does not necessarily constitute unconditional authority to complete the full consequential act. A.25. E25 — Receipt-Gated Vehicle Effectuation and Progressive Vehicular Authority A.25.1. E25.1 Purpose E25 applies the staged-effectuation architecture to a vehicle whose computational system, autonomous controller, driver-assistance system, remote operator, route planner, fleet controller, or other source proposes an act capable of causing a physical vehicular consequence. The Candidate Act may concern propulsion, braking, steering, gear state, route movement, parking, lane movement, docking, charging connection, door state, cargo handling, or another vehicle operation. The embodiment separates at least three technical events: 1. generation or selection of a proposed vehicle act; 2. protected authorization of a bounded or complete vehicular effect; and 3. actual effectuation through an effect-capable vehicle boundary. A vehicle planner therefore does not obtain unconditional authority merely by producing a trajectory, command, or route. A representative staged relationship is: V ehicle Candidate Act → Bounded V ehicle Effect → P rotected V ehicle Receipt → Continuation Authority → Broader V ehicle Effect A.25.2. E25.2 Candidate Vehicle Acts A Candidate Act may include, without limitation: * accelerate to a requested speed; * decelerate or brake; Das Expires 4 April 2027 [Page 430] Internet-Draft Reality as a Cryptographic Dependency October 2026 * steer to a requested heading; * change lane; * enter or leave a road segment; * move from one parking location to another; * reverse; * perform a parking maneuver; * begin a trip; * continue through a route segment; * cross a defined boundary; * dock at a station; * couple or uncouple a trailer or equipment module; * open or close an externally consequential vehicle mechanism; * activate a powered loading system; * enable autonomous movement; * transfer control between automated and human control modes. The Candidate Act may be generated by an AI model, deterministic planner, optimization engine, human interface, remote operator, fleet-management system, or combination thereof. A.25.3. E25.3 Vehicle Act Binding The protected system may bind the vehicle act to a canonical representation or other deterministic act representation. A protected vehicle act descriptor may identify: * vehicle identity; * current protected vehicle state; * origin; * destination; * route segment; Das Expires 4 April 2027 [Page 431] Internet-Draft Reality as a Cryptographic Dependency October 2026 * requested path; * permitted speed range; * permitted acceleration range; * permitted steering range; * maximum distance; * maximum duration; * propulsion mode; * braking mode; * environmental constraints; * passenger or cargo constraint; * operator identity; * policy epoch; * revocation state; * and the intended Finality Sink or equivalent vehicle effectuation boundary. The protected system may form: DV = H(Canon(AV )) where AV denotes the Candidate Vehicle Act. The precise canonicalization mechanism is not mandatory. The required property is that later vehicle authority remains associated with the authorized act or authorized act envelope. A.25.4. E25.4 Maximum Vehicle Effectuation Envelope Before movement, protected policy may establish a maximum permitted vehicle-effectuation envelope. Let: VMAX represent the maximum authorized vehicle-effect envelope. The envelope may constrain one or more of: * geographical region; * road or lane; Das Expires 4 April 2027 [Page 432] Internet-Draft Reality as a Cryptographic Dependency October 2026 * maximum speed; * maximum acceleration; * maximum deceleration; * maximum steering angle; * maximum travel distance; * maximum travel duration; * destination; * route family; * number of maneuvers; * energy or propulsion expenditure; * passenger or cargo condition; * actuation mode; * or another physical or operational dimension. Receipt success must not, by itself, authorize a vehicle act outside VMAX . A.25.5. E25.5 Protected Vehicle State The PED may obtain protected vehicle state from one or more trusted or protected sources. State may include: * wheel speed; * vehicle speed; * steering angle; * brake state; * propulsion state; * gear state; * battery or fuel state; * localization state; Das Expires 4 April 2027 [Page 433] Internet-Draft Reality as a Cryptographic Dependency October 2026 * inertial state; * route position; * obstacle state; * tire or traction state; * door or restraint state; * controller health; * sensor health; * actuator health; * policy state; * secure-boot or firmware measurement; * human-control state; * remote-control state; * network state; * and prior phase-receipt state. The proposing computational component need not be permitted to rewrite this protected state. A.25.6. E25.6 Vehicle State Vector For mathematical description, a protected vehicle state may be represented as: T xi = [ pi vi ai ψi ψi̇ δi βi ] where components may represent position, velocity, acceleration, heading, yaw rate, steering state, braking or another implementation-specific physical state. No particular state vector is mandatory. A.25.7. E25.7 Protected Safe-State Set Protected policy may define an acceptable state set: ΩV A continuation predicate may require: xi ∈ Ω V Das Expires 4 April 2027 [Page 434] Internet-Draft Reality as a Cryptographic Dependency October 2026 after completion of a bounded vehicle phase. The safe-state set may be fixed or dynamic. For example, the acceptable state after a bounded maneuver may depend upon current route, permitted speed, obstacle state, road geometry, vehicle condition, or operator instruction. A.25.8. E25.8 Phase-0 Vehicle Demonstration Where staged vehicle effectuation is selected, Phase 0 may cause a real but bounded vehicle effect. Examples include: * move two metres at limited speed; * release the brake and move only within a defined parking envelope; * apply a bounded steering movement; * perform a low-speed lane-centering correction; * execute one short route segment; * perform one braking pulse within a protected test envelope; * engage propulsion only up to a bounded torque or speed; * move from a dock position to a protected staging position. The Phase-0 effect is a real physical consequence and is not merely a simulated trajectory. A.25.9. E25.9 Example Bounded Vehicle Phase A requested movement may be: Distancerequested = 500 m Protected policy may first authorize: Distance0 = 2 m with: Speed0 ≤ 5 km/h The real two-metre movement occurs through the protected vehicle effectuation boundary. A protected observer then confirms the actual result before broader movement authority is made available. A.25.10. E25.10 Vehicle Finality Sink The vehicle Finality Sink or equivalent effectuation-control component may reside at or control: * propulsion controller; Das Expires 4 April 2027 [Page 435] Internet-Draft Reality as a Cryptographic Dependency October 2026 * brake controller; * steering controller; * drive-by-wire controller; * powertrain controller; * transmission controller; * body controller; * secure gateway; * vehicle control unit; * domain controller; * zonal controller; * safety controller; * motor inverter; * actuator control module; * or another component without which the physical vehicle effect cannot validly occur. The sink may be software-enforced, hardware-enforced, or jointly enforced. A.25.11. E25.11 Vehicle Effect Observation The result of a bounded vehicle act may be observed using one or more protected sources such as: * wheel encoder; * inertial measurement unit; * steering sensor; * brake-pressure sensor; * propulsion controller; * secure odometry; * protected localization component; Das Expires 4 April 2027 [Page 436] Internet-Draft Reality as a Cryptographic Dependency October 2026 * hardware counter; * vehicle control unit; * protected sensor fusion; * remote trusted observer; * or another effect-relevant state source. The observer should preferably be sufficiently independent from the proposing planner that the planner cannot merely assert that the maneuver succeeded. A.25.12. E25.12 Vehicle Effect Receipt After a bounded vehicle effect, the protected observer or sink may generate a vehicle-effect receipt. Let: RiV represent the receipt for vehicle phase i. It may bind: * DV ; * phase identifier; * authorized movement envelope; * actual observed state; * start state; * end state; * distance; * speed range; * steering or braking result; * vehicle identity; * sink identity; * sensor identity; * nonce; * timestamp or protected time state; Das Expires 4 April 2027 [Page 437] Internet-Draft Reality as a Cryptographic Dependency October 2026 * policy epoch; * status; * prior receipt commitment; * and next-stage eligibility evidence. The receipt may be signed, MACed, attested, hash-linked, stored in protected state, or otherwise authenticated. A.25.13. E25.13 Vehicle Continuation Predicate A general continuation rule may be: V Enable(Pi+1 ) = V alid(RiV ) ∧ M atchAct(RiV , DV ) V ∧ W ithinV ehicleEnvelope(Pi+1 ) ∧ StateAcceptable(xi ) ∧ P olicyCurrent ∧ RevocationClear ∧ ApprovalSatisfiedi+1 . Where a required term is false or indeterminate, broader vehicle authority remains unavailable. A.25.14. E25.14 Automatic Vehicle Continuation Protected policy may automatically release the next phase if required receipt, state, and risk conditions are acceptable. This can support low-latency operation where repeated human approval would be impractical. For example: V alid(RiV ) ∧ xi ∈ ΩV ∧ RiskAcceptablei ⇒ Enable(Pi+1 V ) The vehicle planner itself need not have authority to mark these conditions as satisfied. A.25.15. E25.15 Human Vehicle Continuation A protected human approval surface may present: * requested maneuver; * real bounded movement already performed; * observed final state; * current vehicle position; * requested next movement; * route or destination; * current risk indication; Das Expires 4 April 2027 [Page 438] Internet-Draft Reality as a Cryptographic Dependency October 2026 * receipt status; * and consequence of continuing. A driver, passenger, remote operator, fleet supervisor, or other authorized human may approve, deny, restrict, delay, or terminate continuation. A.25.16. E25.16 Hybrid Vehicle Continuation A higher-assurance rule may require both automatic protected conditions and protected human authorization. For example: V alid(RiV ) ∧ V ehicleP olicyP assi ∧ HumanApprovali ⇒ Enable(Pi+1 V ) A threshold or role-separated approval model may also be used. A.25.17. E25.17 Progressive Route Segmentation A route may be divided into protected segments: R = {Seg0 , Seg1 , ... , Segn } Each completed segment may produce a protected receipt. The next segment remains unavailable until the required prior receipt and current protected state are accepted. The segments need not be equal in length. Phase size may adapt to vehicle speed, traffic conditions, localization confidence, route certainty, obstacle state, policy, or other protected criteria. A.25.18. E25.18 Progressive Speed Envelope Vehicle authority may expand by speed rather than distance. Example: 5 km/h → 15 km/h → 30 km/h → AuthorizedM aximum Receipt failure at a lower speed can prevent release of a higher speed envelope. A.25.19. E25.19 Progressive Steering Envelope The system may constrain steering effectuation by maximum permitted steering angle or curvature. For example: |δi | ≤ δmax,i where δmax,i may increase only after accepted protected evidence. Das Expires 4 April 2027 [Page 439] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.25.20. E25.20 Braking and Emergency-State Variation A safety-critical braking path may be treated differently from ordinary progressive authority. Protected policy may allow an immediate emergency reduction of consequence even when ordinary forward progression is blocked. Thus a fail-closed continuation rule need not prevent a fail-safe or fail-limited emergency action whose purpose is to reduce physical hazard. Such emergency authority may itself be narrowly scoped to braking, power reduction, safe-stop movement, or another hazard-reduction operation. A.25.21. E25.21 Transfer of Control A Candidate Act may request transfer between: * autonomous control; * assisted control; * human control; * remote operator control; * protected safe-state controller. The transfer itself may be receipt-gated. For example, a vehicle may not grant higher-speed autonomous authority until protected state confirms that the intended control domain is active and the previous controller has relinquished conflicting authority. A.25.22. E25.22 Vehicle Credential Separation The planning component may possess no reusable credential capable of directly driving vehicle actuators. Instead, a protected controller may expose only phase-bounded authority. The protected authority may be: * one-time command authenticator; * short-lived capability; * hardware key share; * protected register state; * phase-bound MAC key; * signed control envelope; Das Expires 4 April 2027 [Page 440] Internet-Draft Reality as a Cryptographic Dependency October 2026 * secure gateway permit; * or another non-bearer technical condition. A.25.23. E25.23 Hardware-Rooted Vehicle Variation A hardware-rooted implementation may place protected keys and phase state in: * secure processor; * safety MCU; * TEE; * HSM; * secure element; * vehicle security controller; * protected gateway; * actuator controller; * or dedicated hardware security block. A downstream controller may accept a propulsion, braking, or steering command only if the hardware-derived phase authority is valid. A.25.24. E25.24 Vehicle Phase Key A vehicle phase key may be derived as: V V Ki+1 = KDF (KR , DV , H(RiV ), i + 1, V ehicleID) The exact KDF is non-limiting. The protected property is that later vehicle authority can be made cryptographically dependent upon accepted earlier real-effect evidence. A.25.25. E25.25 Multi-Controller Vehicle Variation Different vehicle effects may use different finality sinks. For example: * propulsion sink; * braking sink; * steering sink; Das Expires 4 April 2027 [Page 441] Internet-Draft Reality as a Cryptographic Dependency October 2026 * cargo-actuation sink. A composite maneuver may require coordinated protected receipts from multiple controllers. A broader phase may require all mandatory subsystem receipts or an implementation-specific protected quorum. A.25.26. E25.26 Fleet Variation A fleet controller may authorize a bounded effect on one vehicle before authorizing the same class of act across a fleet. Example: 1 vehicle → 10 vehicles → 100 vehicles → AuthorizedF leet Each expansion may be conditioned on protected receipts from prior vehicles or cohorts. This can be combined with E17 cloud-rollout logic while preserving vehicle-local effectuation control. A.25.27. E25.27 Parking and Docking Variation A parking or docking act may be progressively released by distance, speed, spatial zone, steering envelope, or proximity to the final target. The first real effect may move the vehicle only into a protected staging region. Receipt-confirmed localization and actuator state may then permit the final parking, charging, coupling, or docking movement. A.25.28. E25.28 Dynamic Environment Change A successful earlier receipt does not freeze the environment. Before each later phase, the PED may revalidate current state. If a new obstacle, route restriction, revocation, operator instruction, or protected risk state arises, the next phase may be reduced, delayed, redirected, or denied. Thus: V alid(RiV ) ⇏ U nconditionalContinuation A.25.29. E25.29 Indeterminate Vehicle Effect If protected state cannot determine whether a vehicle phase occurred as intended: Status(RiV ) = IN DET ERM IN AT E broader authority remains blocked. The system may reconcile using protected odometry, actuator counters, control-unit state, sensor history, secure logs, or another protected state source. Das Expires 4 April 2027 [Page 442] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.25.30. E25.30 Loss of Communication Loss of cloud, network, remote operator, or fleet connectivity need not create unrestricted local authority. Protected policy may transition the vehicle to: * safe stop; * limited-speed mode; * bounded local navigation; * return-to-safe location; * human-only control; * or another fail-limited state. The exact response depends on implementation and hazard model. A.25.31. E25.31 Anti-Bypass Equivalent vehicle effect paths may include: * direct CAN command; * automotive Ethernet control path; * diagnostic interface; * maintenance interface; * engineering mode; * alternate ECU; * raw actuator command; * service tool; * recovery firmware; * remote-management path; * privileged application; Das Expires 4 April 2027 [Page 443] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or physical control gateway. Where non-bypassability is required, equivalent effect-capable paths are disabled, mediated, cryptographically restricted, hardware gated, or subjected to corresponding protected finality checks. A.25.32. E25.32 Vehicle Crash / Restart Recovery If the protected controller restarts after a physical movement, it must not assume that the last command failed merely because the receipt was not delivered. The recovery process may compare: * last accepted phase identifier; * hardware counter; * actual vehicle state; * idempotency identifier; * actuator state; * secure journal; * and pending continuation state. Only after reconciliation may a retry or next phase be authorized. A.25.33. E25.33 Required Invariants The frozen core of E25 includes: 1. the vehicle planner or Candidate Act Source is distinguishable from the protected physical effectuation authority; 2. the vehicle effect is constrained by an authorized envelope; 3. where staged operation is selected, at least one bounded real vehicle effect precedes broader authority; 4. protected evidence of the prior physical state transition is evaluated before required broader continuation; 5. prior success does not expand authority beyond the authorized maximum; 6. failure or indeterminate state prevents unauthorized broader physical progression; 7. emergency hazard-reduction authority may be separately and narrowly defined; 8. software, hardware, or combined enforcement may be used; 9. equivalent alternate actuator paths are correspondingly controlled where necessary for nonbypassability. ATION A.26. E26 — Receipt-Gated UAV and Mobile-Robot Effectuation Das Expires 4 April 2027 [Page 444] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.26.1. E26.1 Purpose E26 applies receipt-gated progressive effectuation to unmanned aerial vehicles, drones, autonomous ground vehicles, warehouse robots, delivery robots, inspection robots, mobile manipulators, and other mobile machines whose software can cause movement through a physical environment. The embodiment is especially useful where a planner or AI system may generate a complete mission, while protected authority is released only in bounded stages. Representative flow: M ission P roposal → Bounded M obility P hase → P rotected M obility Receipt → N ext M obility Authority → Broader M ission Effect A.26.2. E26.2 Candidate Mobility Acts Candidate Acts may include: * takeoff; * hover; * climb; * descend; * yaw; * translate; * travel to waypoint; * traverse corridor; * enter zone; * leave zone; * land; * dock; * return to base; * pick up or deliver an object; * activate mobile manipulation; * follow a target; Das Expires 4 April 2027 [Page 445] Internet-Draft Reality as a Cryptographic Dependency October 2026 * inspect a structure; * perform one segment of a delivery or survey mission. A.26.3. E26.3 Mission Envelope A protected mission envelope may define: MMAX which may constrain: * allowed geographic region; * altitude range; * speed range; * route or corridor; * distance; * duration; * energy expenditure; * permitted payload operation; * allowed landing zones; * communications state; * human-supervision requirement; * sensor-health requirement; * and mission termination conditions. No successful receipt may validly enlarge the mission beyond MMAX absent a new protected authorization. A.26.4. E26.4 Mobility Phase Plan The mission may be represented as: W = {W0 , W1 , ... , Wn } where each Wi may be a waypoint, corridor, mobility segment, protected zone transition, or another bounded movement phase. A phase need not correspond to a single geographic waypoint. It may instead be defined by altitude, time, energy, speed, task completion, or another effect dimension. Das Expires 4 April 2027 [Page 446] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.26.5. E26.5 UAV Initial Demonstration A UAV may first perform a real but bounded effect such as: * arm propulsion without takeoff; * raise thrust within a bounded range; * take off to a low protected altitude; * hover for a short interval; * move a short horizontal distance; * rotate within a bounded yaw range; * reach a protected staging waypoint. A protected observer verifies the result before broader flight authority is released. A.26.6. E26.6 Example UAV Sequence A planned mission may require travel to a remote destination. Protected phases may be: T akeoff to 2m → R0 → Hover 5s → R1 → W aypoint 1 → R2 → W aypoint 2 → ⋯ The receipts may be required prerequisites for subsequent propulsion or navigation authority. A.26.7. E26.7 Mobile Ground Robot Sequence A warehouse or delivery robot may progress as: 0.5m → R0 → 5m → R1 → Corridor A → R2 → Destination The phase boundaries may be chosen according to route risk, human proximity, localization confidence, obstacle density, or policy. A.26.8. E26.8 Protected Mobility Controller Protected effectuation authority may reside in or be enforced by: * flight controller; * autopilot; * safety controller; * motor controller; Das Expires 4 April 2027 [Page 447] Internet-Draft Reality as a Cryptographic Dependency October 2026 * propulsion ESC; * protected navigation controller; * secure gateway; * robotics safety MCU; * drive controller; * wheel controller; * motor inverter; * secure element; * TEE; * HSM; * or another effect-capable protected component. A.26.9. E26.9 Protected Mobility Observation Protected observations may include: * inertial state; * altitude; * position; * speed; * heading; * motor state; * rotor state; * wheel state; * battery state; * localization confidence; * obstacle state; Das Expires 4 April 2027 [Page 448] Internet-Draft Reality as a Cryptographic Dependency October 2026 * controller health; * sensor health; * geofence state; * link state; * payload state; * landing state; * or another mobility-relevant condition. A.26.10. E26.10 Mobility State Vector An implementation may represent mobility state as: T zi = [pi vi qi ωi hi ei ] where the components may represent position, velocity, orientation, angular rate, altitude, energy state, or other physical variables. The precise state representation is non-limiting. A.26.11. E26.11 Protected Mobility Receipt Let: RiM represent the receipt for mobility phase i. It may bind: * mission digest; * phase or waypoint identifier; * permitted mobility envelope; * actual observed position or state; * route segment; * altitude; * speed; * duration; * propulsion or wheel state; * energy state; Das Expires 4 April 2027 [Page 449] Internet-Draft Reality as a Cryptographic Dependency October 2026 * sink identity; * observer identity; * nonce; * policy epoch; * status; * prior receipt commitment; * and current geofence or protected-zone state. A.26.12. E26.12 Geofence / Zone Constraint Protected policy may define a permitted mobility region: Γi Continuation may require: pi ∈ Γ i and a proposed next phase may be rejected if its predicted or commanded envelope lies outside the authorized region. The geofence or zone may change dynamically. A.26.13. E26.13 Altitude-Bounded Progression A UAV may receive progressively larger altitude authority. For example: 2m → 10m → 30m → AuthorizedAltitudeM aximum Each increase may require an accepted protected receipt from the previous phase. A.26.14. E26.14 Distance-Bounded Progression A mobile robot may receive distance authority in increments: 1m → 10m → 50m → M issionSegment The next increment may be reduced rather than enlarged if protected risk increases. A.26.15. E26.15 Energy-Bounded Progression Authority may also be bounded by energy expenditure. Let: Eimob represent permitted energy for phase i. Protected policy may enforce: Das Expires 4 April 2027 [Page 450] Internet-Draft Reality as a Cryptographic Dependency October 2026 Eimob ≤ EMAX mob and may require a valid prior receipt before a larger energy envelope is released. A.26.16. E26.16 Payload-Operation Separation Mobility authority need not automatically authorize payload effectuation. A UAV may be permitted to fly to a location while a separate protected authority governs: * release of payload; * camera activation; * data transmission; * robotic-arm use; * spraying; * sampling; * package drop; * or another payload consequence. Thus: F lightAuthority ⇏ P ayloadAuthority unless protected policy expressly binds them. A.26.17. E26.17 Takeoff Versus Mission Authority A protected architecture may distinguish: Authorityarm ≠ Authoritytakeoff ≠ Authoritymission A successful propulsion-arm state need not authorize takeoff, and successful takeoff need not authorize the complete mission. A.26.18. E26.18 Landing Authority Landing may itself be treated as a protected physical effect. The system may require protected evidence of: * landing-zone identity; * permitted location; Das Expires 4 April 2027 [Page 451] Internet-Draft Reality as a Cryptographic Dependency October 2026 * altitude; * descent profile; * obstacle condition; * and sink state before releasing final descent or touchdown authority. A.26.19. E26.19 Human Approval Variation A protected human may authorize: * complete mission envelope at the start; * each waypoint or route segment; * takeoff only; * entry into sensitive zones; * payload operation; * final delivery; * or emergency continuation. The protected approval surface may display verified evidence from completed phases rather than relying only on the planner’s prediction. A.26.20. E26.20 Automatic Continuation Autonomous continuation may occur where protected receipts and current state satisfy policy. For example: Enable(Wi+1 ) = V alid(RiM ) ∧ P ositionAcceptablei ∧ SensorHealthi ∧ EnergySufficienti ∧ W ithinM issionEnvelope(Wi+1 ) ∧ N otRevokedi . A.26.21. E26.21 Hybrid Continuation A hybrid policy may automatically advance ordinary phases but require protected human approval for: * entering a designated zone; * crossing a distance threshold; * raising altitude above a threshold; Das Expires 4 April 2027 [Page 452] Internet-Draft Reality as a Cryptographic Dependency October 2026 * activating payload; * approaching humans or critical infrastructure; * or releasing final delivery. A.26.22. E26.22 GNSS / Localization Uncertainty Variation If localization becomes uncertain, prior success does not imply continued authority. Protected policy may reduce the next phase, hold position, land, stop, return, or require another localization source. The architecture can distinguish: U N KN OW N ≠ SAF E and may refuse broader progression while localization state is unresolved. A.26.23. E26.23 Sensor Disagreement Where multiple sensors disagree, the mobility receipt may become indeterminate rather than selecting an optimistic interpretation. Protected logic may require: * sensor quorum; * confidence threshold; * protected fusion result; * human review; * reduced mobility envelope; * or safe termination. A.26.24. E26.24 Protected Sensor Quorum If n protected observers produce mobility evidence, continuation may require: n ∑ V alid(RiM,j ) ≥ m j=1 with additional role constraints where necessary. This is a mobility-specific use of the already disclosed quorum principle. Das Expires 4 April 2027 [Page 453] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.26.25. E26.25 Communication-Link Loss A UAV or mobile robot may lose communication with a cloud service, operator, or network. The absence of communication need not release unrestricted autonomous authority. Protected policy may transition to: * hold; * hover; * land; * stop; * return-to-base; * bounded local navigation; * or another predefined fail-limited behavior. A.26.26. E26.26 Energy Depletion If battery or energy state falls below a protected threshold, planned mission continuation may be denied even if the previous receipt was valid. The system may prioritize a protected recovery or safe-state maneuver. Thus receipt validity is necessary but not always sufficient for continuation. A.26.27. E26.27 Crash After Movement If a controller crashes after the robot moved but before the receipt was propagated, the architecture may reconcile actual state using: * flight controller log; * motor counter; * odometry; * protected position history; * secure journal; * actuator state; * or another protected source. Blind replay of a consequential mobility phase is avoided where it could duplicate movement. Das Expires 4 April 2027 [Page 454] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.26.28. E26.28 Swarm / Multi-Robot Variation A protected controller may authorize one unit or small subset before expanding to a larger group. For example: 1 robot → 5 robots → 25 robots → AuthorizedGroup The broader group phase may depend upon protected receipts from the earlier subset. Different robots may produce independent receipts, an aggregate receipt, or a quorum result. A.26.29. E26.29 Cooperative Mobility Where two or more robots must coordinate, the next phase may require receipt evidence that required peers reached compatible states. For example, a protected convoy may require that all mandatory members reach a staging point before the next movement phase is enabled. A.26.30. E26.30 Mobile Manipulator Variation A mobile robot may separate mobility authority from manipulator authority. Example: 1. move to staging location; 2. verify protected mobility receipt; 3. authorize bounded arm motion; 4. verify protected arm-effect receipt; 5. authorize grasp, placement, or broader task. This prevents successful navigation from automatically granting unrestricted manipulation authority. A.26.31. E26.31 Anti-Bypass Equivalent mobility-effect paths may include: * raw motor interface; * flight-control debug interface; * maintenance channel; * alternate navigation controller; * direct motor command; * service port; * recovery mode; * remote-control channel; * hardware bus; Das Expires 4 April 2027 [Page 455] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or privileged operating-system path. Where the staged architecture is intended to be non-bypassable, those paths are correspondingly mediated or restricted. A.26.32. E26.32 Required Invariants The frozen core of E26 includes: 1. mission generation is not itself unconditional mobility authority; 2. the mission remains bounded by a protected maximum envelope; 3. where staged operation is selected, real bounded mobility produces protected evidence before required broader progression; 4. position, motion, sensor, energy, policy, or other current protected state may be revalidated at every phase; 5. successful flight or movement does not automatically authorize payload effectuation; 6. uncertain location or indeterminate physical outcome does not become implicit authorization; 7. fail-limited recovery behavior may be separately authorized; 8. alternate propulsion or mobility paths are controlled where needed for non- bypassability. PROCESS-CONTROL EFFECTUATION A.27. E27 — Receipt-Gated Industrial, PLC, Machine, and Process-Control Effectuation A.27.1. E27.1 Purpose E27 applies the receipt-gated effectuation architecture to industrial control systems, programmable logic controllers, manufacturing systems, process plants, machine tools, energy systems, material- handling equipment, industrial robots, pumps, valves, drives, and other operational technology capable of causing consequential physical or process-state changes. The architecture separates a supervisory computation, AI optimizer, scheduling engine, engineering workstation, human-machine interface, or other Candidate Act Source from the protected authority required to make an industrial act effective. Representative relationship: Industrial Candidate Act → Bounded P rocess Effect → P rotected P rocess Receipt → N ext P rocess Authority → Broader Industrial Effect A.27.2. E27.2 Candidate Industrial Acts Candidate Acts may include: * start or stop machine; * open or close valve; Das Expires 4 April 2027 [Page 456] Internet-Draft Reality as a Cryptographic Dependency October 2026 * change pump speed; * change motor speed or torque; * energize or de-energize circuit; * change setpoint; * change temperature or pressure target; * initiate production cycle; * modify batch quantity; * activate conveyor; * move industrial robot; * commit CNC operation; * release material; * change flow rate; * change process recipe; * switch source or destination; * alter power-distribution state; * change controller mode; * or another machine/process consequence. A.27.3. E27.3 Industrial Effectuation Envelope Protected policy may define: IMAX as the maximum authorized industrial-effect envelope. It may constrain: * machine identity; * production line; * process unit; * batch size; Das Expires 4 April 2027 [Page 457] Internet-Draft Reality as a Cryptographic Dependency October 2026 * quantity; * setpoint range; * pressure range; * temperature range; * flow range; * speed; * torque; * electrical power; * duration; * number of cycles; * spatial zone; * material identity; * recipe; * operator role; * or another operational parameter. A series of successful receipts must not silently enlarge authority beyond IMAX . A.27.4. E27.4 Protected Industrial Enforcement Domain The PED may reside in or include: * safety PLC; * standard PLC with protected partition; * industrial controller; * secure gateway; * process-control server; * drive controller; * robot controller; Das Expires 4 April 2027 [Page 458] Internet-Draft Reality as a Cryptographic Dependency October 2026 * machine controller; * distributed-control-system component; * field gateway; * secure remote I/O; * HSM; * TEE; * secure MCU; * FPGA; * ASIC; * protected industrial computer; * or another protected control component. The architecture does not require a single physical PED. A.27.5. E27.5 Process State Acquisition Protected state may include: * machine mode; * interlock state; * emergency-stop state; * pressure; * temperature; * flow; * vibration; * speed; * torque; * current; * voltage; Das Expires 4 April 2027 [Page 459] Internet-Draft Reality as a Cryptographic Dependency October 2026 * position; * material level; * valve position; * sensor health; * actuator health; * controller state; * recipe state; * batch state; * maintenance state; * operator state; * network state; * policy epoch; * and prior phase state. A.27.6. E27.6 Bounded Industrial Trial A staged industrial operation may first permit a real but limited effect. Examples include: * run one machine cycle before a full batch; * open a valve five percent before wider opening; * energize one protected subsystem before the full line; * move an industrial robot through a short protected trajectory; * process one workpiece before a larger production run; * change a setpoint by a small bounded increment; * activate one conveyor section before the complete line; * execute one CNC feature before the remaining operation; Das Expires 4 April 2027 [Page 460] Internet-Draft Reality as a Cryptographic Dependency October 2026 * enable one server-room cooling unit before a coordinated cooling change; * switch one low-consequence load before a larger power-distribution change. A.27.7. E27.7 Example Valve Sequence Requested valve position: 100% Phase 0 may authorize: 5% A protected position sensor and process observer confirm actual state. If the observed process remains within the permitted range, later authority may permit: 20% → 50% → 100% or another protected progression. A.27.8. E27.8 Example Machine-Cycle Sequence A requested production run may comprise 10,000 items. Protected progression may be: 1 item → R0 → 10 items → R1 → 100 items → R2 → AuthorizedRun The phase size may increase only after protected process receipts are accepted. A.27.9. E27.9 Industrial Process State Vector An implementation may represent protected process state as: T yi = [Ti Pi Fi Vi Ii ωi qi ] where the components may represent temperature, pressure, flow, voltage, current, rotational speed, quality state, or another implementation-specific process variable. The notation is illustrative and non-limiting. A.27.10. E27.10 Protected Operating Region Protected policy may define an acceptable operating region: ΩI Continuation may require: yi ∈ Ω I after the bounded effect. The operating region may be static or dynamically determined from current process state, machine mode, material type, recipe, safety state, or another protected input. Das Expires 4 April 2027 [Page 461] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.27.11. E27.11 Process Effect Receipt Let: RiI represent the protected receipt for industrial phase i. It may bind: * Candidate Act digest; * machine or process identity; * phase identifier; * authorized process envelope; * actual observed state; * sensor evidence; * actuator evidence; * controller identity; * material or batch identity; * recipe state; * nonce; * protected time; * policy epoch; * prior receipt commitment; * status; * and next-phase eligibility evidence. A.27.12. E27.12 Process Receipt Status A process receipt may indicate: * SUCCESS; * FAILURE; * REJECTED; Das Expires 4 April 2027 [Page 462] Internet-Draft Reality as a Cryptographic Dependency October 2026 * PARTIAL; * ROLLED_BACK; * COMPENSATED; * INDETERMINATE; * SAFE_STOP; * or another protected status. The receipt need not assert that the overall business objective succeeded. It may confirm a narrower physical or control-system fact. A.27.13. E27.13 Automatic Industrial Continuation Protected policy may automatically release the next phase where: I Enable(Pi+1 ) = V alid(RiI ) ∧ P rocessStateAcceptable(yi ) I ∧ InterlocksSatisfiedi ∧ W ithinIndustrialEnvelope(Pi+1 ) ∧ P olicyCurrent ∧ RevocationClear. The supervisory AI, optimizer, or application does not need authority to self-certify these conditions. A.27.14. E27.14 Protected Human Approval An operator, supervisor, engineer, or other authorized human may be required to approve progression after reviewing protected receipt evidence. The approval surface may show: * requested operation; * actual bounded process change; * sensor values; * machine identity; * current process state; * interlock state; * alarm state; * next proposed effect; * and protected receipt status. Das Expires 4 April 2027 [Page 463] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.27.15. E27.15 Hybrid Industrial Approval A higher-assurance implementation may require: V alid(RiI ) ∧ AutoP rocessP assi ∧ HumanApprovali ⇒ Enable(Pi+1 I ) Different roles may approve different effect classes. A.27.16. E27.16 Safety-System Separation A process controller, optimizer, or AI system may remain separate from a safety controller or other protected hazard-reduction function. A safety system may retain authority to stop, isolate, depressurize, de-energize, brake, or otherwise reduce hazard even when normal process continuation is denied. The architecture therefore need not equate fail-closed production with blocking all safety actions. A.27.17. E27.17 One-Cycle Demonstration A machine may perform exactly one real production or machine cycle. A protected receipt may confirm: * cycle completion; * measured position; * force; * torque; * temperature; * dimensional result; * sensor health; * and machine state. Only then may the next cycle count be released. A.27.18. E27.18 Progressive Batch Authority Batch authority may expand according to: B0 < B1 < ⋯ < Bn ≤ BMAX where Bi represents cumulative or per-phase batch quantity. A failed or indeterminate phase may freeze remaining batch authority. Das Expires 4 April 2027 [Page 464] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.27.19. E27.19 Progressive Setpoint Change Rather than immediately moving from setpoint s0 to sF , the controller may use: s0 → s 1 → s 2 → ⋯ → s F with protected process confirmation after each consequential change. This may be useful where rapid setpoint changes could create undesirable transients. A.27.20. E27.20 Rate-Limited Effectuation A protected controller may limit the rate of change: ds ∣ ∣ ≤ ρMAX dt and may require accepted receipt evidence before enlarging ρMAX or the target envelope. A.27.21. E27.21 Industrial Robot Variation An industrial robot may use the physical-actuation principles of E23-E24 with additional industrial process constraints. A protected sequence may be: 1. authorize short trajectory; 2. verify protected pose and force state; 3. authorize approach; 4. verify object or fixture state; 5. authorize grasp or tool operation; 6. verify result; 7. authorize broader production cycle. A.27.22. E27.22 CNC / Machine Tool Variation A CNC system may divide a requested machining operation into protected segments. The protected system may bind authority to: * tool identity; * spindle speed; * feed rate; * workpiece identity; * coordinate envelope; * operation number; * permitted depth; * and process state. The machine may not receive full-program authority merely because the first toolpath segment succeeded. Das Expires 4 April 2027 [Page 465] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.27.23. E27.23 Power and Electrical Variation Industrial effectuation may include energizing loads, changing switching state, modifying inverter behavior, or altering power distribution. A bounded phase may energize one load or a reduced power envelope before a larger effect is released. Protected receipts may include breaker state, current, voltage, protection state, or other effectrelevant evidence. A.27.24. E27.24 Pump / Valve / Flow Variation A pump or valve may be progressively enabled by flow, pressure, time, or position. For example: F low0 < F low1 < ⋯ ≤ F lowMAX A protected sensor confirms each phase before the next flow authority is made available. A.27.25. E27.25 Thermal Process Variation A thermal process may progressively increase temperature or heat input. A protected controller may require actual temperature response and sensor-health evidence before a broader heat envelope is released. The next stage can be reduced or terminated if the measured response diverges from the protected range. A.27.26. E27.26 Material Release Variation A process may stage the release of physical material. Example: 1 unit → 10 units → 100 units → AuthorizedQuantity Protected scales, counters, flow meters, or inventory-state systems may produce effect receipts. A.27.27. E27.27 Distributed Process Variation Different process phases may occur across multiple controllers or locations. A downstream unit may require protected receipt evidence from an upstream unit before accepting material, energy, or process authority. The receipt chain can therefore span multiple industrial effectuation boundaries. A.27.28. E27.28 Multi-Controller Quorum A consequential industrial transition may require multiple protected authorities. For example: * process controller approval; Das Expires 4 April 2027 [Page 466] Internet-Draft Reality as a Cryptographic Dependency October 2026 * safety controller approval; * maintenance-state clearance; * operator approval; * quality-system approval. A threshold or conjunction rule may be applied using the principles already disclosed in E11. A.27.29. E27.29 Deterministic / Low-Latency Path A time-sensitive industrial implementation may perform the critical continuation check locally inside a protected controller rather than requiring a remote cloud round trip. The system may pre-load protected policy, phase state, keys, and permitted envelopes so that local receipt verification and next-phase release occur within the required control interval. This embodiment is intended to preserve execution-finality semantics without requiring a particular network latency. A.27.30. E27.30 Offline Industrial Operation An industrial system may continue within a previously authorized local envelope while disconnected from an external network. Offline operation does not imply unlimited authority. The local protected domain may enforce: * maximum duration; * maximum number of cycles; * maximum material quantity; * maximum setpoint range; * local receipt requirements; * and mandatory reauthorization after reconnect or epoch change. A.27.31. E27.31 Maintenance Mode Maintenance mode may create distinct authority from production mode. A maintenance credential should not automatically authorize ordinary production effectuation, and a production credential should not necessarily authorize maintenance overrides. Protected state may bind authority to: M ode ∈ {P RODU CT ION , M AIN T EN AN CE, T EST , RECOV ERY } Das Expires 4 April 2027 [Page 467] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.27.32. E27.32 Engineering Workstation Separation An engineering workstation may propose logic, recipes, setpoints, or configuration changes without having direct authority to cause their full process consequences. A protected industrial gate may require staged validation, protected receipt evidence, or human approval before the changed configuration becomes effect-capable. A.27.33. E27.33 PLC Logic Update Variation A controller update may be staged: 1. load candidate logic into non- effective or shadow state; 2. validate protected digest and configuration; 3. activate on one bounded machine or process unit; 4. obtain receipt evidence; 5. promote to broader equipment only after protected acceptance. This can be combined with E17 software- deployment principles. A.27.34. E27.34 Process Recipe Update A recipe or control parameter set may be treated as a Candidate Act whose semantic consequence occurs only when it controls real equipment. A bounded batch may therefore be used as the real demonstration phase. The protected receipt binds the actual recipe version and observed process result before the recipe is enabled more broadly. A.27.35. E27.35 Sensor Failure If a required protected sensor fails, the system may not substitute an untrusted optimistic value. Possible protected responses include: * hold; * reduce effect envelope; * use protected redundant sensor; * request human intervention; * enter safe state; * or mark the phase indeterminate. Das Expires 4 April 2027 [Page 468] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.27.36. E27.36 Actuator Failure If a commanded actuator does not reach the expected bounded state, the receipt may be FAILURE, PARTIAL, or INDETERMINATE. The system may prevent the next broader phase and initiate protected compensation, isolation, or safe shutdown. A.27.37. E27.37 Crash After Industrial Effect If an industrial effect occurred but the controller crashed before a receipt was propagated, blind replay may be hazardous. The recovery workflow may inspect: * machine counter; * batch identifier; * actuator position; * PLC retained state; * historian or protected journal; * secure transaction identifier; * sensor state; * or another authoritative process source. Only then may retry or continuation be considered. A.27.38. E27.38 Process Idempotency Where practical, a phase may include an idempotency identifier: IiI = H(DA ∥ M achineID ∥ P hasei ∥ Ni ) A protected controller may record the identifier atomically or near-atomically with the industrial effect. A.27.39. E27.39 Anti-Bypass Equivalent industrial effect paths may include: * HMI command; * engineering workstation; * direct PLC programming; Das Expires 4 April 2027 [Page 469] Internet-Draft Reality as a Cryptographic Dependency October 2026 * fieldbus command; * maintenance port; * local manual override; * remote service interface; * drive configuration interface; * safety bypass; * raw I/O control; * alternate credential; * recovery mode; * or privileged operating-system path. Where the receipt-gated architecture is intended to govern the effect, those alternate routes are disabled, scoped, logged, cryptographically restricted, physically interlocked, or subjected to equivalent protected finality requirements. A.27.40. E27.40 SEND Analogue The same control principle can be understood in a communication system: 1. a bounded real message or protected trailer is sent; 2. a protected receipt confirms the intended path or recipient; 3. only then is the remaining communication authority released. The industrial counterpart is a bounded real physical/process effect followed by protected confirmation before broader machine authority. A.27.41. E27.41 Payment Analogue Likewise, a payment system may first perform a bounded reservation or verification transfer and release the remaining authorized amount only after a protected receipt. The industrial counterpart may first release a bounded quantity, energy amount, cycle count, or setpoint change and release the remainder only after protected process evidence. Das Expires 4 April 2027 [Page 470] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.27.42. E27.42 Required Invariants The frozen core of E27 includes: 1. supervisory computation, AI optimization, HMI input, or engineering proposal is not itself unconditional industrial effectuation authority; 2. industrial authority is bounded by a protected maximum envelope; 3. where staged operation is selected, a real bounded process or machine effect produces protected evidence before required broader continuation; 4. current interlock, process, safety, policy, and revocation state may be revalidated between phases; 5. a successful bounded effect does not authorize operation outside the maximum envelope; 6. sensor, actuator, crash, or process uncertainty may create a blocked or indeterminate state rather than implicit authorization; 7. hazard- reduction and safe-shutdown paths may retain separately scoped authority; 8. time-critical implementations may enforce the receipt gate locally; 9. alternate machine/process paths are controlled where needed to preserve non-bypassability. FROZEN RELATIONSHIP BETWEEN E25, E26 AND E27 V ehicle P roposal → Bounded Real M ovement → V ehicle Receipt → Broader V ehicle Authority M ission P roposal → Bounded M obility P hase → M obility Receipt → N ext M ission P hase P rocess P roposal → Bounded Real P rocess Effect → P rocess Receipt → Broader P rocess Authority The common architecture is that a computationally generated plan is not itself unconditional authority for the full physical consequence. A protected boundary may first permit a bounded real effect, obtain protected evidence of what actually occurred, and make later authority technically dependent on that evidence. A.28. E28 — Receipt-Gated Telecom Effectuation and Progressive Network Authority A.28.1. E28.1 Purpose E28 applies the staged-effectuation architecture to telecommunications systems in which a computational source proposes a network, subscriber, routing, signaling, session, service, or trafficcontrol act capable of creating a consequential change in a live communications infrastructure. The Candidate Act may originate from an AI controller, telecom orchestration system, policy engine, network-management application, SDN controller, service-management system, subscribermanagement function, radio-access controller, core- network function, edge platform, human operator, or another Das Expires 4 April 2027 [Page 471] Internet-Draft Reality as a Cryptographic Dependency October 2026 computational source. The central relationship is: T elecom Candidate Act → Bounded Live N etwork Effect → P rotected T elecom Receipt → Continuat The computational production of a network plan, configuration, route, subscriber policy, or control decision does not itself constitute unconditional authority to make the corresponding live network consequence effective. A.28.2. E28.2 Candidate Telecom Acts A Candidate Act may include, without limitation: * establishing, modifying, or terminating a communications session; * changing a subscriber or device policy; * enabling a network slice or service class; * modifying a QoS profile; * changing routing, steering, forwarding, or next-hop state; * enabling or disabling a service path; * changing a bearer, tunnel, or flow configuration; * updating a policy-control decision; * modifying admission-control behavior; * changing a radio or core-network configuration; * releasing or withholding a communication; * changing message-delivery policy; * modifying traffic exposure to an application or edge service; * changing charging or quota-control state; * activating a feature for a subscriber, cohort, cell, region, tenant, or network domain; * performing a handover or route transition; * enabling a roaming, interconnect, or partner path; Das Expires 4 April 2027 [Page 472] Internet-Draft Reality as a Cryptographic Dependency October 2026 * changing a service-chain function; * or another act capable of affecting live communications. A.28.3. E28.3 Telecom Act Binding A protected telecom act descriptor may bind the Candidate Act to relevant technical context, including: * service type; * subscriber or endpoint identity; * device identity; * flow identity; * source and destination; * network domain; * cell, region, access point, or edge site; * route or service chain; * traffic class; * permitted throughput or rate; * session identifier; * slice identifier; * policy epoch; * revocation state; * network-function identity; * sink identity; * time window; * and maximum permitted consequence. The system may form: Das Expires 4 April 2027 [Page 473] Internet-Draft Reality as a Cryptographic Dependency October 2026 DT EL = H(Canon(AT EL )) where AT EL denotes the Candidate Telecom Act. The precise representation is not mandatory. The required property is that later authority remains associated with the authorized telecommunications act or authorized act envelope. A.28.4. E28.4 Maximum Telecom Effectuation Envelope Protected policy may define: TMAX as the maximum telecom consequence permitted under the relevant authorization. The envelope may constrain one or more of: * number of subscribers; * number of devices; * number of sessions; * traffic fraction; * geographic region; * network slice; * cell set; * destination set; * permitted service type; * rate or bandwidth; * duration; * routing domain; * allowed network functions; * allowed protocol or transport class; * permitted interconnect; * permitted data exposure; * permitted message scope; * or another live-network dimension. Prior receipt success must not itself authorize a consequence outside TMAX . Das Expires 4 April 2027 [Page 474] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.28.5. E28.5 Protected Network State Before or between phases, the PED may obtain protected state from one or more network functions, gateways, telemetry systems, hardware elements, policy engines, subscriber databases, transaction stores, or protected observers. Such state may include: * current route state; * flow counters; * session state; * bearer or tunnel state; * subscriber authorization; * network-function health; * cell or region state; * congestion state; * packet loss; * latency; * error rate; * policy state; * revocation state; * credential state; * attestation state; * configuration digest; * software or firmware measurement; * prior-phase receipt state; * and destination confirmation state. The proposing controller need not be able to rewrite this protected state. Das Expires 4 April 2027 [Page 475] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.28.6. E28.6 Phase-0 Live Telecom Effect Where staged effectuation is selected, Phase 0 produces a real live- network consequence bounded relative to the requested full consequence. Examples include: * enable a service for one subscriber before a large cohort; * route one protected test flow through a new path before a larger traffic fraction; * activate one cell or edge site before a region; * apply a new QoS policy to one flow before a service class; * establish one actual session before a large session batch; * transmit a bounded protected message before a larger communication release; * enable one destination or interconnect before a larger destination set; * move a small traffic fraction to a new network function before broader steering; * enable a feature for one device class before the full fleet. The Phase-0 operation is not merely simulation. At least one live network state relevant to the requested consequence changes. A.28.7. E28.7 Telecom Phase Scope A telecom phase may be bounded by a target set: Ui ⊆ UMAX where Ui represents the subscriber, device, session, flow, cell, or endpoint set affected by phase i. A traffic-fraction embodiment may additionally use: 0 < φiT EL ≤ 1 where φiT EL denotes the fraction of eligible traffic released into the phase. A progressive sequence may satisfy: φ0T EL < φ1T EL < ⋯ ≤ φMAX T EL where monotonic progression is appropriate. Das Expires 4 April 2027 [Page 476] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.28.8. E28.8 Phase-Specific Telecom Authority The PED may create or release authority sufficient only for the selected telecom phase. Such authority may comprise: * a scoped network capability; * a signed policy object; * a route-install authorization; * a flow-rule authorization; * a limited subscriber-policy update; * a one-time service activation; * a network-function command authenticator; * a hardware release value; * a DPU or SmartNIC rule-enablement value; * a gateway permit state; * or another bounded technical condition. The authority may bind DT EL , phase identity, target set, sink identity, expiry, policy epoch, revocation state, and prior receipt evidence. A.28.9. E28.9 Effectuation Boundary The telecom Finality Sink or equivalent effectuation boundary may reside in or adjacent to: * a packet gateway; * user-plane function; * policy-control function; * session-management function; * subscriber-management function; * SDN switch or controller boundary; * service-mesh or API gateway; Das Expires 4 April 2027 [Page 477] Internet-Draft Reality as a Cryptographic Dependency October 2026 * message gateway; * telecom application server; * edge node; * DPU; * SmartNIC; * NIC; * baseband or modem path; * secure network processor; * or another component technically capable of making the network act effective. The architecture does not require one standardized telecom function name. A.28.10. E28.10 Protected Telecom Receipt After the bounded live-network phase, a protected observer may generate: RiT EL The receipt may bind: * DT EL ; * phase identifier; * actual target set; * route or function identity; * live-session or flow identifier; * observed counters; * actual network result; * destination or endpoint evidence; * sink identity; * observer identity; * time; Das Expires 4 April 2027 [Page 478] Internet-Draft Reality as a Cryptographic Dependency October 2026 * nonce; * policy epoch; * and status. The receipt may be signed, MACed, attested, hash- linked, hardware-protected, or otherwise authenticated. A.28.11. E28.11 Telecom Health Vector Where a protected health representation is useful, the system may form: T hT i EL = [Lossi Latencyi Errori Congestioni Availabilityi ] The listed components are illustrative and not mandatory. Continuation may require: hT i EL ∈ ΩT EL where ΩT EL represents a protected acceptable telecom-operating region. A.28.12. E28.12 Receipt-Gated Continuation A representative continuation condition is: Enable(Pi+1 ) = V alid(RiT EL )∧W ithinT elecomEnvelope(Pi+1 )∧N etworkStateAcceptablei ∧P olicyCurr If any required condition fails, the next broader phase remains unavailable. A.28.13. E28.13 Progressive Subscriber or Device Rollout A feature may be released progressively to: |U0 | < |U1 | < ⋯ ≤ |UMAX | Each expansion may depend upon a protected receipt from the prior live cohort. The cohort may be selected by protected policy, randomization, topology, geography, device class, customer class, risk class, or another non-agent- controlled criterion. A.28.14. E28.14 Progressive Traffic Steering A traffic-steering embodiment may release increasing fractions through a new path or service function. Example: 1% → 5% → 20% → 50% → 100% Each phase remains bounded by the authorized maximum and may be stopped or reduced if protected evidence indicates unacceptable behavior. Das Expires 4 April 2027 [Page 479] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.28.15. E28.15 Route and Service-Chain Verification The system may bind a phase to an expected route or service-function sequence. Let: CTi EL = {ci,1 , ci,2 , ... , ci,k } represent an ordered or partially ordered set of network components or service functions expected for phase i. The protected observer may confirm that the actual route or service chain satisfies the authorized constraint before broader progression. An unauthorized function substitution may invalidate the receipt. A.28.16. E28.16 Message-SEND Telecom Variant A telecom system carrying a message, alert, file, or signaling object may first deliver a bounded protected object to the real destination. A destination-side or network-side receipt confirms the actual endpoint or delivery path. Only thereafter may the full communication, larger payload, decryption material, broader recipient set, or continued message stream be released. This is the telecom- specific realization of the earlier SEND staged-effectuation pattern. A.28.17. E28.17 Session Establishment Variant A large session batch may be preceded by one or more real bounded session establishments. A receipt may confirm: * endpoint identity; * session creation; * negotiated transport state; * policy application; * route selection; * or another protected technical fact. The later batch or broader session release remains unavailable until the required session receipt is accepted. A.28.18. E28.18 Network-Slice / Service-Class Variant A network slice, service class, tenant network, or isolated service domain may be activated in a bounded phase. Phase 0 may affect only: * one subscriber; Das Expires 4 April 2027 [Page 480] Internet-Draft Reality as a Cryptographic Dependency October 2026 * one test device; * one cell; * one region; * one application; * one traffic class; * or one protected service instance. Protected evidence from the bounded activation may gate broader slice or service-class exposure. A.28.19. E28.19 Edge and Multi-Access Variant A staged effect may occur first at one edge node or access domain. A receipt may confirm: * successful route installation; * destination reachability; * service health; * policy conformance; * or protected traffic handling. Only after acceptance may the effect expand to additional edge sites, access technologies, or regional domains. A.28.20. E28.20 Hardware-Rooted Telecom Enforcement A hardware-rooted implementation may place critical phase state or authority in: * DPU; * SmartNIC; * NIC security engine; * baseband security processor; * modem secure subsystem; * secure element; Das Expires 4 April 2027 [Page 481] Internet-Draft Reality as a Cryptographic Dependency October 2026 * HSM; * TEE; * FPGA; * ASIC; * switch silicon; * router security module; * or another protected hardware component. The hardware may reject a phase transition unless a valid prior receipt or derived phase authorization is present. A.28.21. E28.21 Local Low-Latency Enforcement Where a remote round trip would be too slow, a protected local telecom component may hold the necessary policy, state, and verification material. The sequence may become: Local Bounded Effect → Local P rotected Observation → Local Receipt V alidation → N ext Local Auth A remote controller may receive the receipt later for audit or synchronization without being on the critical path. A.28.22. E28.22 Human Approval A protected human may approve: * the initial telecom act; * the maximum network envelope; * the first bounded phase; * expansion after a receipt; * a high-risk route change; * a broad subscriber rollout; * or a recovery after failure. The approval may be bound to DT EL , RiT EL , phase scope, target set, network region, and expiry. Das Expires 4 April 2027 [Page 482] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.28.23. E28.23 Automatic Approval Protected policy may automatically advance where the receipt and current network state satisfy required predicates. For example: V alid(RiT EL ) ∧ hTi EL ∈ ΩT EL ∧ W ithinT elecomEnvelope(Pi+1 ) ⇒ AutoContinue The proposing AI or network optimizer need not control this decision. A.28.24. E28.24 Hybrid Approval An implementation may automatically advance low-consequence phases but require a protected human for broader scope, inter-domain changes, large subscriber populations, or high-risk service classes. A receipt therefore informs both automatic and human continuation logic. A.28.25. E28.25 Failure and Rollback If a bounded telecom phase fails, the system may: * stop progression; * restore a prior route; * withdraw a policy; * reduce traffic fraction; * isolate an affected cohort; * fail back to a prior network function; * require human review; * or terminate the requested change. The rollback path may itself be protected and may use separate hazard-reduction or continuity authority. A.28.26. E28.26 Indeterminate Telecom State If the system cannot determine whether the live network change took effect, it may enter: T EL_IN DET ERM IN AT E The PED may reconcile using: * network-function state; Das Expires 4 April 2027 [Page 483] Internet-Draft Reality as a Cryptographic Dependency October 2026 * flow-table state; * session records; * subscriber database state; * counters; * protected logs; * transaction identifiers; * endpoint confirmation; * or hardware state. Broader effectuation remains blocked until a permitted reconciliation outcome is established. A.28.27. E28.27 Crash After Network Effect A network change may occur before its receipt reaches the controller. The phase may therefore use an idempotency identifier: IiT EL = H(DT EL ∥ P hasei ∥ Ni ) The sink or protected network function may atomically bind the identifier to the applied livenetwork change. After restart, the system can distinguish a previously effected phase from one that never occurred. A.28.28. E28.28 Alternate-Path Closure The staged telecom path should not be trivially bypassable through an equivalent full-effect route. Relevant paths may include: * direct network-management interfaces; * emergency or recovery interfaces; * alternate controller credentials; * low-level switch or router configuration paths; * raw flow-programming interfaces; * direct subscriber-database mutation; * alternate message gateways; * shadow policy systems; Das Expires 4 April 2027 [Page 484] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or another act-equivalent network path. Such paths may be disabled, scoped, mediated, cryptographically locked, or subjected to equivalent protected verification. A.28.29. E28.29 Multi-Domain Telecom Progression A telecom act may cross multiple administrative or technical domains. Each domain may issue its own protected receipt. Continuation may require a set or quorum of domain receipts before the end-to-end consequence expands. A downstream domain may refuse expansion even if an upstream domain has already succeeded. A.28.30. E28.30 E28 Required Invariants The frozen core of E28 is: 1. a telecom proposal is distinguishable from live telecom effectuation; 2. a protected maximum telecom envelope bounds the permitted consequence; 3. where staged mode is selected, at least one bounded phase causes a real live-network effect; 4. protected evidence of that effect may gate a broader or subsequent network effect; 5. a successful receipt does not authorize expansion beyond the maximum envelope; 6. network uncertainty may block progression rather than being treated as success; 7. the proposing controller need not possess unrestricted live-network authority; 8. software, hardware, or split enforcement may be used; 9. act-equivalent alternate paths are controlled where needed to preserve non-bypassability. TERRESTRIAL NETWORK EFFECTUATION A.29. E29 — Receipt-Gated Radio, Satellite, and Non-Terrestrial Network Effectuation A.29.1. E29.1 Purpose E29 applies the staged-effectuation architecture to radio-frequency, wireless, satellite, spacecommunications, high-altitude, relay, and non-terrestrial network operations in which a computational source proposes an action capable of creating an externally consequential transmission, link, beam, waveform, channel, relay, payload, or communications-state change. A representative relationship is: Radio/N T N Candidate Act → Bounded Real RF /Link Effect → P rotected RF /Link Receipt → Con Das Expires 4 April 2027 [Page 485] Internet-Draft Reality as a Cryptographic Dependency October 2026 The architecture may operate at a transmitter, receiver, gateway, modem, satellite payload, ground station, relay, baseband, beamformer, secure radio, or another protected communications boundary. A.29.2. E29.2 Candidate Radio and NTN Acts A Candidate Act may include: * transmit a frame, packet, burst, stream, or message; * select or change a frequency or channel; * change transmit power; * change bandwidth; * change waveform or modulation parameters; * activate a beam; * steer a beam; * change coding or redundancy; * open or close a radio link; * perform handover; * select a gateway; * select an inter-satellite or relay path; * activate a payload communications function; * allocate a time/frequency resource; * change a satellite service footprint; * change an NTN route; * activate a ground-to-space or space-to-ground path; * release an encrypted payload or decryption key; * or another radio/NTN consequence. Das Expires 4 April 2027 [Page 486] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.29.3. E29.3 Protected RF/NTN Act Binding The protected act descriptor may bind: * transmitter identity; * receiver identity; * satellite or relay identity; * gateway identity; * frequency or channel; * power limit; * bandwidth; * beam identifier; * pointing or footprint constraint; * modulation or waveform class; * duration; * payload identity; * destination; * route or hop sequence; * time window; * policy epoch; * revocation state; * and maximum permitted radio/NTN consequence. The system may form: DRF = H(Canon(ARF )) where ARF denotes the Candidate Radio/NTN Act. A.29.4. E29.4 Maximum Radio/NTN Effectuation Envelope Protected policy may define: Das Expires 4 April 2027 [Page 487] Internet-Draft Reality as a Cryptographic Dependency October 2026 ERF MAX as the maximum permitted radio or NTN consequence. The envelope may constrain: * power; * duration; * frequency range; * bandwidth; * beam direction; * beam footprint; * receiver set; * gateway set; * route or relay path; * satellite or payload function; * geographic area; * traffic volume; * data object; * protocol or waveform class; * and phase count. A.29.5. E29.5 Phase-0 Real RF Effect A bounded Phase-0 effect may comprise, for example: * a low-power transmission; * a short-duration burst; * a narrow-bandwidth transmission; * one protected verification frame; * one bounded encrypted object; Das Expires 4 April 2027 [Page 488] Internet-Draft Reality as a Cryptographic Dependency October 2026 * one beam to a limited footprint; * one gateway path; * one satellite relay hop; * one short session; * one bounded payload-service activation; * or another deliberately restricted but real radio effect. The effect occurs through the actual RF, optical-wireless, satellite, or NTN path rather than solely in simulation. A.29.6. E29.6 Phase-Specific RF Parameters A phase may be bounded by one or more parameters such as: pitx , BiRF , Δti , bi where, locally: * pitx may represent transmit-power scope; * BiRF may represent authorized bandwidth; * Δti may represent authorized transmission duration; * bi may identify a beam, footprint, or directional transmission state. The architecture does not require these particular radio parameters. A.29.7. E29.7 Protected Receiver-Side Observation The actual receiving endpoint or another protected observer may confirm one or more technical facts such as: * protected frame received; * expected transmitter authenticated; * expected receiver reached; * expected route or relay used; * signal arrived within a permitted condition; * integrity verified; * bounded object stored; Das Expires 4 April 2027 [Page 489] Internet-Draft Reality as a Cryptographic Dependency October 2026 * expected beam or footprint observed; * expected gateway or satellite identity confirmed. This observation may be more probative than transmitter-side intent alone. A.29.8. E29.8 RF Effect Receipt A protected receipt may be generated as: RiRF and may bind: * DRF ; * phase identifier; * transmitter; * receiver; * gateway; * satellite or relay; * actual RF parameters; * actual route or hop evidence; * protected observation; * time; * nonce; * policy epoch; * and status. A.29.9. E29.9 Receiver Confirmation Receipt Where destination-side confirmation is required, a receiving system may issue: RiRX The continuation predicate may require both local transmission evidence and remote receiver evidence: V alid(RiRF ) ∧ V alid(RiRX ) before the broader phase is enabled. Das Expires 4 April 2027 [Page 490] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.29.10. E29.10 Beam-Progression Embodiment A radio or satellite system may begin with a narrow or low- consequence beam configuration. After protected receipt evidence, it may progress to: * a wider footprint; * a different beam; * multiple beams; * longer duration; * higher throughput; * or a larger receiver set. A protected maximum envelope prevents prior success from becoming unrestricted beam authority. A.29.11. E29.11 Power-Progression Embodiment Transmit power may progress according to a protected schedule. For example: p0tx < p1tx < ⋯ ≤ pMAX tx where each increase is permitted only after required receipt validation and current policy checks. A higher-power phase is not automatically authorized merely because a lower-power phase succeeded. A.29.12. E29.12 Duration-Progression Embodiment A system may first authorize a short-duration transmission and then expand the permitted interval. For example: Δt0 < Δt1 < ⋯ ≤ ΔtMAX A receipt may prove that the prior bounded transmission reached the intended receiver or behaved within the expected technical envelope. A.29.13. E29.13 Bandwidth / Resource-Block Progression A radio system may begin with limited spectral or time-frequency resources and expand only after protected evidence. The bounded stage may use: * one channel; Das Expires 4 April 2027 [Page 491] Internet-Draft Reality as a Cryptographic Dependency October 2026 * one carrier; * one sub-band; * one timeslot; * one resource-block set; * one protected waveform instance; * or another limited radio resource. A.29.14. E29.14 Gateway Verification Before broader satellite or NTN traffic is released, a bounded stage may verify the actual gateway path. A gateway receipt may bind: * gateway identity; * route identity; * satellite or relay identity; * protected session identifier; * bounded traffic result; * and next-stage eligibility. An unauthorized gateway substitution may block continuation. A.29.15. E29.15 Multi-Hop / Relay Path A non-terrestrial or relay path may include multiple hops. Let: Hi = {hi,1 , hi,2 , ... , hi,k } represent the authorized hop sequence or hop set for phase i. Protected evidence may be collected from one or more hops. Continuation may require: RouteAcceptable(Hi ) = T RU E in addition to ordinary receipt validation. A.29.16. E29.16 Aggregate Relay Receipt Where multiple relay or gateway receipts exist, the system may create an aggregate protected commitment: Das Expires 4 April 2027 [Page 492] Internet-Draft Reality as a Cryptographic Dependency October 2026 RiAGG = Commit(Ri,1 , Ri,2 , ... , Ri,k ) The aggregate may be a hash tree, threshold signature, multi-signature, protected summary, or other authenticated construction. The construction is non-limiting. A.29.17. E29.17 Store-and-Forward NTN Variant In a delayed or intermittently connected NTN environment, the full receipt may not return immediately. The system may therefore: * allow only a bounded locally authorized phase; * store the protected result; * await later authenticated return evidence; * reconcile the phase state; * and release broader authority only after the delayed receipt is accepted. This permits receipt-gated operation without assuming continuously available connectivity. A.29.18. E29.18 Long-Latency Local Continuation Where a round trip to a remote ground or cloud authority is impractical, a protected local radio, satellite, or gateway component may hold phase policy and cryptographic continuation material. The local sequence may be: Bounded RF Effect → Local P rotected Observation → Local Receipt → Local N ext P hase The resulting receipts may later be synchronized with a remote authority. A.29.19. E29.19 Cryptographic Phase Release A protected component may derive a next-stage key or command authenticator from the prior accepted receipt. For example: RF RF Ki+1 = KDF (KR , DRF , H(RiRF ), i + 1) The later transmission authority therefore becomes technically dependent on accepted evidence from the earlier real radio phase. Das Expires 4 April 2027 [Page 493] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.29.20. E29.20 Destination-Key Release A full encrypted communication may be pre-staged through the radio or satellite network while semantic release remains unavailable. After a valid bounded-path or receiver receipt, the protected system may release: * a decryption key; * a key share; * unwrap authority; * a session continuation value; * or equivalent missing execution material. This can separate transport completion from semantic disclosure. A.29.21. E29.21 Satellite Payload Communications Variant A satellite payload may perform a bounded communications action before broader service activation. Examples include: * one protected beacon; * one test frame; * one gateway session; * one beam; * one tenant channel; * one bounded data object; * or one short-duration service interval. Receipt evidence from a ground station, destination, onboard protected observer, or combination may gate broader payload communications authority. A.29.22. E29.22 Cross-Link Variant A satellite or relay network may verify one real cross-link or relay path before permitting broader path use. A protected receipt may bind: * source node; * destination node; Das Expires 4 April 2027 [Page 494] Internet-Draft Reality as a Cryptographic Dependency October 2026 * intermediate relay identity; * link identifier; * observed integrity; * and phase status. The later path authority may be scoped to the verified cross-link topology or authorized route class. A.29.23. E29.23 Handover Variant A wireless or NTN system may first move a bounded session, flow, or traffic fraction to a new link or serving node. Receipt evidence may confirm that the handover actually completed and that the resulting state satisfies protected conditions before additional sessions or traffic are moved. A.29.24. E29.24 Human Approval A protected human may approve: * a maximum RF envelope; * a new gateway; * a new beam footprint; * a broader receiver set; * a high-power phase; * a satellite payload-service activation; * or recovery after an indeterminate state. The approval may bind the current receipt and exact continuation scope. A.29.25. E29.25 Automatic Approval A protected policy engine may automatically continue where: V alid(RiRF )∧W ithinRF Envelope(Pi+1 )∧LinkStateAcceptablei ∧P olicyCurrenti ∧RevocationCleari is satisfied. The proposing radio optimizer need not be able to mark these conditions as true. Das Expires 4 April 2027 [Page 495] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.29.26. E29.26 Hybrid Approval A system may automatically advance low-power, short-duration, or small-footprint phases but require a protected human or additional authority for broader or more consequential phases. A.29.27. E29.27 Failure and Indeterminate Link State If a receipt reports failure, rejection, unacceptable observation, or indeterminate state, broader radio/NTN progression remains unavailable. Reconciliation may query: * transmitter state; * receiver state; * gateway logs; * onboard protected logs; * link counters; * satellite telemetry; * transaction or frame identifiers; * and protected hardware state. A.29.28. E29.28 Duplicate Transmission Protection A consequential radio transmission may use a protected idempotency or sequence identifier. For example: IiRF = H(DRF ∥ P hasei ∥ Ni ) A receiver, gateway, or protected sink may reject an unauthorized duplicate associated with the same single- use phase authority. A.29.29. E29.29 Anti-Bypass Alternative paths capable of creating the broader RF or NTN consequence may be subjected to corresponding control. Examples include: * direct modem control; * raw radio commands; * alternate gateway credentials; Das Expires 4 April 2027 [Page 496] Internet-Draft Reality as a Cryptographic Dependency October 2026 * low-level beamformer control; * maintenance interfaces; * payload-debug paths; * direct baseband programming; * fallback satellite routing; * or another effect-equivalent path. A.29.30. E29.30 E29 Required Invariants The frozen core of E29 is: 1. radio/NTN proposal is distinguishable from actual transmission or link effect; 2. a protected maximum radio/NTN envelope bounds authority; 3. where staged mode applies, the initial stage creates a real bounded RF/link consequence; 4. protected evidence from the sink, receiver, gateway, relay, or protected observer may gate broader authority; 5. missing or indeterminate evidence blocks unauthorized broader progression; 6. long-latency and store-and-forward environments may use local protected gating and later synchronization; 7. phase authority may be cryptographically derived from earlier receipt evidence; 8. software, firmware, hardware, or distributed enforcement may be used; 9. equivalent alternate radio-control paths are controlled where needed for non-bypassability. EGRESS EFFECTUATION A.30. E30 — Receipt-Gated GPU, Accelerator, and Compute-Egress Effectuation A.30.1. E30.1 Purpose E30 applies the architecture to GPUs, AI accelerators, neural- processing units, tensor processors, compute cards, accelerator clusters, confidential-computing accelerators, DMA-capable devices, and related compute fabrics. The embodiment distinguishes computation from authority to create an external or durable consequence. A system may therefore permit substantial computation while separately controlling whether the resulting operation may: * leave protected accelerator memory; * reach a host or network; * update durable model state; Das Expires 4 April 2027 [Page 497] Internet-Draft Reality as a Cryptographic Dependency October 2026 * modify external storage; * invoke another device; * release sensitive output; * or become an externally consequential act. A representative relationship is: Accelerator Candidate Act → Bounded Real Compute/Device Effect → P rotected Accelerator Receip A.30.2. E30.2 Candidate Accelerator Acts A Candidate Act may include: * dispatch a kernel; * execute a graph; * run an inference batch; * execute a training step; * update accelerator-local state; * write a memory region; * initiate DMA; * export a tensor or result; * send data over a high-speed fabric; * transfer data to a NIC or DPU; * expose an output to a host process; * decrypt or unwrap accelerator-resident data; * activate a cluster-wide job; * expand a job to more devices; * enable a new memory or fabric path; * or another accelerator consequence. Das Expires 4 April 2027 [Page 498] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.30.3. E30.3 Accelerator Act Binding The protected system may bind a Candidate Accelerator Act to: * accelerator identity; * device or cluster identity; * command queue; * kernel or graph identity; * code digest; * model digest; * input identity; * memory range; * output range; * destination; * DMA target; * fabric peer; * host process; * VM or confidential workload; * tenant; * permitted batch size; * permitted runtime; * permitted egress; * policy epoch; * revocation state; * and maximum consequence. The system may form: Das Expires 4 April 2027 [Page 499] Internet-Draft Reality as a Cryptographic Dependency October 2026 DACC = H(Canon(AACC )) where AACC denotes the Candidate Accelerator Act. A.30.4. E30.4 Maximum Accelerator Effectuation Envelope Protected policy may define: GMAX as the maximum permitted accelerator consequence. It may constrain: * device set; * memory region; * kernel or graph set; * batch size; * execution count; * runtime; * output size; * destination set; * DMA range; * host-visible memory; * network-visible output; * model or dataset scope; * accelerator-fabric path; * privilege level; * or another compute or egress dimension. A.30.5. E30.5 Compute Versus Effectuation Separation The accelerator may be permitted to calculate a result without thereby obtaining authority to expose, commit, transmit, or otherwise effectuate that result externally. For example: Das Expires 4 April 2027 [Page 500] Internet-Draft Reality as a Cryptographic Dependency October 2026 ComputeComplete = T RU E ⇏ ExternalReleaseAuthorized = T RU E This separation is particularly important where model inference, training, or transformation can occur inside a protected accelerator but the resulting output has not yet crossed an effectuation boundary. A.30.6. E30.6 Phase-0 Bounded Accelerator Effect A bounded first phase may include: * execute on one accelerator before a cluster; * process one small batch before a larger batch; * write one protected local buffer before a broader memory range; * export one bounded digest or result fragment before a complete output; * perform one DMA transfer to a protected staging region before a final destination; * activate one fabric peer before a larger peer set; * release one encrypted output segment before semantic decryption; * execute one kernel or graph stage before a larger pipeline. The Phase-0 operation is real. It changes accelerator, memory, fabric, staging, or destination state in a bounded manner. A.30.7. E30.7 Device-Set Progression Let: DACC i represent the accelerator-device set authorized for phase i. A progressive rollout may satisfy: DACC 0 ⊂ DACC 1 ⊂ ⋯ ⊆ DACC MAX where expansion is appropriate. The next device set becomes available only after the required prior-phase evidence is accepted. A.30.8. E30.8 Memory-Region Scope A phase may be restricted to a protected memory region: MACC i Das Expires 4 April 2027 [Page 501] Internet-Draft Reality as a Cryptographic Dependency October 2026 The sink or memory-control component may reject access outside that region. A later receipt may authorize a larger region, a different region, or a destination-specific export from the region. A.30.9. E30.9 Protected Accelerator State The PED or protected device logic may obtain state such as: * device identity; * firmware measurement; * secure-boot state; * command-queue state; * memory-protection state; * IOMMU state; * confidential-compute state; * tenant identity; * current job identity; * kernel or graph identity; * device-health state; * error counters; * thermal state; * memory-integrity state; * fabric-link state; * destination identity; * prior receipt state; * and phase-latch state. A.30.10. E30.10 Accelerator Effect Receipt After a bounded phase, protected logic may generate: Das Expires 4 April 2027 [Page 502] Internet-Draft Reality as a Cryptographic Dependency October 2026 RiACC The receipt may bind: * DACC ; * accelerator identity; * phase identifier; * command or graph identity; * device set; * memory region; * observed result digest; * DMA or fabric destination; * output-release state; * hardware measurement; * time; * nonce; * policy epoch; * and status. A.30.11. E30.11 Protected Device State Vector An implementation may represent selected accelerator health or effectuation state as: T gi = [Healthi Errori M emoryIntegrityi F abricStatei EgressStatei ] Continuation may require: gi ∈ ΩACC where ΩACC is a protected acceptable accelerator-state region. A.30.12. E30.12 Command-Queue Gate A protected component may prevent a phase command from becoming executable until required authority is present. The gate may reside at: Das Expires 4 April 2027 [Page 503] Internet-Draft Reality as a Cryptographic Dependency October 2026 * driver boundary; * kernel module; * runtime; * hypervisor; * confidential-compute monitor; * device firmware; * security processor; * command processor; * doorbell path; * MMIO gate; * or another device-command boundary. The precise placement is non- limiting. A.30.13. E30.13 Protected Command Release The system may withhold a command descriptor, authenticator, queue- release value, doorbell enablement, key, or hardware state required for the next phase. Only after protected receipt verification is the missing command material released. Thus the next phase may be technically unavailable even if ordinary software has already constructed the command. A.30.14. E30.14 DMA Effectuation Gate A DMA-capable accelerator may compute locally while a protected boundary separately controls whether data can be written to an external memory or device. A phase may authorize DMA only to: * a staging buffer; * a protected host page range; * a DPU buffer; * a specific NIC queue; * a specific storage target; Das Expires 4 April 2027 [Page 504] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or another bounded destination. The full DMA path remains unavailable until prior receipt conditions are satisfied. A.30.15. E30.15 IOMMU / Memory-Controller Variation An IOMMU, memory controller, secure memory subsystem, or equivalent device may participate in the Finality Sink function. It may verify: * authorized device; * memory range; * phase identity; * destination; * access type; * and current protected state. A valid compute result alone does not override the protected memory-access constraint. A.30.16. E30.16 Fabric-Gated Progression Accelerator fabrics may include PCIe, CXL, device-to-device links, GPU interconnects, or other high-speed fabrics. A phase may authorize communication only to a bounded peer set. Let: FACC i represent the permitted accelerator-fabric peer or path set for phase i. A later receipt may enable a broader peer set, subject to the maximum envelope. A.30.17. E30.17 DPU / SmartNIC Egress Gate A DPU, SmartNIC, NIC, or secure network processor may prevent accelerator output from becoming network-visible until protected continuation conditions succeed. The accelerator may complete computation while the DPU or SmartNIC withholds network release. A receipt from the compute phase, destination path, or both may then unlock a bounded or full egress phase. A.30.18. E30.18 Output-Key Release A protected accelerator may produce encrypted output. The system may withhold an output-release key: KiOUT until the required phase receipt is accepted. Thus: Das Expires 4 April 2027 [Page 505] Internet-Draft Reality as a Cryptographic Dependency October 2026 CiphertextAvailable = T RU E ⇏ SemanticOutputAvailable = T RU E The key may be destination-bound, phase-bound, tenant-bound, or receipt- derived. A.30.19. E30.19 Receipt-Derived Output Authority A strong embodiment derives the next output-release authority from a prior protected receipt. For example: OUT ACC Ki+1 = KDF (KR , DACC , H(RiACC ), i + 1, Destination) The named KDF is illustrative. Equivalent protected derivation or unsealing mechanisms may be used. A.30.20. E30.20 One-Accelerator-to-Cluster Progression A large compute job may first execute on one protected accelerator or one small accelerator group. Protected evidence may confirm: * code identity; * model identity; * bounded output integrity; * memory behavior; * device health; * fabric behavior; * or destination handling. Only thereafter may the job expand to a larger accelerator set. A.30.21. E30.21 Batch-Size Progression A job may begin with bounded batch size: JOB B0JOB < B1JOB < ⋯ ≤ BMAX Each larger batch may require accepted evidence from the preceding real phase. The batch notation is local to E30 and does not alter earlier uses of B . A.30.22. E30.22 Progressive Output Release A large output may be released in phases: * digest only; * metadata only; Das Expires 4 April 2027 [Page 506] Internet-Draft Reality as a Cryptographic Dependency October 2026 * one output segment; * one encrypted chunk; * a bounded sample; * a larger output subset; * complete ciphertext; * final decryption authority. This permits computation and transport to progress without immediately creating the complete semantic consequence. A.30.23. E30.23 Confidential-Computing Variant A confidential VM, TEE, accelerator enclave, or other protected compute environment may hold the phase state and cryptographic authority. Attestation may bind: * workload measurement; * accelerator measurement; * model identity; * tenant identity; * policy; * and phase state. A valid attestation alone need not constitute permission for unrestricted egress; the receipt-gated effectuation condition may still be required. A.30.24. E30.24 GPU Security-Processor Variation A GPU or accelerator security processor may maintain: * root key; * phase counter; * receipt-consumption state; * permitted memory region; Das Expires 4 April 2027 [Page 507] Internet-Draft Reality as a Cryptographic Dependency October 2026 * permitted destination; * command-release state; * or output-key state. Ordinary host software may be unable to force advancement without satisfying the protected receipt predicate. A.30.25. E30.25 Multi-Accelerator Receipt Aggregation Where a phase spans multiple devices, each device may issue: ACC Ri,j for accelerator j. Continuation may require: n ACC ∑ V alid(Ri,j )≥m j=1 or another protected aggregate condition. The required threshold may depend on the workload and policy. A.30.26. E30.26 Partial Device Failure If some accelerators succeed and others fail, the system may: * continue only on the successful set; * reduce the next device set; * isolate failed devices; * re-run a bounded phase; * require human review; * or terminate. A successful subset must not silently become authority to bypass failed-device constraints. A.30.27. E30.27 Human Approval A protected human may approve: * the maximum accelerator envelope; * a cluster expansion; * release of sensitive output; * broader memory access; Das Expires 4 April 2027 [Page 508] Internet-Draft Reality as a Cryptographic Dependency October 2026 * a new egress destination; * a high-value model or dataset operation; * or recovery after an indeterminate device state. A.30.28. E30.28 Automatic Approval Protected logic may automatically continue where: V alid(RiACC )∧gi ∈ ΩACC ∧W ithinAcceleratorEnvelope(Pi+1 )∧P olicyCurrenti ∧RevocationCleari is satisfied. The AI workload itself need not control this decision. A.30.29. E30.29 Hybrid Approval An implementation may automatically expand low-consequence compute phases while requiring human or multi-authority approval for: * external egress; * large cluster activation; * sensitive data exposure; * durable external state change; * or broader privilege. A.30.30. E30.30 SEND Example An AI model may generate a message entirely on an accelerator. The computation may complete, but the message remains inside protected memory or encrypted staging. A bounded recipient-verification or trailer phase occurs first. After a valid receipt, the protected egress gate releases the complete message, ciphertext, or decryption key to the authorized communication path. Thus model generation does not itself constitute SEND authority. A.30.31. E30.31 Payment Example An accelerator may compute a payment recommendation, fraud score, amount, or transaction object. The resulting object remains non- effective until protected payment authority is released through the relevant receipt-gated payment boundary. A successful GPU computation therefore does not itself authorize funds movement. Das Expires 4 April 2027 [Page 509] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.30.32. E30.32 Crash / Reset / Device-Recovery State An accelerator may reset after a bounded effect but before the host records the receipt. Protected recovery may use: * device monotonic counter; * protected phase journal; * command identifier; * memory-state digest; * DPU or host-side protected record; * destination record; * or hardware receipt store. The system should not blindly reissue a potentially consequential phase if the prior effect may already have occurred. A.30.33. E30.33 Idempotency A phase-specific accelerator effect may use: IiACC = H(DACC ∥ P hasei ∥ Ni ) The relevant sink, queue gate, DPU, memory controller, or destination may record the identifier atomically with the effect where practical. A.30.34. E30.34 Revocation During Compute A long-running compute phase may begin while authorization is valid and finish after revocation. The architecture may distinguish: * permission to continue internal computation; * permission to release output; * permission to commit durable external state; * permission to communicate to another device; * and permission to begin another phase. Revocation may therefore block later consequence even if internal computation has already completed. Das Expires 4 April 2027 [Page 510] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.30.35. E30.35 Alternate-Path Closure Relevant bypass paths may include: * raw device-driver access; * alternate command queue; * privileged MMIO; * unprotected DMA mapping; * debug interface; * peer-to-peer fabric path; * direct NIC path; * alternate decryption key; * host memory copy path; * recovery firmware; * or another effect-equivalent accelerator path. Such paths may be disabled, mediated, scoped, cryptographically gated, or subjected to equivalent finality verification. A.30.36. E30.36 E30 Required Invariants The frozen core of E30 is: 1. accelerator computation is distinguishable from authority to create the final external or durable consequence; 2. a protected maximum accelerator envelope bounds compute, memory, device, fabric, and/or egress consequence; 3. where staged mode applies, an initial real bounded compute/device effect is observed and evidenced; 4. broader compute, memory, fabric, DMA, or egress authority may depend technically on accepted prior evidence; 5. completion of computation alone does not require release of sensitive or consequential output; 6. revocation, failure, or indeterminate state may block later consequence even after computation has occurred; 7. software, firmware, DPU, SmartNIC, IOMMU, memory-controller, accelerator-securityprocessor, or other hardware enforcement may be used; 8. alternate effect-capable device paths are controlled where needed to preserve nonbypassability; 9. SEND, payment, and other external acts remain separately subject to their corresponding effectuation boundaries. FROZEN RELATIONSHIP BETWEEN E28, E29 AND E30 Das Expires 4 April 2027 [Page 511] Internet-Draft Reality as a Cryptographic Dependency October 2026 N etwork P roposal → Bounded Live N etwork Effect → T elecom Receipt → Broader N etwork Authori RF /N T N P roposal → Bounded Real Link/T ransmission Effect → RF /Link Receipt → Broader RF Compute P roposal → Bounded Real Compute/Device Effect → Accelerator Receipt → Broader Comp The common architecture is that computation, optimization, route selection, transmission planning, or accelerator execution does not itself constitute unconditional authority for the complete external consequence. Protected evidence from a bounded real effect may become a technical prerequisite for broader effectuation. A.31. E31 — Receipt-Gated Model-State Update, Protected Memory Commit, and Progressive Model-State Effectuation A.31.1. E31.1 Purpose E31 applies the staged-effectuation architecture to persistent or consequential state associated with an AI model, agent, model-serving system, retrieval system, learned component, adaptive controller, or autonomous computational system. The embodiment addresses the distinction between computing a proposed state change and making that change authoritative for subsequent operation. A model, agent, optimizer, trainer, adaptation routine, tool, application, or human operator may propose a state modification. The proposal itself need not become durable, trusted, deployable, or execution-relevant state merely because it was computed. The central relationship is: P roposed M odel State Change → Bounded P rotected State U pdate → Observed State Receipt → Conti E31 may be used independently or together with E16 database promotion, E18 model deployment, E19 tool-use control, E20 credential release, E21 data export, E30 accelerator effectuation, or another embodiment. A.31.2. E31.2 Model-State Scope For purposes of this embodiment, model state may include, without limitation: * model parameters or weights; * adapter parameters; * low-rank adaptation state; Das Expires 4 April 2027 [Page 512] Internet-Draft Reality as a Cryptographic Dependency October 2026 * fine-tuning state; * optimizer state; * routing or gating state; * model-selection state; * persistent agent memory; * long-term memory objects; * vector-store entries used as durable model memory; * retrieval indexes or protected retrieval metadata; * tool-use policy state; * action-policy state; * planning memory; * protected conversation-derived memory; * task-state memory; * safety or execution-control configuration; * trusted prompt/configuration state; * policy tables; * preference state; * model-serving metadata; * model registry state; * calibration state; * reward or evaluation state; * protected provenance state; * state of a learned or adaptive control system; Das Expires 4 April 2027 [Page 513] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or another persistent state capable of changing later computational or external behavior. Temporary internal computation that is never promoted into a protected or persistent state may remain outside this embodiment unless protected policy elects to treat it as consequential state. A.31.3. E31.3 Candidate Model-State Update Let: AMS denote a Candidate Model-State Update. The Candidate Model-State Update may identify: * source model or agent; * target model or agent; * target state class; * object or parameter set; * prior-state version; * proposed new-state version; * change-set; * provenance; * source data or source event identifier; * update reason; * policy epoch; * approval requirement; * intended deployment scope; * permitted downstream effect class; * and maximum authority that may result from the state update. A protected representation may be formed: DMS = H(Canon(AMS )) or another deterministic binding may be used. Das Expires 4 April 2027 [Page 514] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.31.4. E31.4 State-Authority Separation A central property of E31 is that: P roposedState ≠ AuthoritativeState until the required protected promotion conditions have been satisfied. An agent may therefore be permitted to: * calculate a memory entry; * suggest a preference update; * produce an adapter delta; * generate a learned policy update; * create a candidate model version; * or derive a new model-state object; without being able to make the proposal authoritative for subsequent operation. A.31.5. E31.5 Provisional Model-State Region A proposed state change may first be placed into a provisional, shadow, quarantined, candidate, staging, or non-authoritative region. Let: SMS prov denote such a provisional model-state region. The provisional region may be implemented in: * protected memory; * a database namespace; * object storage; * a model registry; * a vector database; * a trusted execution environment; * a secure element; * protected accelerator memory; Das Expires 4 April 2027 [Page 515] Internet-Draft Reality as a Cryptographic Dependency October 2026 * a firmware-controlled partition; * a remote protected service; * or another storage domain. Material in the provisional region may be readable for evaluation while remaining unavailable as authoritative live state. A.31.6. E31.6 Authoritative Model-State Region Let: SMS auth denote the authoritative state region used by the live model, agent, or serving system. Promotion from provisional to authoritative state may require protected continuation authority. An implementation may therefore enforce: MS W rite(Sprov ) ⇏ W rite(SMS auth ) without a separate protected decision. A.31.7. E31.7 Bounded Phase-0 State Update Phase 0 may make a real but bounded state modification. Examples include: * commit one candidate memory item but not the full memory batch; * update one adapter layer before the complete adapter set; * activate a model-state change for one test replica before all replicas; * expose the candidate memory to one protected evaluation session; * update one routing rule before a complete routing policy; * promote one vector-memory record while holding the remainder; * update one low-risk preference field before a broader profile state; * apply one bounded parameter delta under a maximum norm or scope; * activate the state for a constrained tool-free evaluation environment; Das Expires 4 April 2027 [Page 516] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or make the new state authoritative only for a protected cohort. The initial state update is real because at least one protected system component begins using the changed state. A.31.8. E31.8 Model-State Effectuation Envelope Protected policy may define: EMS MAX as the maximum model-state consequence authorized for the Candidate Model-State Update. The envelope may constrain: * parameter subset; * layer subset; * adapter subset; * memory-object count; * memory namespace; * model replicas; * tenants; * user cohort; * retrieval scope; * permitted tools; * permitted destinations; * allowed downstream action classes; * duration; * model version; * deployment domain; * data-source provenance class; * or another state dimension. A successful bounded update must not itself enlarge the maximum envelope. Das Expires 4 April 2027 [Page 517] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.31.9. E31.9 Delta-Bounded Parameter Update Where a numeric model update is used, a protected bound may be defined over a candidate delta: Δθi for phase i. An illustrative bounded-update condition is: ‖Δθi ‖ ≤ λi where λi is a protected phase-specific update bound. The norm, distance, metric, or bound may be replaced by any suitable model-state constraint and is not mandatory. A.31.10. E31.10 Protected Evaluation of Updated State After the bounded state update becomes effective within its restricted scope, protected evaluation may measure one or more properties, including: * state integrity; * state availability; * correct model-version binding; * correct memory-object binding; * absence of unauthorized namespace changes; * evaluation accuracy; * regression metrics; * safety predicates; * output stability; * downstream tool-use behavior; * resource consumption; * execution-finality behavior; * latency; * destination behavior; * retrieval correctness; Das Expires 4 April 2027 [Page 518] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or another protected acceptance condition. The evaluation itself may be performed by the same PED, a separate evaluator, a model monitor, hardware observer, trusted service, or destination-side verifier. A.31.11. E31.11 Model-State Receipt Following the real bounded update, the protected system may produce: RiMS binding one or more of: * DMS ; * prior state version; * resulting state version; * affected state subset; * state digest; * evaluation result; * model identity; * serving replica or device identity; * policy epoch; * phase identifier; * nonce; * timestamp or trusted-time evidence; * observer identity; * and next-stage eligibility state. A receipt may be signed, MACed, attested, hash-chained, hardware-protected, or otherwise authenticated. A.31.12. E31.12 State-Version Binding Let: viMS denote the protected model-state version after phase i. A receipt may bind: Das Expires 4 April 2027 [Page 519] Internet-Draft Reality as a Cryptographic Dependency October 2026 MS MS (vi−1 , vi ) so that continuation authority cannot be validly applied to an unrelated state lineage. A later phase may require: CurrentV ersion = viMS before it can proceed. A.31.13. E31.13 State-Digest Binding Let: GMS i = H(StateMS i ) or an equivalent protected commitment identify the resulting state. Continuation may require: ObservedDigest = GMS i or an equivalent membership/provenance proof. The exact state need not always be revealed if a protected commitment or privacy- preserving proof is sufficient. A.31.14. E31.14 Automatic Continuation Automatic progression may occur where: V alid(RiMS )∧StateAcceptableMS i ∧P olicyCurrent∧RevocationClear∧W ithinM odelStateEnvelope(Pi+ is true. The proposing model or agent need not be permitted to mark these predicates as satisfied. A.31.15. E31.15 Human Continuation A protected human may review: * what state changed; * prior and new version; * affected model or agent; * evaluation evidence; * model behavior under bounded activation; * downstream consequence scope; * provenance; Das Expires 4 April 2027 [Page 520] Internet-Draft Reality as a Cryptographic Dependency October 2026 * and the next proposed expansion. The human may approve, deny, restrict, delay, or require further bounded evaluation. The human decision may be bound to RiMS and to the next state scope. A.31.16. E31.16 Hybrid Continuation A hybrid continuation may require: V alid(RiMS ) ∧ AutoM odelStateP assi ∧ HumanApprovali before broader promotion. The system may also require hardware approval, destination confirmation, or a threshold of independent authorities. A.31.17. E31.17 Progressive Memory Promotion A persistent agent-memory embodiment may proceed as: 1. Candidate memory is created. 2. Candidate memory is written only to a provisional memory namespace. 3. A bounded evaluation session uses that memory. 4. A protected receipt confirms the exact memory object, source, and observed behavior. 5. Protected policy or a human approves promotion. 6. The memory object is promoted to the authoritative memory namespace. 7. A final receipt records authoritative promotion. The agent cannot promote the memory solely by asserting that the memory is valid. A.31.18. E31.18 Progressive Vector-Memory Update A vector-memory or retrieval-memory embodiment may bind: * source document digest; * embedding-model identity; * vector identifier; * namespace; * access policy; * user or tenant scope; * retrieval permissions; * provenance; * and downstream effect scope. The first phase may place the vector in a non-authoritative index. A bounded retrieval test produces R0MS . Only then may the vector be admitted to the authoritative retrieval index. Das Expires 4 April 2027 [Page 521] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.31.19. E31.19 Parameter / Adapter Promotion A model adapter may be staged through: Adaptercandidate → Replica0 → R0MS → ReplicaSet1 → R1MS → P roduction The adapter artifact itself may already exist, while authority to make it effective across progressively broader serving scope remains receipt-gated. A.31.20. E31.20 Protected Policy-State Update The state being changed may itself control later permissions. Examples include: * tool allowlists; * model routing policy; * action-risk thresholds; * destination permissions; * data-access policy; * execution-finality policy; * protected automation rules; * or human-approval thresholds. Because such state can indirectly enlarge later authority, E31 may require a stricter promotion path than ordinary application configuration. A.31.21. E31.21 No Self-Authorization Through State Mutation A model or agent must not obtain broader authority merely by writing state that declares itself trusted, approved, low-risk, or authorized. A protected implementation may enforce: AgentW rite(T rustState) ⇏ T rustState = Authoritative unless a protected promotion path independently validates the change. A.31.22. E31.22 Rollback and Previous-State Preservation The system may preserve: StateMS i−1 Das Expires 4 April 2027 [Page 522] Internet-Draft Reality as a Cryptographic Dependency October 2026 until the next phase is accepted. If RiMS = F AILU RE , the system may: * restore the prior state; * disable the candidate state; * quarantine the changed object; * stop deployment expansion; * require human review; * or create a compensating state update. Rollback itself may be protected where restoring an old state could reintroduce revoked or unsafe authority. A.31.23. E31.23 Crash and Indeterminate State If a system crashes after model-state promotion but before receipt return, blind reapplication may duplicate or corrupt the update. A phase-specific idempotency identifier may be used: IiMS = H(DMS ∥ vi−1 MS ∥ P hasei ∥ Ni ) Protected reconciliation may determine whether the update was: * applied; * not applied; * partially applied; * rolled back; * or still indeterminate. Broader promotion remains blocked while the required state is indeterminate. A.31.24. E31.24 Multi-Replica Model State For replicated serving systems, phase i may affect a subset: RMS i ⊆ RMS MAX where the set contains model-serving replicas, devices, accelerators, or execution nodes. A protected aggregate receipt may require confirmation from all selected replicas or a protected quorum before expansion. Das Expires 4 April 2027 [Page 523] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.31.25. E31.25 Hardware-Rooted Model-State Promotion A hardware implementation may keep the authoritative model-state key, registry key, or activation secret inside: * TEE; * HSM; * secure element; * accelerator security processor; * TPM-backed service; * DPU/SmartNIC security domain; * or another protected component. A candidate state may be stored but remain unusable until the hardware accepts the required prior receipt and releases phase-specific activation material. A.31.26. E31.26 Accelerator-Resident State Where model state resides in GPU or accelerator memory, E31 may combine with E30. A protected control path may require: V alid(RiMS ) ∧ V alid(RiACC ) before the next model-state phase becomes active on the accelerator. This can bind both the state transition and the device on which the state is allowed to become effective. A.31.27. E31.27 SEND Analogue A communication system may treat an automatically learned recipient preference as provisional state. Example: 1. an agent proposes that future reports be automatically sent to recipient X ; 2. the preference is stored provisionally; 3. a bounded protected communication to X occurs; 4. the receiving endpoint confirms the intended identity; 5. a protected receipt is returned; 6. only then may the recipient preference become authoritative for later SEND operations. Thus a learned memory does not silently become authority to communicate externally. Das Expires 4 April 2027 [Page 524] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.31.28. E31.28 Payment Analogue A financial agent may propose a learned beneficiary preference or recurring-payment rule. The rule may first remain provisional. A bounded verification transfer or protected destination confirmation produces a receipt. Only after protected validation may the beneficiary or recurringpayment state become authoritative within the authorized maximum envelope. The state update does not itself authorize payment beyond independently applicable payment controls. A.31.29. E31.29 Anti-Bypass An implementation intended to protect model-state finality should correspondingly control alternate paths capable of writing authoritative state, including: * direct database writes; * administrative consoles; * model-registry APIs; * direct object-store writes; * vector-index mutation APIs; * debug paths; * model-serving hot-reload interfaces; * accelerator memory loaders; * hidden configuration channels; * or equivalent state-changing routes. An unprotected alternate path must not make a protected promotion gate merely advisory. A.31.30. E31.30 Required Invariants The frozen core of E31 includes: 1. a model-state proposal is distinguishable from authoritative model state; 2. at least one protected path controls promotion into authoritative state; 3. a staged embodiment may make a bounded real state change before broader promotion; 4. protected evidence of the bounded state change may become a prerequisite for later promotion; 5. later state scope cannot exceed the maximum authorized model-state envelope merely because earlier evaluation succeeds; 6. the proposing model or agent cannot create authoritative approval solely by writing its own Das Expires 4 April 2027 [Page 525] Internet-Draft Reality as a Cryptographic Dependency October 2026 approval/trust state; 7. failure or indeterminate state blocks unauthorized broader promotion; 8. software, hardware, or split enforcement may be used. FIGURATION UPDATE WITH PROGRESSIVE ACTIVATION A.32. E32 — Receipt-Gated Software, Firmware, and Configuration Update with Progressive Activation A.32.1. E32.1 Purpose E32 applies staged effectuation to software, firmware, configuration, boot-image, package, application, operating-system, driver, controller, appliance, embedded-device, and infrastructure update operations. The embodiment distinguishes possession of an update artifact from authority to make that artifact effective. The central relationship is: U pdate Artifact → Bounded Activation → P rotected U pdate Receipt → Continuation Authority → Br An update may therefore be downloaded, cached, replicated, or staged without being authorized to become active everywhere. A.32.2. E32.2 Candidate Update Act Let: AUP D denote a Candidate Update Act. The Candidate Update Act may identify: * package or image; * artifact digest; * signer; * software version; * firmware version; * configuration version; * target device or target class; * deployment cohort; * prerequisite version; Das Expires 4 April 2027 [Page 526] Internet-Draft Reality as a Cryptographic Dependency October 2026 * rollback version; * update slot; * activation time; * reboot requirement; * policy epoch; * allowed geographic region; * maximum target set; * and permitted post-update authority. A protected act identifier may be: DUP D = H(Canon(AUP D )) or an equivalent binding. A.32.3. E32.3 Update Artifact Binding Let: GUP D = H(ArtifactUP D ) identify the exact update artifact or a protected manifest commitment. The activation authority may bind both: DUP D and: GUP D so that approval for one update cannot be substituted for another artifact. A.32.4. E32.4 Staging Versus Activation An update may pass through separate states such as: Downloaded → V erified → Staged → Activated → Observed → P romoted Downloading or staging alone need not create the operational consequence associated with activation. This separation allows low- latency pre-positioning while preserving protected control of the final activation boundary. A.32.5. E32.5 Maximum Update Envelope Protected policy may define: EUP MAX D Das Expires 4 April 2027 [Page 527] Internet-Draft Reality as a Cryptographic Dependency October 2026 constraining: * device count; * device class; * tenant set; * geographic region; * server set; * service set; * boot slot; * component type; * firmware subsystem; * permitted version transition; * activation duration; * rollback authority; * and post-update capability. No prior successful canary receipt independently enlarges this maximum envelope. A.32.6. E32.6 Phase-0 Real Update Phase 0 may activate the real update on a deliberately bounded target. Examples include: * one server; * one VM; * one container host; * one network appliance; * one handset; * one vehicle controller; * one PLC; Das Expires 4 April 2027 [Page 528] Internet-Draft Reality as a Cryptographic Dependency October 2026 * one modem; * one satellite subsystem; * one GPU node; * one embedded device; * one availability zone; * one protected tenant; * one device class sample; * or one inactive A/B update slot that is actually booted and evaluated. The update must create a real operational state change within the bounded target if the embodiment relies upon real- update evidence. A.32.7. E32.7 Target-Cohort Progression Let: DUP i D denote the target device or system set for phase i. A progressive rollout may satisfy: DUP D ⊂ DUP D ⊂ ⋯ ⊆ DUP MAX D where nested cohort growth is appropriate. Non-nested cohorts may also be used where different regions, device classes, or hardware revisions require independent progression. A.32.8. E32.8 Update Manifest A protected Update Manifest may bind: * artifact digest; * version; * signer identity; * target hardware/software class; * prerequisite version; Das Expires 4 April 2027 [Page 529] Internet-Draft Reality as a Cryptographic Dependency October 2026 * permitted downgrade/upgrade direction; * secure-boot measurement; * boot slot; * post-install measurement; * expected services; * expected configuration; * rollback path; * receipt requirements; * and maximum activation scope. The manifest may itself be signed or authenticated by a protected authority. A.32.9. E32.9 Phase-Specific Activation Authority The PED may create: CiUP D sufficient only to activate the update for phase i. The authority may comprise: * signed activation manifest; * update-slot unlock value; * boot authorization; * hardware monotonic-counter transition; * package-manager authorization; * firmware-install key; * device-specific update credential; * configuration-promotion token; * KMS release; * or another technical enablement condition. Das Expires 4 April 2027 [Page 530] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.32.10. E32.10 Protected Installation and Activation The protected sink may verify: * DUP D ; * GUP D ; * target identity; * current version; * update path; * signature or MAC; * policy epoch; * revocation state; * phase identifier; * activation scope; * secure-boot state; * and anti-replay state. Only then may the update become operational. A.32.11. E32.11 Post-Activation Observation Following activation, a protected observer may evaluate: * successful boot; * expected software measurement; * expected firmware measurement; * service health; * crash rate; * network reachability; * data integrity; * policy integrity; Das Expires 4 April 2027 [Page 531] Internet-Draft Reality as a Cryptographic Dependency October 2026 * security-control availability; * resource use; * latency; * actuator state; * radio behavior; * model behavior; * storage behavior; * or another relevant condition. A.32.12. E32.12 Update Effect Receipt The system may generate: RiUP D binding: * update act digest; * artifact digest; * target identity; * pre-update version; * post-update version; * post-update measurement; * boot slot; * health state; * observer identity; * phase identifier; * nonce; * and completion status. Das Expires 4 April 2027 [Page 532] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.32.13. E32.13 Measured-Boot / Secure-Boot Receipt A hardware-rooted variation may use measured boot or secure boot. Let: μboot i denote an illustrative post-update measured-boot value. Continuation may require: μboot i ∈ ΩUP D boot where ΩUP D boot represents an allowed measurement set or protected acceptable boot-state region. The exact attestation scheme is implementation-dependent. A.32.14. E32.14 Automatic Rollout Continuation Automatic progression may require: V alid(RiUP D )∧HealthAcceptableUP i D ∧P olicyCurrent∧RevocationClear∧W ithinU pdateEnvelope(Pi+1 UP D before Ci+1 is released. A.32.15. E32.15 Human Approval Between Update Phases A human operator may review: * exact artifact; * exact version transition; * target cohort; * post-update health; * errors or regressions; * security measurements; * rollback availability; * and consequence of broader rollout. The human approval may be cryptographically bound to RiUP D and to the next cohort. Das Expires 4 April 2027 [Page 533] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.32.16. E32.16 Hybrid Update Approval A high-assurance update may require: V alid(RiUP D ) ∧ AutoU pdateP assi ∧ HumanApprovali or a threshold including vendor, enterprise, device, and hardware authorities. A.32.17. E32.17 A/B Partition Update A device may maintain: * active slot A; * inactive slot B . The update is written to the inactive slot. A protected boot component may permit one bounded boot into slot B . A protected receipt confirms the resulting measurement and health state. Only thereafter may slot B become the preferred or durable active slot. If the receipt is unacceptable, the device may return to slot A. A.32.18. E32.18 Firmware Update A firmware embodiment may apply to: * BIOS/UEFI; * BMC; * NIC firmware; * SmartNIC/DPU firmware; * SSD/controller firmware; * modem/baseband firmware; * GPU/accelerator firmware; * secure-element firmware; * embedded MCU firmware; * vehicle ECU firmware; * industrial-controller firmware; * satellite subsystem firmware; Das Expires 4 April 2027 [Page 534] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or other device firmware. A protected hardware root may withhold activation authority until the exact firmware image and current device state satisfy policy. A.32.19. E32.19 Configuration Update The update may be configuration rather than executable code. Examples include: * routing policy; * firewall policy; * model-serving configuration; * device calibration; * feature flags; * execution-finality policy; * safety thresholds; * radio configuration; * cloud infrastructure configuration; * or industrial setpoint configuration. Because configuration can create consequential behavior, E32 may apply the same receipt- gated activation model. A.32.20. E32.20 Dependency-Aware Update An update may require a dependency set: QUP D such as minimum firmware version, compatible driver version, model version, schema version, cryptographic module version, or device revision. Activation may require: DependenciesSatisfied(QUP D ) = T RU E before the update becomes effective. A.32.21. E32.21 Multi-Component Atomic Update A protected update may involve multiple components that should advance consistently. For example: * application + database schema; Das Expires 4 April 2027 [Page 535] Internet-Draft Reality as a Cryptographic Dependency October 2026 * driver + firmware; * model + tokenizer; * controller + policy file; * bootloader + firmware; * network function + routing policy. The system may withhold final promotion until receipts from the required component set are accepted. A.32.22. E32.22 Progressive Percentage Rollout A fleet update may use an activation fraction: ρiUP D with: 0 < ρ0UP D < ρ1UP D < ⋯ ≤ 1 where percentage-based progression is appropriate. The fraction may be adjusted downward or halted when protected health criteria degrade. A.32.23. E32.23 Device-Class Segmentation Different hardware revisions may have separate phase chains. For example: ClassA ∶ P0A → R0A → P1A and: ClassB ∶ P0B → R0B → P1B A receipt from Class A need not authorize Class B unless protected policy explicitly permits equivalence. A.32.24. E32.24 Rollback Authority Rollback may itself require protected authority. This is important where: * the previous version is revoked; * downgrade could reintroduce a vulnerability; * rollback would restore a deprecated cryptographic state; * old policy would grant broader authority; * or data/schema changes are not backward compatible. Therefore: Das Expires 4 April 2027 [Page 536] Internet-Draft Reality as a Cryptographic Dependency October 2026 RollbackAllowed ≠ T RU E merely because a new version fails. A.32.25. E32.25 Update Failure If: RiUP D = F AILU RE then later activation phases remain unavailable unless a new protected decision authorizes another path. Responses may include: * rollback; * hold; * isolate target; * reduce cohort; * replace artifact; * patch configuration; * human escalation; * or terminate rollout. A.32.26. E32.26 Indeterminate Update If activation may have occurred but receipt delivery failed, the system should not blindly reinstall or advance. A phase-specific idempotency identifier may be: IiUP D = H(DUP D ∥ GUP D ∥ Devicei ∥ P hasei ∥ Ni ) Reconciliation may query protected boot state, version registers, package database, firmware counters, attestation measurements, or other authoritative state. A.32.27. E32.27 Anti-Rollback Counter A hardware or firmware embodiment may maintain a monotonic counter: cUP D or protected version floor. An update or rollback command may be accepted only if the resulting version satisfies protected monotonicity or an explicitly authorized exception. Das Expires 4 April 2027 [Page 537] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.32.28. E32.28 Cryptographic Activation Material A staged update may be pre-positioned as ciphertext while activation material remains unavailable. After a valid receipt from an earlier cohort, the PED may release: * decryption key; * unwrap key; * signature authorization; * boot key; * slot-activation secret; * or equivalent material for the next cohort. A.32.29. E32.29 Offline Device Update A device without continuous network connectivity may enforce E32 locally. The update package may contain: * signed phase policy; * bounded activation authority; * expected measurements; * expiration; * maximum version transition; * and local receipt requirements. A local hardware root may advance only according to the preauthorized phase policy, later synchronizing receipts when connectivity returns. A.32.30. E32.30 SEND Analogue A communication-client update may first activate on one protected client or tenant. The client sends a bounded protected message and obtains a verified delivery receipt. Only then may the updated communication behavior be activated for a larger population. This preserves the principle that a successful software install alone does not prove correct external SEND behavior. Das Expires 4 April 2027 [Page 538] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.32.31. E32.31 Payment Analogue A payment-processing update may first activate for a bounded protected transaction class or one low-value verification flow. A protected payment receipt confirms actual rail behavior. Broader payment authority remains unavailable until that receipt and applicable policy are accepted. A.32.32. E32.32 Alternate-Path Closure Equivalent activation routes may include: * direct package manager; * administrator shell; * bootloader recovery mode; * vendor update utility; * firmware flashing port; * debug interface; * BMC path; * device-management API; * container image override; * configuration-management bypass; * or another path capable of making the update effective. Where non-bypassability is required, such paths are disabled, mediated, cryptographically locked, or placed under equivalent protected control. A.32.33. E32.33 Required Invariants The frozen core of E32 includes: 1. update possession/staging is distinguishable from update activation; 2. update authority is bound to the intended artifact or permitted artifact class; 3. a staged embodiment may first activate the update on a bounded real target; 4. protected evidence from the bounded activation may become a prerequisite for broader activation; 5. later rollout cannot exceed the maximum update envelope merely because earlier targets succeed; 6. failure or indeterminate state blocks unauthorized broader rollout; 7. rollback may itself be policy-controlled; 8. software, Das Expires 4 April 2027 [Page 539] Internet-Draft Reality as a Cryptographic Dependency October 2026 firmware, hardware, and configuration updates may use the architecture; 9. alternate activation routes are correspondingly controlled where required for non-bypassability. SINK, AND DISTRIBUTED RECEIPT-GATED EFFECTUATION A.33. E33 — Multi-Destination, Multi-Recipient, Multi-Sink, and Distributed Receipt-Gated Effectuation A.33.1. E33.1 Purpose E33 applies staged effectuation where a single Candidate Act or protected effectuation plan may affect multiple destinations, recipients, sinks, endpoints, devices, accounts, regions, services, machines, or other consequence-bearing targets. The embodiment prevents success at one destination from automatically becoming authority for all other destinations unless protected policy expressly defines that relationship. The central relationship is: Candidate M ultiDestination Act → Bounded Destination Set → DestinationBound Receipts → P rote A.33.2. E33.2 Candidate Multi-Destination Act Let: AMD denote a Candidate Multi-Destination Act. The act may represent: * sending one message to multiple recipients; * transferring a file to multiple destinations; * distributing software to multiple devices; * executing payments to multiple beneficiaries; * deploying a model to multiple regions; * changing policy across multiple network domains; * operating multiple robots or actuators; * exporting data to multiple processors or storage systems; * releasing credentials to multiple services; * or another act whose consequence spans more than one target. Das Expires 4 April 2027 [Page 540] Internet-Draft Reality as a Cryptographic Dependency October 2026 A protected act digest may be: DMD = H(Canon(AMD )) A.33.3. E33.3 Maximum Destination Set Let: ZMAX denote the maximum authorized destination/recipient/target set. A phase-specific active set is: Zi ⊆ ZMAX The architecture may enforce: Zi+1 ⊈ ZMAX ⇒ Enable(Pi+1 ) = F ALSE so a valid receipt chain cannot create unauthorized target expansion. A.33.4. E33.4 Destination Identity Binding Each destination may have a protected destination identity: zj and destination-specific receipt: MD Ri,j A receipt generated for zj should not normally authorize effectuation to a materially different destination zk unless protected policy defines a valid equivalence class. A.33.5. E33.5 Destination Descriptor A destination descriptor may bind: * destination identifier; * recipient identity; * account; * device; * endpoint; * network address; * service identity; * region; * jurisdiction; Das Expires 4 April 2027 [Page 541] Internet-Draft Reality as a Cryptographic Dependency October 2026 * sink identity; * public key or credential identity; * permitted effect class; * data classification; * maximum amount or scope; * and phase eligibility. The descriptor may be included in the Candidate Act, a separate protected target list, or a phase plan. A.33.6. E33.6 Bounded Initial Destination Set Phase 0 may operate on: Z0 where: |Z0 | < |ZMAX | for a staged multi-destination embodiment. Examples include: * one recipient before a distribution list; * one payment beneficiary before a payout batch; * one region before a global deployment; * one device before a fleet; * one storage destination before replication; * one network peer before broader routing; * one robot before a robot group; * one model-serving cluster before all clusters. A.33.7. E33.7 Destination-Specific Effectuation Authority The PED may issue destination-specific authority: MD Ci,j bound to destination zj and phase i. A general protected property is: MD Ci,j ⇏ Authority(zk ) for an unauthorized zk . Das Expires 4 April 2027 [Page 542] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.33.8. E33.8 Destination-Specific Cryptographic Material A strong cryptographic variation may derive: MD MD AGG Ki,j = KDF (KR , DMD , zj , H(Ri−1 ), i) where applicable. The exact KDF is non-limiting. The protected property is that effectuation material for one destination is not freely reusable for another destination. A.33.9. E33.9 Parallel Destination Effectuation A phase may operate on several destinations in parallel: {z1 , z2 , ... , zk } Each destination may produce an independently protected receipt. The system need not force sequential per- destination execution where parallel execution is permitted by protected policy. A.33.10. E33.10 Aggregate Receipt Set For phase i, let: RMD i MD = {Ri,1 MD , Ri,2 MD , ... , Ri,k } represent the destination-receipt set. A protected aggregate receipt may commit to the set: RiAGG = P rotect(DMD , P hasei , Commit(RMD i ), Statusi ) where Commit may be a Merkle root, hash-list commitment, authenticated set commitment, threshold attestation, or equivalent mechanism. A.33.11. E33.11 All-Destination Confirmation Rule A strict phase may require: MD ∀zj ∈ Zi ∶ V alid(Ri,j ) = T RU E before broader progression. This may be appropriate where all selected targets must behave correctly before any expansion. A.33.12. E33.12 Quorum Destination Confirmation Another phase may require: MD ∑ 1[V alid(Ri,j )] ≥ qi zj ∈Zi where qi is a protected destination-confirmation threshold. The system may also require that no designated critical destination has failed. Das Expires 4 April 2027 [Page 543] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.33.13. E33.13 Weighted Destination Confirmation Destinations may have protected weights: wjMD and continuation may require: ∑ wjMD ⋅ 1[V alid(Ri,j MD )] ≥ τiMD j where τiMD is a protected weighted threshold. This may be useful where certain regions, devices, or authorities have different assurance significance. A.33.14. E33.14 Critical-Destination Predicate Let: Zcrit ⊆ Zi represent critical destinations. Continuation may require: MD ∀zj ∈ Zcrit ∶ V alid(Ri,j ) = T RU E regardless of the aggregate success rate. A.33.15. E33.15 Partial Success If only a subset succeeds: Zsucc,i ⊂ Zi then protected policy may: * continue only for successful destinations; * retry failed destinations under new authority; * remove failed destinations; * require human review; * reduce next-phase scope; * substitute an explicitly authorized destination; * or terminate the entire operation. Partial success does not automatically imply permission to reroute to an unapproved destination. A.33.16. E33.16 Failed-Destination Set Let: Das Expires 4 April 2027 [Page 544] Internet-Draft Reality as a Cryptographic Dependency October 2026 Zfail,i denote destinations with protected failure status. The next phase may explicitly exclude: Zfail,i unless a new protected decision authorizes retry or remediation. A.33.17. E33.17 Indeterminate-Destination Set Let: Zind,i denote destinations whose effect state is indeterminate. The architecture may freeze only those destinations, or the entire phase, depending on protected policy. For non-idempotent effects such as payments or messages, blind retry to an indeterminate destination may be prohibited. A.33.18. E33.18 Per-Destination Reconciliation Each destination may use its own idempotency identifier: MD Ii,j = H(DMD ∥ zj ∥ P hasei ∥ Ni,j ) Reconciliation may determine: * PROVEN_EFFECTED; * PROVEN_NOT_EFFECTED; * STILL_INDETERMINATE; * or another protected status for each destination independently. A.33.19. E33.19 Progressive Destination Expansion A progressive rollout may use: Z0 ⊂ Z1 ⊂ ⋯ ⊆ ZMAX where nested expansion is appropriate. The next set may be determined adaptively from prior receipt quality, destination class, risk, policy, jurisdiction, latency, cost, or human approval. A.33.20. E33.20 Destination-Class Progression Destinations may be partitioned into classes: * internal; * external; * trusted partner; Das Expires 4 April 2027 [Page 545] Internet-Draft Reality as a Cryptographic Dependency October 2026 * high-risk; * regulated; * geographic region; * device class; * account class; * service class; * or another protected category. A low-risk class may progress automatically while a high-risk class requires human approval. A.33.21. E33.21 Multi-Recipient SEND Workflow A communication embodiment may proceed as: 1. create a maximum authorized recipient set; 2. select one or a small bounded recipient subset; 3. send a real protected trailer or bounded communication; 4. obtain destination-specific receipts; 5. verify identity, delivery path, and receipt validity; 6. form an aggregate decision; 7. release the full message or additional recipients only where protected continuation conditions are satisfied. A receipt from recipient A does not by itself authorize disclosure to recipient B . A.33.22. E33.22 Group Message With Per-Recipient Keys A group message may be encrypted once or represented through a shared content object, while recipient-specific key-wrapping material remains independently controlled. For recipient zj : MD Kwrap,j may be released only after the required recipient-specific conditions are satisfied. This permits a common ciphertext object while preserving per-recipient effectuation control. A.33.23. E33.23 Multi-Beneficiary Payment Workflow A payment batch may define: ZMAX = {Account1 , ... , Accountn } The system may first execute bounded transfers to a subset, validate payment-rail receipts, and then authorize remaining beneficiaries according to protected policy. A successful transfer to one beneficiary must not be treated as proof that another beneficiary identity, bank route, currency, or settlement path is correct. Das Expires 4 April 2027 [Page 546] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.33.24. E33.24 Multi-Region Deployment Workflow A cloud/model/software deployment may progress through: AGG Region1 → R1 → {Region2 , Region3 } → R2,3 → GlobalSet with protected health evidence and destination-specific state at each stage. A.33.25. E33.25 Multi-Sink Effectuation Different destinations may use different Finality Sinks. Let: Sink(zj ) denote the sink expected for destination zj . The destination authority may bind: (zj , Sink(zj )) so a valid receipt from one sink cannot silently substitute for another required sink. A.33.26. E33.26 Heterogeneous Sink Types A multi-destination act may span heterogeneous sinks, for example: * payment gateway; * message gateway; * storage controller; * device actuator; * cloud deployment controller; * hardware security module; * telecom gateway; * and remote destination service. Protected policy may require different receipt predicates for each sink type before aggregate continuation. A.33.27. E33.27 Cross-Jurisdiction Destination Control A destination may carry jurisdiction or policy metadata. A protected next-set function may be: Zi+1 = f(RMD i , P olicyi , Riski , J urisdictioni , Approvali ) A successful receipt in one jurisdiction does not necessarily authorize progression into another jurisdiction. Das Expires 4 April 2027 [Page 547] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.33.28. E33.28 Human Approval of Destination Expansion A protected human may review: * destinations already effected; * successful and failed receipt sets; * proposed new destination set; * recipient identities; * data or amount involved; * jurisdiction; * risk; * and maximum remaining consequence. Human approval may be bound to the exact next set: Zi+1 rather than to an open-ended future distribution. A.33.29. E33.29 Automatic Destination Expansion Automatic progression may require: AggregateV alid(RMD i )∧DestinationP olicyP assi ∧W ithinDestinationEnvelope(Zi+1 )∧RevocationClea before the next set is enabled. A.33.30. E33.30 Hybrid Destination Expansion A hybrid embodiment may automatically expand within one class but require human approval for another. For example: zj ∈ T rustedClass ⇒ Auto and: zj ∈ ExternalHighRiskClass ⇒ HumanApproval The class labels and thresholds remain protected policy. A.33.31. E33.31 Destination Revocation A destination may be revoked after earlier phases. If: Das Expires 4 April 2027 [Page 548] Internet-Draft Reality as a Cryptographic Dependency October 2026 Revoked(zj ) = T RU E then unused destination-specific authority for zj becomes invalid even if the aggregate act remains authorized for other destinations. A.33.32. E33.32 Destination Substitution Substitution of a failed or unavailable destination should require protected policy. A replacement destination: zj′ must not inherit authority merely because zj was previously authorized. A protected rebind may require new destination identity validation, policy evaluation, and approval. A.33.33. E33.33 Duplicate-Destination and Alias Handling Two identifiers may resolve to the same underlying destination. The system may canonicalize destination identity to prevent duplicate effects where: * aliases; * redirects; * account aliases; * replicated endpoint names; * multiple network addresses; * or service discovery entries refer to the same consequential target. Protected duplicate detection may therefore operate on a canonical destination identity rather than only presentation strings. A.33.34. E33.34 Destination-Path Binding Where route matters, receipt validity may bind not only destination identity but the permitted path, gateway, region, or service chain. This may be used for: * regulated data routing; * payment rails; * telecom interconnect; * secure messaging; Das Expires 4 April 2027 [Page 549] Internet-Draft Reality as a Cryptographic Dependency October 2026 * cross-region storage; * or hardware control paths. A.33.35. E33.35 Recipient Privacy Variation A multi-recipient system need not expose the entire recipient list to every component. The aggregate commitment may use: * Merkle root; * blinded identifier set; * privacy-preserving membership proof; * destination-local tokens; * or another protected commitment. The system may prove that a destination belongs to the authorized set without revealing unrelated recipients. A.33.36. E33.36 Threshold Cryptography Across Destinations E33 may combine with E11. For example, a later group key or continuation authority may require protected receipt shares from q of n destinations or independent sink observers. The resulting authority may remain bound to the next destination set and maximum effect envelope. A.33.37. E33.37 Hardware-Enforced Multi-Destination Release A hardware security component may hold destination-specific keys or unwrap material. The component may release: MD Ki,j only if: * the prior required aggregate receipt is valid; * destination zj is authorized; * phase i is current; * policy is current; * revocation is clear; * and the maximum destination envelope is not exceeded. Das Expires 4 April 2027 [Page 550] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.33.38. E33.38 Multi-Destination Receipt Tree For large target populations, the receipt set may be represented as a tree. A protected root: RootMD i may commit to destination-specific leaves containing destination identity, effect status, nonce, sink, and result. A later phase may verify membership or aggregate predicates without transporting every receipt to every component. A.33.39. E33.39 Completion Semantics The multi-destination operation may define several completion classes: * ALL_DESTINATIONS_COMPLETED; * REQUIRED_QUORUM_COMPLETED; * CRITICAL_DESTINATIONS_COMPLETED; * PARTIAL_COMPLETION; * COMPENSATED; * FAILED; * INDETERMINATE. The selected completion semantics are protected policy and should not be inferred merely from a raw success percentage. A.33.40. E33.40 Final Multi-Destination Receipt A final receipt may bind: RFMD = P rotect(DMD , Commit(Zeffected ), Commit(RMD final ), F inalStatus) This may provide compact evidence of which authorized destinations actually received or experienced the effect. Das Expires 4 April 2027 [Page 551] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.33.41. E33.41 Alternate-Path Closure A multi-destination architecture may be bypassed if an actor can use another credential, endpoint, route, batch API, broadcast interface, group key, administrator function, or direct hardware path to reach additional destinations without the required destination-bound authority. Such paths may therefore be: * disabled; * mediated; * separately authorized; * cryptographically bound; * destination-filtered; * or placed under equivalent receipt-gated control. A.33.42. E33.42 Required Invariants The frozen core of E33 includes: 1. the maximum authorized destination set is distinguishable from the currently enabled destination set; 2. destination-specific authority is bound to the intended target or a protected target class; 3. receipt from one destination does not automatically authorize a materially different destination; 4. a bounded destination subset may be effected before a broader set; 5. protected destination receipts may be aggregated under all, quorum, weighted, critical-target, or other protected rules; 6. partial, failed, and indeterminate destination states remain distinguishable; 7. broader progression cannot exceed the maximum authorized destination set; 8. human, automatic, and hybrid expansion are supported; 9. software, hardware, or split enforcement may be used; 10. alternate paths capable of unauthorized destination expansion are correspondingly controlled where non-bypassability is required. FROZEN RELATIONSHIP BETWEEN E31, E32 AND E33 The three embodiments extend the receipt-gated architecture into three different consequence domains. E31 P roposed M odel State → Bounded Authoritative U se → State Receipt → Broader State P romotion The focus is what becomes authoritative internal state for later model/agent behavior. Das Expires 4 April 2027 [Page 552] Internet-Draft Reality as a Cryptographic Dependency October 2026 E32 Staged U pdate → Bounded Real Activation → U pdate Receipt → Broader Activation The focus is what software/firmware/configuration becomes operational. E33 Bounded Destination Set → Destination Receipts → Aggregate P rotected Decision → Broader Destin The focus is where the consequence is permitted to propagate. These embodiments may be combined. For example, a new model state (E31) may require a software/model-serving update (E32), which may then be activated across progressively larger destination or regional sets (E33). A.34. E34 — Replicated, Quorum-Confirmed, and Consensus Receipt-Gated Effectuation A.34.1. E34.1 Purpose E34 applies receipt-gated effectuation to systems in which a consequential act, state transition, communication, payment state, deployment state, control decision, storage mutation, model-state update, or hardware command is represented, executed, observed, or committed across multiple replicas, observers, nodes, services, controllers, or protected authorities. The embodiment addresses a central distributed-systems problem: a single local success indication may be insufficient to establish that a consequential act has reached the required replicated state. Accordingly, E34 permits continuation authority to depend upon a protected set of replica- specific receipts and a protected quorum, consensus, commit- certificate, or equivalent aggregate confirmation rule. The central relationship is: Candidate Act → Bounded Replicated Effect → Replica Receipts → P rotected Quorum/Consensus Confirmation → Broader or F inal Effectuation E34 may operate with E03 multi-phase progression, E16 database promotion, E17 cloud rollout, E25-E27 physical systems, E28 telecom, E29 NTN/satellite, E30 accelerator systems, E31 model-state update, E32 software/firmware update, E33 multi-destination effectuation, or another embodiment. A.34.2. E34.2 Replicated Effectuation Set Let: NREP = {n1 , n2 , ... , nm } Das Expires 4 April 2027 [Page 553] Internet-Draft Reality as a Cryptographic Dependency October 2026 represent the protected set of replicas, observers, authorities, nodes, devices, controllers, or services relevant to a replicated effectuation decision. Members may comprise, without limitation: * database replicas; * transaction replicas; * consensus nodes; * message brokers; * storage replicas; * cloud nodes; * availability-zone controllers; * regional controllers; * device controllers; * redundant safety controllers; * telecom network functions; * satellite or ground-segment controllers; * accelerator nodes; * secure enclaves; * HSMs; * independent effect observers; * destination-side observers; * or another protected component whose state contributes to continuation authority. The set may be static or protectedly reconfigured. A.34.3. E34.3 Replica-Specific Phase Authority For phase i, a protected system may issue replica-specific authority: REP Ci,j Das Expires 4 April 2027 [Page 554] Internet-Draft Reality as a Cryptographic Dependency October 2026 for replica or protected participant nj . The authority may bind: * Candidate Act digest; * phase identifier; * replica identity; * replica role; * permitted operation; * permitted state transition; * expected prior version; * expected destination; * nonce; * policy epoch; * revocation state; * and maximum local consequence. A replica-specific authority for one participant need not authorize another participant. A.34.4. E34.4 Real Replicated Effect Phase i may cause a real effect at one or more members of NREP . Examples include: * one or more database replicas persist a bounded record set; * one or more message brokers durably enqueue a bounded communication; * one or more cloud nodes activate a bounded deployment; * one or more hardware controllers adopt a bounded command state; * one or more payment-side systems record a reservation or accepted state; * one or more telecom nodes activate a bounded policy; Das Expires 4 April 2027 [Page 555] Internet-Draft Reality as a Cryptographic Dependency October 2026 * one or more model-serving replicas adopt a bounded model-state change; * or one or more protected observers confirm a real external effect. The architecture does not require every member to perform the same physical operation. Different members may contribute different protected roles to the aggregate confirmation. A.34.5. E34.5 Replica Receipt Each participating member may generate a protected receipt: REP Ri,j binding, where applicable: * act identity; * phase identity; * replica identity; * replica role; * actual observed operation; * actual resulting local state; * prior-state version; * new-state version; * transaction or log position; * nonce; * protected time or sequence state; * status; * and prior receipt-chain material. A receipt from nj is not automatically substitutable for a receipt required from nk . A.34.6. E34.6 Replica Role Binding Protected policy may assign roles to replicas. Example roles include: Das Expires 4 April 2027 [Page 556] Internet-Draft Reality as a Cryptographic Dependency October 2026 * proposer; * effecting replica; * witness; * storage replica; * destination witness; * safety controller; * ledger witness; * quorum voter; * independent verifier; * hardware observer; * or commit-certifying authority. A continuation rule may require not merely a count of receipts, but receipts from defined role classes. For example: Required = 2 StorageReceipts ∧ 1 IndependentObserver ∧ 1 SafetyController A.34.7. E34.7 Protected Receipt Set For phase i, the protected receipt verifier may form: RREP i REP = {Ri,1 REP , Ri,2 , ...} The set may contain: * successful receipts; * failed receipts; * rejected receipts; * negative receipts; * indeterminate receipts; * stale receipts; Das Expires 4 April 2027 [Page 557] Internet-Draft Reality as a Cryptographic Dependency October 2026 * conflicting receipts; * or receipts excluded by protected policy. Only receipts satisfying the required validation rules contribute to continuation. A.34.8. E34.8 Quorum Rule A count-based quorum may require: m REP ∑ V alid(Ri,j ) ≥ qiREP j=1 where qiREP is the protected minimum valid-confirmation count. The threshold may be: * fixed; * phase-dependent; * risk-dependent; * role-dependent; * destination-dependent; * dynamically raised; * or determined by protected policy. A quorum count is one embodiment, not a mandatory consensus protocol. A.34.9. E34.9 Weighted Quorum Protected participants may have different weights. Let: wjREP represent the protected weight of participant nj . Continuation may require: m ∑ wjREP ⋅ V alid(Ri,j REP ) ≥ τiREP j=1 where τiREP is a protected weighted threshold. Weight may reflect role, trust level, hardware protection, organizational independence, geographic independence, or another protected criterion. Das Expires 4 April 2027 [Page 558] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.34.10. E34.10 Role-Constrained Quorum A stronger rule may require both numerical quorum and mandatory-role satisfaction. For example: Quorumi ∧ DestinationW itnessi ∧ HardwareW itnessi ∧ P olicyAuthorityi may all be required before continuation. Thus three receipts from the same role class cannot necessarily replace one required independent role. A.34.11. E34.11 Consensus Confirmation Where an implementation uses a consensus protocol, replicated state machine, distributed transaction protocol, or equivalent agreement mechanism, continuation may depend upon a protected confirmation that the relevant effect has reached the required consensus state. This may be represented as: ConsensusConfirmedi = T RU E only when the protected conditions associated with the chosen protocol have been satisfied. E34 does not require any particular consensus algorithm. A.34.12. E34.12 Commit Certificate A protected aggregate confirmation may be represented by a Commit Certificate: CCi The Commit Certificate may bind: * Candidate Act digest; * phase identifier; * protected membership/version state; * receipt-set commitment; * quorum rule; * satisfied role constraints; * resulting replicated state version; Das Expires 4 April 2027 [Page 559] Internet-Draft Reality as a Cryptographic Dependency October 2026 * protected decision status; * policy epoch; * and continuation eligibility. The Commit Certificate may be a signed object, multi-signature, threshold signature, attestation, ledger commitment, Merkle-root-bound structure, or another protected aggregate artifact. A.34.13. E34.13 Commit Certificate Construction One illustrative construction is: CCi = P rotect(DA , P hasei , Root(RREP i ), ViREP , QREP i , P olicyEpoch) where QREP i represents the protected quorum/consensus result and ViREP represents the resulting replicated-state version. The construction is illustrative and non-limiting. A.34.14. E34.14 Receipt-Tree Aggregation A large replicated system need not place every receipt directly inside a continuation artifact. The system may compute: RootREP i REP = M erkleRoot(Ri,1 REP , ... , Ri,k ) or use another authenticated aggregate commitment. The protected verifier may retain enough information to prove which receipts participated in the quorum result. A.34.15. E34.15 Replicated-State Version Binding Continuation authority may bind the replicated-state version: ViREP or an equivalent log position, term, epoch, sequence number, transaction version, block height, generation identifier, or protected state digest. This prevents a valid receipt from an obsolete replicated state from being reused as if it described the current state. A.34.16. E34.16 Membership Version Binding Where the participating set changes, protected policy may maintain: M embEpochi Das Expires 4 April 2027 [Page 560] Internet-Draft Reality as a Cryptographic Dependency October 2026 representing the membership configuration applicable to phase i. A receipt created under an obsolete membership configuration need not satisfy a quorum defined under a later membership configuration. Protected reconfiguration may itself require receipt-gated effectuation. A.34.17. E34.17 Replica Lag Some replicas may be valid but delayed. Let: Lagi,j represent a protected measure or classification of replica lag. Protected policy may: * accept bounded lag; * exclude stale replicas from quorum; * delay continuation; * require stronger quorum; * require catch-up evidence; * or route future phases away from the lagging replica. A lagging replica must not be silently treated as having observed an effect it has not yet confirmed. A.34.18. E34.18 Partial Replica Success After a real phase, participants may partition into: NREP succ,i , NREP fail,i , NREP ind,i representing proven-successful, proven-failed, and indeterminate members. Continuation policy may depend on the composition of these sets rather than on a single binary system status. A.34.19. E34.19 Critical Replica Requirement Protected policy may identify: NREP crit as a critical participant set. Even if a numerical quorum succeeds, continuation may remain blocked where a mandatory critical participant has not confirmed the required state. For example, a Das Expires 4 April 2027 [Page 561] Internet-Draft Reality as a Cryptographic Dependency October 2026 payment-side quorum may still require the receiving institution’s protected confirmation; a robotic system may still require a safety- controller receipt; a storage system may still require the authoritative metadata controller. A.34.20. E34.20 Split-Brain Detection A replicated system may produce mutually incompatible protected observations. Example: REP Ri,a ⇒ State = X while: REP Ri,b ⇒ State = Y with: X≠Y where the two states cannot both satisfy the relevant protected invariant. The system enters a Split-Brain Effect State rather than arbitrarily selecting one outcome. A.34.21. E34.21 Split-Brain Effect State A protected split-brain state may cause: Enable(Pi+1 ) = F ALSE until reconciliation determines an acceptable authoritative state. Possible responses include: * freeze progression; * isolate inconsistent replicas; * require a stronger authority; * select an authoritative log or state source; * re-run bounded verification; * require human review; * or terminate the candidate act. Das Expires 4 April 2027 [Page 562] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.34.22. E34.22 Byzantine or Malicious Replica Variation Where threat models include malicious or compromised replicas, the quorum/consensus rule may require sufficient independent protected confirmations such that one or more malicious participants cannot independently unlock broader effectuation. The embodiment may use: * threshold signatures; * hardware-attested participants; * organizationally independent witnesses; * diversity of implementation; * protected membership; * fault thresholds; * or another Byzantine-resilient mechanism. E34 does not require a specific Byzantine consensus algorithm. A.34.23. E34.23 Same-Organization Replica Variation Replicas need not be operated by different organizations. A cloud provider may use multiple protected nodes or services under one administrative domain while still requiring independent protected receipt paths. The technical property is that the continuation decision depends on the required independently generated protected state evidence, not merely on an unverified assertion by the proposing process. A.34.24. E34.24 Cross-Organization Replica Variation Alternatively, protected confirmations may come from different organizations, institutions, trust domains, jurisdictions, or infrastructure operators. Examples include: * sender and receiver institutions; * cloud provider and customer enclave; * telecom operator and destination network; * spacecraft and ground station; * payer system and payee-side institution; Das Expires 4 April 2027 [Page 563] Internet-Draft Reality as a Cryptographic Dependency October 2026 * device vendor and enterprise controller; * or multiple regulated/independent authorities. A.34.25. E34.25 Phase-Specific Quorum Different phases may require different thresholds. For example: q0REP = 2, q1REP = 3, q2REP = 5 as consequence increases. A later phase may also require a different role composition, not merely a larger count. A.34.26. E34.26 Risk-Adaptive Quorum The protected quorum requirement may depend on risk. Illustratively: REP qi+1 = f(Riski , EffectScopei+1 , ReceiptQualityi , P olicyi ) Higher consequence or lower confidence may require more independent confirmations. A.34.27. E34.27 Human Approval After Quorum A protected human approval may be required after quorum or consensus confirmation. Flow: Replica Effects → Replica Receipts → CCi → HumanReview → Pi+1 The human therefore reviews protected aggregate evidence rather than a mere unverified success message. A.34.28. E34.28 Automatic Continuation After Quorum Automatic continuation may occur where: V alid(CCi ) ∧ P olicyP assi ∧ RiskAcceptablei ∧ W ithinEnvelope(Pi+1 ) is true. The proposing agent need not possess authority to manufacture CCi . A.34.29. E34.29 Hybrid Continuation A hybrid implementation may require: V alid(CCi ) ∧ AutomaticP rotectedDecisioni ∧ HumanApprovali before broader effectuation. Threshold authority from E11 may also be used to combine multiple protected decision sources. Das Expires 4 April 2027 [Page 564] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.34.30. E34.30 Receipt-Derived Continuation Authority Continuation authority may be bound to the Commit Certificate: REP Ci+1 = Derive(DA , H(CCi ), P hasei+1 , Scopei+1 ) or equivalent missing execution material may be released only after CCi validates. A.34.31. E34.31 Hardware-Rooted Aggregate Confirmation An HSM, TEE, secure element, security coprocessor, DPU, SmartNIC, controller, FPGA, ASIC, or other protected component may verify the required replica receipts and expose only a phase-specific continuation authority. Ordinary software may therefore be unable to bypass the distributed confirmation requirement by directly generating the next-stage capability. A.34.32. E34.32 Database Replication Example A bounded mutation is written to a replicated database. Phase 0 may require: * leader acceptance; * at least two durable follower acknowledgements; * protected commit-index confirmation; * and no detected conflict. Only then may a broader data migration, secondary mutation, external notification, or irreversible follow- on action be released. The database’s own replication semantics may be used where they provide the required protected evidence, or E34 may layer an additional protected receipt mechanism above them. A.34.33. E34.33 Distributed Storage Example A sensitive object may be written to a bounded storage replica set. Replica receipts confirm: * object digest; * protected destination; * encryption state; * storage generation; Das Expires 4 April 2027 [Page 565] Internet-Draft Reality as a Cryptographic Dependency October 2026 * durability class; * and local acceptance. Broader visibility, decryption-key release, deletion of the source copy, or distribution to additional storage regions may depend on the protected aggregate confirmation. A.34.34. E34.34 SEND / Messaging Example A consequential communication may be delivered through redundant brokers or destination-side services. A protected continuation rule may require: * broker acceptance receipt; * destination-domain receipt; * and intended-recipient endpoint receipt; before releasing a larger attachment, decryption key, follow-up command, or broader recipient set. A mere sender-side “queued” state need not be treated as proof of recipient-side effect. A.34.35. E34.35 Payment Example A bounded payment phase may produce protected evidence from multiple points, such as: * originating payment processor; * transaction rail; * beneficiary-side institution; * settlement/ledger observer; * or escrow/conditional-holding component. Continuation to the remaining payment amount may require a protected quorum/role rule appropriate to the infrastructure. E34 does not assume that every payment system exposes the same confirmation semantics. A.34.36. E34.36 Cloud Deployment Example A bounded deployment may be activated across a small replica set. Protected receipts may confirm: * artifact identity; * node health; Das Expires 4 April 2027 [Page 566] Internet-Draft Reality as a Cryptographic Dependency October 2026 * configuration digest; * traffic state; * policy state; * and actual activation. A Commit Certificate may then authorize broader rollout to additional nodes, zones, or regions. A.34.37. E34.37 Telecom Example A network-control update may be applied to a bounded subset of network functions. Protected confirmations may come from: * control plane; * data plane; * gateway; * baseband or radio unit; * destination network; * or independent telemetry authority. Broader rollout may remain blocked until the required protected quorum is satisfied. A.34.38. E34.38 Physical-Control Example A redundant robotic or industrial controller may require multiple protected observations of the bounded physical effect. For example: * local encoder receipt; * independent safety sensor receipt; * controller-state receipt; * and remote supervisory receipt. A later, larger movement remains unavailable unless the configured quorum/role predicate is satisfied. A.34.39. E34.39 Replica Failure During Phase If one or more replicas fail during a phase, protected policy may: * continue if quorum and critical-role requirements remain satisfied; Das Expires 4 April 2027 [Page 567] Internet-Draft Reality as a Cryptographic Dependency October 2026 * reduce the next-phase scope; * substitute a preauthorized replica; * require reconfiguration; * enter reconciliation; * or terminate progression. A failed replica is not silently counted as a successful receipt. A.34.40. E34.40 Membership Change During Phase If the protected membership configuration changes while a phase is active, the system may: * complete under the old membership epoch; * abort and restart under the new epoch; * require both old and new quorum rules; * or freeze progression pending protected review. The selected rule should be bound to protected state so that membership cannot be changed merely to manufacture an easier quorum. A.34.41. E34.41 Late Receipt Handling A receipt arriving after quorum has already been formed may be: * retained as supplementary evidence; * used to update replica health; * ignored for the already-consumed continuation decision; * used for reconciliation; * or treated as conflicting evidence if it contradicts the committed state. It must not independently cause duplicate continuation after the relevant aggregate authority has already been consumed. A.34.42. E34.42 Quorum Receipt Consumption Where a Commit Certificate or aggregate confirmation is single-use for a transition: Consumed(CCi ) = T RU E Das Expires 4 April 2027 [Page 568] Internet-Draft Reality as a Cryptographic Dependency October 2026 may be recorded atomically with issuance or consumption of the next- stage authority. Replay of CCi must not produce duplicate unauthorized broader effectuation. A.34.43. E34.43 Replica Receipt Replay Protection Replica receipts may bind: * phase nonce; * transaction identifier; * replicated-state version; * membership epoch; * receipt sequence; * and replica identity. A receipt from an earlier phase or earlier membership configuration must not silently satisfy a later quorum. A.34.44. E34.44 Conflicting Aggregate Certificates If two incompatible aggregate certificates appear for the same protected transition, the system may treat this as a high-assurance conflict state. Broader effectuation may be blocked until: * certificate provenance is verified; * membership state is reconciled; * revoked keys are checked; * protected logs are inspected; * and an authoritative state is established. A.34.45. E34.45 Network Partition During a network partition, different participant subsets may observe different states. Protected policy may require that no partition lacking the necessary protected quorum and critical-role composition can generate continuation authority. Where both partitions can independently satisfy a quorum under the selected protocol, additional consensus/fencing/epoch rules may be required to prevent contradictory effectuation chains. Das Expires 4 April 2027 [Page 569] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.34.46. E34.46 Fencing and Epoch Authority A protected fencing value, lease epoch, term, generation, or equivalent monotonically controlled state may be incorporated into authority and receipts. A participant with an obsolete fencing value cannot validly extend the current effectuation chain. This may be particularly useful for database leaders, storage controllers, cloud orchestration, and industrial controllers. A.34.47. E34.47 Reconciliation After Replica Divergence Reconciliation may compare: * protected logs; * replica versions; * transaction IDs; * sink records; * destination state; * hardware counters; * commit certificates; * receipt trees; * and current membership state. The result may identify: * authoritative committed state; * non-authoritative divergent state; * still-indeterminate state; * or a state requiring protected human intervention. A.34.48. E34.48 Anti-Bypass Requirement Where replicated confirmation is required for a consequence, an alternate path must not permit the same or broader consequence based solely on one unverified replica. Relevant bypasses may include: * direct leader API; Das Expires 4 April 2027 [Page 570] Internet-Draft Reality as a Cryptographic Dependency October 2026 * direct database connection; * administrative write path; * raw storage path; * privileged network route; * local hardware register; * unprotected deployment API; * alternate credential; * or another effect-equivalent route. A.34.49. E34.49 Software Implementation A software embodiment may comprise: Candidate Source → Protected Replication Coordinator → Replicas / Protected Observers → Receipt Aggregator / Quorum Verifier → Continuation Authority → Next Effectuation Boundary. A.34.50. E34.50 Hardware / Split Implementation A split embodiment may use software to collect receipts while protected hardware independently verifies: * participant keys; * membership epoch; * quorum threshold; * critical-role satisfaction; * receipt freshness; * and current phase state. The hardware releases the next key, latch state, signing operation, network capability, or actuator enable only when the aggregate predicate succeeds. A.34.51. E34.51 Required Invariants The minimum frozen conceptual invariants of E34 are: Das Expires 4 April 2027 [Page 571] Internet-Draft Reality as a Cryptographic Dependency October 2026 Invariant 1 Where protected policy requires replicated confirmation, a single unverified local success indication is insufficient to unlock broader effectuation. Invariant 2 Receipts contributing to the aggregate decision are bound to the relevant act, phase, participant, and protected state. Invariant 3 The aggregate rule is evaluated by protected logic not controlled solely by the proposing source. Invariant 4 A later phase may be made technically dependent upon the accepted quorum/consensus confirmation or Commit Certificate. Invariant 5 Stale, replayed, wrong-participant, wrong-phase, or otherwise invalid receipts do not silently satisfy the protected aggregate rule. Invariant 6 A split-brain, conflicting, or indeterminate state blocks unauthorized broader progression unless a new protected decision resolves the state. Invariant 7 A successful quorum cannot enlarge authority beyond the already authorized maximum envelope. Invariant 8 Equivalent bypass paths are correspondingly controlled where required to preserve the replicated-confirmation property. Everything else in E34 may vary by implementation unless expressly required. TION, AND RECOVERY RECEIPT-GATED EFFECTUATION A.35. E35 — Negative, Indeterminate, Conflict, Reconciliation, and Recovery Receipt-Gated Effectuation A.35.1. E35.1 Purpose E35 defines a protected effectuation workflow for cases in which the system receives evidence that an effect did not occur, may not have occurred, occurred only partially, produced conflicting observations, or cannot yet be determined with sufficient confidence. The embodiment is important because absence of a positive success receipt is not equivalent to proof that no effect occurred. A consequential system must distinguish, where relevant, between at least: * PROVEN EFFECTED; * PROVEN NOT EFFECTED; Das Expires 4 April 2027 [Page 572] Internet-Draft Reality as a Cryptographic Dependency October 2026 * PARTIALLY EFFECTED; * ROLLED BACK / COMPENSATED; * REJECTED BEFORE EFFECT; * CONFLICTING EVIDENCE; * and INDETERMINATE. The central relationship is: Attempted Effect → P rotected Outcome Evidence → Outcome Classification → Reconciliation if Required → P rotected Retry/Continue/Stop Authority The key safety property is: N o P ositive Receipt ⇏ N o Effect A.35.2. E35.2 Negative Receipt A Negative Receipt is protected evidence affirmatively indicating that a specified effect did not become effective under the relevant technical definition. A negative receipt may be produced where, for example: * a sink rejected the operation before effect; * a destination proves no matching transaction was committed; * a storage engine proves the candidate object was not promoted; * a device proves the command was not actuated; * a payment rail proves the transaction identifier was not accepted; * a message destination proves the candidate message identifier was not delivered; * a database proves a transaction did not commit; * or another protected component can affirmatively establish non- effectuation. The negative receipt is stronger than a timeout or missing acknowledgement. Das Expires 4 April 2027 [Page 573] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.35.3. E35.3 Negative Receipt Representation A protected negative receipt may be represented as: Ri− and may bind: * Candidate Act digest; * phase identifier; * attempted effect identifier; * sink/destination identity; * transaction/idempotency identifier; * protected time or sequence; * reason for non-effectuation; * protected state consulted; * policy epoch; * and cryptographic authenticator. The minus sign denotes negative/ non-effect evidence only for this embodiment and is not arithmetic subtraction. A.35.4. E35.4 Indeterminate Receipt Where a protected component cannot establish either effectuation or non-effectuation, it may generate: Ri? representing an Indeterminate Receipt or protected indeterminate outcome artifact. Examples include: * crash after sending a command but before local completion state is durable; * network partition after destination acceptance but before acknowledgement returns; * payment request transmitted but settlement state unavailable; Das Expires 4 April 2027 [Page 574] Internet-Draft Reality as a Cryptographic Dependency October 2026 * hardware moved but sensor evidence lost; * message broker accepted a message but destination state cannot be queried; * database commit status unavailable after failover; * or two protected observers disagree. A.35.5. E35.5 Conflict Receipt / Conflict Evidence A protected conflict state may be represented by: Ri× where evidence exists that cannot be simultaneously reconciled with the required invariant. For example, one authoritative observer may report EFFECTED while another equally required observer reports NOT EFFECTED. The multiplication sign is merely a local conflict symbol and is not a mathematical product. A.35.6. E35.6 Outcome State Set For phase i, protected outcome classification may belong to: ΣOUT i ∈ {EF F ECT ED, N OT _EF F ECT ED, P ART IAL, ROLLED_BACK, REJ ECT ED, IN DET ERM IN AT E, CON F LICT } An implementation may define additional states. The important property is that the states are not collapsed into a single success/ failure Boolean where doing so would make retry unsafe. A.35.7. E35.7 Positive Evidence Versus Negative Evidence A successful positive receipt may prove a defined effect occurred. A valid negative receipt may prove a defined effect did not occur. An indeterminate receipt proves neither. Thus: Ri+ ≠ Ri− ≠ Ri? as semantic outcome classes, even if all are authenticated using similar cryptographic structures. The Ri+ notation is used locally here only to distinguish a positive receipt from negative and indeterminate outcome artifacts. Das Expires 4 April 2027 [Page 575] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.35.8. E35.8 Missing Receipt Is Not Negative Receipt If no receipt is received: ReceiptAbsenti = T RU E protected logic must not automatically infer: N OT _EF F ECT ED unless the system has an independently protected reason to do so. A missing receipt may result from: * network loss; * crash; * delayed processing; * dropped return path; * destination outage; * observer outage; * malicious suppression; * clock/timeout mismatch; * or actual non-effectuation. A.35.9. E35.9 Negative Receipt Validation Before a negative receipt authorizes retry, the protected verifier may check: * receipt authenticity; * correct act binding; * correct phase; * correct sink/destination; * correct transaction/idempotency identifier; * freshness; Das Expires 4 April 2027 [Page 576] Internet-Draft Reality as a Cryptographic Dependency October 2026 * authoritative non-effect source; * policy epoch; * revocation state; * and whether the negative evidence covers the entire relevant consequence domain. A negative receipt that proves “not settled” may not necessarily prove “not authorized” or “not reserved.” The receipt must be interpreted according to the state it actually proves. A.35.10. E35.10 Effect-State Granularity A consequential act may pass through multiple technical states. A payment may be: * requested; * accepted; * authorized; * reserved; * captured; * clearing; * settled; * reversed; * or refunded. A message may be: * submitted; * queued; * transmitted; * accepted by destination domain; * delivered to endpoint; * rendered; Das Expires 4 April 2027 [Page 577] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or acknowledged. A hardware command may be: * accepted; * latched; * energized; * moving; * physically completed; * sensed; * or stabilized. A receipt must therefore identify the technical state actually evidenced. A.35.11. E35.11 Protected Reconciliation State When outcome is indeterminate or conflicting, the PED may enter: State = RECON CILIN G During this state, broader effectuation authority remains unavailable unless protected policy expressly permits a bounded recovery action. A.35.12. E35.12 Reconciliation Evidence Set Let: ΓREC i represent the protected reconciliation evidence set for phase i. It may contain: * sink logs; * destination query results; * transaction ledger entries; * idempotency records; * replicated-state versions; * message broker state; Das Expires 4 April 2027 [Page 578] Internet-Draft Reality as a Cryptographic Dependency October 2026 * storage metadata; * hardware counters; * sensor state; * secure logs; * trusted timestamps; * payment-rail query results; * remote attestations; * consensus certificates; * or another authoritative state source. A.35.13. E35.13 Reconciliation Function Protected reconciliation may be represented as: Reci = Reconcile(DA , P hasei , ΓREC i , P olicyi ) where the result may be: Reci ∈ {P ROV EN _EF F ECT ED, P ROV EN _N OT _EF F ECT ED, P ART IAL, CON F LICT , ST ILL_IN DET ERM IN AT E} The named function is architectural and does not require a specific API or algorithm. A.35.14. E35.14 PROVEN_EFFECTED Result If reconciliation establishes that the effect already occurred, the system must not blindly repeat it. Protected logic may: * reconstruct or recover a valid completion receipt; * mark the authority consumed; * advance protected state if permitted; * issue a later-phase continuation authority; * or require human review before continuation. The recovery path preserves the fact that the real effect occurred even if the original receipt was lost. Das Expires 4 April 2027 [Page 579] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.35.15. E35.15 PROVEN_NOT_EFFECTED Result If reconciliation establishes that the effect did not occur, protected policy may permit a retry. A new retry authority may be generated rather than reusing the original consumed/expired authority. The retry may bind: * the original act; * original phase; * negative/reconciliation evidence; * a new nonce; * a retry counter; * current policy; * current revocation state; * and a new idempotency identifier or safely reusable idempotency identifier depending on infrastructure semantics. A.35.16. E35.16 Retry Authority Let: RET RY Ci,k represent retry authority for retry attempt k of phase i. A protected derivation may include: RET RY Ci,k = Derive(DA , H(Ri− ), P hasei , k, P olicyCurrent) where a valid negative receipt is the technical prerequisite for retry. Alternatively the authority may depend on a protected reconciliation result rather than directly on Ri− . A.35.17. E35.17 Retry Counter Protected state may maintain: kiRET RY as the number of authorized retry attempts for phase i. Policy may enforce: Das Expires 4 April 2027 [Page 580] Internet-Draft Reality as a Cryptographic Dependency October 2026 kiRET RY ≤ kMAX RET RY where the maximum is protected policy. This prevents unbounded automatic repetition of a consequential act. A.35.18. E35.18 Consequence-Safe Retry A retry is consequence-safe where protected controls make duplicate or contradictory effect acceptably bounded under the applicable system semantics. Techniques may include: * idempotency identifier; * transaction uniqueness constraint; * destination-side duplicate suppression; * protected phase counter; * hardware monotonic counter; * conditional commit; * compare-and-swap state; * ledger uniqueness; * message deduplication; * or another effect-specific control. E35 does not assume that all infrastructure provides exactly-once semantics. A.35.19. E35.19 Partial Effect Result If only part of the requested effect occurred, the system may classify: ΣOUT i = P ART IAL The protected workflow then determines the actually effected subset or magnitude before deciding whether to: * complete only the remainder; * compensate; * rollback; Das Expires 4 April 2027 [Page 581] Internet-Draft Reality as a Cryptographic Dependency October 2026 * reduce scope; * re-plan; * require human approval; * or terminate. A retry of the entire original operation may be unsafe. A.35.20. E35.20 Partial Effect Quantification Where meaningful, let: Eiactual represent the proven actual effect and: Eitarget represent the intended phase effect. The protected remaining effect may be constrained by: Eiremaining = Eitarget − Eiactual where arithmetic subtraction is meaningful. For qualitative effects, a set-difference or state-specific reconciliation rule may be used instead. A.35.21. E35.21 Compensation Receipt Where rollback is impossible but a compensating action is performed, the system may generate: RiCOMP binding: * original effect; * compensation act; * compensation result; * affected resource; * transaction identifiers; * remaining residual consequence; Das Expires 4 April 2027 [Page 582] Internet-Draft Reality as a Cryptographic Dependency October 2026 * and protected status. A compensation receipt does not necessarily mean the original effect never occurred. A.35.22. E35.22 Rollback Receipt Where the original effect is technically reversible, a protected rollback receipt may establish that the system returned to an acceptable protected state. Rollback may be complete or partial. Continuation policy may distinguish: * original effect never occurred; * original effect occurred then was rolled back; * original effect occurred and was compensated; * and original effect remains active. A.35.23. E35.23 Late Positive Receipt After Negative Receipt A critical race condition occurs where a negative or timeout-related path is processed and a delayed positive receipt later arrives. Protected logic must determine whether: * the negative evidence was authoritative and the late positive receipt is stale/invalid; * the positive receipt proves the effect actually occurred and the earlier classification was wrong or incomplete; * the two receipts refer to different technical stages; * or a conflict state exists. No duplicate retry should be released merely because the system first saw a timeout. A.35.24. E35.24 Late Receipt After Retry Suppose: 1. original attempt A0 becomes indeterminate; 2. protected reconciliation authorizes retry A1 ; 3. a late receipt for A0 arrives. The system may compare: * idempotency identifiers; * effect identifiers; * destination state; * transaction IDs; Das Expires 4 April 2027 [Page 583] Internet-Draft Reality as a Cryptographic Dependency October 2026 * phase counters; * and actual effect state. If both attempts became effective, the system may enter duplicate-effect handling rather than falsely reporting one clean success. A.35.25. E35.25 Duplicate-Effect Detection A protected duplicate-effect detector may identify: DuplicateEffecti = T RU E where two or more effect instances correspond to one intended single- use consequence. Responses may include: * compensation; * reversal; * quarantine; * account reconciliation; * message suppression where still possible; * hardware safe-state transition; * human escalation; * or another effect-specific remediation. A.35.26. E35.26 Conflicting Protected Evidence If protected evidence conflicts, continuation may require: ConflictResolvedi = T RU E before broader authority is released. The system may rank sources according to protected authority, require quorum, invoke E34 replicated confirmation, or require human resolution. The proposing agent must not resolve the conflict solely by choosing the evidence that enables its preferred action. Das Expires 4 April 2027 [Page 584] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.35.27. E35.27 Evidence Authority Hierarchy Protected policy may define an authority order among evidence sources. For example: 1. destination-side authoritative transaction state; 2. protected sink journal; 3. replicated commit certificate; 4. hardware counter; 5. signed observer receipt; 6. non-authoritative application log. The hierarchy is implementation-specific and may differ by domain. The important property is that evidence authority is protected policy, not arbitrary source selection by the proposing process. A.35.28. E35.28 Human Reconciliation Approval A protected human may review reconciliation evidence before retry or continuation. The review surface may show: * original candidate act; * attempted phase; * positive/negative/indeterminate receipts; * transaction identifiers; * actual destination state; * duplicate risk; * current protected policy; * proposed recovery action; * and maximum additional consequence. The human may approve, deny, reduce scope, compensate, or terminate. A.35.29. E35.29 Automatic Reconciliation Automatic recovery may be permitted where protected logic can establish a sufficiently authoritative state. For example: Reci = P ROV EN _N OT _EF F ECT ED ∧ RetryP olicyP assi ∧ W ithinEnvelope(Pi ) may authorize a bounded retry. If: Reci = ST ILL_IN DET ERM IN AT E broader progression remains blocked. Das Expires 4 April 2027 [Page 585] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.35.30. E35.30 Hybrid Recovery A hybrid policy may allow automatic reconciliation but require human approval for: * second retry; * irreversible effect; * high financial value; * physical-safety consequence; * cross-jurisdiction data release; * conflicting evidence; * or effect beyond a protected threshold. A.35.31. E35.31 Time-Bounded Indeterminate State An indeterminate state may persist for a bounded observation interval. Let: TiREC represent the protected reconciliation window. During this interval the system may perform safe read/query operations without authorizing duplicate effect. Expiry of the window need not convert indeterminate state into NOT_EFFECTED; it may instead trigger escalation. A.35.32. E35.32 Protected Recovery Query A recovery query is a protected operation intended to determine effect state without independently creating the disputed consequential effect. Examples include: * query payment transaction ID; * query message-delivery ID; * read database commit record; * query storage object generation; * read actuator encoder/counter; Das Expires 4 April 2027 [Page 586] Internet-Draft Reality as a Cryptographic Dependency October 2026 * query cloud deployment state; * query telecom policy generation; * query GPU job/output record; * or inspect a replicated commit certificate. Recovery queries may themselves require bounded credentials and protected rate limits. A.35.33. E35.33 Query Result Receipt A protected recovery query may produce: RiQUERY binding the queried object, authoritative source, returned state, query time/sequence, and integrity evidence. Multiple query receipts may contribute to ΓREC i . A.35.34. E35.34 SEND Example - Missing Delivery Confirmation A file/message is sent using a single-use communication authority. The sender loses the acknowledgement. The system must not immediately resend the full communication merely because no receipt arrived. It may query: * broker message ID; * destination-domain state; * recipient endpoint state; * or a protected delivery ledger. Possible outcomes: * PROVEN_EFFECTED: do not resend; recover completion receipt; * PROVEN_NOT_EFFECTED: protected retry may be issued; * PARTIAL: send only the missing segment if technically possible; * INDETERMINATE: hold; * CONFLICT: reconcile or escalate. Das Expires 4 April 2027 [Page 587] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.35.35. E35.35 SEND Example - Wrong Recipient Rejection If a protected destination proves that a candidate communication was rejected because recipient binding failed, a negative receipt may prove that semantic release did not occur at the required recipient. The system may then permit a newly authorized corrected-recipient attempt if current policy and human/automatic approval allow it. The rejected receipt cannot by itself authorize sending to an arbitrary new recipient. A.35.36. E35.36 Payment Example - Timeout After Submission A payment request is submitted and the sender times out before receiving status. The system queries the transaction identifier. If the payment rail or authoritative institution returns: * settled/accepted: mark effected and do not duplicate; * definitively rejected/not found under authoritative semantics: a protected retry may be considered; * pending: remain in a non-final state; * unknown: remain indeterminate; * conflicting: reconcile. This avoids treating network timeout as proof of non-payment. A.35.37. E35.37 Payment Example - Partial Settlement Where only part of an intended payment was settled, protected state may identify the settled amount and maximum remaining authorized amount. A continuation or corrective payment must be bounded so cumulative effect does not exceed the authorized maximum. The prior partial settlement remains part of cumulative consequence accounting. A.35.38. E35.38 Database Example A database transaction loses its client acknowledgement during failover. Protected recovery may query: * transaction ID; * commit log; * replicated commit index; * unique constraint state; Das Expires 4 April 2027 [Page 588] Internet-Draft Reality as a Cryptographic Dependency October 2026 * or authoritative row version. A new transaction is released only if protected evidence establishes that doing so will not create an unauthorized duplicate mutation. A.35.39. E35.39 Storage Example An object upload completes to some replicas but promotion state is uncertain. Reconciliation may determine: * object absent; * object provisional only; * object promoted; * object partially replicated; * or conflicting metadata state. Deletion of the source copy or release of a decryption key remains blocked until the required state is established. A.35.40. E35.40 Hardware Actuation Example A motor command is issued and controller power fails before the completion receipt returns. Protected recovery may inspect: * monotonic command counter; * encoder position; * current/energy record; * actuator-local journal; * safety controller state; * and command identifier. If the motor already moved, the system must not blindly issue the same full movement again. A.35.41. E35.41 Vehicle / UAV Example A vehicle or UAV reaches an intermediate waypoint but communication with the supervisory PED is lost. Local protected state may record the completed phase. After reconnection, reconciliation compares: * actual position; * protected route phase; Das Expires 4 April 2027 [Page 589] Internet-Draft Reality as a Cryptographic Dependency October 2026 * command counter; * local receipt; * remote receipt chain; * and current policy. Only the remaining authorized route/movement may be released. A.35.42. E35.42 Industrial Example A valve or process-control command is issued, then supervisory communication is lost. The recovery workflow may inspect: * valve position sensor; * PLC state; * process pressure/flow; * hardware command counter; * and protected event log. A duplicate open/close command is not issued until the real process state is established or a protected safe-state action is required. A.35.43. E35.43 Telecom Example A network policy update is sent to a network function but acknowledgement is lost. Protected recovery may inspect: * policy generation; * network-function state; * data-plane behavior; * controller journal; * and protected telemetry. Broader rollout remains blocked until the bounded phase is classified. A.35.44. E35.44 GPU / Accelerator Example A protected accelerator completes a job but the host loses the completion notification. Recovery may inspect: * protected job identifier; Das Expires 4 April 2027 [Page 590] Internet-Draft Reality as a Cryptographic Dependency October 2026 * accelerator queue state; * output digest; * device counter; * secure memory state; * and egress state. The architecture distinguishes recomputing an internal result from repeating an external consequence such as data release or network transmission. A.35.45. E35.45 Model-State Example A model-memory update may have been committed to one authoritative state store before a crash. The recovery path queries the protected model-state version and digest before issuing another update. If the update already became authoritative, a duplicate memory entry or duplicated parameter update is prevented. A.35.46. E35.46 Software/Firmware Update Example An update activation request loses its acknowledgement during reboot. Recovery may inspect: * active slot; * boot measurement; * version counter; * firmware generation; * secure-boot state; * and update receipt journal. The system need not reinstall or reactivate the update blindly. A.35.47. E35.47 Multi-Destination Recovery For a multi-destination act, different destinations may have different outcome states. Let: Das Expires 4 April 2027 [Page 591] Internet-Draft Reality as a Cryptographic Dependency October 2026 Zeff , Znot , Zind represent effected, proven-not-effected, and indeterminate destination subsets. A retry may be restricted to Znot while Zeff is excluded and Zind remains blocked pending reconciliation. A.35.48. E35.48 Replicated Recovery with E34 Where outcome depends on replicated state, E35 may use E34 Commit Certificates or quorum evidence as authoritative reconciliation material. For example: V alid(CCi ) ⇒ P ROV EN _EF F ECT ED under the protected semantics of the relevant replicated system. An insufficient replica set may instead leave the outcome indeterminate. A.35.49. E35.49 Recovery Receipt After reconciliation, a protected Recovery Receipt may be generated: RiREC binding: * original act; * original phase; * initial outcome state; * reconciliation evidence commitment; * authoritative reconciliation result; * retry/continue/stop decision; * policy epoch; * and protected time/sequence. A.35.50. E35.50 Recovery-Receipt-Derived Authority A new continuation or retry authority may depend cryptographically on the recovery result. For example: REC Ci+1 = Derive(DA , H(RiREC ), N extAction, Scope) Thus recovery is not merely informational; it may become part of the authority chain. Das Expires 4 April 2027 [Page 592] Internet-Draft Reality as a Cryptographic Dependency October 2026 A.35.51. E35.51 Recovery Authority Consumption A Recovery Receipt or retry authorization may be single-use. After the protected recovery transition: Consumed(RiREC ) = T RU E or equivalent protected state may be recorded. Replay must not create repeated retries or repeated continuation authority. A.35.52. E35.52 Recovery Policy Change If protected policy changes during reconciliation, a prior negative or recovery receipt need not automatically authorize retry under the new policy. The system may require: * revalidation; * reduced scope; * new human approval; * new automatic policy decision; * or termination. A.35.53. E35.53 Revocation During Reconciliation If the act, user, credential, destination, device, or policy authority is revoked while outcome is unresolved, recovery may remain limited to state determination and safe remediation. A valid negative receipt does not necessarily override current revocation. A.35.54. E35.54 Safe-State Authority Certain systems may permit a narrowly defined protected safe-state action even while the original effect remains indeterminate. Examples include: * stop motor; * apply brake; * close safety valve; * isolate network path; * revoke credential; Das Expires 4 April 2027 [Page 593] Internet-Draft Reality as a Cryptographic Dependency October 2026 * quarantine data; * or disable further release. Such authority should be bounded to hazard reduction and must not silently become a broader continuation authority. A.35.55. E35.55 Audit and Evidence Preservation Protected reconciliation may preserve: * original authority; * all received receipts; * missing-receipt condition; * query evidence; * state transitions; * retry decisions; * human approvals; * automatic decisions; * compensation actions; * and final recovery receipt. This supports later technical reconstruction of how the final consequence was determined. A.35.56. E35.56 Privacy-Preserving Reconciliation Recovery evidence need not disclose unnecessary payload or personal data. The system may use: * digests; * commitments; * selective disclosure; * attestation claims; * zero-knowledge proofs; Das Expires 4 April 2027 [Page 594] Internet-Draft Reality as a Cryptographic Dependency October 2026 * destination-side yes/no proofs; * or protected enclaves; provided the evidence remains sufficient for the required protected decision. A.35.57. E35.57 Anti-Bypass Requirement An unresolved outcome must not be bypassed by using an alternate path to repeat or broaden the consequence. Relevant bypasses may include: * alternate API; * different credential; * administrator interface; * direct network socket; * different message broker; * raw database connection; * direct device command; * recovery console; * or another effect-equivalent path. A.35.58. E35.58 Fail-Closed and Fail-Limited Recovery For high-consequence operations, indeterminate state may fail closed. For systems requiring continued operation, protected policy may instead enter a fail-limited state that permits only bounded low-risk or hazard-reducing actions. The permissible fail-limited envelope remains protected and must not silently expand because a receipt is unavailable. A.35.59. E35.59 Required Invariants The minimum frozen conceptual invariants of E35 are: Invariant 1 Absence of a positive receipt is not automatically treated as proof that no effect occurred. Invariant 2 A negative receipt used to authorize retry is protected, act-bound, phase-bound, and sufficiently authoritative for the non- effect state it asserts. Das Expires 4 April 2027 [Page 595] Internet-Draft Reality as a Cryptographic Dependency October 2026 Invariant 3 Indeterminate or conflicting effect state blocks unauthorized broader progression. Invariant 4 Reconciliation uses protected evidence from one or more authoritative state sources. Invariant 5 A proven already-effected operation is not blindly repeated. Invariant 6 A retry, where permitted, is separately bounded and authorized under current protected state. Invariant 7 Partial effect is accounted for so cumulative consequence does not exceed the authorized maximum. Invariant 8 Recovery receipts, retry authorities, and continuation authorities may be consumed or otherwise replay-protected. Invariant 9 Equivalent alternate paths do not silently bypass unresolved-effect controls. Invariant 10 Safe-state or fail-limited actions remain bounded to their protected recovery purpose. Everything else in E35 may vary by implementation unless expressly required. FROZEN RELATIONSHIP BETWEEN E34 AND E35 E34 addresses how multiple protected observations or replicas establish sufficient confirmation for continuation. E35 addresses what the protected system does when effect status is negative, partial, conflicting, missing, or indeterminate. The two workflows may operate together: Replicated Effect → Replica Receipts → Quorum/Consensus Evaluation ⎧Confirmed → Continue { {N egative → P rotected Retry/Stop { → ⎨P artial → Reconcile Remaining {Conflict → Reconciliation { {Indeterminate → Hold/Reconcile ⎩ The final architectural principle remains: Computational P roposal ≠ Authority to Create or Repeat Consequence and, correspondingly: M issing Evidence ≠ P roof of N on-Effect Das Expires 4 April 2027 [Page 596] Internet-Draft Reality as a Cryptographic Dependency October 2026 Appendix B. Normalized Mathematical and State-Machine Summary The following formulas restate recurring source relationships using one notation. They are not intended to require a particular cryptographic primitive or data representation. Act binding: D_A = H(Canon(A)) Exact effect confirmation: O_i = X_i Tolerance effect confirmation: d(O_i, X_i) <= epsilon_i Envelope constraint: Scope(P_i) <= E_MAX Receipt-gated continuation: Enable(P_(i+1)) = ReceiptValid_i AND CurrentConditions_i Receipt chain example: R_i = Protect(D_A || i || O_i || H(R_(i-1)) || context_i) Progressive chain: P_0 -> R_0 -> Gamma_1 -> P_1 -> R_1 -> Gamma_2 -> ... -> P_n Threshold continuation: sum_j ValidShare_j >= m Quorum continuation: sum_j Valid(R_i^j) >= m Conflict rule: Authentic(R_a) AND Authentic(R_b) AND NOT Consistent(R_a,R_b) => no ordinary continuation Indeterminate rule: UNKNOWN != SUCCESS Anti-bypass rule: EffectCapable(q) => EquivalentFinalityControl(q) OR Disable(q) Figure 34: Cross-workflow mathematical summary Das Expires 4 April 2027 [Page 597] Internet-Draft Reality as a Cryptographic Dependency October 2026 Appendix C. Workflow Coverage Map +==========+======================================================+ | Profiles | Primary coverage | +==========+======================================================+ | E01-E03 | Baseline single-phase, demonstration-then-full, and | | | progressive multi-phase effectuation. | +----------+------------------------------------------------------+ | E04-E06 | Protected human, automatic, and hybrid continuation. | +----------+------------------------------------------------------+ | E07-E09 | Software, hardware, and split software/hardware | | | protected enforcement. | +----------+------------------------------------------------------+ | E10-E12 | Receipt-conditioned key chains, threshold | | | continuation, and SEND trailer/full release. | +----------+------------------------------------------------------+ | E13-E15 | File transfer, payment demonstration, and escrow/ | | | conditional settlement. | +----------+------------------------------------------------------+ | E16-E18 | Database promotion, cloud rollout, and AI model | | | deployment/activation. | +----------+------------------------------------------------------+ | E19-E21 | Tool invocation, progressive credential release, and | | | progressive data export. | +----------+------------------------------------------------------+ | E22-E24 | Storage release, robotic actuation, and sensor- | | | confirmed hardware actuation. | +----------+------------------------------------------------------+ | E25-E27 | Vehicle, UAV/mobile robot, and industrial/PLC/ | | | process control. | +----------+------------------------------------------------------+ | E28-E30 | Telecom, radio/satellite/NTN, and GPU/accelerator/ | | | compute egress. | +----------+------------------------------------------------------+ | E31-E33 | Model-state updates, software/firmware/configuration | | | activation, and multi-destination effects. | +----------+------------------------------------------------------+ | E34-E35 | Replicated/quorum/consensus confirmation and | | | negative/indeterminate/conflict/recovery handling. | +----------+------------------------------------------------------+ Table 2: Workflow families Author's Address Das Expires 4 April 2027 [Page 598] Internet-Draft Reality as a Cryptographic Dependency October 2026 Sangam Das Independent Researcher Balasore Odisha India Email: info@sangamdas.com Das Expires 4 April 2027 [Page 599]