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
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sangam Das | ||
| Last updated | 2026-10-08 (Latest revision 2026-10-01) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Report- The 85.B2 Challenge: Does This Earlier Disclosed AI-Agent Architecture is Similar to Meta Muse/Sentinel?
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-das-safety-first-execution-finality-00
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
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),
<https://zenodo.org/records/23040181>. 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]