Network Working Group S. Das Internet-Draft Independent Researcher Intended status: Experimental 1 October 2026 Expires: 4 April 2027 Authority Is Earned from the Real Path, Not Granted Per Session: Receipt-Gated Interim Effectuation Validation for AI Agents, Frontier AI Model Providers, and Autonomous Systems draft-das-interim-effectuation-validation-00 Abstract Authority to cause a real-world effect should not be granted for a whole session; it should be earned, one bounded step at a time, from the real path itself. This document specifies an experimental architecture for controlling consequential external effects produced by agentic, autonomous, and conventional computing systems, and is addressed in particular to operators of AI machines and to frontier AI model providers. It separates a proposed act from authority to make that act effective, permits a real bounded effect to occur, obtains protected evidence of what actually occurred, independently evaluates that evidence in an Interim Effectuation Validator (IEV), and makes a later effect technically dependent on a protected continuation condition. The validator does not relay the original command, and if trustworthy evidence is missing the system holds or quarantines the act instead of retrying it. The architecture supports single-phase, two-phase, and multi-phase operation; human, automatic, and hybrid escalation; crash and indeterminate-state reconciliation; validator-integrity hardening; conflicting-evidence handling; effectuation-time revocation; taint and provenance propagation; privilege-separated credential surrogation; and software, hardware, virtual-machine, operating-system, destination- native, quorum, and tokenless realizations. The document defines an abstract protocol and conformance model rather than one mandatory transport or serialization. It also specifies implementation-invariance rules so that changing component placement, token representation, operating system, proxy topology, validator location, or credential representation does not by itself change the functional sequence when the required security properties are preserved. 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". Das Expires 4 April 2027 [Page 1] Internet-Draft Earned Authority: Interim Validation October 2026 Discussion This note is to be removed before publishing as an RFC. This is an individual Internet-Draft intended for technical review. It does not state or imply IETF consensus, adoption, implementation status, patent scope, infringement, ownership, or legal priority. 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/. 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 . . . . . . . . . . . . . . . . . . . . . . . . 13 2. Conventions and Requirement Language . . . . . . . . . . . . 14 3. Scope, Goals, and Non-Goals . . . . . . . . . . . . . . . . . 14 4. Terminology and Notation . . . . . . . . . . . . . . . . . . 15 5. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Architectural Roles . . . . . . . . . . . . . . . . . . . . . 17 6.1. Candidate Act Source . . . . . . . . . . . . . . . . . . 17 Das Expires 4 April 2027 [Page 2] Internet-Draft Earned Authority: Interim Validation October 2026 6.2. Protected Policy / Authority Function . . . . . . . . . . 18 6.3. Finality Sink . . . . . . . . . . . . . . . . . . . . . . 18 6.4. Effect Observer . . . . . . . . . . . . . . . . . . . . . 18 6.5. Interim Effectuation Validator . . . . . . . . . . . . . 18 6.6. Credential Authority . . . . . . . . . . . . . . . . . . 18 7. Conformance Profiles . . . . . . . . . . . . . . . . . . . . 18 8. Core Conformance Requirements . . . . . . . . . . . . . . . . 19 9. Candidate Act Binding and Authorized Envelope . . . . . . . . 20 10. Single-Phase Protected Effectuation . . . . . . . . . . . . . 20 11. Two-Phase Receipt-Gated Effectuation . . . . . . . . . . . . 21 12. Multi-Phase Progressive Effectuation . . . . . . . . . . . . 21 13. Effect Evidence and Observation . . . . . . . . . . . . . . . 22 14. Interim Effectuation Validator . . . . . . . . . . . . . . . 22 14.1. Protected IEV State . . . . . . . . . . . . . . . . . . 23 14.2. Validation Predicate . . . . . . . . . . . . . . . . . . 23 14.3. Effect Comparison . . . . . . . . . . . . . . . . . . . 23 15. Continuation Conditions and CVI . . . . . . . . . . . . . . . 24 16. Finality-Sink Verification at Effectuation Time . . . . . . . 24 17. Human Escalation . . . . . . . . . . . . . . . . . . . . . . 25 18. Automatic Remediation Without Human Approval . . . . . . . . 25 19. Indeterminate Outcomes, Reconciliation, and Crash Recovery . 26 20. Validator Integrity and Failure Hardening . . . . . . . . . . 26 21. Conflicting Authentic Evidence . . . . . . . . . . . . . . . 27 22. Post-PASS Revocation and Time-of-Effectuation Revalidation . 27 23. Taint, Provenance, and Origin Attribution . . . . . . . . . . 28 24. Surrogate Credentials and Boundary Resolution . . . . . . . . 28 25. Privilege-Separated Connectors and Brokers . . . . . . . . . 29 26. Platform Realizations . . . . . . . . . . . . . . . . . . . . 29 26.1. Isolated VM or microVM . . . . . . . . . . . . . . . . . 29 26.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . 29 26.3. Android . . . . . . . . . . . . . . . . . . . . . . . . 30 26.4. iOS and iPadOS . . . . . . . . . . . . . . . . . . . . . 30 26.5. macOS . . . . . . . . . . . . . . . . . . . . . . . . . 30 26.6. Windows . . . . . . . . . . . . . . . . . . . . . . . . 30 26.7. Ordinary application . . . . . . . . . . . . . . . . . . 30 27. Implementation Invariance and Equivalent Realizations . . . . 30 28. Abstract Protocol Objects . . . . . . . . . . . . . . . . . . 32 29. Encoding and Cryptographic Binding . . . . . . . . . . . . . 33 30. Domain Examples . . . . . . . . . . . . . . . . . . . . . . . 34 30.1. SEND / communication . . . . . . . . . . . . . . . . . . 34 30.2. Payment . . . . . . . . . . . . . . . . . . . . . . . . 34 30.3. File and data release . . . . . . . . . . . . . . . . . 34 30.4. Database . . . . . . . . . . . . . . . . . . . . . . . . 34 30.5. Cloud rollout . . . . . . . . . . . . . . . . . . . . . 34 30.6. AI tool use . . . . . . . . . . . . . . . . . . . . . . 34 30.7. Credential progression . . . . . . . . . . . . . . . . . 35 30.8. GPU / accelerator . . . . . . . . . . . . . . . . . . . 35 30.9. Model state . . . . . . . . . . . . . . . . . . . . . . 35 Das Expires 4 April 2027 [Page 3] Internet-Draft Earned Authority: Interim Validation October 2026 30.10. Software / firmware update . . . . . . . . . . . . . . . 35 30.11. Robotics / actuator . . . . . . . . . . . . . . . . . . 35 30.12. Vehicle / UAV . . . . . . . . . . . . . . . . . . . . . 35 30.13. Industrial / PLC . . . . . . . . . . . . . . . . . . . . 35 30.14. Telecom / radio / satellite . . . . . . . . . . . . . . 35 30.15. Multi-destination / quorum . . . . . . . . . . . . . . . 35 31. Interoperability and Deployment Considerations . . . . . . . 36 32. Security Considerations . . . . . . . . . . . . . . . . . . . 36 32.1. Forgery and substitution . . . . . . . . . . . . . . . . 36 32.2. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 37 32.3. Downgrade . . . . . . . . . . . . . . . . . . . . . . . 37 32.4. Alternate-path bypass . . . . . . . . . . . . . . . . . 37 32.5. Unknown outcomes . . . . . . . . . . . . . . . . . . . . 37 32.6. Validator compromise . . . . . . . . . . . . . . . . . . 37 32.7. Conflicting evidence . . . . . . . . . . . . . . . . . . 37 32.8. Time-of-check/time-of-use . . . . . . . . . . . . . . . 37 32.9. Credential exposure . . . . . . . . . . . . . . . . . . 37 32.10. Denial of service . . . . . . . . . . . . . . . . . . . 38 32.11. Privacy leakage . . . . . . . . . . . . . . . . . . . . 38 33. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38 34. Operational Considerations . . . . . . . . . . . . . . . . . 38 35. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 36. Normative References . . . . . . . . . . . . . . . . . . . . 39 37. Informative References . . . . . . . . . . . . . . . . . . . 39 Appendix A. Detailed IEV Architecture and Mathematical Model . . 40 A.1. Document Structure . . . . . . . . . . . . . . . . . . . 41 A.2. Unified Mathematical Notation and Formal Model . . . . . 41 A.2.1. A. Core objects and indices . . . . . . . . . . . . 42 A.2.2. B. Candidate-act binding . . . . . . . . . . . . . . 42 A.2.3. C. Core inter-phase causal relationship . . . . . . 43 A.2.4. D. Effect comparison . . . . . . . . . . . . . . . . 43 A.2.5. E. Formal IEV pass predicate . . . . . . . . . . . . 44 A.2.6. F. Continuation Validation Instruction . . . . . . . 44 A.2.7. G. Receipt-dependent cryptographic material . . . . 44 A.2.8. H. Hardware-latch realization . . . . . . . . . . . 45 A.2.9. I. Decision domain . . . . . . . . . . . . . . . . . 45 A.3. PART I - CORE INTERIM EFFECTUATION VALIDATOR IMPLEMENTATION PATTERN . . . . . . . . . . . . . . . . . . . . . . . . 45 A.3.1. 1. Purpose . . . . . . . . . . . . . . . . . . . . . 45 A.3.2. 2. Interim Effectuation Validator Definition . . . . 46 A.3.3. 3. Decision Independence and Neutrality . . . . . . 47 A.3.4. 4. First-Phase Direct Effectuation . . . . . . . . . 48 A.3.5. 5. Effectuation Evidence Returned to the IEV . . . . 48 A.3.6. 6. Evidence of Where Effectuation Actually Occurred . . . . . . . . . . . . . . . . . . . . . . 49 A.3.7. 7. Independent Validation of the Earlier Phase . . . 51 A.3.8. 8. Comparison of Expected and Actual Effect . . . . 51 A.3.9. 9. Successful Interim Validation . . . . . . . . . . 52 Das Expires 4 April 2027 [Page 4] Internet-Draft Earned Authority: Interim Validation October 2026 A.3.10. 10. Binding the Continuation Instruction to the Verified Prior Effect . . . . . . . . . . . . . . . . 53 A.3.11. 11. Finality Sink Dependence on the IEV . . . . . . 53 A.3.12. 12. Multi-Phase Interim Validation . . . . . . . . . 54 A.3.13. 13. Misalignment Detection . . . . . . . . . . . . . 54 A.3.14. 14. Human Escalation Following Misalignment . . . . 55 A.3.15. 15. Automated Error-Catcher / Remediation Path . . . 56 A.3.16. 16. Indeterminate Result . . . . . . . . . . . . . . 57 A.3.17. 17. Protected Middle Decision Plane . . . . . . . . 57 A.3.18. 18. On-Chip IMPLEMENTATION PATTERN . . . . . . . . . 57 A.3.19. 19. Physically Separate IEV IMPLEMENTATION PATTERN . . . . . . . . . . . . . . . . . . . . . . . 58 A.3.20. 20. SEND / Communication Example . . . . . . . . . . 58 A.3.21. 21. Payment Example . . . . . . . . . . . . . . . . 58 A.3.22. 22. Hardware Actuator Example . . . . . . . . . . . 59 A.3.23. 23. Multiple Evidence Sources . . . . . . . . . . . 60 A.3.24. 24. Logical Distinction Without Physical Separation . . . . . . . . . . . . . . . . . . . . . 60 A.3.25. 25. Anti-Bypass Requirement . . . . . . . . . . . . 60 A.3.26. 26. Required Core Invariants . . . . . . . . . . . . 61 A.3.27. 27. Central Technical Statement . . . . . . . . . . 61 A.4. PART II - CROSS-IMPLEMENTATION PATTERN TECHNICAL IMPLEMENTATION OF THE IEV . . . . . . . . . . . . . . . 62 A.4.1. 28. Applicability to Other Embodiments . . . . . . . 62 A.4.2. 29. Technical Insertion Rule . . . . . . . . . . . . 62 A.4.3. 30. Concrete IEV Input Interface . . . . . . . . . . 63 A.4.4. 31. Protected IEV State . . . . . . . . . . . . . . 63 A.4.5. 32. Protected IEV Validation Algorithm . . . . . . . 64 A.4.6. 33. Exact, Range, Tolerance, Set, and Predicate Validation . . . . . . . . . . . . . . . . . . . . . 66 A.4.7. 34. Continuation Validation Instruction . . . . . . 66 A.4.8. 35. Finality Sink Verification of IEV Output . . . . 67 A.4.9. 36. Cryptographically Missing Continuation Material . . . . . . . . . . . . . . . . . . . . . . 67 A.4.10. 37. Split-Key Implementation . . . . . . . . . . . . 67 A.4.11. 38. Hardware-Latch Implementation . . . . . . . . . 68 A.4.12. 39. Secure-Mailbox Implementation . . . . . . . . . 68 A.4.13. 40. Protected Shared-Memory Implementation . . . . . 69 A.4.14. 41. Kernel / Operating-System Implementation . . . . 69 A.4.15. 42. Network Implementation . . . . . . . . . . . . . 70 A.4.16. 43. Database / Transaction Implementation . . . . . 70 A.4.17. 44. Storage Implementation . . . . . . . . . . . . . 70 A.4.18. 45. Communication / SEND Implementation . . . . . . 71 A.4.19. 46. Payment Implementation . . . . . . . . . . . . . 71 A.4.20. 47. Robotic / Vehicle / Actuator Implementation . . 71 A.4.21. 48. Telecom / Radio / Satellite Implementation . . . 72 A.4.22. 49. GPU / Accelerator Implementation . . . . . . . . 72 A.4.23. 50. AI Tool-Use Implementation . . . . . . . . . . . 72 Das Expires 4 April 2027 [Page 5] Internet-Draft Earned Authority: Interim Validation October 2026 A.4.24. 51. Model-State / Memory Update Implementation . . . 73 A.4.25. 52. Software / Firmware Update Implementation . . . 73 A.4.26. 53. Multi-Destination Implementation . . . . . . . . 73 A.4.27. 54. Quorum / Consensus Implementation . . . . . . . 74 A.4.28. 55. Human Escalation Implementation . . . . . . . . 74 A.4.29. 56. Automated Error-Catcher Implementation . . . . . 75 A.4.30. 57. Atomic Validation, Consumption, and Phase Advancement . . . . . . . . . . . . . . . . . . . . . 75 A.4.31. 58. Crash After IEV Approval . . . . . . . . . . . . 75 A.4.32. 59. Crash During the Next Effect . . . . . . . . . . 76 A.4.33. 60. Anti-Substitution . . . . . . . . . . . . . . . 76 A.4.34. 61. Anti-Bypass Implementation . . . . . . . . . . . 76 A.4.35. 62. Concrete Cross-IMPLEMENTATION PATTERN Insertion Procedure . . . . . . . . . . . . . . . . . . . . . . 77 A.4.36. 63. Cross-IMPLEMENTATION PATTERN Technical Invariant . . . . . . . . . . . . . . . . . . . . . . 78 A.5. PART III - STEP-BY-STEP PSEUDOCODE / OPERATIONAL WORKFLOW . . . . . . . . . . . . . . . . . . . . . . . . 78 A.5.1. Concrete execution sequence . . . . . . . . . . . . . 98 A.6. Appendix A - Mathematical Consistency Notes . . . . . . . 99 A.7. Appendix B - Central IEV Relationships . . . . . . . . . 100 A.8. PART IV - HARDENED IEV EMBODIMENTS . . . . . . . . . . . 100 A.9. H1. IEV Compromise, Failure, Unavailability, or State Inconsistency . . . . . . . . . . . . . . . . . . . . . 100 A.9.1. H1.1 Failure model . . . . . . . . . . . . . . . . . 100 A.9.2. H1.2 IEV Decision Evidence Object . . . . . . . . . . 101 A.9.3. H1.3 Protected state digest and chain . . . . . . . . 101 A.9.4. H1.4 Monotonic counter requirement . . . . . . . . . 101 A.9.5. H1.5 Validator attestation . . . . . . . . . . . . . 102 A.9.6. H1.6 Independent watchdog . . . . . . . . . . . . . . 102 A.9.7. H1.7 Dual and threshold validators . . . . . . . . . 102 A.9.8. H1.8 Hierarchical validation . . . . . . . . . . . . 103 A.9.9. H1.9 Validator unavailability . . . . . . . . . . . . 103 A.9.10. H1.10 Failover to an alternate IEV . . . . . . . . . 104 A.9.11. H1.11 Inconsistent protected state . . . . . . . . . 104 A.9.12. H1.12 Crash-consistent state transition . . . . . . . 104 A.9.13. H1.13 Compromised validator key . . . . . . . . . . . 104 A.9.14. H1.14 Protection against a lying IEV . . . . . . . . 105 A.9.15. H1.15 Proof-carrying IEV decision . . . . . . . . . . 105 A.9.16. H1.16 Core validator-integrity invariant . . . . . . 105 A.10. H2. Conflicting but Individually Authentic Effect Evidence . . . . . . . . . . . . . . . . . . . . . . . . 106 A.10.1. H2.1 Evidence vector . . . . . . . . . . . . . . . . 106 A.10.2. H2.2 Conflict predicate . . . . . . . . . . . . . . 106 A.10.3. H2.3 Conflict is distinct from invalid evidence . . 106 A.10.4. H2.4 Fail-closed conflict behavior . . . . . . . . . 107 A.10.5. H2.5 Protected Conflict Record . . . . . . . . . . . 107 A.10.6. H2.6 Predicate-specific source authority . . . . . . 107 Das Expires 4 April 2027 [Page 6] Internet-Draft Earned Authority: Interim Validation October 2026 A.10.7. H2.7 Weighted evidence . . . . . . . . . . . . . . . 107 A.10.8. H2.8 Quorum evidence . . . . . . . . . . . . . . . . 108 A.10.9. H2.9 Temporal consistency . . . . . . . . . . . . . 108 A.10.10. H2.10 Causal reconciliation . . . . . . . . . . . . 108 A.10.11. H2.11 Additional evidence and bounded diagnostic phase . . . . . . . . . . . . . . . . . . . . . . . . 108 A.10.12. H2.12 Conflict-resolution domain . . . . . . . . . . 108 A.10.13. H2.13 Consistency proof . . . . . . . . . . . . . . 109 A.10.14. H2.14 Core conflicting-evidence invariant . . . . . 109 A.11. H3. Continuation Revocation After IEV PASS but Before Finality-Sink Consumption . . . . . . . . . . . . . . . 109 A.11.1. H3.1 Time-of-check / time-of-effectuation gap . . . 109 A.11.2. H3.2 Effectuation-time revalidation . . . . . . . . 109 A.11.3. H3.3 Short-lived continuation lease . . . . . . . . 110 A.11.4. H3.4 Policy-epoch binding . . . . . . . . . . . . . 110 A.11.5. H3.5 Revocation-epoch binding . . . . . . . . . . . 110 A.11.6. H3.6 Continuation Revocation Record . . . . . . . . 110 A.11.7. H3.7 Generation-based invalidation . . . . . . . . . 111 A.11.8. H3.8 Destination-state revalidation . . . . . . . . 111 A.11.9. H3.9 Human-approval withdrawal . . . . . . . . . . . 111 A.11.10. H3.10 Risk and taint revalidation . . . . . . . . . 111 A.11.11. H3.11 Revalidation object . . . . . . . . . . . . . 112 A.11.12. H3.12 Online consume protocol . . . . . . . . . . . 112 A.11.13. H3.13 Revoke-or-consume race . . . . . . . . . . . . 112 A.11.14. H3.14 Hardware revocation realization . . . . . . . 113 A.11.15. H3.15 Cryptographic revocation realization . . . . . 113 A.11.16. H3.16 Prepare/commit continuation . . . . . . . . . 113 A.11.17. H3.17 Scope reduction after PASS . . . . . . . . . . 114 A.11.18. H3.18 Post-PASS substitution protection . . . . . . 114 A.11.19. H3.19 Distributed revocation and offline operation . . . . . . . . . . . . . . . . . . . . . . 114 A.11.20. H3.20 Core post-PASS invariant . . . . . . . . . . . 114 A.12. H4. Combined Hardened IEV Model . . . . . . . . . . . . 115 A.13. H5. Fail-Closed and Fail-Limited Defaults . . . . . . . 115 A.14. H6. Formal Distinctions . . . . . . . . . . . . . . . . 116 A.15. H7. Combined Security Invariant . . . . . . . . . . . . 116 A.16. Appendix C - Mathematical Notation for the Hardened Embodiments . . . . . . . . . . . . . . . . . . . . . . 117 Appendix B. Software, VM, Operating-System, and Application Realizations . . . . . . . . . . . . . . . . . . . . . . 118 B.1. 1. Purpose and Scope . . . . . . . . . . . . . . . . . . 119 B.2. 2. Formal Notation . . . . . . . . . . . . . . . . . . . 119 B.3. 3. Canonical Functional Sequence . . . . . . . . . . . . 120 B.4. 4. IEV Decision Function . . . . . . . . . . . . . . . . 121 B.5. 5. Effect Comparison Models . . . . . . . . . . . . . . 121 B.5.1. 5.1 Exact equality . . . . . . . . . . . . . . . . . 121 B.5.2. 5.2 Tolerance . . . . . . . . . . . . . . . . . . . . 122 B.5.3. 5.3 Range . . . . . . . . . . . . . . . . . . . . . . 122 Das Expires 4 April 2027 [Page 7] Internet-Draft Earned Authority: Interim Validation October 2026 B.5.4. 5.4 Authorized result set . . . . . . . . . . . . . . 122 B.5.5. 5.5 Predicate set . . . . . . . . . . . . . . . . . . 122 B.6. 6. Software IEV Protection Requirements . . . . . . . . 122 B.7. 7. Generic Software State . . . . . . . . . . . . . . . 123 B.8. 8. Continuation Validation Instruction . . . . . . . . . 124 B.9. 9. Tokenless Continuation . . . . . . . . . . . . . . . 124 B.10. 10. Receipt-Derived Execution Material . . . . . . . . . 124 B.11. 11. Isolated Virtual Machine IMPLEMENTATION PATTERN . . 125 B.12. 12. VM Network IMPLEMENTATION PATTERN . . . . . . . . . 126 B.13. 13. VM Storage IMPLEMENTATION PATTERN . . . . . . . . . 126 B.14. 14. MicroVM IMPLEMENTATION PATTERN . . . . . . . . . . . 127 B.15. 15. Linux Process-Separated IMPLEMENTATION PATTERN . . . 127 B.16. 16. Linux Namespace and Container IMPLEMENTATION PATTERN . . . . . . . . . . . . . . . . . . . . . . . . 128 B.17. 17. Linux Kernel/LSM/eBPF-Adjacent IMPLEMENTATION PATTERN . . . . . . . . . . . . . . . . . . . . . . . . 128 B.18. 18. Linux Credential Broker . . . . . . . . . . . . . . 129 B.19. 19. Android System-Service IMPLEMENTATION PATTERN . . . 129 B.20. 20. Android Protected Binder Interface . . . . . . . . . 130 B.21. 21. Android Hardware-Backed Key IMPLEMENTATION PATTERN . . . . . . . . . . . . . . . . . . . . . . . . 130 B.22. 22. Android TEE IMPLEMENTATION PATTERN . . . . . . . . . 131 B.23. 23. Android App-Only / Backend IMPLEMENTATION PATTERN . 131 B.24. 24. iOS / iPadOS IMPLEMENTATION PATTERN . . . . . . . . . 132 B.25. 25. iOS Secure-Key-Assisted IEV . . . . . . . . . . . . . 133 B.26. 26. macOS Helper / XPC IMPLEMENTATION PATTERN . . . . . . 133 B.27. 27. Windows Service IMPLEMENTATION PATTERN . . . . . . . 133 B.28. 28. Windows VBS-Enclave-Assisted IMPLEMENTATION PATTERN . . . . . . . . . . . . . . . . . . . . . . . . 134 B.29. 29. Ordinary Desktop Application IMPLEMENTATION PATTERN . . . . . . . . . . . . . . . . . . . . . . . . 134 B.30. 30. Same-Process Lower-Assurance IMPLEMENTATION PATTERN . . . . . . . . . . . . . . . . . . . . . . . . 135 B.31. 31. Local-Plus-Remote Validator . . . . . . . . . . . . 135 B.32. 32. Application Backend Finality . . . . . . . . . . . . 135 B.33. 33. SEND / Communication Example . . . . . . . . . . . . 136 B.34. 34. Payment Example . . . . . . . . . . . . . . . . . . 137 B.35. 35. File / Data Release Example . . . . . . . . . . . . 137 B.36. 36. AI Tool-Use Example . . . . . . . . . . . . . . . . 138 B.37. 37. GPU / Accelerator Example . . . . . . . . . . . . . 138 B.38. 38. Database / Storage Example . . . . . . . . . . . . . 139 B.39. 39. Software / Firmware Rollout Example . . . . . . . . 139 B.40. 40. Human Escalation in Software . . . . . . . . . . . . 140 B.41. 41. Fully Automatic Remediation . . . . . . . . . . . . 140 B.42. 42. Process Crash and Recovery . . . . . . . . . . . . . 140 B.43. 43. Effect Occurred but Receipt Missing . . . . . . . . 141 B.44. 44. Anti-Bypass Requirement . . . . . . . . . . . . . . 141 B.45. 45. Validator-Substitution Invariance . . . . . . . . . 142 Das Expires 4 April 2027 [Page 8] Internet-Draft Earned Authority: Interim Validation October 2026 B.45.1. 45.1 Core principle . . . . . . . . . . . . . . . . 142 B.45.2. 45.2 Functional equivalence relation . . . . . . . . 143 B.46. 46. Validator Substitution Example - Linux Daemon to Isolated VM . . . . . . . . . . . . . . . . . . . . . . 144 B.47. 47. Validator Substitution Example - Android Local Service to Remote IEV . . . . . . . . . . . . . . . . . . . . . 145 B.48. 48. Validator Substitution Example - Windows Service to VBS-Assisted Validator . . . . . . . . . . . . . . . . . 146 B.49. 49. Validator Substitution Example - iOS Local/Remote Mix . . . . . . . . . . . . . . . . . . . . . . . . . . 146 B.50. 50. Validator Substitution Example - Same Process to Separate Process . . . . . . . . . . . . . . . . . . . . 147 B.51. 51. Validator Substitution Example - Single IEV to Threshold IEV . . . . . . . . . . . . . . . . . . . . . 148 B.52. 52. Validator Substitution Example - Token to Protected State . . . . . . . . . . . . . . . . . . . . . . . . . 148 B.53. 53. Validator Substitution Example - Software Key to Hardware Latch . . . . . . . . . . . . . . . . . . . . . 149 B.54. 54. Implementation Independence Statement . . . . . . . 149 B.55. 55. Platform-Independent Enhanced IMPLEMENTATION PATTERN . . . . . . . . . . . . . . . . . . . . . . . . 150 B.56. 56. Mathematical Platform-Neutral Invariant . . . . . . 151 B.57. 57. Final Technical Statement . . . . . . . . . . . . . 152 Appendix C. Taint-Aware Boundary Mediation, Credential Surrogation, and Privilege Separation . . . . . . . . . . 153 C.1. 1. Purpose and Scope . . . . . . . . . . . . . . . . . . 153 C.2. 2. Formal Notation . . . . . . . . . . . . . . . . . . . 155 C.3. 3. Act-Originating Domain and Protected Domain . . . . . 155 C.4. 4. Taint Classification . . . . . . . . . . . . . . . . 156 C.5. 5. Taint Propagation . . . . . . . . . . . . . . . . . . 157 C.6. 6. Taint Representation . . . . . . . . . . . . . . . . 157 C.7. 7. Protected Origin Attribution . . . . . . . . . . . . 158 C.8. 8. Taint-Dependent Policy . . . . . . . . . . . . . . . 159 C.9. 9. Surrogate Credential Concept . . . . . . . . . . . . 159 C.10. 10. Surrogate Scope and Binding . . . . . . . . . . . . 160 C.11. 11. Protected Credential Authority . . . . . . . . . . . 160 C.12. 12. Boundary Credential Substitution or Resolution . . . 161 C.13. 13. Boundary Swap Predicate . . . . . . . . . . . . . . 161 C.14. 14. Credential Is Not Returned to the Agent . . . . . . 162 C.15. 15. Finality Sink Incorporating Credential Resolution . 162 C.16. 16. Privilege-Separated Connector Execution . . . . . . 162 C.17. 17. Three Distinct Security Functions . . . . . . . . . 163 C.18. 18. Network Boundary . . . . . . . . . . . . . . . . . . 163 C.19. 19. Browser Broker . . . . . . . . . . . . . . . . . . . 164 C.20. 20. Independent Safety and Risk Classifiers . . . . . . 164 C.21. 21. Candidate-Act Descriptor with Taint and Provenance . . . . . . . . . . . . . . . . . . . . . . . 165 C.22. 22. Real Bounded First Effect . . . . . . . . . . . . . 165 Das Expires 4 April 2027 [Page 9] Internet-Draft Earned Authority: Interim Validation October 2026 C.23. 23. Protected Effect Receipt Including Boundary Context . . . . . . . . . . . . . . . . . . . . . . . . 166 C.24. 24. IEV Validation of Effect and Boundary Behavior . . . 166 C.25. 25. Effect Comparison Modes . . . . . . . . . . . . . . 166 C.26. 26. Boundary Substitution Detection . . . . . . . . . . 167 C.27. 27. Equivalent Boundary . . . . . . . . . . . . . . . . 167 C.28. 28. Boundary-Substitution Invariance . . . . . . . . . . 168 C.29. 29. Surrogate-Representation Invariance . . . . . . . . 168 C.30. 30. No-Explicit-Surrogate Variant . . . . . . . . . . . 168 C.31. 31. Surrogate Plus IEV Continuation . . . . . . . . . . 169 C.32. 32. Taint Plus Surrogate Gating . . . . . . . . . . . . 169 C.33. 33. Taint Change Between Phases . . . . . . . . . . . . 169 C.34. 34. Effectuation-Time Taint Revalidation . . . . . . . . 170 C.35. 35. SEND Example - Tainted Context . . . . . . . . . . . 170 C.36. 36. SEND With Human Review . . . . . . . . . . . . . . . 171 C.37. 37. SEND Without Human Review . . . . . . . . . . . . . 171 C.38. 38. Payment Example . . . . . . . . . . . . . . . . . . 171 C.39. 39. Browser Example . . . . . . . . . . . . . . . . . . 172 C.40. 40. Connector Example . . . . . . . . . . . . . . . . . 172 C.41. 41. Cross-Tool Taint Propagation . . . . . . . . . . . . 172 C.42. 42. Taint Snapshot in Receipt Chain . . . . . . . . . . 173 C.43. 43. Durable-State Separation . . . . . . . . . . . . . . 173 C.44. 44. Authenticated IPC . . . . . . . . . . . . . . . . . 173 C.45. 45. Human Approval as a Protected Capability . . . . . . 173 C.46. 46. Read/Write Privilege Separation . . . . . . . . . . 174 C.47. 47. Sensitive-Content Filtering . . . . . . . . . . . . 174 C.48. 48. Protected Inference Path . . . . . . . . . . . . . . 174 C.49. 49. Defense in Depth . . . . . . . . . . . . . . . . . . 174 C.50. 50. Strong Next-Phase Authorization Expression . . . . . 175 C.51. 51. Anti-Bypass . . . . . . . . . . . . . . . . . . . . 175 C.52. 52. Implementation Independence . . . . . . . . . . . . 175 C.53. 53. Replacement Invariance Across Security Mechanisms . 176 C.54. 54. Combined Invariance Function . . . . . . . . . . . . 176 C.55. 55. Non-Limiting Pseudocode - Protected Taint-Aware Boundary and IEV Workflow . . . . . . . . . . . . . . . 177 C.56. 56. Non-Limiting Pseudocode - Taint Propagation . . . . 180 C.57. 57. Non-Limiting Pseudocode - Boundary Credential Resolution . . . . . . . . . . . . . . . . . . . . . . . 180 C.58. 58. Non-Limiting Pseudocode - IEV Validation . . . . . . 181 C.59. 59. Non-Limiting Pseudocode - SEND Trailer Then Full Payload . . . . . . . . . . . . . . . . . . . . . . . . 183 C.60. 60. Non-Limiting Pseudocode - Automatic Misalignment Handling . . . . . . . . . . . . . . . . . . . . . . . . 183 C.61. 61. Example - Linux / VM Deployment . . . . . . . . . . 184 C.62. 62. Example - Android / Mobile Deployment . . . . . . . 185 C.63. 63. Example - Windows / Desktop Deployment . . . . . . . 185 C.64. 64. Example - iOS / Sandboxed App Deployment . . . . . . 185 C.65. 65. Commercial Deployment Forms . . . . . . . . . . . . 186 Das Expires 4 April 2027 [Page 10] Internet-Draft Earned Authority: Interim Validation October 2026 C.66. 66. Final Technical Invariants . . . . . . . . . . . . . 187 Appendix D. Equivalent-Realization and Topology-Independent Patterns . . . . . . . . . . . . . . . . . . . . . . . . 187 D.1. Purpose and Interpretive Rule . . . . . . . . . . . . . . 188 D.2. Alternative Implementation Pattern T1 -- Monolithic Protected Executor . . . . . . . . . . . . . . . . . . . 188 D.3. Alternative Implementation Pattern T2 -- Implicit-State / No-Token Authority . . . . . . . . . . . . . . . . . . . 189 D.4. Alternative Implementation Pattern T3 -- Direct Human-Signed Exact Act . . . . . . . . . . . . . . . . . 189 D.5. Alternative Implementation Pattern T4 -- Human Re-Originated Operation After AI Recommendation . . . . 190 D.6. Alternative Implementation Pattern T5 -- Structural Capability / Object-Capability / Typed-Authority System 190 D.7. Alternative Implementation Pattern T6 -- Native Transactional Invariant / Commit-State Enforcement . . . 191 D.8. Alternative Implementation Pattern T7 -- Risk-Selective or Consequence-Selective Mediation . . . . . . . . . . . . 192 D.9. Alternative Implementation Pattern T8 -- Post-Effect Compensation as an Ancillary or Fallback Mode . . . . . 192 D.10. Alternative Implementation Pattern T9 -- Formally Verified, Attested, or Deterministic Agent Within a Protected Envelope . . . . . . . . . . . . . . . . . . . . . . . . 193 D.11. Alternative Implementation Pattern T10 -- Native Destination Policy and Destination-Local Finality . . . 193 D.12. Alternative Implementation Pattern T11 -- Replicated / Quorum / Consensus-Native Effectuation . . . . . . . . . 194 D.13. Alternative Implementation Pattern T12 -- Pre-Authorized Finite Action Machine / Bounded Action Graph . . . . . . 194 D.14. Cross-Cutting Implementation Rule for T1-T12 . . . . . . 195 Appendix E. Extended Domain and Workflow Catalogue . . . . . . . 195 E.1. E01: Single-phase protected effectuation . . . . . . . . 195 E.2. E02: Real bounded demonstration effect -> verified receipt -> full effectuation . . . . . . . . . . . . . . . . . . 195 E.3. E03: Real demonstration effect -> receipt-gated multi-phase progressive effectuation . . . . . . . . . . . . . . . . 196 E.4. E04: Verified demonstration effect -> protected human approval -> broader or full effectuation . . . . . . . . 196 E.5. E05: Verified demonstration effect -> automatic protected decision -> receipt-gated continuation . . . . . . . . . 196 E.6. E06: Hybrid human + automatic receipt-gated continuation . . . . . . . . . . . . . . . . . . . . . . 196 E.7. E07: Software protected enforcement domain . . . . . . . 196 E.8. E08: Hardware protected enforcement domain . . . . . . . 197 E.9. E09: Split software/hardware protected enforcement domain . . . . . . . . . . . . . . . . . . . . . . . . . 197 E.10. E10: Receipt-conditioned hardware cryptographic key-chain effectuation . . . . . . . . . . . . . . . . . . . . . . 197 Das Expires 4 April 2027 [Page 11] Internet-Draft Earned Authority: Interim Validation October 2026 E.11. E11: Threshold / multi-party cryptographic continuation . . . . . . . . . . . . . . . . . . . . . . 197 E.12. E12: Message SEND demonstration / trailer-then-full effectuation . . . . . . . . . . . . . . . . . . . . . . 197 E.13. E13: Receipt-gated file transfer and progressive file release . . . . . . . . . . . . . . . . . . . . . . . . 198 E.14. E14: Payment demonstration and receipt-gated full / progressive payment . . . . . . . . . . . . . . . . . . 198 E.15. E15: Escrow / conditional settlement and receipt-gated release . . . . . . . . . . . . . . . . . . . . . . . . 198 E.16. E16: Receipt-gated database commit, provisional persistence, and promotion . . . . . . . . . . . . . . . 198 E.17. E17: Receipt-gated cloud deployment and progressive infrastructure rollout . . . . . . . . . . . . . . . . . 198 E.18. E18: Receipt-gated AI model deployment, model activation, and progressive consequence release . . . . . . . . . . 199 E.19. E19: AI tool-use and external-action invocation . . . . . 199 E.20. E20: Progressive credential release . . . . . . . . . . . 199 E.21. E21: Data export, progressive disclosure, and cryptographic release . . . . . . . . . . . . . . . . . . . . . . . . 199 E.22. E22: Storage, provisional persistence, and progressive visibility . . . . . . . . . . . . . . . . . . . . . . . 199 E.23. E23: Robotics and progressive physical effect . . . . . . 200 E.24. E24: Hardware actuator and sensor-receipt-derived motion authority . . . . . . . . . . . . . . . . . . . . . . . 200 E.25. E25: Receipt-gated vehicle effectuation and progressive vehicular authority . . . . . . . . . . . . . . . . . . 200 E.26. E26: Receipt-gated UAV and mobile-robot effectuation . . 200 E.27. E27: Receipt-gated industrial, PLC, machine, and process-control effectuation . . . . . . . . . . . . . . 200 E.28. E28: Receipt-gated telecom effectuation and progressive network authority . . . . . . . . . . . . . . . . . . . 201 E.29. E29: Receipt-gated radio, satellite, and non-terrestrial-network effectuation . . . . . . . . . . 201 E.30. E30: Receipt-gated GPU, accelerator, and compute-egress effectuation . . . . . . . . . . . . . . . . . . . . . . 201 E.31. E31: Receipt-gated model-state update, protected memory commit, and progressive model-state effectuation . . . . 201 E.32. E32: Receipt-gated software, firmware, and configuration update with progressive activation . . . . . . . . . . . 202 E.33. E33: Multi-destination, multi-recipient, multi-sink, and distributed receipt-gated effectuation . . . . . . . . . 202 E.34. E34: Replicated, quorum-confirmed, and consensus receipt-gated effectuation . . . . . . . . . . . . . . . 202 E.35. E35: Negative, indeterminate, conflict, reconciliation, and recovery receipt-gated effectuation . . . . . . . . . . 202 Appendix F. Non-Limiting Reference Pseudocode . . . . . . . . . 202 Appendix G. Consolidated Functional Invariants . . . . . . . . . 204 Das Expires 4 April 2027 [Page 12] Internet-Draft Earned Authority: Interim Validation October 2026 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 206 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 206 1. Introduction Agentic systems increasingly cross a boundary between computation and consequence. A model can propose a SEND operation, payment, API call, database mutation, network change, software deployment, physical command, or credential use, but the computation that produced the proposal is not necessarily the authority that should make the resulting effect real. A conventional authorization design often evaluates a request once and then permits the entire requested consequence. This document describes an alternative in which authority can be staged. A first real effect may be deliberately bounded. Evidence of that effect is then validated independently before a later or broader effect becomes technically possible. Candidate Act | v Protected Validation / Phase-0 Authority | v Finality Sink FS[0] | v REAL EFFECT P[0] | v Protected Evidence R[0] | v Interim Effectuation Validator (IEV) | v Protected Continuation Condition Gamma[1] | v Finality Sink FS[1] | v REAL EFFECT P[1] Figure 1: Core inter-phase sequence Das Expires 4 April 2027 [Page 13] Internet-Draft Earned Authority: Interim Validation October 2026 The IEV is not merely a post-event auditor. In the IEV profile, a required continuation condition is established only after the earlier real effect has been independently evaluated, and the next Finality Sink depends on that condition. 2. Conventions and Requirement 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, as shown here. See [RFC2119] and [RFC8174]. Most implementation examples in this document are explicitly non- normative. Normative requirements apply only when an implementation claims conformance to a profile defined in this document. 3. Scope, Goals, and Non-Goals The architecture is applicable to AI agents, deterministic applications, operating systems, cloud controllers, communication systems, payment systems, databases, storage systems, accelerators, vehicles, robots, industrial controllers, telecom systems, radio systems, and other systems capable of causing consequential external or persistent effects. * Goal: distinguish proposal or computation from effectuation authority. * Goal: permit single-phase effectuation where protected policy allows it. * Goal: permit bounded real effectuation before broader effectuation. * Goal: bind later authority to protected evidence of an earlier real effect. * Goal: support exact, tolerance, range, set-membership, semantic, and predicate-based effect comparison. * Goal: preserve fail-closed or fail-limited behavior for unknown, stale, conflicting, replayed, or indeterminate evidence. * Goal: support software, hardware, local, remote, distributed, tokenless, state-machine, and destination-native realization. Das Expires 4 April 2027 [Page 14] Internet-Draft Earned Authority: Interim Validation October 2026 * Goal: prevent an implementation detail such as component naming, token format, or validator placement from being mistaken for the architecture itself. * Non-goal: define a single universal wire encoding, credential system, policy language, or human-approval interface. * Non-goal: treat every operation as requiring staged effectuation. Protected policy can select direct single-phase, staged, or denied paths by consequence class. 4. Terminology and Notation Candidate Act (A) A proposed operation capable of causing an external, persistent, financial, communicative, informational, storage, network, rendering, model-state, device, or physical consequence. Candidate Act Digest (D_A) A protected identifier for the Candidate Act, commonly D_A = H(Canon(A)), or an equivalent deterministic act-binding mechanism. Effectuation The transition by which a proposed operation becomes externally or persistently consequential. Finality Sink (FS) A component or protected function positioned at an effect-capable boundary and able to withhold, permit, commit, transmit, actuate, persist, settle, render, decrypt, sign, route, or otherwise make a consequential operation effective. Bounded Real Effect (P[i]) A real but intentionally limited effectuation phase. It is not solely simulation, prediction, preview, or dry-run. Effect Evidence / Receipt (R[i]) Machine-verifiable evidence representing what actually occurred during or after phase P[i]. Effect Observer A source of evidence meaningfully connected to the real effect, such as a destination, transaction system, storage engine, protected sensor, network component, device, or trusted observer. Interim Effectuation Validator (IEV) A protected decision function that independently evaluates evidence of an earlier real effect before establishing eligibility for a later effect. Continuation Validation Instruction (CVI) One possible explicit Das Expires 4 April 2027 [Page 15] Internet-Draft Earned Authority: Interim Validation October 2026 protected continuation object established after successful IEV validation. A CVI is not required in tokenless realizations. Protected Continuation Condition (Gamma[i+1]) Any technically required condition for phase i+1, including a CVI, key, key share, state bit, transaction state, latch, secure mailbox entry, policy transition, destination-side state, or equivalent mechanism. Protected Enforcement Domain (PED) One or more protected components that evaluate, bind, authorize, or enforce effectuation. The PED may be physically separate, logically separate, distributed, or co-located with the Finality Sink. Non-Effective State (NES) A state in which a requested remainder or later phase is not yet capable of producing its intended consequential effect. Taint State (tau) Protected metadata representing relevant trust, provenance, exposure, information-flow, behavioral-risk, or lineage state. Surrogate Credential (sigma) A non-authoritative credential reference, placeholder, handle, alias, or session-scoped representation that requires protected boundary resolution before an actual credential can be used. Indeterminate A state in which the system cannot establish whether a required effect, non-effect, receipt, or continuation condition is proven. Index i current completed or observed phase P[i] real effectuation phase i R[i] protected evidence for P[i] X[i] expected effect for phase i O[i] observed effect for phase i FS[i] Finality Sink controlling phase i S_IEV[i] protected IEV state at phase i CVI[i+1] explicit continuation instruction for next phase Gamma[i+1] generic protected continuation condition Envelope_MAX maximum authorized consequence envelope PE, RE policy epoch and revocation epoch Ctr_IEV protected IEV monotonic counter Figure 2: Core notation Das Expires 4 April 2027 [Page 16] Internet-Draft Earned Authority: Interim Validation October 2026 5. Threat Model The architecture assumes that an act-generating component may be buggy, compromised, manipulated by untrusted input, subject to prompt injection, stale, confused about external state, or simply incorrect. It also considers failures or compromise in observers, validators, networks, credentials, destinations, and Finality Sinks. * Act substitution after approval or between phases. * Destination, recipient, route, resource, device, or sink substitution. * Forged, replayed, stale, duplicated, downgraded, or cross-act evidence. * Crash or timeout after a real effect but before receipt delivery. * Crash after continuation issuance but before Finality-Sink consumption. * Blind retry of an operation whose prior outcome is unknown. * Alternate effect-capable path that bypasses the protected continuation condition. * Validator unavailability, rollback, stale state, key compromise, false PASS, duplicate issuance, or internal inconsistency. * Two or more individually authentic evidence objects that are mutually inconsistent. * Policy, risk, taint, destination, human authority, or revocation change after IEV PASS but before the next effect becomes real. * Credential theft or leakage from an act-generating process. * Cross-tool taint propagation and provenance loss. 6. Architectural Roles 6.1. Candidate Act Source Produces or transports a proposed operation. It can be an AI agent, application, OS, workflow engine, human-operated application, controller, or other computational source. Generating a Candidate Act does not itself make the source authoritative. Das Expires 4 April 2027 [Page 17] Internet-Draft Earned Authority: Interim Validation October 2026 6.2. Protected Policy / Authority Function Evaluates current policy, revocation, risk, taint, provenance, destination, scope, user authority, receipt state, and other protected predicates. It can authorize a direct single phase or a bounded phase. 6.3. Finality Sink Controls the actual effect-capable boundary. A Finality Sink can be a network proxy, API gateway, database engine, payment gateway, storage controller, kernel boundary, device driver, secure monitor, actuator controller, DPU, SmartNIC, GPU controller, telecom gateway, radio controller, remote destination, or equivalent component. 6.4. Effect Observer Reports protected evidence about what actually occurred. The observer and sink can be the same component or separate components. 6.5. Interim Effectuation Validator Authenticates, binds, compares, evaluates, and decides whether earlier real-effect evidence satisfies required continuation predicates. 6.6. Credential Authority Optionally holds actual secrets, keys, OAuth-like credentials, API credentials, signing material, or equivalent authority outside the act-generating domain and resolves a surrogate or reference only at a protected boundary. 7. Conformance Profiles Profiles make explicit which properties are required for a deployment claiming a particular level of behavior. A deployment can implement more than one profile. EF-BASELINE A single protected effectuation phase is permitted after protected validation. The Candidate Act remains distinct from final effectuation authority. EF-STAGED At least one real bounded effect occurs before a broader effect, and accepted evidence of the bounded effect is technically relevant to broader continuation. EF-IEV EF-STAGED plus an IEV decision function that independently Das Expires 4 April 2027 [Page 18] Internet-Draft Earned Authority: Interim Validation October 2026 evaluates earlier real-effect evidence and establishes Gamma[i+1] before FS[i+1] permits the next phase. EF-HARDENED EF-IEV plus validator-integrity checks, conflicting- evidence handling, replay protection, effectuation-time policy/ revocation revalidation, and defined indeterminate-state behavior. EF-TAINT-SURROGATE EF-IEV or EF-HARDENED plus protected taint/ provenance evaluation and protected credential resolution or equivalent late-binding authority at an effectuation boundary. EF-NON-BYPASSABLE Any applicable profile plus closure of act- equivalent alternate paths so that a required protected condition cannot be avoided through another API, credential, device path, debug path, network path, or equivalent route. 8. Core Conformance Requirements An implementation claiming EF-IEV conformance satisfies the following functional requirements. These requirements intentionally describe properties rather than product topology. REQ1: Candidate Act or authorized act class is distinguishable from the actual consequential effect. REQ2: At least one phase preceding a gated subsequent phase produces a real effect or protected predecessor state, not solely a simulation or model prediction. REQ3: Protected evidence for the preceding phase is obtained from a source or mechanism meaningfully connected to that phase. REQ4: The evidence is authenticated, integrity-protected, or otherwise made machine-verifiable to the degree required by policy. REQ5: The IEV decision function is not arbitrarily writable by the Candidate Act Source. REQ6: The IEV validates act/phase binding, freshness, replay state, relevant sink/destination/resource bindings, effect acceptability, and current protected policy predicates applicable to the deployment. REQ7: On successful validation, the IEV establishes or causes establishment of Gamma[i+1]. Receipt existence by itself is not sufficient. Das Expires 4 April 2027 [Page 19] Internet-Draft Earned Authority: Interim Validation October 2026 REQ8: FS[i+1] verifies or consumes Gamma[i+1] before making P[i+1] effective. REQ9: If a mandatory predicate is false, the ordinary next phase remains non-effective. REQ10: If a mandatory predicate is unknown or indeterminate, the deployment applies its defined reconciliation, safe-state, fail-limited, or escalation policy rather than silently treating the predicate as satisfied. REQ11: Consumed evidence and one-time continuation state are protected against replay or duplicate use. REQ12: No phase is permitted to expand authority beyond Envelope_MAX merely because earlier phases succeeded. 9. Candidate Act Binding and Authorized Envelope Where exact binding is required, a Candidate Act can be canonicalized and hashed. Canonicalization is one mechanism; a deterministic typed representation, transaction identifier, protected object identity, or equivalent binding can be used instead. A_C = Canon(A) D_A = H(A_C) Authority(A) !=> Authority(B) where B is a materially different unauthorized act. Figure 3: Candidate-act binding An authorized maximum envelope limits progression. Successful receipts do not implicitly enlarge that envelope. Scope(P[i]) <= Envelope_MAX RequestedNextScope > Envelope_MAX => DENY Figure 4: Maximum envelope 10. Single-Phase Protected Effectuation The architecture is not limited to staged operation. Protected policy may select a single-phase path for lower-consequence, pre- authorized, reversible, latency-sensitive, or structurally constrained acts. Das Expires 4 April 2027 [Page 20] Internet-Draft Earned Authority: Interim Validation October 2026 Candidate Act -> Protected Validation -> Effectuation Authority -> Finality Sink -> Authorized Full Effect -> Completion Evidence Figure 5: Single-phase baseline A system can therefore deploy staged IEV controls only for selected consequence classes without requiring every operation to pass through a multi-phase workflow. 11. Two-Phase Receipt-Gated Effectuation In the two-phase profile, the initial operation causes a real but bounded consequence. The evidence from this consequence participates in the authority chain for the next phase. Candidate Act -> bounded authority C[0] -> FS[0] -> REAL bounded effect P[0] -> protected evidence R[0] -> IEV -> Gamma[1] -> FS[1] -> remaining or full effect P[1] Figure 6: Two-phase sequence The first phase can be bounded by amount, bytes, recipient set, destination set, duration, device range, privilege, transaction state, deployment population, bandwidth, or another consequence dimension. 12. Multi-Phase Progressive Effectuation P[0] -> R[0] -> IEV[0] -> Gamma[1] -> P[1] P[1] -> R[1] -> IEV[1] -> Gamma[2] -> P[2] ... P[n-1] -> R[n-1] -> IEV[n-1] -> Gamma[n] -> P[n] -> R[n] Figure 7: Multi-phase progression Mandatory phases cannot be skipped merely by invoking a later API or alternate route. A protected phase counter, receipt chain, transaction state, or equivalent sequence-binding mechanism can enforce ordering. If phase index == i, direct execution of P[i+2] is rejected unless policy explicitly defines P[i+1] as unnecessary or equivalent. Das Expires 4 April 2027 [Page 21] Internet-Draft Earned Authority: Interim Validation October 2026 Figure 8: Anti-skip rule 13. Effect Evidence and Observation Evidence can originate from the Finality Sink, destination, recipient, transaction system, database, storage engine, protected sensor, device controller, network component, cloud service, DPU, SmartNIC, secure element, HSM, TEE, quorum, or multiple observers. An Effect Receipt can bind the Candidate Act digest, phase, prior authority digest, observed result, sink, destination, observer, resource, transaction identifier, nonce, counter, policy epoch, revocation epoch, timestamp, status, route, device measurement, taint snapshot, provenance digest, and next-stage eligibility evidence. EffectReceipt R_i = { act_digest, phase_id, phase_authority_digest, observed_effect, sink_id, destination_id, observer_id, resource_id, transaction_id, nonce, counter, policy_epoch, revocation_epoch, timestamp, result_code, optional_taint_state, optional_provenance_digest, authentication_or_attestation } Figure 9: Illustrative abstract receipt fields 14. Interim Effectuation Validator The IEV consumes protected evidence of an already attempted or completed phase and decides whether continuation is permitted, denied, held, reconciled, reduced, remediated, escalated, or terminated. The first phase need not traverse the IEV before effectuation; the IEV role can begin after P[0] has produced evidence. Das Expires 4 April 2027 [Page 22] Internet-Draft Earned Authority: Interim Validation October 2026 P[i] -> R[i] -> IEV[i] -> Decision[i] Decision[i] in { PASS, FAIL, HOLD, RECONCILE, RETRY_OR_REMEDIATE, HUMAN_REVIEW, REDUCE_SCOPE, TERMINATE } Figure 10: IEV decision domain 14.1. Protected IEV State Protected IEV state can contain D_A, Envelope_MAX, current phase, expected sink and destination, expected effect, tolerance, receipt quality, policy and revocation epochs, next scope, consumed-receipt state, retry state, risk, taint, provenance, counters, escalation state, and continuation-issuance state. 14.2. Validation Predicate IEVPass[i] = AuthValid(R[i]) AND ActMatch(R[i], D_A) AND PhaseMatch(R[i], i) AND SinkMatch(R[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 11: Representative IEV PASS predicate 14.3. Effect Comparison Exact: O[i] == X[i] Tolerance: distance(O[i], X[i]) <= epsilon[i] Range: L[i] <= O[i] <= U[i] Authorized set: O[i] in A_set[i] Predicate set: ALL required Pred_k(O[i]) == TRUE Figure 12: Effect comparison modes Das Expires 4 April 2027 [Page 23] Internet-Draft Earned Authority: Interim Validation October 2026 15. Continuation Conditions and CVI A continuation condition is a technical condition required by the next effectuation boundary. It need not be a bearer token and need not be externally visible. CVI[i+1] = Protect_IEV({ act_digest: D_A, prior_phase: i, next_phase: i+1, prior_receipt_digest: H(R[i]), next_scope: Scope(P[i+1]), next_sink: Sink[i+1], next_destination: Destination[i+1], policy_epoch, revocation_epoch, iev_counter, expiry }) Figure 13: Illustrative CVI fields A tokenless implementation can instead atomically update protected state. A hardware implementation can set a latch. A cryptographic implementation can derive or unseal next-phase material. K[i+1] = KDF(K_root_IEV, D_A, H(R[i]), i+1, Sink[i+1], Ctr_IEV) K_final[i+1] = Combine(K_FS[i+1], K_IEV[i+1]) ENABLE[i+1] = FSValid AND (IEV_Latch == PASS[i]) Figure 14: Alternative continuation realizations 16. Finality-Sink Verification at Effectuation Time The Finality Sink is the final protected decision point before the next real consequence becomes effective. A previously valid IEV decision does not remove the need to check current state at the effectuation boundary. Enable(P[i+1], t_effect) = Valid(Gamma[i+1]) AND PolicyCurrent(t_effect) AND RevocationClear(t_effect) AND ContinuationNotWithdrawn(t_effect) AND DestinationStillValid(t_effect) AND ScopeStillAuthorized(t_effect) Das Expires 4 April 2027 [Page 24] Internet-Draft Earned Authority: Interim Validation October 2026 Figure 15: Effectuation-time revalidation 17. Human Escalation When a misalignment or policy condition requires human judgment, the IEV can form a protected escalation record that binds the Candidate Act, prior receipt, expected effect, observed effect, deviation, proposed next phase, risk, and policy context. The human response returns to protected validation; it is not required to act as unrestricted direct execution authority. PER_i = Protect({ act_digest: D_A, receipt_digest: H(R[i]), expected_effect: X[i], observed_effect: O[i], deviation, proposed_next_phase, risk_state, policy_epoch }) HumanDecision -> IEV revalidation -> bounded Gamma[i+1] Figure 16: Protected human escalation A communication-specific example is trailer -> real recipient -> receipt -> IEV misalignment -> protected human review -> IEV revalidation -> communication-specific continuation -> Finality Sink -> full SEND. 18. Automatic Remediation Without Human Approval Human participation is optional. An automated remediation controller can propose re-query, re-attestation, retry, reduced scope, rollback, compensation, alternate sink, quarantine, safe state, or termination. The remediation controller does not automatically obtain unrestricted effectuation authority; its proposal returns through protected validation. Mismatch -> Automated Remediation Proposal -> IEV revalidation -> bounded remediation or continuation condition -> Finality Sink Figure 17: Automatic remediation path Das Expires 4 April 2027 [Page 25] Internet-Draft Earned Authority: Interim Validation October 2026 19. Indeterminate Outcomes, Reconciliation, and Crash Recovery An uncertain outcome is not treated as proof of failure and is not treated as proof of success. The system can query protected state using act digest, phase, nonce, transaction identifier, idempotency identifier, counters, destination state, sink state, ledger state, sensors, replicas, or protected journals. ReconciliationResult in { PROVEN_EFFECTED, PROVEN_NOT_EFFECTED, PARTIALLY_EFFECTED, STILL_INDETERMINATE } PROVEN_EFFECTED -> recovered evidence -> IEV validation PROVEN_NOT_EFFECTED -> optional new bounded retry with new authority PARTIALLY_EFFECTED -> residual-scope / compensation / escalation STILL_INDETERMINATE -> next ordinary phase remains blocked Figure 18: Reconciliation outcomes If a Finality Sink performed P[i] but R[i] was not delivered, the system does not blindly repeat P[i]. If a CVI was issued but consumption is unknown, the system reconciles the consumption state before reissuing equivalent authority. 20. Validator Integrity and Failure Hardening A hardened deployment does not assume that a single IEV can never fail or lie. Validator integrity can be checked through state chaining, monotonic counters, attestation, watchdogs, diverse validators, threshold validators, hierarchical validators, proof- carrying decisions, or a subset of independent Finality-Sink checks. SD[i] = H(S_IEV[i]) SD[i+1] = H(SD[i] || H(R[i]) || Decision[i] || Counter[i+1]) IEVTrusted[i] = AttestationValid[i] AND StateConsistent[i] AND CounterValid[i] AND WatchdogClear[i] Enable(P[i+1]) = CVIValid[i+1] AND IEVTrusted[i] AND FSBoundaryChecksValid Figure 19: Validator integrity model Das Expires 4 April 2027 [Page 26] Internet-Draft Earned Authority: Interim Validation October 2026 If the primary validator is unavailable, policy can HOLD, enter SAFE_STATE, use reduced scope, select an alternate validator, use FAIL_LIMITED behavior, or terminate. High-consequence profiles do not treat validator unavailability as implicit PASS. 21. Conflicting Authentic Evidence Authentication and consistency are distinct properties. Two receipts can each authenticate correctly and still disagree about the effect. Valid(R_a) == TRUE Valid(R_b) == TRUE Constraint(R_a, R_b) == FALSE => EvidenceState = CONFLICT => no ordinary continuation until conflict policy resolves Figure 20: Conflict predicate Conflict resolution can use predicate-specific source authority, quorum, weighted evidence, veto-class sensors, temporal consistency, causal identifiers, additional evidence, bounded diagnostic effects, automatic resolution, or protected human adjudication. A majority does not necessarily override a critical high-assurance contradiction. 22. Post-PASS Revocation and Time-of-Effectuation Revalidation A CVI valid when issued can become stale before the next effect. Policy, revocation, destination state, taint, risk, human approval, or device health can change in the interval between IEV PASS and Finality-Sink consumption. IEVPass(t0) != IrrevocableAuthority(t1), where t1 > t0 ValidAtIssue(CVI) !=> ValidAtEffectuation(CVI) Figure 21: Time-of-check versus time-of-effectuation Mechanisms include short-lived continuation leases, policy-epoch binding, revocation-epoch binding, explicit continuation-revocation records, generation counters, online consume handshakes, atomic revoke-or-consume state, hardware revocation latches, current-epoch key derivation, and prepare/commit continuation. Das Expires 4 April 2027 [Page 27] Internet-Draft Earned Authority: Interim Validation October 2026 23. Taint, Provenance, and Origin Attribution Taint is an input to protected policy and can represent semantic information flow, sensitive-data exposure, untrusted external content, provenance uncertainty, behavioral risk, tool-output lineage, or other trust-relevant state. Taint need not be a Linux- style byte label; equivalent protected lineage or risk state can be used. tau_out = Join(tau_process, tau_input_1, ..., tau_input_n) tau(A[i+1]) = Propagate(tau(A[i]), tau(Context), tau(ToolOutputs), tau(Provenance)) UnableToValidateTaint !=> CLEAN Figure 22: Taint propagation Origin attribution can bind a request to process, task, agent, UID, cgroup, container, VM, code measurement, session, or other protected identity. A receipt may preserve the relevant origin and taint snapshot so the IEV can evaluate the pathway that produced the effect. 24. Surrogate Credentials and Boundary Resolution An act-generating domain can hold a non-authoritative surrogate credential or reference while the actual credential remains in a protected credential authority. The protected boundary resolves, inserts, uses, or activates the actual credential only after required policy checks. The actual credential need not be returned to the agent. sigma_j != K_real_j Possess(sigma_j) !=> EffectAuthority SwapAllowed[i+1] = SurrogateValid(sigma[i+1]) AND CVIValid(CVI[i+1]) AND PolicyCurrent AND RevocationClear AND DestinationCurrent AND TaintAcceptable Figure 23: Boundary credential resolution Das Expires 4 April 2027 [Page 28] Internet-Draft Earned Authority: Interim Validation October 2026 The surrogate can be an opaque token, handle, credential alias, object reference, session reference, key handle, signed request reference, or implicit protected credential reference. The architecture does not require a literal token swap. 25. Privilege-Separated Connectors and Brokers Connector or tool logic can be divided into a narrow unprivileged stub and a protected worker. The worker can be restricted to a service-specific credential class and effect scope. Network, browser, filesystem, payment, database, and cloud operations can be mediated by corresponding brokers or Finality Sinks. Agent / Lower-Trust Domain | v Narrow Connector Stub | authenticated IPC v Privilege-Separated Worker / Broker / FS | protected credential and policy checks v External Service Figure 24: Privilege-separated connector pattern 26. Platform Realizations The IEV role is functional rather than tied to a particular platform. Changing the validator placement does not change the sequence when the required protected properties are preserved. 26.1. Isolated VM or microVM The agent and IEV can execute in separate VMs or microVMs. A host broker, hypervisor service, or separate VM can act as Finality Sink. The agent VM can lack unrestricted network or storage authority. 26.2. Linux The agent and IEV can use separate UIDs, namespaces, cgroups, containers, mandatory-access-control domains, or services. Kernel, LSM, eBPF-adjacent, seccomp, proxy, credential-broker, or transaction mechanisms can enforce effect boundaries. Das Expires 4 April 2027 [Page 29] Internet-Draft Earned Authority: Interim Validation October 2026 26.3. Android The IEV can be a system service, isolated process, Binder service, native daemon, TEE component, remote validator, or application/ backend service. Protected key operations can authenticate continuation decisions. 26.4. iOS and iPadOS The IEV can be implemented through a protected backend, separate supported extension/helper, secure-key-assisted mechanism, or platform service. Where a third-party app cannot mediate all local OS resources, the server-side Finality Sink can preserve the same inter-phase dependency. 26.5. macOS A helper, XPC service, daemon, sandboxed component, privileged broker, remote service, or hardware-backed key service can implement the protected validator and Finality Sink functions. 26.6. Windows A Windows service, AppContainer-separated broker, restricted process, VM, VBS-assisted component, remote validator, or credential broker can implement the roles. 26.7. Ordinary application A lower-assurance realization can use separate processes, app-owned brokers, server-side gates, or even logically distinct modules in one process. Stronger isolation increases resistance to compromise but does not change the functional sequence. 27. Implementation Invariance and Equivalent Realizations This section states functional equivalence rules intended to prevent accidental coupling of the architecture to one topology, product name, token type, proxy, operating system, or cryptographic representation. It is a technical interoperability and architecture statement, not a legal conclusion. Functional sequence F: E[i] -> R[i] -> IEV[i] -> Gamma[i+1] -> FS[i+1] -> E[i+1] If implementation X and implementation Y preserve the required role, trust-boundary, binding, state-transition, and anti-bypass properties, then replacing a component representation does not by itself change F. Das Expires 4 April 2027 [Page 30] Internet-Draft Earned Authority: Interim Validation October 2026 Figure 25: Functional-sequence invariance Monolithic protected executor One component can validate, perform a bounded effect, observe it, advance protected state, and perform the broader effect. Physical separation is not required if protected state prevents skipping the confirmation transition. Tokenless authority Gamma can be an internal state bit, transaction state, database state, latch, register, monotonic counter, consensus state, or other protected state rather than a transferable token. Direct human exact-act authorization A protected human signature can directly authorize an exact act or authorized envelope, with staged continuation optionally bound to prior evidence. Human re-origination An AI can provide only a recommendation while a human independently originates the effect-capable operation in a trusted application. Structural or object capability Authority can be encoded in typed objects, capability graphs, language-level effect types, file descriptors, namespaces, memory-safe references, or hardware protection domains. Receipt validation can expose or unlock broader objects. Native transactional invariant A database, payment service, message service, cloud control plane, or storage engine can enforce the staged state machine natively without an external token or broker. Risk-selective mediation Only protected consequence classes need staged effectuation. Lower-risk classes can use direct-within- envelope paths. Post-effect compensation Compensation and rollback can exist as ancillary or fallback behavior when pre-effect staging is unavailable. They do not replace the staged invariant where policy requires it. Attested or formally constrained agent A strongly constrained or formally verified agent can reduce risk, while an effectuation boundary can still enforce execution-finality for selected consequence classes. Destination-native enforcement The destination itself can observe, validate, and gate broader effectuation. Quorum or consensus Evidence and continuation authority can be Das Expires 4 April 2027 [Page 31] Internet-Draft Earned Authority: Interim Validation October 2026 represented by quorum certificates, threshold signatures, consensus state, or replicated commit state. Pre-authorized finite action graph A protected action graph can define allowed states and transitions. Receipts can unlock edges, consume edges, advance a protected state pointer, or reduce the remaining graph. Validator substitution A Linux daemon, VM, enclave, remote service, same-chip security domain, destination-local validator, or threshold set can replace another validator placement without changing the functional sequence if required properties remain. Boundary substitution A forward proxy, kernel gate, SmartNIC, DPU, API gateway, transaction engine, native destination, or hardware controller can implement the effectuation boundary. Surrogate representation substitution A token, handle, alias, credential reference, object capability, protected slot, or implicit state can all represent late-bound authority. Taint representation substitution Kernel labels, provenance graphs, cryptographic tags, protected metadata, process taint, semantic taint, or policy-derived lineage can represent the relevant protected state. 28. Abstract Protocol Objects The architecture is intentionally transport-neutral. Interoperable deployments can define these objects using CBOR, JSON, protobuf-like schemas, typed RPC objects, database records, protected shared memory, hardware registers, or another deterministic representation. When cryptographic binding depends on serialization, implementations need a deterministic encoding or an unambiguous typed object representation. CandidateActDescriptor act identifier or digest; act class; destination; resource; payload digest; scope; maximum envelope; policy epoch; revocation epoch; nonce; expiry; origin; optional taint and provenance. PhaseAuthority act digest; phase; phase scope; sink; destination; nonce; expiry; policy/revocation epoch; authority authenticator or protected state reference. EffectReceipt act digest; phase; observed effect; sink/destination/ Das Expires 4 April 2027 [Page 32] Internet-Draft Earned Authority: Interim Validation October 2026 observer; transaction and resource identifiers; nonce; counter; timestamp; status; optional prior receipt digest; authentication/ attestation. InterimValidationInputRecord expected and observed effect, receipt digest, phase authority digest, sink/destination/observer/resource identifiers, policy state, transaction state, nonce, counter, timestamp. ContinuationValidationInstruction act digest; prior phase; next phase; prior receipt digest; next scope; next sink/destination; policy/revocation epoch; counter; expiry; authenticator. ValidatorDecisionEvidenceObject validator identity; validator measurement; protected state digest; decision; receipt digest; next scope; policy/revocation epoch; counter; timestamp; expiry; attestation or signature. ConflictRecord digests of conflicting evidence; conflicting fields; source identities and roles; policy epoch; conflict class; time window; optional confidence or assurance metadata. ProtectedEscalationRecord act digest; receipt digest; expected effect; observed effect; deviation; proposed next phase; risk; policy context. ContinuationRevocationRecord CVI digest or continuation generation; act digest; revocation reason; revocation epoch; authority identity; timestamp; authenticator. FinalReceipt act digest; commitment to phase receipts or receipt- chain root; final state; final counter; policy epoch; authenticator. 29. Encoding and Cryptographic Binding This version does not mandate one encoding. CBOR can be used as described by RFC 8949, with COSE structures from RFC 9052 for signing or message authentication. JSON deployments can use a deterministic canonicalization scheme such as RFC 8785 before hashing or signing. These are examples, not mandatory dependencies of the abstract architecture. Das Expires 4 April 2027 [Page 33] Internet-Draft Earned Authority: Interim Validation October 2026 Cryptographic binding can use digital signatures, MACs, authenticated encryption, HSM/TEE attestations, hardware counters, threshold signatures, hash chains, Merkle commitments, secure logs, or equivalent mechanisms. Keys for a later phase can be derived from a prior receipt digest so that the later phase is cryptographically non-completable without accepted predecessor evidence. 30. Domain Examples 30.1. SEND / communication Send a real trailer or bounded communication object, obtain recipient- or endpoint-bound evidence, validate it in the IEV, and release the remaining message, attachment, payload, or decryption capability only after continuation validation. 30.2. Payment Perform a bounded hold, verification transfer, authorization, or escrow reservation. Validate beneficiary, account, amount, currency, rail, and transaction state before capture, settlement, or later tranche. 30.3. File and data release Release a manifest, ciphertext fragment, bounded chunk, or restricted object. Validate destination storage state and then release remaining data, visibility, or a decryption key. 30.4. Database Commit a provisional or restricted mutation, obtain durable commit evidence, validate it, then promote, expose, replicate, or perform dependent transactions. 30.5. Cloud rollout Deploy to a bounded target set, validate health and state, then expand to additional nodes, zones, regions, tenants, or traffic percentages. 30.6. AI tool use Permit a bounded real tool effect, validate actual tool result and destination, then authorize a dependent or broader tool effect. Das Expires 4 April 2027 [Page 34] Internet-Draft Earned Authority: Interim Validation October 2026 30.7. Credential progression Expose only a surrogate, reference, or low-scope authority for an earlier phase, then release or broker broader credential authority after validation. 30.8. GPU / accelerator Validate workload/device/firmware/output/DMA or egress evidence before broader memory exposure, external egress, or dependent action. 30.9. Model state Write or expose a provisional state change, validate namespace, provenance, conflict, taint, and state receipt, then promote or replicate. 30.10. Software / firmware update Activate a canary scope, obtain health evidence, validate it, then authorize broader rollout. 30.11. Robotics / actuator Move a bounded amount, measure actual motion or device state, validate against tolerance, then release the next motion envelope. 30.12. Vehicle / UAV Authorize a bounded trajectory, maneuver, speed, or operating region and expand only after protected sensor/position/state evidence passes. 30.13. Industrial / PLC Apply a bounded process change, validate protected sensor response, then permit broader setpoint, batch, flow, or machine cycle. 30.14. Telecom / radio / satellite Perform a bounded bearer, route, beam, RF burst, power level, or transmission, validate network/receiver state, then expand scope. 30.15. Multi-destination / quorum Collect a vector of destination receipts and require all, quorum, weighted, or role-constrained acceptance before broader progression. Das Expires 4 April 2027 [Page 35] Internet-Draft Earned Authority: Interim Validation October 2026 31. Interoperability and Deployment Considerations * A deployment should document which component acts as Finality Sink for each consequence class. * A deployment should document which evidence sources are authoritative for which predicates. * A deployment should document whether Gamma is explicit, implicit, tokenless, cryptographic, transactional, hardware-backed, or distributed. * A deployment should document canonicalization or typed object binding sufficient to prevent material interpretation drift. * A deployment should document receipt freshness, replay state, phase ordering, crash recovery, and idempotency behavior. * A deployment should document effectuation-time policy and revocation checks. * A deployment claiming EF-NON-BYPASSABLE should identify act- equivalent paths and how each path is mediated, disabled, credential-restricted, or equivalently gated. * A deployment using taint or provenance should document UNKNOWN or UNVERIFIABLE behavior rather than silently mapping missing lineage to clean state. * A deployment using surrogate credentials should document whether actual credentials ever enter the act-generating domain. 32. Security Considerations The security objective is not merely to decide whether a computation appears safe. It is to control the boundary at which computation becomes consequential and to keep later effects technically dependent on current protected conditions and verified predecessor evidence. 32.1. Forgery and substitution Receipts and continuation objects require authenticity and binding to the intended act, phase, sink, destination, resource, scope, and relevant policy state. A valid signature over the wrong operation is not sufficient. Das Expires 4 April 2027 [Page 36] Internet-Draft Earned Authority: Interim Validation October 2026 32.2. Replay Single-use receipts and continuation objects are consumed in protected state. Nonces, counters, phase identifiers, expiries, transaction identifiers, or sequence state can prevent reuse. 32.3. Downgrade An attacker must not replace a required high-assurance trial, observer, validator, or effect boundary with a weaker one unless policy explicitly permits an equivalent profile. 32.4. Alternate-path bypass Direct sockets, hidden APIs, alternate credentials, admin interfaces, raw device paths, debug paths, recovery paths, message queues, database connections, lower-level primitives, and equivalent effect- capable routes need equivalent mediation where non-bypassability is claimed. 32.5. Unknown outcomes Blind retry is dangerous for payments, SEND operations, deletes, commits, and physical actions. Reconciliation precedes retry when duplicate consequence would be unsafe. 32.6. Validator compromise Attestation, diverse validators, threshold decisions, watchdogs, state chaining, counters, proof-carrying decisions, and Finality-Sink minimum checks can limit reliance on one validator. 32.7. Conflicting evidence Authenticity does not imply consistency. Conflicting authentic evidence triggers conflict policy rather than ordinary continuation. 32.8. Time-of-check/time-of-use Policy, destination, risk, taint, human authority, and revocation can change after PASS. The Finality Sink revalidates current protected conditions at effectuation time. 32.9. Credential exposure Actual effect-capable credentials can remain outside the act- generating process and be resolved only at a protected boundary. Das Expires 4 April 2027 [Page 37] Internet-Draft Earned Authority: Interim Validation October 2026 32.10. Denial of service Attackers can trigger repeated trials, evidence collection, or reconciliation. Rate limits, bounded retries, backoff, quotas, safe fallback, and consequence-aware throttling are applicable. 32.11. Privacy leakage Receipts can expose destinations, users, transaction state, physical state, or provenance. Deployments should minimize evidence and can use commitments, selective disclosure, protected storage, or privacy- preserving proofs. 33. Privacy Considerations Effect receipts, taint metadata, provenance graphs, human approvals, and reconciliation logs can contain sensitive personal or enterprise information. Implementations should minimize collection, bind evidence to the minimum necessary predicates, apply retention limits, separate operational telemetry from long-lived identity where possible, and protect evidence at rest and in transit. General Internet privacy guidance is available in RFC 6973. An IEV can validate commitments or attestations rather than raw content when the predicate can be proven without exposing the underlying payload. For example, a receipt can prove that a destination, account, device, or state belongs to an authorized set without disclosing unrelated details. 34. Operational Considerations Staged effectuation introduces latency, additional state, evidence collection, and failure modes. It is therefore especially appropriate where consequence magnitude justifies additional control, while lower-consequence operations can remain single-phase under protected policy. * Choose bounded phase size so the trial is meaningful but consequence-limited. * Define timeout behavior and distinguish timeout from proven non- effect. * Define receipt quality and authoritative observer classes. * Use idempotency and transaction identifiers when retried effects can duplicate consequence. Das Expires 4 April 2027 [Page 38] Internet-Draft Earned Authority: Interim Validation October 2026 * Define safe-state or fail-limited behavior for offline, partitioned, or validator-unavailable operation. * Keep policy epochs, revocation epochs, counters, and validator state rollback-resistant where required. * Test native-operation substitution, crash after provider entry, and alternate effect-capable paths. * Test canonicalization ambiguity and cross-language object equivalence. * Test high-concurrency receipt consumption and duplicate continuation races. 35. IANA Considerations This document requests no IANA actions. Future specifications that define interoperable wire encodings, media types, registries, CBOR tags, or protocol parameters can define the corresponding IANA considerations separately. 36. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . 37. Informative References [DAS-MUSE-SENTINEL-GUIDE] Das, S., "Before Comparing Meta Muse / Sentinel, Read the Earlier DAS Disclosures: An AI-Assisted Primary-Source Technical Guide", Zenodo record 23040181 (resource type: Patent, open access), . Patent pending concept: Indian Patent Office application number 202631117633. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", RFC 3552, July 2003, . Das Expires 4 April 2027 [Page 39] Internet-Draft Earned Authority: Interim Validation October 2026 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", RFC 9052, August 2022, . [RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP Semantics", RFC 9110, June 2022, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, January 2023, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, May 2023, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, September 2023, . Appendix A. Detailed IEV Architecture and Mathematical Model This appendix preserves detailed source-derived technical material underlying the abstract protocol model in the main body. It is non- normative unless an explicit profile in the main body incorporates a requirement by reference. title: "INTERIM EFFECTUATION VALIDATOR (IEV)" subtitle: "Core Embodiment, Cross-Embodiment Implementation, Operational Workflow, and Hardened Mathematical Model" author: "Technical drafting compilation" date: "1 October 2026" geometry: margin=22mm fontsize: 10pt linestretch: 1.08 papersize: a4 header-includes: Das Expires 4 April 2027 [Page 40] Internet-Draft Earned Authority: Interim Validation October 2026 \usepackage{amsmath,amssymb,mathtools} \usepackage{microtype} \usepackage{booktabs,longtable,array} \usepackage{enumitem} \usepackage{fancyhdr} \usepackage{listings} \usepackage{xcolor} \lstset{basicstyle=\ttfamily\scriptsize,breaklines=true,breakatwhitespace=false,columns=fullflexible,keepspaces=true,showstringspaces=false,frame=single} \pagestyle{fancy} \fancyhf{} \fancyhead[L]{Interim Effectuation Validator (IEV)} \fancyhead[R]{Revised Mathematical Edition} \fancyfoot[C]{\thepage} \setlength{\headheight}{14pt} \setlist{nosep,leftmargin=} * | A.1. Document Structure This document combines three coordinated technical parts concerning an Interim Effectuation Validator (IEV): 1. Part I - Core Interim Effectuation Validator Embodiment: defines the IEV, its protected inter-phase position, evidence intake, independent validation, continuation decision, escalation, and representative implementations. 2. Part II - Cross-Embodiment Technical Implementation: specifies how the IEV is concretely inserted into other compatible embodiments, including protected state, authenticated interfaces, continuation instructions, cryptographic missing material, hardware latches, software/kernel enforcement, network, transaction, SEND, payment, robotics, telecom, accelerator, model-state, update, multi-destination, and quorum implementations. 3. Part III - Step-by-Step Pseudocode / Operational Workflow: gives a procedural implementation from Candidate Act intake through Phase 0, receipt generation, IEV validation, continuation authority, Finality Sink verification, multi-phase repetition, human escalation, automated remediation, reconciliation, crash recovery, replay protection, anti-bypass, and final receipt generation. The mathematical notation is normalized throughout this document. Unless expressly stated otherwise, a symbol retains the same meaning in all three Parts. A.2. Unified Mathematical Notation and Formal Model This section controls the mathematical notation used throughout the document. Textual workflow labels appearing later are illustrative shorthand; where there is any ambiguity, the definitions and indexed relationships in this section govern. Das Expires 4 April 2027 [Page 41] Internet-Draft Earned Authority: Interim Validation October 2026 A.2.1. A. Core objects and indices Let the effectuation process contain phases indexed by i\in\{0,1,\ldots,n\}. The following symbols are used consistently. | Symbol | Formal meaning | |---|---| | A | Candidate Act. | | \operatorname{Canon}(A) | Canonical representation of Candidate Act A. | | D_A | Stable protected digest of A, with D_A=H(\operatorname{Canon}(A)). | | P_i | Real effectuation phase i, including its authorized phase scope. | | C_i | Explicit phase- specific authority for P_i, when an explicit authority object is used. | | FS_i | Finality Sink or equivalent effect-capable boundary controlling P_i. | | R_i | Protected evidence or receipt describing the actual result of P_i. | | X_i | Expected protected result for phase i. | | O_i | Observed protected result for phase i. | | IEV_i | Interim Effectuation Validator responsible for the transition after P_i. | | S^{IEV}_i | Protected IEV state relevant to validation after phase i. | | IVIR_i | Interim Validation Input Record associated with R_i. | | V_i | IEV validation decision for phase i. | | CVI_{i+1} | Continuation Validation Instruction for proposed phase P_{i+1}. | | \epsilon_i | Permitted tolerance for a phase-i observed result. | | \mathcal{A}_i | Authorized set of acceptable observed results for phase i. | | \mathcal{E}_{\max} | Maximum authorized effectuation envelope. | | p_i | Policy epoch bound to the relevant decision or continuation state. | | r_i | Revocation epoch bound to the relevant decision or continuation state. | | q_i | Protected monotonic IEV counter. | | \sigma_i | Protected digest of IEV state, \sigma_i=H(S^{IEV}_i). | | PER_i | Protected Escalation Record for phase i. | | CR_i | Continuation Revocation Record for CVI_{i+1}. | Cryptographic concatenation is denoted by \parallel. Boolean conjunction, disjunction, and negation are denoted by \land, \lor, and \neg, respectively. A statement such as \operatorname{Pass}_i=\mathrm{true} denotes a protected Boolean decision and not a free-form textual assertion. A.2.2. B. Candidate-act binding The Candidate Act digest is defined as D_A = H\!\left(\operatorname{Canon}(A)\right). Das Expires 4 April 2027 [Page 42] Internet-Draft Earned Authority: Interim Validation October 2026 Where a phase authority C_i is used, it should be bound to at least the Candidate Act, phase identity, permitted phase scope, authorized sink or destination, freshness information, and applicable policy/ revocation state. A.2.3. C. Core inter-phase causal relationship The central IEV relationship is \boxed{ P_i \longrightarrow R_i \longrightarrow IEV_i \longrightarrow CVI_{i+1} \longrightarrow FS_{i+1} \longrightarrow P_{i+1} }. A receipt is evidence of a preceding real effect, not by itself authority for a later real effect: \boxed{ \operatorname{ReceiptExists}(R_i)=\mathrm{true} \;\not\Rightarrow\; \operatorname{Enable}(P_{i+1})=\mathrm{true} }. Ordinary continuation instead requires protected interim validation: \operatorname{Enable}(P_{i+1}) \Rightarrow \operatorname{Pass}_i=\mathrm{true}, subject to the expressly disclosed escalation, remediation, reconciliation, reduced-scope, revocation, or fail-limited paths. A.2.4. D. Effect comparison Exact equality may be expressed as O_i=X_i. A scalar tolerance may be expressed as \lvert O_i-X_i\rvert\leq\epsilon_i. For vector, structured, or non-scalar observations, a distance or domain-specific metric d_i may be used: d_i(O_i,X_i)\leq\epsilon_i. Range acceptance may be expressed as L_i\leq O_i\leq U_i. Set membership may be expressed as O_i\in\mathcal{A}_i. Das Expires 4 April 2027 [Page 43] Internet-Draft Earned Authority: Interim Validation October 2026 A predicate-set embodiment may require \bigwedge_{k=1}^{m_i} \operatorname{Pred}_{i,k}(O_i)=\mathrm{true}. A.2.5. E. Formal IEV pass predicate A non-limiting formalization is \begin{aligned} \operatorname{Pass}_i={}& \operatorname{AuthValid}(R_i) \land \operatorname{ActMatch}(R_i,D_A) \land \operatorname{PhaseMatch}(R_i,i)\\ &\land \operatorname{SinkMatch}(R_i,FS_i) \land \operatorname{DestinationMatch}(R_i) \land \operatorname{Fresh}(R_i)\\ &\land \neg\operatorname{Consumed}(R_i) \land \operatorname{EffectAcceptable}(O_i,X_i)\\ &\land \operatorname{PolicyCurrent}(p_i) \land \operatorname{RevocationClear}(r_i) \land \operatorname{WithinEnvelope}(P_{i+1},\mathcal{E}_{\max}). \end{aligned} The exact predicate set may vary by embodiment, but a protected PASS decision is distinct from a mere receipt assertion. A.2.6. F. Continuation Validation Instruction An illustrative protected continuation instruction is \begin{aligned} CVI_{i+1} =\operatorname{Protect}_{K_{IEV}}\!\Big(& D_A \parallel (i+1) \parallel H(R_i) \parallel \operatorname{Scope}(P_{i+1})\\ &\parallel \operatorname{ID}(FS_{i+1}) \parallel \operatorname{DestinationID}_{i+1} \parallel p_i\\ &\parallel r_i \parallel q_{i+1} \parallel t^{\mathrm{exp}}_{i+1} \Big). \end{aligned} Accordingly, the continuation object can be act-bound, phase-bound, receipt-bound, scope-bound, sink-bound, destination-bound, epoch- bound, counter-bound, and expiry-bound. A.2.7. G. Receipt-dependent cryptographic material A stronger cryptographic embodiment may derive next-phase material as K^{IEV}_{i+1} = \operatorname{KDF}\!\left( K^{IEV}_{root}, D_A, H(R_i), i+1, \operatorname{ID}(FS_{i+1}), q_{i+1} \right). Without an accepted phase-i result, the required IEV-controlled material is absent, sealed, or unavailable: Das Expires 4 April 2027 [Page 44] Internet-Draft Earned Authority: Interim Validation October 2026 \operatorname{Pass}_i\neq\mathrm{true} \Rightarrow K^{IEV}_{i+1}\ \text{unavailable}. In a split-authority embodiment, K^{Final}_{i+1} = \operatorname{Combine}\!\left( K^{FS}_{i+1}, K^{IEV}_{i+1} \right). A.2.8. H. Hardware-latch realization A hardware realization may use \operatorname{ENABLE}_{i+1} = \operatorname{FSValid}_{i+1} \land \bigl(L^{IEV}_{i}=\mathrm{PASS}\bigr). The latch or equivalent protected state may be implemented in hardware, firmware, protected memory, a security processor, a transaction engine, or another protected control plane. A.2.9. I. Decision domain A non-limiting decision domain is \begin{aligned} V_i\in\{&\mathrm{PASS},\ \mathrm{FAIL},\ \mathrm{HOLD},\ \mathrm{RECONCILE},\ \mathrm{REMEDIATE},\\ &\mathrm{REDUCE\_SCOPE},\ \mathrm{HUMAN\_REVIEW},\ \mathrm{TERMINATE},\ \mathrm{INDETERMINATE}\}. \end{aligned} The value \mathrm{INDETERMINATE} is not treated as equivalent to \mathrm{FAIL} or \mathrm{PASS} unless an expressly disclosed protected policy maps it to a bounded safe or fail-limited action. \newpage A.3. PART I - CORE INTERIM EFFECTUATION VALIDATOR IMPLEMENTATION PATTERN A.3.1. 1. Purpose In one embodiment, a multi-phase effectuation architecture includes an Interim Effectuation Validator positioned logically between completion or attempted completion of an earlier real effectuation phase and authorization of a later effectuation phase. Das Expires 4 April 2027 [Page 45] Internet-Draft Earned Authority: Interim Validation October 2026 The IEV provides an independent protected decision point that determines whether the preceding real effect occurred in a manner sufficiently aligned with the authorized Candidate Act, expected effect, applicable policy, protected state, and continuation conditions before the Finality Sink is permitted to produce a subsequent effect. A first real effectuation phase may therefore occur through a Finality Sink directly to an external device, destination, service, actuator, transaction rail, network endpoint, storage system, or other effect-capable target: A \rightarrow FS_0 \rightarrow P_0 After that real phase, protected evidence is returned to the IEV: P_0 \rightarrow R_0 \rightarrow IEV_0 The IEV independently evaluates the evidence and, only if required continuation predicates are satisfied, issues or establishes the protected condition needed for the next phase: R_0 \rightarrow IEV_0 \rightarrow CVI_1 \rightarrow FS_1 \rightarrow P_1 The IEV therefore need not relay the first effectuation command. It may become causally mandatory after the first real effect and before the next real effect. A.3.2. 2. Interim Effectuation Validator Definition An Interim Effectuation Validator (IEV) means one or more protected logical, software, firmware, hardware, cryptographic, transactional, network, or distributed components positioned in a causal control path between an earlier effectuation event and authorization of a later effectuation event. The IEV is configured to independently evaluate evidence associated with an earlier real effectuation before permitting, recommending, authorizing, cryptographically enabling, or otherwise causing availability of a later effectuation phase. The term is functional and non-limiting. An IEV need not be a physically separate device. An IEV may be implemented: * inside the same chip as a Finality Sink; Das Expires 4 April 2027 [Page 46] Internet-Draft Earned Authority: Interim Validation October 2026 * inside a different security island of the same chip; * inside a secure enclave, TEE, HSM, TPM-associated service, secure element, or security processor; * inside a DPU, SmartNIC, NIC, modem, baseband processor, GPU security processor, storage controller, database transaction engine, or payment controller; * inside a vehicle ECU, robotic safety controller, PLC, actuator controller, industrial controller, or dedicated safety MCU; * inside firmware, a kernel, privileged operating-system service, hypervisor, microVM, or protected broker; * inside a remote protected service or destination-side protected service; * across multiple protected components under threshold, quorum, or distributed validation; * or through another architecture providing equivalent protected interim validation. The IEV may be part of a Protected Enforcement Domain, may constitute a separate Protected Enforcement Domain, or may cooperate with one or more PEDs or Finality Sinks. A.3.3. 3. Decision Independence and Neutrality The IEV is preferably arranged so that its continuation decision cannot be arbitrarily determined, rewritten, forged, or bypassed by the component that proposed the Candidate Act or by an untrusted executor. The IEV may receive externally generated evidence. Its neutrality therefore does not mean that it ignores external information. Rather, external information affects the IEV through defined authenticated evidence interfaces and protected policy inputs, after which the IEV applies its own protected validation logic. Thus: Assertion_{Agent} \neq Validation_{IEV} and receipt existence alone does not imply continuation: ReceiptExists_i = TRUE \not\Rightarrow Enable(P_{i+1}) Das Expires 4 April 2027 [Page 47] Internet-Draft Earned Authority: Interim Validation October 2026 A preferred causal relationship is: Enable(P_{i+1}) \Rightarrow IEVPass_i=TRUE unless an expressly authorized escalation, remediation, or recovery path substitutes for ordinary continuation. Decision independence may be provided by privilege separation, process isolation, memory isolation, hardware-enforced isolation, key isolation, protected boot, secure firmware, immutable or authenticated policy, enclave protection, a separate security processor, physically separate hardware, a remote protected service, distributed threshold validation, administrative separation, or combinations thereof. A.3.4. 4. First-Phase Direct Effectuation A Candidate Act A defines or is associated with a requested complete effect and an authorized maximum envelope Envelope_{MAX}. The system first selects a bounded real phase P_0 and forms or activates a Phase-0 authority C_0 where explicit authority is used. The Phase-0 Finality Sink verifies the applicable protected conditions and causes P_0 to become real: FS_0(C_0,P_0) \rightarrow Effect_0 The first phase may travel directly from the Finality Sink to the external effect-capable target. The original effectuation command is not required to pass through the IEV before P_0. The IEV's principal role may begin when protected evidence of that real first-phase effect is generated. A.3.5. 5. Effectuation Evidence Returned to the IEV After phase P_i, evidence associated with the actual effect is delivered to the IEV. Such evidence may comprise: * an Effect Confirmation Receipt; * sink-generated receipt; * destination acknowledgement; Das Expires 4 April 2027 [Page 48] Internet-Draft Earned Authority: Interim Validation October 2026 * protected sensor measurement; * transaction identifier or payment-rail confirmation; * database commit evidence; * storage commitment; * network acknowledgement; * actuator position or motion measurement; * current, voltage, pressure, temperature, torque, speed, or other physical measurement; * device-state transition; * hardware counter; * signed telemetry; * attestation; * secure log entry; * protected interrupt; * receiver-generated receipt; * route or endpoint evidence; * quorum evidence; * or another machine-verifiable representation of the preceding effect. Let R_i represent the protected evidence associated with P_i. The receipt may originate from the Finality Sink itself, the destination, an independent observer, a protected sensor, transaction system, network element, or multiple sources. A.3.6. 6. Evidence of Where Effectuation Actually Occurred In a preferred embodiment, R_i contains or cryptographically binds information sufficient for the IEV to determine where, through what boundary, or under what protected context the earlier effect actually occurred. Das Expires 4 April 2027 [Page 49] Internet-Draft Earned Authority: Interim Validation October 2026 R_i may bind one or more of: * sink identity; * device identity; * destination or recipient identity; * route or endpoint; * account, wallet, payment rail, or settlement path; * database instance, shard, resource generation, or commit position; * storage object, namespace, media/controller identity, or durability state; * actuator, motor channel, controller, or physical device; * process, VM, container, host, or hardware measurement; * execution environment; * resource identifier; * transaction identifier; * phase identifier; * policy epoch; * revocation epoch; * nonce; * timestamp; * observed result. The IEV may therefore distinguish: Effect\ at\ AuthorizedTarget from: Effect\ at\ SubstituteTarget although both may superficially report success. Das Expires 4 April 2027 [Page 50] Internet-Draft Earned Authority: Interim Validation October 2026 A.3.7. 7. Independent Validation of the Earlier Phase The IEV independently validates the earlier phase evidence. A general protected operation may be written: V_i = V_{IEV}(R_i,A,P_i,S^{IEV}_i) The IEV may verify: VerifyAuth(R_i),\quad MatchAct(R_i,D_A),\quad MatchPhase(R_i,P_i) MatchSink(R_i),\quad MatchDestination(R_i),\quad MatchDevice(R_i) Fresh(R_i),\quad NotReplayed(R_i),\quad PolicyCurrent,\quad RevocationClear and may additionally verify observed effect, current protected state, risk, taint, provenance, receipt quality, authorized envelope, next- phase scope, required approvals, and other domain-specific predicates. A generalized decision may be represented as: IEVDecision_i = Validate( R_i, D_A, X_i, S^{IEV}_i ) A.3.8. 8. Comparison of Expected and Actual Effect The IEV may compare the expected effect X_i with the protected observed effect O_i. For exact systems: O_i=X_i may be required. For tolerance-based systems: d(O_i,X_i)\le \epsilon_i may be accepted. For range-based systems: L_i \le O_i \le U_i may be required. Das Expires 4 April 2027 [Page 51] Internet-Draft Earned Authority: Interim Validation October 2026 For set-based systems: O_i\in\mathcal{A}_i may be sufficient. For predicate-based systems: \bigwedge_{j=1}^{k} Pred_j(O_i)=TRUE may define acceptance. Accordingly, the IEV need not merely determine that "something happened." It may independently determine whether the correct bounded consequence occurred at the correct place, through the correct effect-capable boundary, within the correct scope, and under the correct protected conditions. A.3.9. 9. Successful Interim Validation If the preceding effect satisfies the required conditions: IEVDecision_i=PASS then the IEV may produce or establish a Continuation Validation Instruction for the next phase: CVI_{i+1} The CVI may be implemented as: * signed instruction; * MAC-protected instruction; * protected state transition; * continuation capability or non-bearer authority; * key, key share, or key-unsealing condition; * transaction-state transition; * commit permission; * network permit; * actuator enablement; Das Expires 4 April 2027 [Page 52] Internet-Draft Earned Authority: Interim Validation October 2026 * register value; * hardware latch state; * policy-state transition; * cryptographic proof; * destination-local permission; * or equivalent technical continuation condition. A.3.10. 10. Binding the Continuation Instruction to the Verified Prior Effect A strong embodiment binds the continuation instruction to the Candidate Act, prior receipt, next phase, next sink, and current protected state. For example: CVI_{i+1} = Protect_{K_{IEV}} \left( D_A \parallel (i+1) \parallel H(R_i) \parallel Scope(P_{i+1}) \parallel Sink_{i+1} \parallel PE \parallel Counter_{IEV} \parallel Expiry \right) Thus: Valid(R_i) \land IEVPass_i \rightarrow CVI_{i+1} \rightarrow FS_{i+1} \rightarrow P_{i+1} while: IEVPass_i=FALSE \rightarrow \neg CVI_{i+1} unless an expressly authorized alternate escalation or remediation path is completed. A.3.11. 11. Finality Sink Dependence on the IEV The later Finality Sink may be configured so that the next phase is technically unavailable without the IEV's accepted result. For example: Enable(P_{i+1}) = Valid(CVI_{i+1}) \land CurrentStateValid \land WithinEnvelope(P_{i+1}) Das Expires 4 April 2027 [Page 53] Internet-Draft Earned Authority: Interim Validation October 2026 The Finality Sink therefore does not need to trust a statement from the proposing agent that the preceding phase succeeded. It verifies protected IEV output or protected state established by the IEV. The architecture creates the causal sequence: RealEffect_i \rightarrow IndependentInterimValidation_i \rightarrow RealEffect_{i+1} A.3.12. 12. Multi-Phase Interim Validation The same process may be repeated for any number of phases: P_0 \rightarrow R_0 \rightarrow IEV_0 \rightarrow CVI_1 \rightarrow P_1 \rightarrow R_1 \rightarrow IEV_1 \rightarrow CVI_2 \rightarrow \cdots \rightarrow P_n The same physical IEV may validate every phase, or distinct validators may be used: IEV_0,IEV_1,\ldots,IEV_{n-1} A.3.13. 13. Misalignment Detection The IEV may determine that the earlier phase does not sufficiently match the authorized or expected result. Examples include: * wrong recipient or endpoint; * wrong sink or device; * wrong actuator or route; * wrong amount, file, object, or resource; * excessive or insufficient physical movement; * unexpected latency or altered payload; * incorrect transaction state; * stale policy epoch or stale receipt; * invalid signature or missing attestation; * sensor disagreement; Das Expires 4 April 2027 [Page 54] Internet-Draft Earned Authority: Interim Validation October 2026 * route substitution; * unexpected taint or provenance; * unauthorized intermediary; * excessive risk; * partial failure; * or another protected deviation. Let: Misalignment_i=TRUE When misalignment is detected, the next phase is not automatically released. A.3.14. 14. Human Escalation Following Misalignment One response path is: Misalignment_i \rightarrow ProtectedHumanReview The IEV may prepare a protected escalation record describing the intended effect, actual observed effect, deviation, receipt, sink, destination, device, risk, proposed next phase, remediation options, and relevant protected context. The human may: * authorize continuation; * authorize reduced scope; * require another trial; * change an authorized destination where policy permits; * deny continuation; * require rollback or compensation; * terminate the act; * or escalate to another protected authority. Das Expires 4 April 2027 [Page 55] Internet-Draft Earned Authority: Interim Validation October 2026 A human override should preferably be separately authenticated and bound to the observed evidence and requested continuation scope. A.3.15. 15. Automated Error-Catcher / Remediation Path Misalignment need not always require human intervention. The IEV may send the condition to an Automated Error-Correction or Escalation Controller. The controller may propose: * evidence re-query; * stronger attestation; * bounded retry; * reduced next-phase scope; * alternate authorized sink; * rollback; * compensation; * reconciliation; * quarantine; * a new bounded trial; * fail-limited mode; * or protected human review. The automated controller need not itself receive unrestricted authority. Its proposed remediation may return to the IEV for validation before a bounded remediation authority is issued. A generalized IEV decision set may be: \begin{aligned} \operatorname{IEVDecision}_i\in\{&\mathrm{PASS},\ \mathrm{FAIL},\ \mathrm{HOLD},\ \mathrm{RETRY},\ \mathrm{RECONCILE},\\ &\mathrm{ESCALATE},\ \mathrm{HUMAN\_REVIEW},\ \mathrm{REDUCE\_SCOPE},\ \mathrm{TERMINATE}\}. \end{aligned} Das Expires 4 April 2027 [Page 56] Internet-Draft Earned Authority: Interim Validation October 2026 A.3.16. 16. Indeterminate Result If the IEV cannot independently establish whether the preceding phase occurred correctly: IEVDecision_i=INDETERMINATE then the next phase remains unavailable. The system may obtain additional sink evidence, destination state, protected logs, idempotency state, sensor evidence, transaction status, replica evidence, quorum evidence, trusted time, hardware counters, or other reconciliation inputs. No broader effect need be released until the indeterminate state is resolved under protected policy. A.3.17. 17. Protected Middle Decision Plane The IEV may form a protected middle decision plane: \begin{aligned} \mathrm{Application/Agent} &\rightarrow FS_i \rightarrow \operatorname{RealEffect}_i \rightarrow R_i \rightarrow IEV_i\\ &\rightarrow CVI_{i+1} \rightarrow FS_{i+1} \rightarrow \operatorname{RealEffect}_{i+1}. \end{aligned} The IEV may be positioned locally, remotely, on-chip, off-chip, within the same physical component, or across multiple protected components. The controlling concept is the protected causal position between evidence of one real effectuation phase and authority for the next phase. A.3.18. 18. On-Chip IMPLEMENTATION PATTERN In one embodiment, the IEV resides inside the same SoC as the executor or Finality Sink but within a separate protected security domain. A representative chain is: \begin{aligned} \mathrm{ApplicationCPU} &\rightarrow \mathrm{HardwareFS} \rightarrow P_i \rightarrow \mathrm{ProtectedCompletionState}\\ &\rightarrow \mathrm{OnChipIEV} \rightarrow CVI_{i+1} \rightarrow \mathrm{HardwareFS} \rightarrow P_{i+1}. \end{aligned} Das Expires 4 April 2027 [Page 57] Internet-Draft Earned Authority: Interim Validation October 2026 The IEV may have independent key storage, protected SRAM, policy state, monotonic counters, validation logic, secure boot measurement, and receipt-verification logic. A.3.19. 19. Physically Separate IEV IMPLEMENTATION PATTERN The IEV may instead reside in another device or protected service: Device_A \rightarrow P_i \rightarrow Device_B \rightarrow R_i \rightarrow IndependentValidator_C \rightarrow CVI_{i+1} \rightarrow FS_A Such separation may provide administrative, hardware, manufacturer, jurisdictional, or operational independence. A.3.20. 20. SEND / Communication Example An AI agent proposes sending a sensitive file. Phase 0 causes a real bounded trailer or protected pre-release object to reach the intended recipient. The recipient generates R_0 confirming the actual endpoint, recipient, trailer digest, and relevant path state. The receipt is not used directly by the agent to release the full file. Instead: R_0 \rightarrow IEV_0 The IEV verifies recipient, endpoint, trailer digest, message binding, route, freshness, receipt authenticity, policy, and expected destination state. If all required conditions match: IEV_0\rightarrow CVI_1 The Finality Sink verifies CVI_1 and only then releases the remaining payload or decryption key. If the recipient or endpoint differs from the authorized destination, the IEV may block, reduce scope, reconcile, or route the matter to protected human review. A.3.21. 21. Payment Example A Candidate Payment Act requests transfer of a larger authorized amount. Das Expires 4 April 2027 [Page 58] Internet-Draft Earned Authority: Interim Validation October 2026 The Finality Sink first performs a bounded real verification transfer, reservation, hold, or other rail-supported bounded financial effect. The payment infrastructure returns R_0. The IEV independently verifies payer, beneficiary, account, rail, bounded amount, asset/ currency, transaction identifier, settlement/hold state, policy, and receipt authenticity. Only after successful validation does the IEV provide CVI_1 or equivalent continuation material to the payment Finality Sink. A mismatch may cause: HOLD,\quad HUMAN\_REVIEW,\quad RECONCILE,\quad REDUCE\_SCOPE,\quad or\quad TERMINATE rather than automatic broader payment. A.3.22. 22. Hardware Actuator Example Suppose the requested total movement is: 90^{\circ} The first real phase permits: 5^{\circ} A protected sensor reports an observed movement such as: O_0=4.98^{\circ} The IEV checks: |4.98^{\circ}-5^{\circ}|\le\epsilon_0 and additionally verifies actuator identity, sensor identity, fault state, nonce, time window, policy, and applicable safety state. If valid, the IEV issues CVI_1, allowing the hardware Finality Sink to release the next movement envelope. The sensor does not directly authorize the remaining movement; the IEV independently interprets the protected sensor evidence. Das Expires 4 April 2027 [Page 59] Internet-Draft Earned Authority: Interim Validation October 2026 A.3.23. 23. Multiple Evidence Sources The IEV may require multiple evidence sources, for example: R_i^{Sink},\quad R_i^{Destination},\quad R_i^{Sensor},\quad R_i^{Network} Continuation may require conjunction: \bigwedge_{j=1}^{m} Valid(R_i^j)=TRUE or a threshold/quorum rule: \sum_{j=1}^{n} Valid(R_i^j)\ge m This may prevent a single compromised observer from automatically causing progression. A.3.24. 24. Logical Distinction Without Physical Separation Physical separation is not required. A single chip, processor, controller, or service may implement both IEV and Finality Sink functions provided protected state preserves the causal separation between: 1. effectuation; 2. observation; 3. interim validation; and 4. continuation authorization. Thus: PhysicalComponent_{IEV}=PhysicalComponent_{FS} may be permitted while the protected decision functions remain logically distinct. A.3.25. 25. Anti-Bypass Requirement Where interim validation is mandatory, the next phase must not remain available through an alternate path that ignores the IEV. Das Expires 4 April 2027 [Page 60] Internet-Draft Earned Authority: Interim Validation October 2026 Equivalent continuation paths may therefore require an IEV-issued instruction, IEV-controlled state, IEV-derived key/share, IEV signature, IEV counter transition, protected latch, threshold participation, or an equivalent protected condition. If an act-equivalent alternate path can cause P_{i+1} without equivalent interim validation, that path must be disabled, mediated, capability-restricted, cryptographically locked, hardware-gated, transaction-gated, or subjected to corresponding protected validation. A.3.26. 26. Required Core Invariants Invariant 1. At least one earlier real effectuation phase occurs or is attempted through an effect-capable boundary. Invariant 2. Evidence describing the actual earlier effect is made available to an IEV. Invariant 3. The IEV evaluates that evidence independently of a mere success assertion by the Candidate Act source. Invariant 4. A required later phase remains unavailable until the IEV accepts the earlier effect or an explicitly authorized escalation/remediation path completes. Invariant 5. The IEV may be software, firmware, hardware, on-chip, off-chip, local, remote, centralized, distributed, or combined with another protected component. Invariant 6. Mismatch, failure, uncertainty, or policy deviation may block progression, reduce scope, invoke remediation, enter reconciliation, or invoke protected human escalation. Invariant 7. Physical placement does not define the architecture; the controlling property is the protected causal position of the IEV between evidence of one real effectuation phase and authority for a subsequent phase. A.3.27. 27. Central Technical Statement The embodiment may be summarized as: \boxed{ \begin{aligned} \operatorname{RealEffect}_i &\rightarrow \operatorname{ProtectedEvidence}_i \rightarrow \operatorname{IndependentIEVValidation}_i\\ &\rightarrow \operatorname{ContinuationAuthority}_{i+1} \rightarrow FS_{i+1} \rightarrow \operatorname{RealEffect}_{i+1} \end{aligned} } Das Expires 4 April 2027 [Page 61] Internet-Draft Earned Authority: Interim Validation October 2026 The IEV operates as a protected inter-phase judgment boundary. It does not itself need to perform the external effect. It independently determines whether evidence generated by an earlier real effect is sufficiently aligned with the authorized act and continuation requirements, and only thereafter permits the Finality Sink to produce the next consequential effect. \newpage A.4. PART II - CROSS-IMPLEMENTATION PATTERN TECHNICAL IMPLEMENTATION OF THE IEV A.4.1. 28. Applicability to Other Embodiments The IEV architecture may be incorporated into any compatible single- phase, two-phase, multi-phase, software, hardware, network, transaction, communication, payment, storage, database, cloud, AI- tool, credential, data-release, robotic, vehicular, industrial, telecom, radio, satellite, accelerator, model-state, software-update, distributed, multi-destination, quorum, reconciliation, or recovery embodiment in which a later consequential phase can be made dependent on protected evaluation of evidence from an earlier phase. Where an embodiment includes effectuation events or protected transitions P_0,P_1,\ldots,P_n, an IEV may be inserted between selected phases: P_i \rightarrow R_i \rightarrow IEV_i \rightarrow CVI_{i+1} \rightarrow FS_{i+1} \rightarrow P_{i+1} The IEV need not replace an existing Finality Sink, PED, receipt verifier, hardware gate, policy engine, transaction controller, or effect observer. It may be inserted as an additional protected validation layer in the continuation path. A.4.2. 29. Technical Insertion Rule For an existing embodiment having: P_i \rightarrow R_i \rightarrow ContinuationAuthority_{i+1} \rightarrow P_{i+1} an IEV-enabled version may replace the direct transition with: P_i \rightarrow R_i \rightarrow IEV_i \rightarrow ValidatedContinuationState_i \rightarrow ContinuationAuthority_{i+1} \rightarrow P_{i+1} Das Expires 4 April 2027 [Page 62] Internet-Draft Earned Authority: Interim Validation October 2026 The IEV therefore becomes a required consumer of phase-i evidence. A receipt merely existing is insufficient: ReceiptExists_i=TRUE The protected continuation condition may instead require: ReceiptValid_i \land IEVPass_i =TRUE before broader effectuation is technically enabled. A.4.3. 30. Concrete IEV Input Interface Each effectuation phase may produce a structured Interim Validation Input Record: IVIR_i A non-limiting structure is: \begin{aligned} IVIR_i=\{&D_A,\ PhaseID_i,\ H(C_i),\ X_i,\ O_i,\\ &SinkID_i,\ DestinationID_i,\ ObserverID_i,\\ &ResourceID_i,\ TransactionID_i,\ Nonce_i,\\ &Counter_i,\ PE_i,\ RE_i,\ ResultCode_i,\\ &H(R_i),\ Timestamp_i\}. \end{aligned} The IVIR may be formed from an ECR, completion receipt, sensor receipt, payment receipt, database commit receipt, network receipt, storage receipt, hardware event, or equivalent protected evidence. It may be authenticated using digital signature, MAC, attestation, authenticated hardware mailbox, protected shared memory, secure interrupt, secure RPC, measured IPC channel, hardware register, transaction record, or equivalent integrity-protected transport. The IEV rejects an unauthenticated or structurally invalid IVIR. A.4.4. 31. Protected IEV State The IEV may maintain protected state S^{IEV}_i containing one or more of: * D_A; * Envelope_{MAX}; * current phase identifier; Das Expires 4 April 2027 [Page 63] Internet-Draft Earned Authority: Interim Validation October 2026 * expected prior phase; * expected sink, destination, and observer; * acceptable result or tolerance; * minimum receipt quality; * policy and revocation epochs; * allowed continuation scope; * permitted phase sequence; * receipt-consumption state; * retry state; * human-escalation state; * reconciliation state; * taint and provenance requirements; * current risk state; * monotonic counter; * continuation-authority status. The state may reside in protected process memory, kernel-protected memory, enclave memory, secure-element memory, HSM state, TPM NV storage, protected SRAM, secure flash, FPGA registers, ASIC state, hardware counters, protected database state, replicated consensus state, or other tamper-resistant/access-controlled storage. The Candidate Act source preferably lacks arbitrary write authority to S^{IEV}_i. A.4.5. 32. Protected IEV Validation Algorithm A concrete validation operation may comprise: 1. authenticate the receipt source; 2. confirm Candidate Act binding; 3. confirm the phase identifier; Das Expires 4 April 2027 [Page 64] Internet-Draft Earned Authority: Interim Validation October 2026 4. confirm prior phase authority where applicable; 5. verify sink identity; 6. verify destination or recipient identity; 7. verify resource identity; 8. verify observer identity where applicable; 9. verify receipt freshness; 10. verify nonce/counter state; 11. verify absence of replay; 12. compare expected and observed effects; 13. verify policy epoch; 14. verify revocation state; 15. verify risk, taint, and provenance predicates; 16. determine whether the requested next phase remains inside Envelope_{MAX}; 17. determine whether additional human or threshold approval is required; 18. atomically record the validation result. For example: \begin{aligned} IEVPass_i ={}& AuthValid(R_i) \land ActMatch(R_i,D_A) \land PhaseMatch(R_i,i)\\ &\land SinkMatch(R_i) \land DestinationMatch(R_i) \land Fresh(R_i)\\ &\land NotConsumed(R_i) \land EffectAcceptable(O_i,X_i)\\ &\land PolicyCurrent \land RevocationClear \land WithinEnvelope(P_{i+1}). \end{aligned} Only if all required predicates evaluate to an acceptable protected state does ordinary continuation proceed. Das Expires 4 April 2027 [Page 65] Internet-Draft Earned Authority: Interim Validation October 2026 A.4.6. 33. Exact, Range, Tolerance, Set, and Predicate Validation A.4.6.1. Exact comparison O_i=X_i A.4.6.2. Tolerance comparison |O_i-X_i|\le\epsilon_i or, for structured effects: d(O_i,X_i)\le\epsilon_i A.4.6.3. Range comparison L_i\le O_i\le U_i A.4.6.4. Set-membership comparison O_i\in\mathcal{A}_i A.4.6.5. Predicate-based comparison \bigwedge_{j=1}^{k}Pred_j(O_i)=TRUE These alternatives permit the IEV to operate across digital, transactional, network, and physical systems. A.4.7. 34. Continuation Validation Instruction After successful evaluation, the IEV may create: CVI_{i+1} A representative structure is: \begin{aligned} CVI_{i+1}=Protect_{K_{IEV}}(&D_A \parallel (i+1) \parallel H(R_i) \parallel Scope(P_{i+1})\\ &\parallel Sink_{i+1} \parallel Destination_{i+1} \parallel PE\\ &\parallel Counter_{IEV} \parallel Expiry). \end{aligned} The CVI may therefore bind the original act, prior verified effect, next phase, next scope, next sink, next destination, protected epoch, validator counter, and validity period. Das Expires 4 April 2027 [Page 66] Internet-Draft Earned Authority: Interim Validation October 2026 A.4.8. 35. Finality Sink Verification of IEV Output The next Finality Sink may independently verify: Verify_{IEV}(CVI_{i+1}) MatchAct(CVI_{i+1},D_A) MatchReceipt(CVI_{i+1},H(R_i)) MatchPhase(CVI_{i+1},i+1) MatchScope(CVI_{i+1},P_{i+1}) MatchSink(CVI_{i+1},FS_{i+1}) and may additionally verify destination, policy epoch, freshness, expiry, counter, consumption state, and protected local state. A CVI for one Candidate Act, phase, destination, sink, scope, or epoch therefore need not be valid for another. A.4.9. 36. Cryptographically Missing Continuation Material A stronger implementation makes the IEV technically indispensable by placing part of the next-phase execution material under IEV control. For example: K^{IEV}_{i+1} = KDF\left( K^{IEV}_{root}, D_A, H(R_i), i+1, Sink_{i+1}, Counter_{IEV} \right) The Finality Sink may require that material to authenticate, decrypt, unwrap, sign, schedule, commit, transmit, or actuate the next phase. Without successful IEV validation: IEVPass_i\neq TRUE \Rightarrow K^{IEV}_{i+1}\ unavailable The next phase may therefore be cryptographically non-completable rather than merely policy-disallowed. A.4.10. 37. Split-Key Implementation The Finality Sink may hold its own protected share K^{FS}_{i+1} while the IEV controls K^{IEV}_{i+1}. The usable next-phase authority may require: Das Expires 4 April 2027 [Page 67] Internet-Draft Earned Authority: Interim Validation October 2026 K^{Final}_{i+1} = Combine\left(K^{FS}_{i+1},K^{IEV}_{i+1}\right) Thus: K^{FS}_{i+1}\ alone \not\Rightarrow Enable(P_{i+1}) and: K^{IEV}_{i+1}\ alone \not\Rightarrow Effectuate(P_{i+1}) Both protected conditions are required. A.4.11. 38. Hardware-Latch Implementation Instead of or in addition to cryptographic key material, the IEV may control protected hardware state L_{IEV}. A next-phase enable condition may be: ENABLE_{i+1} = FSValid_{i+1} \land (L_{IEV}=PASS_i) The latch may reside in FPGA logic, ASIC logic, secure MCU, safety controller, motor controller, NIC, SmartNIC, DPU, storage controller, memory controller, GPU security processor, modem, baseband, ECU, PLC, actuator controller, or another hardware component. Ordinary application software preferably cannot directly write the protected latch. A.4.12. 39. Secure-Mailbox Implementation Where the IEV and Finality Sink reside in separate hardware or trust domains, the IEV may place CVI_{i+1} into an authenticated secure mailbox: Mailbox_{IEV\rightarrow FS} The mailbox may enforce authenticated sender identity, sequence numbers, monotonic counters, one-time consumption, fixed destination, integrity protection, confidentiality where required, interrupt binding, and acknowledgement. The Finality Sink accepts continuation only from the protected IEV mailbox or an equivalent authenticated source. Das Expires 4 April 2027 [Page 68] Internet-Draft Earned Authority: Interim Validation October 2026 A.4.13. 40. Protected Shared-Memory Implementation Where IEV and Finality Sink are on the same chip or host, protected memory may hold: ContinuationState[i+1] A representative access model is: Write(ContinuationState): IEV\ only ReadConsume(ContinuationState): FS\ only The AI/application may have neither permission. This may be enforced using MMU/MPU protections, page-table isolation, enclave memory, hypervisor mappings, IOMMU, hardware ACLs, secure SRAM, bus firewalls, capability-tagged memory, or equivalent mechanisms. A.4.14. 41. Kernel / Operating-System Implementation A software PED implementation may operate as follows: 1. an agent issues a bounded Candidate Act; 2. a kernel/service Finality Sink permits P_0; 3. an authenticated result event is delivered to a privileged IEV process; 4. the IEV validates the receipt; 5. the IEV updates protected continuation state; 6. a kernel hook permits P_1 only if that state is valid. A representative chain is: \begin{aligned} \mathrm{Agent} &\rightarrow \mathrm{FinalityGate} \rightarrow P_i \rightarrow \mathrm{Receipt/Event} \rightarrow \mathrm{PrivilegedIEV}\\ &\rightarrow \mathrm{ProtectedContinuationState} \rightarrow \mathrm{Kernel/ NetworkGate} \rightarrow P_{i+1}. \end{aligned} The application cannot directly alter the IEV state. Das Expires 4 April 2027 [Page 69] Internet-Draft Earned Authority: Interim Validation October 2026 A.4.15. 42. Network Implementation A network embodiment may use: \begin{aligned} \mathrm{Application} &\rightarrow \mathrm{EgressFS} \rightarrow \operatorname{BoundedNetworkEffect}_i \rightarrow R_i \rightarrow IEV_i\\ &\rightarrow CVI_{i+1} \rightarrow \mathrm{EgressFS} \rightarrow \operatorname{BroaderTransmission}_{i+1}. \end{aligned} The network Finality Sink may be a host proxy, API gateway, service mesh, firewall, NIC, SmartNIC, DPU, router, switch, telecom gateway, or remote service. The second-phase traffic may carry an IEV-issued authenticator, reference to CVI_{i+1}, or a phase-specific key derived from IEV approval. A.4.16. 43. Database / Transaction Implementation For database or transaction embodiments: TX_i \rightarrow COMMIT_i \rightarrow CommitReceipt_i \rightarrow IEV_i \rightarrow PromotionPermit_{i+1} \rightarrow TX_{i+1} The database may store protected transaction metadata such as: IEV\_APPROVED_{i+1}=TRUE A trigger, transaction manager, commit hook, WAL controller, database policy module, or native state machine may refuse the next commit unless the protected validation state is present. A.4.17. 44. Storage Implementation A storage controller may first persist Object_i in a restricted namespace and generate a durable-state receipt. The IEV may verify object digest, storage target, media/controller identity, namespace, replication state, durability state, destination, and policy. The IEV then authorizes promotion into a broader visible state or key release: RestrictedStorage_i \rightarrow R_i \rightarrow IEV_i \rightarrow PromotionAuthority_{i+1} \rightarrow VisibleStorage_{i+1} Das Expires 4 April 2027 [Page 70] Internet-Draft Earned Authority: Interim Validation October 2026 A.4.18. 45. Communication / SEND Implementation For SEND: Trailer_i \rightarrow Recipient \rightarrow R_i \rightarrow IEV_i \rightarrow CVI^{SEND}_{i+1} \rightarrow MessageFS \rightarrow FullOrBroaderMessage_{i+1} The IEV may verify exact recipient, service identity, device identity, endpoint, trailer digest, message digest binding, route, receipt freshness, policy, and replay state. A receipt from another recipient or endpoint does not satisfy the continuation condition for the authorized target. A.4.19. 46. Payment Implementation For payment: BoundedPayment_i \rightarrow PaymentReceipt_i \rightarrow IEV_i \rightarrow SettlementPermit_{i+1} \rightarrow PaymentFS \rightarrow Payment_{i+1} The IEV may verify payer, beneficiary, account, wallet, asset, currency, amount, rail, transaction identifier, hold/reservation state, settlement state, risk state, policy, and receipt authenticity. The next payment stage may require an IEV-generated signature share, state transition, permit, or key share. A.4.20. 47. Robotic / Vehicle / Actuator Implementation For physical systems: Motion_i \rightarrow SensorEvidence_i \rightarrow IEV_i \rightarrow MotionPermit_{i+1} \rightarrow ActuatorFS \rightarrow Motion_{i+1} The IEV may evaluate position, velocity, acceleration, current, torque, pressure, temperature, fault state, location, geofence, obstacle state, sensor agreement, controller identity, and safety envelope. The IEV may be implemented by a dedicated safety MCU or security island separate from the autonomous planning controller. Das Expires 4 April 2027 [Page 71] Internet-Draft Earned Authority: Interim Validation October 2026 A.4.21. 48. Telecom / Radio / Satellite Implementation For telecommunications or radio: \begin{aligned} \operatorname{BoundedTransmission}_i &\rightarrow \operatorname{NetworkRFReceipt}_i \rightarrow IEV_i \rightarrow \operatorname{TransmissionPermit}_{i+1}\\ &\rightarrow \mathrm{RF/ NetworkFS} \rightarrow \operatorname{BroaderTransmission}_{i+1}. \end{aligned} The IEV may validate carrier/band, frequency, channel, beam, power, duration, cell, destination, route, bearer, network slice, satellite/ gateway identity, receiver acknowledgement, interference state, and applicable safety conditions. The next transmission key, scheduler permit, bearer expansion, or RF authority may remain unavailable before IEV approval. A.4.22. 49. GPU / Accelerator Implementation For accelerator systems: ComputePhase_i \rightarrow DeviceReceipt_i \rightarrow IEV_i \rightarrow ReleasePermit_{i+1} \rightarrow GPU/DPU/MemoryFS \rightarrow Effect_{i+1} The IEV may validate accelerator identity, measured firmware, model/ workload digest, memory region, command queue, device counter, output digest, protected execution state, DMA destination, and allowed egress. Successful computation alone need not permit broader external data release, tool invocation, SEND, payment, or another consequential effect. A.4.23. 50. AI Tool-Use Implementation For tool use: ToolEffect_i \rightarrow ToolReceipt_i \rightarrow IEV_i \rightarrow ToolContinuationPermit_{i+1} \rightarrow ToolFS \rightarrow NextToolEffect_{i+1} The IEV may independently verify tool identity, method, arguments, resource, account, destination, actual result, side-effect scope, authorization envelope, and next requested tool operation. The AI cannot self-certify that the prior tool call was successful. Das Expires 4 April 2027 [Page 72] Internet-Draft Earned Authority: Interim Validation October 2026 A.4.24. 51. Model-State / Memory Update Implementation For model memory, vector stores, or persistent AI state: ProvisionalState_i \rightarrow StateReceipt_i \rightarrow IEV_i \rightarrow PromotionPermit_{i+1} \rightarrow StateFS \rightarrow CommittedState_{i+1} The IEV may validate namespace, model/user identity, provenance, taint, vector/object identifiers, write-set digest, retention policy, conflict state, and resulting storage state. A.4.25. 52. Software / Firmware Update Implementation For updates: CanaryActivation_i \rightarrow HealthReceipt_i \rightarrow IEV_i \rightarrow RolloutPermit_{i+1} \rightarrow UpdateFS \rightarrow BroaderActivation_{i+1} The IEV may verify artifact digest, signer, device/host cohort, boot state, error rate, crash state, health checks, compatibility state, rollback availability, security measurements, and policy. A.4.26. 53. Multi-Destination Implementation Where phase i affects destinations D_1,D_2,\ldots,D_n, the IEV may receive: R_i^1,R_i^2,\ldots,R_i^n Continuation may require all: \bigwedge_{j=1}^{n}Valid(R_i^j)=TRUE or a quorum: \sum_{j=1}^{n}Valid(R_i^j)\ge m or a role-weighted/critical-node rule. The IEV may then determine which destinations may proceed. A failed destination need not cause authority to be granted to another destination unless protected policy permits it. Das Expires 4 April 2027 [Page 73] Internet-Draft Earned Authority: Interim Validation October 2026 A.4.27. 54. Quorum / Consensus Implementation The IEV itself may be distributed. Let: IEV^1,IEV^2,\ldots,IEV^n be independent validator instances. Continuation may require: \sum_{j=1}^{n}Pass(IEV^j)\ge m The resulting continuation instruction may be threshold-signed, multi-signed, consensus committed, Merkle committed, replicated, or otherwise collectively authenticated. No single validator need control continuation. A.4.28. 55. Human Escalation Implementation When: IEVDecision_i=ESCALATE or: IEVDecision_i=HUMAN\_REVIEW the IEV may generate a Protected Escalation Record: PER_i For example: \begin{aligned} PER_i=Protect(&D_A, H(R_i), X_i, O_i, Deviation_i,\\ &RequestedNextPhase_i, Risk_i, PE_i). \end{aligned} The protected human interface displays relevant evidence. A human response H_i may be bound to both H(R_i) and H(PER_i) before becoming effective. The human thereby approves the actual observed deviation and proposed continuation rather than an unrelated generic request. Das Expires 4 April 2027 [Page 74] Internet-Draft Earned Authority: Interim Validation October 2026 A.4.29. 56. Automated Error-Catcher Implementation An automated remediation component may receive PER_i or an equivalent protected error record and propose: \begin{aligned} \operatorname{Action}_i\in\{&\mathrm{REQUERY},\ \mathrm{REATTEST},\ \mathrm{RETRY},\ \mathrm{REDUCE},\ \mathrm{ROLLBACK},\\ &\mathrm{COMPENSATE},\ \mathrm{ALTERNATE\_SINK},\ \mathrm{QUARANTINE},\ \mathrm{HUMAN},\ \mathrm{TERMINATE}\}. \end{aligned} The error controller does not automatically receive unrestricted continuation authority. A protected sequence may be: ErrorControllerProposal \rightarrow IEV_i \rightarrow RemediationAuthority_i A.4.30. 57. Atomic Validation, Consumption, and Phase Advancement To prevent replay, successful IEV validation may atomically: Consumed(R_i)=TRUE PhaseState=i+1 CVI_{i+1}=ISSUED A representative protected transaction is: Atomic\{Consume(R_i);\ AdvancePhase();\ Issue(CVI_{i+1});\} This prevents a crash between validation and consumption from allowing the same receipt to independently authorize multiple next- phase effects. A.4.31. 58. Crash After IEV Approval If the IEV approves continuation but the Finality Sink crashes before confirming consumption, protected state may record: CVIState_{i+1}=ISSUED\_NOT\_CONFIRMED After recovery, the system queries Finality Sink consumption/effect state rather than blindly issuing a second equivalent authority. Das Expires 4 April 2027 [Page 75] Internet-Draft Earned Authority: Interim Validation October 2026 If consumption is proven, the corresponding effect is reconciled. If non-consumption is proven, protected policy may permit reuse or replacement. If unknown, the system enters an indeterminate state. A.4.32. 59. Crash During the Next Effect If CVI_{i+1} was consumed but the result of P_{i+1} is uncertain, the IEV does not simply reissue equivalent continuation authority. Instead: P_{i+1} \rightarrow Reconciliation \rightarrow R_{i+1} must establish whether the phase was effected, not effected, partially effected, rolled back, compensated, or remains indeterminate. A.4.33. 60. Anti-Substitution A receipt from a valid but different operation must not enable continuation for the current operation. For example, R_X is unacceptable for phase i if any required binding differs: D_{A_X}\neq D_A or: Sink_X\neq Sink_i or: Destination_X\neq Destination_i or: Phase_X\neq i. The receipt must therefore be contextually valid, not merely cryptographically authentic. A.4.34. 61. Anti-Bypass Implementation Where IEV validation is mandatory, all act-equivalent paths capable of causing P_{i+1} may be configured so that they lack at least one required execution condition unless the IEV has approved continuation. Das Expires 4 April 2027 [Page 76] Internet-Draft Earned Authority: Interim Validation October 2026 Examples of missing conditions include: * signing key/share; * transaction role; * decryption material; * network permit; * hardware enable; * database role; * message-send credential; * actuator key; * DMA permission; * storage promotion bit; * RF scheduler permit; * protected phase state. Thus: BypassPath_{i+1} \not\supseteq RequiredMaterial_{i+1} unless the bypass path is subjected to the same or equivalent IEV- controlled continuation process. A.4.35. 62. Concrete Cross-IMPLEMENTATION PATTERN Insertion Procedure For avoidance of doubt, an embodiment that does not expressly repeat the words Interim Effectuation Validator may incorporate the IEV by the following technical transformation: 1. Identify a real effectuation phase or bounded consequence already present in the embodiment. 2. Cause the responsible Finality Sink, effect observer, destination, transaction system, sensor, or protected component to generate authenticated evidence describing that phase. 3. Route the authenticated evidence to an IEV having protected state and policy not arbitrarily writable by the Candidate Act source. Das Expires 4 April 2027 [Page 77] Internet-Draft Earned Authority: Interim Validation October 2026 4. Cause the IEV to authenticate the evidence and compare the observed effect with the authorized and expected effect. 5. Where required conditions match, cause the IEV to generate or enable a phase-specific continuation condition. 6. Configure the next Finality Sink or effect-capable boundary to require that continuation condition before the next phase can become effective. 7. Where conditions do not match, withhold the continuation condition and invoke a protected failure, reconciliation, automated-remediation, reduced-scope, or human-escalation path. This provides a concrete technical method for incorporating the IEV into compatible embodiments without reproducing the complete validator description in every domain-specific section. A.4.36. 63. Cross-IMPLEMENTATION PATTERN Technical Invariant Where an IEV is incorporated, the architecture may satisfy: \boxed{ \begin{aligned} \operatorname{Effect}_i &\rightarrow \operatorname{AuthenticatedEvidence}_i \rightarrow \operatorname{IndependentIEVValidation}_i\\ &\rightarrow \operatorname{ProtectedContinuationCondition}_{i+1} \rightarrow FS_{i+1} \rightarrow \operatorname{Effect}_{i+1} \end{aligned} } Accordingly, the statement that an IEV may be used is not merely an abstract policy option. It may specifically mean that: 1. authenticated evidence is generated from a real preceding effect; 2. protected IEV state receives and evaluates that evidence; 3. the IEV produces a cryptographically, electronically, transactionally, or logically enforced continuation condition; and 4. the next effect-capable boundary is technically unable, or is configured not, to effectuate the protected next phase without satisfaction of that condition. \newpage A.5. PART III - STEP-BY-STEP PSEUDOCODE / OPERATIONAL WORKFLOW Das Expires 4 April 2027 [Page 78] Internet-Draft Earned Authority: Interim Validation October 2026 ALGORITHM: INTERIM_EFFECTUATION_VALIDATOR_WORKFLOW PURPOSE: Permit a first real effectuation phase. Obtain protected evidence describing what actually occurred. Independently validate that evidence in an Interim Effectuation Validator (IEV). Permit a subsequent effectuation phase only if: (a) the IEV accepts the earlier effect, or (b) an explicitly authorized escalation/remediation path permits continuation. ---------------------------------------------------------------------- INPUTS ---------------------------------------------------------------------- CandidateAct A ActDigest D_A AuthorizedMaximum Envelope_MAX PhasePlan: P_0, P_1, ... P_n ProtectedPolicy Policy PolicyEpoch PE RevocationEpoch RE ExpectedSink[i] ExpectedDestination[i] ExpectedEffect[i] AllowedTolerance[i] ApprovalMode[i]: AUTOMATIC HUMAN HYBRID PREAUTHORIZED THRESHOLD Protected IEV State S_IEV FinalitySink FS[i] Das Expires 4 April 2027 [Page 79] Internet-Draft Earned Authority: Interim Validation October 2026 EffectObserver EO[i] Optional: HumanApprovalSystem HAS AutomatedErrorController AEC ReconciliationController RC ProtectedReceiptStore PRS ---------------------------------------------------------------------- PROTECTED STATE INITIALIZATION ---------------------------------------------------------------------- S_IEV.act_digest := D_A S_IEV.maximum_envelope := Envelope_MAX S_IEV.current_phase := 0 S_IEV.policy_epoch := PE S_IEV.revocation_epoch := RE S_IEV.status := READY_FOR_PHASE_0 S_IEV.consumed_receipts := EMPTY_SET S_IEV.issued_CVI := EMPTY_SET S_IEV.retry_count := 0 S_IEV.escalation_state := NONE S_IEV.reconciliation_state := NONE ---------------------------------------------------------------------- STEP 1 - RECEIVE CANDIDATE ACT ---------------------------------------------------------------------- function RECEIVE_CANDIDATE_ACT(A): D_A := HASH(CANONICALIZE(A)) if D_A != S_IEV.act_digest: return BLOCK("Candidate Act mismatch") if A exceeds Envelope_MAX: return BLOCK("Candidate Act exceeds authorized maximum") if REVOCATION_ACTIVE(A, RE): return BLOCK("Candidate Act revoked") proceed to PHASE_0_AUTHORIZATION ---------------------------------------------------------------------- STEP 2 - AUTHORIZE FIRST REAL EFFECTUATION PHASE Das Expires 4 April 2027 [Page 80] Internet-Draft Earned Authority: Interim Validation October 2026 ---------------------------------------------------------------------- function PHASE_0_AUTHORIZATION(): P_0 := PhasePlan[0] verify: P_0 is within Envelope_MAX ExpectedSink[0] is authorized ExpectedDestination[0] is authorized Policy is current Required initial approval is satisfied if validation fails: return BLOCK create or activate Phase0Authority C_0 bind C_0 to: D_A PhaseID = 0 Scope(P_0) ExpectedSink[0] ExpectedDestination[0] PE RE nonce_0 expiry_0 send: A P_0 C_0 to: FS[0] ---------------------------------------------------------------------- STEP 3 - FINALITY SINK VERIFIES PHASE 0 ---------------------------------------------------------------------- function FINALITY_SINK_PHASE_0(A, P_0, C_0): verify: AuthorityValid(C_0) MatchAct(C_0, D_A) MatchPhase(C_0, 0) Das Expires 4 April 2027 [Page 81] Internet-Draft Earned Authority: Interim Validation October 2026 MatchScope(C_0, P_0) MatchSink(C_0, FS[0]) MatchDestination(C_0, ExpectedDestination[0]) Fresh(C_0) NotRevoked(A) if any required check fails: return BLOCK perform REAL EFFECT P_0 IMPORTANT: This is an actual effectuation. It is not merely: simulation dry-run prediction local preview or model-generated expectation. Result_0 := EFFECTUATE(P_0) obtain actual-effect evidence R_0 := GENERATE_EFFECT_RECEIPT( D_A, PhaseID=0, Result_0, ActualSink, ActualDestination, Observer, TransactionID, DeviceState, nonce_0, counter, PE, timestamp ) send R_0 to Interim Effectuation Validator ---------------------------------------------------------------------- STEP 4 - CONSTRUCT INTERIM VALIDATION INPUT RECORD ---------------------------------------------------------------------- function BUILD_IVIR(R_i): Das Expires 4 April 2027 [Page 82] Internet-Draft Earned Authority: Interim Validation October 2026 IVIR_i := { ActDigest = D_A, PhaseID = i, PhaseAuthorityDigest = HASH(C_i), ExpectedEffect = ExpectedEffect[i], ObservedEffect = EXTRACT_OBSERVED_EFFECT(R_i), SinkID = EXTRACT_SINK(R_i), DestinationID = EXTRACT_DESTINATION(R_i), ObserverID = EXTRACT_OBSERVER(R_i), ResourceID = EXTRACT_RESOURCE(R_i), TransactionID = EXTRACT_TRANSACTION(R_i), Nonce = EXTRACT_NONCE(R_i), Counter = EXTRACT_COUNTER(R_i), PolicyEpoch = EXTRACT_POLICY_EPOCH(R_i), ResultCode = EXTRACT_RESULT(R_i), ReceiptDigest = HASH(R_i), Timestamp = EXTRACT_TIME(R_i) } return IVIR_i ---------------------------------------------------------------------- STEP 5 - IEV AUTHENTICATES THE EVIDENCE ---------------------------------------------------------------------- function IEV_AUTHENTICATE(IVIR_i, R_i): if NOT VERIFY_RECEIPT_AUTHENTICITY(R_i): return FAIL_INVALID_RECEIPT if IVIR_i.ActDigest != D_A: return FAIL_ACT_SUBSTITUTION if IVIR_i.PhaseID != S_IEV.current_phase: return FAIL_WRONG_PHASE if HASH(R_i) in S_IEV.consumed_receipts: return FAIL_REPLAY if NOT FRESH(R_i): return FAIL_STALE if IVIR_i.PolicyEpoch != CURRENT_POLICY_EPOCH(): return HOLD_POLICY_CHANGED if REVOCATION_ACTIVE(A): return FAIL_REVOKED Das Expires 4 April 2027 [Page 83] Internet-Draft Earned Authority: Interim Validation October 2026 proceed to IEV_EFFECT_VALIDATION ---------------------------------------------------------------------- STEP 6 - IEV INDEPENDENTLY DETERMINES WHERE EFFECT OCCURRED ---------------------------------------------------------------------- function IEV_VALIDATE_EFFECT_LOCATION(IVIR_i): if IVIR_i.SinkID != ExpectedSink[i]: return MISALIGNMENT_WRONG_SINK if IVIR_i.DestinationID != ExpectedDestination[i]: return MISALIGNMENT_WRONG_DESTINATION if ResourceBindingRequired: if IVIR_i.ResourceID != ExpectedResource[i]: return MISALIGNMENT_WRONG_RESOURCE if ObserverBindingRequired: if IVIR_i.ObserverID not in AuthorizedObservers[i]: return MISALIGNMENT_INVALID_OBSERVER return LOCATION_VALID ---------------------------------------------------------------------- STEP 7 - IEV INDEPENDENTLY COMPARES EXPECTED EFFECT WITH ACTUAL EFFECT ---------------------------------------------------------------------- function IEV_COMPARE_EFFECT(IVIR_i): X_i := IVIR_i.ExpectedEffect O_i := IVIR_i.ObservedEffect choose comparison mode CASE EXACT: if O_i == X_i: return EFFECT_VALID else: return EFFECT_MISALIGNED CASE TOLERANCE: Das Expires 4 April 2027 [Page 84] Internet-Draft Earned Authority: Interim Validation October 2026 if DISTANCE(O_i, X_i) <= AllowedTolerance[i]: return EFFECT_VALID else: return EFFECT_MISALIGNED CASE RANGE: if LowerBound[i] <= O_i <= UpperBound[i]: return EFFECT_VALID else: return EFFECT_MISALIGNED CASE AUTHORIZED_SET: if O_i in AuthorizedResultSet[i]: return EFFECT_VALID else: return EFFECT_MISALIGNED CASE PREDICATE_SET: for each mandatory predicate p in EffectPredicates[i]: result := p(O_i) if result == FALSE: return EFFECT_MISALIGNED if result == UNKNOWN or INDETERMINATE: return EFFECT_INDETERMINATE return EFFECT_VALID ---------------------------------------------------------------------- STEP 8 - IEV CHECKS CURRENT PROTECTED CONDITIONS ---------------------------------------------------------------------- function IEV_CHECK_CURRENT_STATE(i): verify: CURRENT_POLICY_EPOCH == S_IEV.policy_epoch OR permitted revalidation completed RevocationClear == TRUE Das Expires 4 April 2027 [Page 85] Internet-Draft Earned Authority: Interim Validation October 2026 RiskState acceptable TaintState acceptable ProvenanceState acceptable ProposedNextPhase inside Envelope_MAX Current phase == i Required receipt quality satisfied Required destination state satisfied Required approval state satisfied if any mandatory predicate is FALSE: return FAIL if any mandatory predicate is UNKNOWN or INDETERMINATE: return INDETERMINATE return PASS ---------------------------------------------------------------------- STEP 9 - FORM IEV DECISION ---------------------------------------------------------------------- function IEV_DECIDE(i, R_i): AuthResult := IEV_AUTHENTICATE(IVIR_i, R_i) LocationResult := IEV_VALIDATE_EFFECT_LOCATION(IVIR_i) EffectResult := IEV_COMPARE_EFFECT(IVIR_i) StateResult := IEV_CHECK_CURRENT_STATE(i) if all required results == PASS or VALID: IEVDecision_i := PASS else if result indicates resolvable evidence uncertainty: IEVDecision_i := RECONCILE Das Expires 4 April 2027 [Page 86] Internet-Draft Earned Authority: Interim Validation October 2026 else if result indicates potentially recoverable technical error: IEVDecision_i := RETRY_OR_REMEDIATE else if protected policy requires human judgment: IEVDecision_i := HUMAN_REVIEW else if next phase may safely continue at reduced scope: IEVDecision_i := REDUCE_SCOPE else: IEVDecision_i := TERMINATE record IEVDecision_i in protected state proceed according to decision ---------------------------------------------------------------------- STEP 10A - PASS PATH ---------------------------------------------------------------------- if IEVDecision_i == PASS: NextPhase := i + 1 verify: P_(i+1) exists P_(i+1) <= Envelope_MAX atomically: mark R_i consumed advance S_IEV.current_phase from i to i+1 create continuation state create CVI_(i+1) Das Expires 4 April 2027 [Page 87] Internet-Draft Earned Authority: Interim Validation October 2026 ---------------------------------------------------------------------- STEP 10B - FORM CONTINUATION VALIDATION INSTRUCTION ---------------------------------------------------------------------- CVI_(i+1) := PROTECT_WITH_IEV_KEY({ ActDigest = D_A, PriorPhase = i, NextPhase = i+1, PriorReceipt = HASH(R_i), NextScope = Scope(P_(i+1)), NextSink = ExpectedSink[i+1], NextDestination = ExpectedDestination[i+1], PolicyEpoch = CURRENT_POLICY_EPOCH, IEVCounter = NEXT_COUNTER(), Expiry = expiry_(i+1) }) ---------------------------------------------------------------------- OPTIONAL STRONGER CRYPTOGRAPHIC IMPLEMENTATION ---------------------------------------------------------------------- K_(i+1) := KDF( K_IEV_ROOT, D_A, HASH(R_i), i+1, ExpectedSink[i+1], IEVCounter ) Without IEV PASS: K_(i+1) does not exist OR K_(i+1) remains sealed OR IEV key share remains unavailable ---------------------------------------------------------------------- OPTIONAL SPLIT-KEY IMPLEMENTATION ---------------------------------------------------------------------- K_FINAL_(i+1) := COMBINE( K_FS_(i+1), Das Expires 4 April 2027 [Page 88] Internet-Draft Earned Authority: Interim Validation October 2026 K_IEV_(i+1) ) Therefore: Finality Sink alone cannot authorize next phase. IEV alone cannot perform next effect. Both protected conditions are required. ---------------------------------------------------------------------- STEP 11 - SEND CONTINUATION AUTHORITY TO FINALITY SINK ---------------------------------------------------------------------- SEND_TO_FINALITY_SINK( CVI_(i+1), P_(i+1), A ) ---------------------------------------------------------------------- STEP 12 - FINALITY SINK VERIFIES IEV OUTPUT ---------------------------------------------------------------------- function FS_VERIFY_CVI(CVI_(i+1)): verify: IEV signature/MAC/attestation ActDigest == D_A PriorReceipt == HASH(R_i) NextPhase == i+1 NextScope == requested scope NextSink == this Finality Sink NextDestination == authorized destination PolicyEpoch current Expiry valid CVI not previously consumed if any check fails: BLOCK P_(i+1) else: mark CVI_(i+1) consumed Das Expires 4 April 2027 [Page 89] Internet-Draft Earned Authority: Interim Validation October 2026 EFFECTUATE P_(i+1) ---------------------------------------------------------------------- STEP 13 - GENERATE NEXT RECEIPT ---------------------------------------------------------------------- after P_(i+1) occurs: R_(i+1) := GENERATE_EFFECT_RECEIPT(...) send R_(i+1) to IEV repeat validation cycle ---------------------------------------------------------------------- GENERAL MULTI-PHASE LOOP ---------------------------------------------------------------------- for i = 0 to n-1: EFFECTUATE P_i R_i := RECEIVE_PROTECTED_EFFECT_EVIDENCE(P_i) IVIR_i := BUILD_IVIR(R_i) Decision := IEV_DECIDE(i, R_i) if Decision == PASS: CVI_(i+1) := ISSUE_PHASE_BOUND_CONTINUATION(R_i) FS_(i+1).VERIFY(CVI_(i+1)) FS_(i+1).EFFECTUATE(P_(i+1)) else if Decision == REDUCE_SCOPE: P_(i+1) := CALCULATE_REDUCED_PHASE() issue restricted CVI_(i+1) continue Das Expires 4 April 2027 [Page 90] Internet-Draft Earned Authority: Interim Validation October 2026 else if Decision == HUMAN_REVIEW: execute HUMAN_ESCALATION_WORKFLOW() else if Decision == RETRY_OR_REMEDIATE: execute AUTOMATED_ERROR_WORKFLOW() else if Decision == RECONCILE: execute RECONCILIATION_WORKFLOW() else: terminate progression ---------------------------------------------------------------------- HUMAN ESCALATION WORKFLOW ---------------------------------------------------------------------- function HUMAN_ESCALATION_WORKFLOW(): PER_i := PROTECT({ ActDigest = D_A, ReceiptDigest = HASH(R_i), ExpectedEffect = X_i, ObservedEffect = O_i, Deviation = DIFFERENCE(X_i, O_i), CurrentPhase = i, ProposedNext = P_(i+1), RiskState = CurrentRisk, PolicyEpoch = CurrentPolicyEpoch }) send PER_i to protected human approval interface HumanDecision := WAIT_FOR_PROTECTED_HUMAN_DECISION() CASE HumanDecision: Das Expires 4 April 2027 [Page 91] Internet-Draft Earned Authority: Interim Validation October 2026 APPROVE_AS_REQUESTED: H_i := SIGN_PROTECTED_HUMAN_APPROVAL( HASH(PER_i), HASH(R_i), Scope(P_(i+1)) ) send H_i back to IEV IEV revalidates: Human signature Human role Freshness Act binding Receipt binding Scope if valid: issue CVI_(i+1) APPROVE_REDUCED_SCOPE: P_(i+1) := HumanSpecifiedReducedScope verify P_(i+1) <= Envelope_MAX issue restricted CVI_(i+1) RETRY_TRIAL: issue new bounded phase authority with NEW nonce and NEW idempotency identifier ROLLBACK: issue rollback/remediation authority DENY: TERMINATE ESCALATE_HIGHER: Das Expires 4 April 2027 [Page 92] Internet-Draft Earned Authority: Interim Validation October 2026 route PER_i to higher protected authority ---------------------------------------------------------------------- AUTOMATED ERROR / REMEDIATION WORKFLOW ---------------------------------------------------------------------- function AUTOMATED_ERROR_WORKFLOW(): ErrorRecord := { D_A, HASH(R_i), X_i, O_i, ErrorClass, RiskState, PhaseID=i } ProposedAction := AUTOMATED_ERROR_CONTROLLER(ErrorRecord) ProposedAction may be: REQUERY REATTEST RETRY REDUCE_SCOPE ROLLBACK COMPENSATE ALTERNATE_SINK QUARANTINE HUMAN_ESCALATION TERMINATE IMPORTANT: Automated Error Controller does NOT itself receive unrestricted authority to perform the next effect. ProposedAction -> return to IEV -> IEV verifies remediation -> Das Expires 4 April 2027 [Page 93] Internet-Draft Earned Authority: Interim Validation October 2026 IEV issues bounded RemediationAuthority ---------------------------------------------------------------------- RECONCILIATION WORKFLOW ---------------------------------------------------------------------- function RECONCILE_PHASE(i): S_IEV.status := RECONCILING obtain evidence from one or more of: Finality Sink Destination Transaction ledger Database Storage controller Hardware counter Sensor Message identifier Network state Replica Protected journal Idempotency record determine: PROVEN_EFFECTED PROVEN_NOT_EFFECTED PARTIALLY_EFFECTED STILL_INDETERMINATE CASE PROVEN_EFFECTED: reconstruct/recover valid receipt pass recovered receipt through IEV validation DO NOT simply assume continuation CASE PROVEN_NOT_EFFECTED: a new bounded retry may be authorized Das Expires 4 April 2027 [Page 94] Internet-Draft Earned Authority: Interim Validation October 2026 use: new nonce new authority new idempotency identifier CASE PARTIALLY_EFFECTED: calculate residual state determine: compensation reduced continuation human escalation termination CASE STILL_INDETERMINATE: keep next phase BLOCKED ---------------------------------------------------------------------- CRASH AFTER IEV APPROVAL ---------------------------------------------------------------------- if IEV issued CVI_(i+1) and Finality Sink has not confirmed consumption: store: CVI_State = ISSUED_NOT_CONFIRMED after restart: query Finality Sink consumption state if PROVEN_NOT_CONSUMED: allow same protected CVI or authorized replacement if PROVEN_CONSUMED: do NOT issue another equivalent CVI reconcile P_(i+1) if UNKNOWN: enter INDETERMINATE Das Expires 4 April 2027 [Page 95] Internet-Draft Earned Authority: Interim Validation October 2026 ---------------------------------------------------------------------- CRASH AFTER EFFECT BUT BEFORE RECEIPT ---------------------------------------------------------------------- if FS performed P_i but R_i was not delivered: DO NOT blindly execute P_i again query using: ActDigest PhaseID nonce transaction ID idempotency identifier protected counter reconcile before retry ---------------------------------------------------------------------- REPLAY PROTECTION ---------------------------------------------------------------------- before accepting any R_i: if HASH(R_i) in S_IEV.consumed_receipts: REJECT before accepting any CVI_i: if CVI_i previously consumed: REJECT ---------------------------------------------------------------------- ANTI-BYPASS RULE ---------------------------------------------------------------------- for each ActEquivalentPath capable of P_(i+1): require at least one protected condition controlled by: IEV OR equivalent protected interim validation logic Das Expires 4 April 2027 [Page 96] Internet-Draft Earned Authority: Interim Validation October 2026 examples: IEV signature IEV key share IEV state bit IEV hardware latch IEV transaction state IEV network permit IEV protected register IEV threshold share if alternate path can effectuate P_(i+1) without any equivalent condition: architecture is NOT non-bypassable protect, disable, or mediate alternate path ---------------------------------------------------------------------- FINAL PHASE ---------------------------------------------------------------------- when P_n completes: R_n := obtain final protected evidence IEV verifies R_n if valid: S_IEV.status := FULLY_EFFECTED FinalReceipt := PROTECT({ D_A, HASH(R_0), HASH(R_1), ... HASH(R_n), FinalState, IEVCounter, PolicyEpoch }) store FinalReceipt Das Expires 4 April 2027 [Page 97] Internet-Draft Earned Authority: Interim Validation October 2026 else: enter failure/reconciliation path A.5.1. Concrete execution sequence The operational sequence is therefore: \boxed{ Candidate\ Act \rightarrow FS_0 \rightarrow Real\ Effect_0 \rightarrow R_0 \rightarrow IEV } The IEV then performs: Authenticate \rightarrow Bind \rightarrow Compare \rightarrow Evaluate \rightarrow Decide If everything matches: IEV \rightarrow CVI_1 \rightarrow FS_1 \rightarrow Real\ Effect_1 and then: R_1 \rightarrow IEV \rightarrow CVI_2 \rightarrow FS_2 \rightarrow Real\ Effect_2 until completion. If misalignment occurs: R_i \rightarrow IEV \rightarrow \begin{cases} HumanReview\\ AutomatedRemediation\\ ReducedScope\\ Reconciliation\\ Rollback\\ Compensation\\ Termination \end{cases} The particularly important technical relationship is: \boxed{ Receipt\ existence \neq Continuation\ authority } Instead: \boxed{ Authenticated\ Receipt + Independent\ IEV\ Validation = Eligibility\ for\ Next\ Phase } and in the stronger implementation: \boxed{ IEV\ PASS \rightarrow Missing\ Execution\ Material \rightarrow Finality\ Sink \rightarrow Next\ Effect } Das Expires 4 April 2027 [Page 98] Internet-Draft Earned Authority: Interim Validation October 2026 This means the IEV is not merely an auditor. It is inside the causal execution path between real effects. \newpage A.6. Appendix A - Mathematical Consistency Notes 1. Phase indexing. P_i is the real effectuation phase whose outcome is described by R_i. The IEV validates R_i before ordinary progression to P_{i+1}. 2. Continuation indexing. CVI_{i+1} is always the continuation instruction associated with the next phase P_{i+1} and is bound to H(R_i). 3. Expected versus observed effect. X_i is the protected expected result; O_i is the protected observed result. Acceptance may use exact equality, a distance/tolerance function, a range, set membership, or protected predicates. 4. Envelope rule. No successful receipt or IEV decision enlarges the operation beyond Envelope_{MAX} unless a new protected authorization explicitly changes that envelope. 5. Key derivation. K^{IEV}_{i+1} is shown as one non-limiting receipt-dependent construction. The essential property is protected dependence on accepted evidence from phase i, not use of a specific KDF. 6. Split-key rule. K^{Final}_{i+1}=Combine(K^{FS}_{i+1},K^{IEV}_{i+1}) is illustrative. Threshold signatures, hardware unsealing, state bits, command authenticators, transaction roles, or equivalent mechanisms may provide the same causal dependence. 7. Human escalation. Human approval does not automatically erase the earlier mismatch. A protected human decision should be bound to the relevant receipt/evidence, deviation, next-phase scope, and act identity. 8. Indeterminate state. Absence of proof of effect is not treated as proof of non-effect. Where effect status is unresolved, the architecture may remain blocked pending reconciliation. 9. Atomicity. Receipt consumption, phase advancement, and issuance of a next-phase continuation condition should preferably be atomic or protected by equivalent replay-safe state machinery. Das Expires 4 April 2027 [Page 99] Internet-Draft Earned Authority: Interim Validation October 2026 10. Non-bypassability. Any act-equivalent path capable of producing the protected next effect should require the IEV-controlled condition or an equivalent protected interim-validation condition where the architecture is intended to be non- bypassable. A.7. Appendix B - Central IEV Relationships The three Parts reduce to the following protected causal relationships: \boxed{ Receipt\ existence \neq Continuation\ authority } \boxed{ AuthenticatedReceipt_i + IndependentIEVValidation_i \Rightarrow EligibilityFor(P_{i+1}) } For a cryptographically stronger implementation: \boxed{ IEVPass_i \rightarrow MissingExecutionMaterial_{i+1} \rightarrow FS_{i+1} \rightarrow P_{i+1} } For repeated multi-phase operation: \boxed{ P_i \rightarrow R_i \rightarrow IEV_i \rightarrow CVI_{i+1} \rightarrow FS_{i+1} \rightarrow P_{i+1} } The IEV is therefore positioned inside the causal chain between real effects rather than functioning merely as a post-event auditor. \newpage A.8. PART IV - HARDENED IEV EMBODIMENTS This Part extends the IEV architecture to three failure surfaces: (i) failure, compromise, or inconsistency of the validator itself; (ii) multiple authentic but mutually incompatible evidence objects; and (iii) revocation or state change after IEV PASS but before Finality- Sink consumption. A.9. H1. IEV Compromise, Failure, Unavailability, or State Inconsistency A.9.1. H1.1 Failure model An IEV may be unavailable, stale, rolled back, internally inconsistent, compromised, partitioned, misconfigured, or malicious. Accordingly, a high-assurance embodiment does not treat the bare proposition Das Expires 4 April 2027 [Page 100] Internet-Draft Earned Authority: Interim Validation October 2026 V_i=\mathrm{PASS} as permanently sufficient authority for P_{i+1}. The validator decision itself may be accompanied by integrity evidence and independently checked boundary predicates. A.9.2. H1.2 IEV Decision Evidence Object An IEV may produce an IEV Decision Evidence Object IDEO_i: \begin{aligned} IDEO_i =\operatorname{Protect}\!\Big(& D_A, i, H(R_i), V_i, \operatorname{Scope}(P_{i+1}), \operatorname{ID}(FS_{i+1}),\\ &\sigma_i, p_i, r_i, \operatorname{ValidatorID}, \operatorname{Measurement}_{IEV},\\ &q_i, t_i, t^{\mathrm{exp}}_i \Big). \end{aligned} This permits the Finality Sink to verify not only a validator decision but also the state, epoch, counter, validator identity, measurement, and freshness to which that decision was bound. A.9.3. H1.3 Protected state digest and chain Define \sigma_i=H(S^{IEV}_i). A rollback-resistant state chain may be formed as \sigma_{i+1} = H\!\left( \sigma_i \parallel H(R_i) \parallel \operatorname{Enc}(V_i) \parallel q_{i+1} \right), where \operatorname{Enc}(V_i) is a canonical encoding of the decision. The chain \sigma_0\rightarrow\sigma_1\rightarrow\cdots\rightarrow\sigma_n can expose omitted, reordered, replayed, or rolled-back validator transitions. A.9.4. H1.4 Monotonic counter requirement The validator may maintain q_{i+1}>q_i. Das Expires 4 April 2027 [Page 101] Internet-Draft Earned Authority: Interim Validation October 2026 A Finality Sink may reject a continuation object whose counter is not strictly newer than the last accepted validator counter: q(CVI_{i+1})\leq q^{FS}_{\mathrm{last}} \Rightarrow \operatorname{Reject}(CVI_{i+1}). A.9.5. H1.5 Validator attestation A non-limiting validator attestation is \operatorname{Att}_{IEV} = \operatorname{Sign}_{K_{att}}\!\left( \operatorname{Measurement}_{IEV} \parallel \operatorname{ConfigDigest} \parallel p_i \parallel q_i \right). A protected trust predicate may be \begin{aligned} \operatorname{IEVTrust}_i={}& \operatorname{AttestationValid}_i \land \operatorname{StateConsistent}_i\\ &\land \operatorname{CounterFresh}_i \land \operatorname{WatchdogClear}_i. \end{aligned} A high-assurance effectuation condition can then require \operatorname{Enable}(P_{i+1}) = \operatorname{Valid}(CVI_{i+1}) \land \operatorname{IEVTrust}_i \land \operatorname{FSBoundaryChecks}_{i+1}. A.9.6. H1.6 Independent watchdog A logically distinct watchdog may evaluate validator liveness, attestation, counter progression, duplicate continuation issuance, impossible state transitions, stale epochs, or decisions inconsistent with independently available evidence. If \operatorname{WatchdogClear}_i=\mathrm{false}, ordinary continuation can be withheld even if a syntactically valid IEV output is present. A.9.7. H1.7 Dual and threshold validators For two validators IEV_i^{(1)} and IEV_i^{(2)}, a high-assurance rule may require \operatorname{Pass}^{(1)}_i \land \operatorname{Pass}^{(2)}_i. Das Expires 4 April 2027 [Page 102] Internet-Draft Earned Authority: Interim Validation October 2026 For n validators and threshold m: \sum_{j=1}^{n} \mathbf{1}\!\left[ \operatorname{ValidPass}\!\left(IEV_i^{(j)}\right) \right] \geq m. A threshold key realization may be K_{i+1} = \operatorname{Combine}\!\left( Share_{j_1},\ldots,Share_{j_m} \right). No single validator need possess sufficient material to authorize the next phase. A.9.8. H1.8 Hierarchical validation A local validator may produce V_i^{local} and a higher-assurance validator may produce V_i^{high}. For a selected consequence class, \operatorname{Enable}(P_{i+1}) = \bigl(V_i^{local}=\mathrm{PASS}\bigr) \land \bigl(V_i^{high}=\mathrm{PASS}\bigr). The required assurance level may depend on consequence, asset class, destination, risk, policy, or operating mode. A.9.9. H1.9 Validator unavailability A protected policy may map unavailability to \begin{aligned} \operatorname{IEVUnavailable} \Rightarrow\{&\mathrm{HOLD},\ \mathrm{SAFE\_STATE},\ \mathrm{REDUCED\_SCOPE},\\ &\mathrm{ALTERNATE\_IEV},\ \mathrm{FAIL\_LIMITED},\ \mathrm{TERMINATE}\}. \end{aligned} For a high-consequence path, IEVUnavailable \Rightarrow \neg\operatorname{OrdinaryContinuation}. Where a bounded fallback is permitted, \operatorname{Scope}_{fallback} \subset \operatorname{Scope}_{normal}. Das Expires 4 April 2027 [Page 103] Internet-Draft Earned Authority: Interim Validation October 2026 A.9.10. H1.10 Failover to an alternate IEV An alternate validator does not merely inherit the prior validator's PASS. It may receive the prior receipt, state digest, phase state, policy and revocation epochs, consumed-receipt state, issued-CVI state, and Finality-Sink consumption state and independently reconstruct continuation eligibility. A.9.11. H1.11 Inconsistent protected state If validator and sink state disagree, for example \operatorname{Phase}_{IEV}=i \qquad\text{and}\qquad \operatorname{Phase}_{FS}=i+1, or \operatorname{Consumed}_{IEV}(R_i)=\mathrm{false} \qquad\text{and}\qquad \operatorname{Consumed}_{Store}(R_i)=\mathrm{true}, then \operatorname{IEVStateConflict}=\mathrm{true} \Rightarrow \neg\operatorname{OrdinaryContinuation}. The system may enter reconciliation, protected-log comparison, secure-counter comparison, quorum recovery, or protected human review. A.9.12. H1.12 Crash-consistent state transition A protected state transition should preferably have atomic or equivalent crash-consistent semantics: \operatorname{Atomic}\left\{ \operatorname{Consume}(R_i); \operatorname{AdvancePhase}(i,i+1); q\leftarrow q+1; \operatorname{Record}\!\left(H(CVI_{i+1})\right); \operatorname{CommitState}(); \right\}. An equivalent prepare/commit/publish implementation may be used. A.9.13. H1.13 Compromised validator key Let \kappa_i denote the validator-key epoch bound to a continuation object. The Finality Sink may require \kappa(CVI_{i+1})=\kappa_{current}. Das Expires 4 April 2027 [Page 104] Internet-Draft Earned Authority: Interim Validation October 2026 Otherwise, \kappa(CVI_{i+1})\neq\kappa_{current} \Rightarrow \operatorname{Reject}(CVI_{i+1}). Unconsumed continuation objects associated with a compromised key epoch may thereby be invalidated. A.9.14. H1.14 Protection against a lying IEV For higher-assurance embodiments, the Finality Sink may independently verify a minimum invariant set: \mathcal{M}_{FS} = \left\{ \operatorname{ActMatch}, \operatorname{PhaseMatch}, \operatorname{ReceiptBinding}, \operatorname{SinkBinding}, \operatorname{ScopeValid}, \operatorname{EpochCurrent}, \operatorname{RevocationClear} \right\}. Thus V_i=\mathrm{PASS} \not\Rightarrow \operatorname{Effectuate}(P_{i+1}). Instead, \operatorname{Effectuate}(P_{i+1}) \Rightarrow \bigl(V_i=\mathrm{PASS}\bigr) \land \bigwedge_{f\in\mathcal{M}_{FS}} f=\mathrm{true}. A.9.15. H1.15 Proof-carrying IEV decision An IEV may produce a proof \pi_i of required predicate satisfaction: CVI_{i+1} = \left( V_i, H(R_i), \operatorname{Scope}(P_{i+1}), \pi_i \right). The Finality Sink may require \operatorname{VerifyProof}(\pi_i)=\mathrm{true}. The proof may comprise signed predicate results, Merkle proofs, attestation evidence, a threshold signature, a zero-knowledge proof, secure-computation evidence, or another machine-verifiable proof. A.9.16. H1.16 Core validator-integrity invariant For an assurance-required embodiment: Das Expires 4 April 2027 [Page 105] Internet-Draft Earned Authority: Interim Validation October 2026 \boxed{ \operatorname{Enable}(P_{i+1}) = \operatorname{CVIValid}_{i+1} \land \operatorname{IEVIntegrityValid}_i \land \operatorname{FSBoundaryChecksValid}_{i+1} }. A.10. H2. Conflicting but Individually Authentic Effect Evidence A.10.1. H2.1 Evidence vector Let the IEV receive \mathbf{R}_i = \left( R_i^{(1)}, R_i^{(2)}, \ldots, R_i^{(n_i)} \right). Each evidence object may authenticate independently: a_{i,j} = \operatorname{AuthValid}\!\left(R_i^{(j)}\right). Authentication and consistency are different properties. A.10.2. H2.2 Conflict predicate For evidence sources j and k, define c_{i,jk} = \operatorname{Consistent}\!\left(R_i^{(j)},R_i^{(k)}\right). A protected conflict exists when \operatorname{Conflict}_i = \bigvee_{1\leq j\tau_{risk}, Das Expires 4 April 2027 [Page 111] Internet-Draft Earned Authority: Interim Validation October 2026 then \operatorname{Allow}_{i+1}=\mathrm{false}. Likewise, if current taint state T(t) is outside the authorized set \mathcal{T}_{allow}, T(t^{eff}_{i+1})\notin\mathcal{T}_{allow} \Rightarrow \operatorname{Allow}_{i+1}=\mathrm{false}. A.11.11. H3.11 Revalidation object Where current conditions have changed but continuation may remain permissible, the IEV may issue a revalidation object RV_{i+1}. The Finality Sink may require \operatorname{Valid}(CVI_{i+1}) \land \operatorname{Valid}(RV_{i+1}). A.11.12. H3.12 Online consume protocol For a high-consequence effect, the Finality Sink may request a fresh one-time consume grant: FS_{i+1} \rightarrow \operatorname{ConsumeRequest}(CVI_{i+1}) \rightarrow IEV_i. After fresh checks, IEV_i \rightarrow \operatorname{ConsumeGrant}_{i+1} \rightarrow FS_{i+1}. The consume grant may be single-use and short-lived. A.11.13. H3.13 Revoke-or-consume race Let \operatorname{CVIState} \in \{\mathrm{ISSUED},\mathrm{REVOKED},\mathrm{CONSUMED}\}. Permitted terminal transitions include \mathrm{ISSUED}\rightarrow\mathrm{REVOKED} and \mathrm{ISSUED}\rightarrow\mathrm{CONSUMED}. Das Expires 4 April 2027 [Page 112] Internet-Draft Earned Authority: Interim Validation October 2026 A transition \mathrm{REVOKED}\rightarrow\mathrm{CONSUMED} is prohibited. An atomic compare-and-swap realization is \operatorname{CAS}\!\left( \operatorname{CVIState}, \mathrm{ISSUED}, \mathrm{CONSUMED} \right)=\mathrm{success}. The Finality Sink effectuates only if the state transition succeeds. A.11.14. H3.14 Hardware revocation realization A hardware boundary may require \operatorname{ENABLE}_{i+1} = L^{IEV}_{pass} \land \neg L_{revoked} \land \operatorname{EpochMatch}. If revocation asserts L_{revoked}=1, then \operatorname{ENABLE}_{i+1}=0. A.11.15. H3.15 Cryptographic revocation realization Next-phase material may include current epochs: K_{i+1} = \operatorname{KDF}\!\left( K_{root}, D_A, H(R_i), p_{current}, r_{current}, i+1 \right). A Finality Sink accepts only material corresponding to the current protected epoch state. A.11.16. H3.16 Prepare/commit continuation An IEV may first issue a prepared continuation object CVI^{prep}_{i+1}. Immediately before effectuation, a protected authority issues a commit object CVI^{commit}_{i+1}. Then \operatorname{Enable}(P_{i+1}) = \operatorname{Valid}(CVI^{prep}_{i+1}) \land \operatorname{Valid}(CVI^{commit}_{i+1}). Das Expires 4 April 2027 [Page 113] Internet-Draft Earned Authority: Interim Validation October 2026 A.11.17. H3.17 Scope reduction after PASS A changed condition need not always require total cancellation. If a previously authorized scope s_{old} exceeds a newly safe scope s_{new}, s_{new}\subset s_{old}, the old continuation object may be invalidated and replaced by a reduced-scope continuation object. A.11.18. H3.18 Post-PASS substitution protection A continuation object may bind destination d_{i+1}. At effectuation, \operatorname{RequestedDestination} = d_{i+1} must hold. Otherwise, \operatorname{RequestedDestination}\neq d_{i+1} \Rightarrow \operatorname{BLOCK}. The same principle may bind account, recipient, resource, device, route, API, tool, file, payment rail, actuator, interface, or storage object. A.11.19. H3.19 Distributed revocation and offline operation Where CVI_{i+1} has propagated to sinks FS^{(1)},\ldots,FS^{(N)}, revocation may be distributed to all such sinks. A sink unable to establish freshness of revocation state may fail closed or enter a bounded fail-limited mode. For an offline sink, protection may be provided by short expiry, bounded scope, one-time keys, monotonic counters, hardware epochs, preloaded revocation windows, or bounded energy/action budgets, with \operatorname{Scope}_{offline} \subset \operatorname{Scope}_{online}. A.11.20. H3.20 Core post-PASS invariant The central time-sensitive rule is \boxed{ \operatorname{IEVPass}(t_0) \neq \operatorname{IrrevocableAuthority}(t_1) \quad\text{for }t_1>t_0 }. Instead, Das Expires 4 April 2027 [Page 114] Internet-Draft Earned Authority: Interim Validation October 2026 \boxed{ \operatorname{Enable}(P_{i+1},t_1) = \operatorname{Valid}(CVI_{i+1},t_1) \land \operatorname{CurrentProtectedConditions}(t_1) }. A.12. H4. Combined Hardened IEV Model The three hardening embodiments may operate simultaneously: \boxed{ \begin{aligned} P_i &\rightarrow \mathbf{R}_i \rightarrow \operatorname{ConsistencyEvaluation}_i \rightarrow \operatorname{HardenedIEVValidation}_i\\ &\rightarrow CVI_{i+1}^{\mathrm{revocable}} \rightarrow \operatorname{BoundaryRevalidation}_{i+1} \rightarrow FS_{i+1} \rightarrow P_{i+1} \end{aligned} }. A formal IEV acceptance condition may be written as \begin{aligned} \operatorname{HardenedPass}_i={}& \operatorname{ReceiptAuthentic}_i \land \operatorname{EvidenceConsistent}_i \land \operatorname{EffectAcceptable}_i\\ &\land \operatorname{IEVIntegrityValid}_i \land \operatorname{PolicyCurrent}_i \land \operatorname{RevocationClear}_i. \end{aligned} The Finality Sink independently evaluates current effectuation conditions: \begin{aligned} \operatorname{FSAllow}_{i+1}={}& \operatorname{CVIValid}_{i+1} \land \operatorname{IEVIntegrityValid}_i \land \operatorname{PolicyCurrent}_{i+1}\\ &\land \operatorname{RevocationClear}_{i+1} \land \operatorname{ContinuationNotWithdrawn}_{i+1}\\ &\land \operatorname{DestinationValid}_{i+1} \land \operatorname{ScopeAuthorized}_{i+1}. \end{aligned} For a high-consequence embodiment, \operatorname{Effectuate}(P_{i+1}) \Rightarrow \operatorname{HardenedPass}_i \land \operatorname{FSAllow}_{i+1}. A.13. H5. Fail-Closed and Fail-Limited Defaults Ordinary continuation may be blocked while any required condition remains unresolved, including Das Expires 4 April 2027 [Page 115] Internet-Draft Earned Authority: Interim Validation October 2026 \begin{gathered} \operatorname{IEVUnavailable},\quad \operatorname{IEVIntegrityUnknown},\quad \operatorname{IEVStateConflict},\\ \operatorname{EvidenceConflict},\quad \operatorname{RevocationStateUnknown},\quad \operatorname{PolicyEpochMismatch},\\ \operatorname{ContinuationWithdrawn},\quad \operatorname{DestinationStateUnknown},\quad \operatorname{CVIConsumptionUnknown}. \end{gathered} Accordingly, \boxed{ \mathrm{UNKNOWN}\neq\mathrm{AUTHORIZED} }. A system may instead enter reconciliation, safe state, reduced scope, alternate-validator mode, bounded diagnostic mode, quarantine, protected human review, or termination. A.14. H6. Formal Distinctions The hardened architecture expressly distinguishes: \boxed{\mathrm{AuthenticEvidence}\neq\mathrm{ConsistentEvidence}} \boxed{\mathrm{IEVPass}\neq\mathrm{InfallibleIEV}} \boxed{\mathrm{ValidAtIssue}\neq\mathrm{ValidAtEffectuation}} \boxed{\mathrm{ValidatorUnavailable}\neq\mathrm{PermissionToBypass}} and \boxed{\mathrm{HumanOrMachineResolution}\neq\mathrm{DirectEffectuationAuthority}}. A.15. H7. Combined Security Invariant For a hardened high-assurance embodiment, define Das Expires 4 April 2027 [Page 116] Internet-Draft Earned Authority: Interim Validation October 2026 \begin{aligned} \operatorname{Enable}(P_{i+1})={}& \operatorname{ReceiptAuthentic}_i \land \operatorname{EvidenceConsistent}_i \land \operatorname{EffectAcceptable}_i\\ &\land \operatorname{IEVIntegrityValid}_i \land \operatorname{CVIValid}_{i+1} \land \operatorname{PolicyCurrent}_{i+1}\\ &\land \operatorname{RevocationClear}_{i+1} \land \operatorname{ContinuationNotWithdrawn}_{i+1}\\ &\land \operatorname{DestinationValid}_{i+1} \land \operatorname{ScopeAuthorized}_{i+1}. \end{aligned} If a required predicate is \mathrm{false}, the ordinary next phase is blocked. If a required predicate is \mathrm{unknown}, the system enters the applicable reconciliation, safe-state, fail-limited, revalidation, or escalation path rather than assuming authorization. The hardened causal chain is therefore \boxed{ \begin{aligned} \operatorname{RealEffect}_i &\rightarrow \operatorname{ProtectedEvidence}_i \rightarrow \operatorname{EvidenceConsistency}_i \rightarrow \operatorname{IEVIntegrity}_i\\ &\rightarrow V_i \rightarrow CVI_{i+1}^{\mathrm{revocable}} \rightarrow \operatorname{EffectuationTimeRevalidation}_{i+1}\\ &\rightarrow FS_{i+1} \rightarrow \operatorname{RealEffect}_{i+1} \end{aligned} }. \newpage A.16. Appendix C - Mathematical Notation for the Hardened Embodiments | Symbol | Meaning | |---|---| | \sigma_i | Digest of protected IEV state S^{IEV}_i. | | q_i | Protected monotonic validator counter. | | IDEO_i | IEV Decision Evidence Object. | | \pi_i | Machine-verifiable proof carried with or referenced by an IEV decision. | | \mathbf{R}_i | Vector of evidence objects for phase i. | | R_i^{(j)} | Evidence object from source j for phase i. | | a_{i,j} | Authenticity predicate for R_i^{(j)}. | | c_{i,jk} | Pairwise consistency predicate between sources j and k. | | E_i | Evidence- state classification. | | G_i | Conflict-resolution result. | | \Pi_i^{cons} | Consistency proof or protected conflict-resolution record. | | t^{iss}_{i+1} | Time at which CVI_{i+1} is issued. | | t^{eff}_{i+1} | Time at which FS_{i+1} is about to cause the next effect. | | CR_i | Continuation Revocation Record. | | g_i | Continuation generation. | | RV_{i+1} | Revalidation object for an already issued continuation. | | \kappa_i | Validator-key epoch. | | \rho_i | Protected risk value. | | \tau_{risk} | Protected risk threshold. | | \mathcal{T}_{allow} | Authorized set of taint Das Expires 4 April 2027 [Page 117] Internet-Draft Earned Authority: Interim Validation October 2026 states. | The symbols in this appendix supplement, rather than replace, the unified notation at the beginning of this document. Appendix B. Software, VM, Operating-System, and Application Realizations This appendix gives non-limiting implementation patterns for isolated VMs, microVMs, Linux, Android, iOS/iPadOS, macOS, Windows, ordinary applications, local-plus-remote validation, and validator substitution. title: "INTERIM EFFECTUATION VALIDATOR (IEV) - SOFTWARE, ISOLATED-VM, OPERATING-SYSTEM, MOBILE-PLATFORM, AND APPLICATION EMBODIMENTS" subtitle: "Platform-Neutral Protected Inter-Phase Validation with Validator-Substitution Invariance" author: "Technical Specification - Non-Limiting Embodiments" date: "October 2026" geometry: margin=18mm fontsize: 10pt mainfont: "DejaVu Serif" sansfont: "DejaVu Sans" monofont: "DejaVu Sans Mono" header-includes: * \usepackage{amsmath,amssymb,mathtools} * \usepackage{booktabs,longtable,array} * \usepackage{microtype} * \usepackage{enumitem} * \setlist[itemize]{itemsep=2pt,topsep=3pt} * \setlist[enumerate]{itemsep=2pt,topsep=3pt} * \usepackage{fancyhdr} * \pagestyle{fancy} * \fancyhf{} * \lhead{Interim Effectuation Validator - Software/OS Embodiments} * \rhead{Platform-Neutral IEV} * \cfoot{\thepage} * \setlength{\headheight}{14pt} Das Expires 4 April 2027 [Page 118] Internet-Draft Earned Authority: Interim Validation October 2026 B.1. 1. Purpose and Scope This section describes non-limiting implementations of an Interim Effectuation Validator (IEV) in software, virtualized computing, operating-system, mobile-platform, desktop, application, backend, and mixed local/remote environments. The IEV is not limited to a dedicated hardware block. It may be realized as an isolated virtual machine, microVM, privileged process, daemon, system service, protected application service, trusted execution component, remote service, distributed validator set, or other protected software component. The functional invariant is preserved regardless of the validator's physical or software placement: boxed{ E_i -> R_i -> V_i -> Gamma_{i+1} -> FS_{i+1} -> E_{i+1} } Figure 26 where an earlier real effect produces protected evidence, the evidence is independently validated, and a subsequent real effect is made dependent on a protected continuation condition. The IEV may be used with communications, payments, file transfer, storage, database transactions, API calls, AI-agent tool use, model- state mutation, GPU or accelerator egress, cloud deployment, software update, telecommunications, physical actuation, robotics, vehicles, industrial control, or other consequential operations. B.2. 2. Formal Notation The following notation is used consistently throughout this embodiment. Das Expires 4 April 2027 [Page 119] Internet-Draft Earned Authority: Interim Validation October 2026 | Symbol | Meaning | |---|---| | A | Candidate Act or proposed consequential operation | | D_A | canonical digest or protected binding of A | | i | current phase index | | P_i | authorized phase specification for phase i | | E_i | actual real effect produced for phase i | | R_i | protected effect evidence or receipt for E_i | | X_i | expected effect or expected effect properties for phase i | | O_i | observed effect or observed effect properties derived from R_i | | V_i | IEV validation function applied to phase i | | S_i^{IEV} | protected IEV state associated with phase i | | FS_i | Finality Sink controlling phase i | | C_i | initial or phase-specific authority enabling phase i | | CVI_{i+1} | Continuation Validation Instruction associated with phase i+1 | | \Gamma_{i+1} | generic protected continuation condition for phase i+1 | | K_{i+1} | optional receipt-dependent execution material or phase key | | p_i | policy epoch or protected policy state | | r_i | revocation epoch or protected revocation state | | c_i | monotonic counter or protected sequence value | | \epsilon_i | permitted numerical or semantic tolerance | | \mathcal{A}_i | authorized result set | | \mathcal{V} | set of permissible IEV implementations | | v\in\mathcal{V} | one concrete IEV implementation | The generic continuation condition \Gamma_{i+1} may be realized as a signed instruction, MAC, protected state transition, key, key share, hardware latch, database state, secure mailbox record, kernel state, transaction state, credential state, or equivalent non-bypassable condition. B.3. 3. Canonical Functional Sequence For any supported software implementation, the preferred sequence is: A -> FS_i -> E_i -> R_i -> V_i(R_i,S_i^{IEV}) -> Gamma_{i+1} -> FS_{i+1} -> E_{i+1}. Figure 27 Das Expires 4 April 2027 [Page 120] Internet-Draft Earned Authority: Interim Validation October 2026 A more explicit form is: D_A = H(Canon(A)), E_i = Effectuate(FS_i,P_i,C_i), R_i = Observe(E_i), delta_i = V_i(R_i,S_i^{IEV}), Gamma_{i+1} = EstablishContinuation(delta_i,R_i,D_A,P_{i+1}), E_{i+1} = Effectuate(FS_{i+1},P_{i+1},Gamma_{i+1}). Figure 28 Ordinary continuation is permitted only when the required validation outcome is satisfied. B.4. 4. IEV Decision Function A non-limiting validation predicate is: Pass_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 negConsumed(R_i) AND EffectAcceptable(O_i,X_i) AND PolicyCurrent(p_i) AND RevocationClear(r_i) AND WithinEnvelope(P_{i+1}). Figure 29 The validator may return more than a binary result: delta_i in {PASS,FAIL,HOLD,RECONCILE,REDUCE,REMEDIATE,ESCALATE,TERMINATE}. Figure 30 B.5. 5. Effect Comparison Models The IEV may evaluate expected and observed effects using one or more of the following. B.5.1. 5.1 Exact equality O_i=X_i. Das Expires 4 April 2027 [Page 121] Internet-Draft Earned Authority: Interim Validation October 2026 Figure 31 B.5.2. 5.2 Tolerance d(O_i,X_i) <= epsilon_i. Figure 32 For a scalar quantity: |O_i-X_i| <= epsilon_i. Figure 33 B.5.3. 5.3 Range L_i <= O_i <= U_i. Figure 34 B.5.4. 5.4 Authorized result set O_i in mathcal{A}_i. Figure 35 B.5.5. 5.5 Predicate set bigwedge_{k=1}^{m} Q_{i,k}(O_i)=true. Figure 36 Different predicates may be used for recipient identity, payment state, route, device state, sensor response, storage persistence, transaction state, model-state mutation, or other properties. B.6. 6. Software IEV Protection Requirements A software IEV is preferably separated from the proposing application such that the proposing component cannot arbitrarily: * write S_i^{IEV}; * create an accepted receipt; * set \delta_i=\mathrm{PASS}; * increment the protected phase counter; Das Expires 4 April 2027 [Page 122] Internet-Draft Earned Authority: Interim Validation October 2026 * mark R_i as consumed; * synthesize a valid CVI_{i+1}; * derive or obtain K_{i+1}; * clear revocation state; * rewrite an expected destination or scope; or * bypass the Finality Sink. Isolation may be implemented by process privilege, VM separation, memory protection, access control, mandatory access control, sandboxing, hypervisor isolation, hardware-backed keys, TEE execution, cryptographic authentication, remote validation, or combinations thereof. B.7. 7. Generic Software State A protected validator state may be represented as: S_i^{IEV}= <= ft( D_A, i, mathcal{E}_{max}, X_i, FS_i, Dest_i, p_i, r_i, c_i, mathcal{C}_i, Risk_i, Taint_i, Prov_i ), Figure 37 where \mathcal{C}_i includes receipt and continuation-consumption state. The app may receive a read-only projection: Pi_{app}(S_i^{IEV}), Das Expires 4 April 2027 [Page 123] Internet-Draft Earned Authority: Interim Validation October 2026 Figure 38 without gaining write authority over protected continuation state. B.8. 8. Continuation Validation Instruction A software CVI may be constructed as: CVI_{i+1} = Protect_{K_{IEV}}(D_A || H(R_i) || (i+1) || Scope_{i+1} || FS_{i+1} || Dest_{i+1} || p_i || r_i || c_{i+1} || Expiry_{i+1}). Figure 39 The protected operation may be a signature, MAC, authenticated encryption, protected database transition, kernel state transition, secure mailbox write, threshold signature, hardware-backed signature, or equivalent authenticated mechanism. B.9. 9. Tokenless Continuation An explicit transferable token is not required. The IEV may atomically establish: State^{cont}_{i+1}=VALID. Figure 40 The Finality Sink then requires: State^{cont}_{i+1}=VALID Figure 41 before the next effect can occur. This state may reside in protected shared memory, kernel state, a database record, transaction engine, daemon memory, secure registry, hypervisor state, remote service state, or other protected state. B.10. 10. Receipt-Derived Execution Material A stronger construction makes the next phase cryptographically incomplete without successful validation: Das Expires 4 April 2027 [Page 124] Internet-Draft Earned Authority: Interim Validation October 2026 K_{i+1} = KDF <= ft( K_{root}^{IEV}, D_A, H(R_i), i+1, FS_{i+1}, c_{i+1} ). Figure 42 If \operatorname{Pass}_i=\mathrm{false}, then K_{i+1} may remain unavailable, sealed, incomplete, or ungenerated. B.11. 11. Isolated Virtual Machine IMPLEMENTATION PATTERN An application or AI agent may execute in: VM_A, Figure 43 while the IEV executes in: VM_{IEV}. Figure 44 The Finality Sink may execute in a host process, hypervisor service, separate VM, or privileged broker. A non-limiting topology is: Das Expires 4 April 2027 [Page 125] Internet-Draft Earned Authority: Interim Validation October 2026 VM_A -> FS_i^{host} -> E_i -> R_i -> VM_{IEV} -> Gamma_{i+1} -> FS_{i+1}^{host}. Figure 45 The application VM is not provided with sufficient host privilege, credential material, or protected state access to synthesize \Gamma_{i+1}. B.12. 12. VM Network IMPLEMENTATION PATTERN The application VM may have only mediated egress: VM_A -> vNIC -> NetworkFS -> Network. Figure 46 A first real bounded effect may be a challenge, trailer, limited payload, connection setup, bounded API call, or endpoint probe. The resulting remote evidence returns to VM_{IEV}. Broader transmission is enabled only after validated continuation. B.13. 13. VM Storage IMPLEMENTATION PATTERN A VM may write to a provisional storage layer: Das Expires 4 April 2027 [Page 126] Internet-Draft Earned Authority: Interim Validation October 2026 Write_{staged} -> R_i^{storage} -> IEV -> Gamma_{promote} -> StorageFS -> Write_{authoritative}. Figure 47 Thus a VM-visible write need not immediately become authoritative or externally visible. B.14. 14. MicroVM IMPLEMENTATION PATTERN An AI agent may run in a microVM with a narrow host interface. The microVM may expose only a SUBMIT_CANDIDATE function, while host-side protected logic exclusively exposes SET_VALIDATED_CONTINUATION to the IEV. The microVM may therefore request an act without being able to advance protected phase state. B.15. 15. Linux Process-Separated IMPLEMENTATION PATTERN A Linux deployment may include: * agentd: proposal/agent process; * effect-broker: Finality Sink; * effect-observer: receipt source; * ievd: Interim Effectuation Validator; * policyd: protected policy service; * credentiald: protected credential/key broker. The sequence is: Das Expires 4 April 2027 [Page 127] Internet-Draft Earned Authority: Interim Validation October 2026 agentd -> effect-broker -> E_i, Figure 48 E_i -> effect-observer -> R_i -> ievd, Figure 49 ievd -> Gamma_{i+1} -> effect-broker. Figure 50 The agent process and IEV daemon may run under different identities and different mandatory-access-control domains. B.16. 16. Linux Namespace and Container IMPLEMENTATION PATTERN The agent and IEV may occupy different user, PID, mount, network, or cgroup domains. The IEV may also be outside the agent container entirely. A container boundary is not relied upon solely as the invention; it is one means of implementing protected separation between the proposer and the validator. B.17. 17. Linux Kernel/LSM/eBPF-Adjacent IMPLEMENTATION PATTERN One or more Linux enforcement points may prevent the agent from using effect-capable paths outside the Finality Sink. For example: Das Expires 4 April 2027 [Page 128] Internet-Draft Earned Authority: Interim Validation October 2026 Agent -> LSM/eBPF/KernelGate -> EffectBroker. Figure 51 An IEV may establish a protected state consumed by the broker or kernel-adjacent enforcement component. The IEV itself may remain a user-space daemon, privileged service, VM, or remote service. B.18. 18. Linux Credential Broker The full credential need not enter agent memory: K_{full} not-in Memory(Agent). Figure 52 After a validated first effect: R_i -> IEV -> Gamma_{i+1} -> credentiald, Figure 53 and the credential broker either performs or authorizes only the scoped subsequent act. B.19. 19. Android System-Service IMPLEMENTATION PATTERN An Android implementation may place the proposing application in its ordinary application sandbox while the IEV resides in a separate process, isolated service, privileged service, OEM system service, native daemon, secure-world component, or remote service. A representative sequence is: Das Expires 4 April 2027 [Page 129] Internet-Draft Earned Authority: Interim Validation October 2026 App -> Binder/SystemFS -> E_i -> R_i -> IEVService -> Gamma_{i+1} -> SystemFS. Figure 54 The proposing app cannot directly write the IEV decision state. B.20. 20. Android Protected Binder Interface The IEV service may expose narrowly defined operations such as: * submitEvidence; * requestContinuation; * queryDecision. It need not expose an app-callable setPass function. A Binder request may be accepted only if: CallerUID in AuthorizedUIDs Figure 55 and required act/phase/nonces are valid. B.21. 21. Android Hardware-Backed Key IMPLEMENTATION PATTERN The IEV may authenticate a continuation instruction using a hardware- backed validator key: Das Expires 4 April 2027 [Page 130] Internet-Draft Earned Authority: Interim Validation October 2026 CVI_{i+1} = Sign_{K_{IEV}} <= ft( D_A, H(R_i), i+1, Scope_{i+1}, Expiry_{i+1} ). Figure 56 The security hardware need not implement the entire IEV policy. It may protect the key used to prove that an authorized IEV instance produced the continuation decision. B.22. 22. Android TEE IMPLEMENTATION PATTERN Some or all validation may run in a trusted execution environment. The normal-world process supplies an authenticated validation input, and trusted-world logic evaluates: delta_i = V_i(R_i,S_i^{IEV}). Figure 57 On PASS, the protected component may sign a CVI, unseal a key, advance a counter, or set protected continuation state. B.23. 23. Android App-Only / Backend IMPLEMENTATION PATTERN No OEM modification is required in another embodiment. An ordinary Android application may use a server-side Finality Sink and remote IEV: Das Expires 4 April 2027 [Page 131] Internet-Draft Earned Authority: Interim Validation October 2026 AndroidApp -> BackendFS_i -> E_i -> R_i -> RemoteIEV -> Gamma_{i+1} -> BackendFS_{i+1}. Figure 58 This preserves the IEV functional sequence even though the validator is remote rather than device-resident. B.24. 24. iOS / iPadOS IMPLEMENTATION PATTERN An iOS or iPadOS application may use a local helper or extension where permitted, a Secure-Enclave-assisted key, app-integrity evidence, a remote IEV, or combinations thereof. The strongest commercial implementation may place the effect- controlling Finality Sink and IEV on a backend service while the sandboxed app remains the proposal interface. A representative sequence is: iOSApp -> BackendFS_i -> E_i -> R_i -> RemoteIEV -> Gamma_{i+1} -> BackendFS_{i+1}. Figure 59 Das Expires 4 April 2027 [Page 132] Internet-Draft Earned Authority: Interim Validation October 2026 B.25. 25. iOS Secure-Key-Assisted IEV A protected device key may authenticate locally generated validation evidence or continuation state: CVI_{i+1} = Sign_{K_{secure}} (D_A,H(R_i),i+1,Scope_{i+1}). Figure 60 The key protection mechanism may be local while the policy engine remains remote. B.26. 26. macOS Helper / XPC IMPLEMENTATION PATTERN An application may separate the agent, validator, and effect broker into distinct application components or services: AgentApp -> EffectHelper -> E_i -> R_i -> IEVService -> Gamma_{i+1} -> EffectHelper. Figure 61 The helper may hold privileges not granted to the agent process. B.27. 27. Windows Service IMPLEMENTATION PATTERN A Windows deployment may use a restricted application or AppContainer for the proposer and a separate broker service for actual effects. Das Expires 4 April 2027 [Page 133] Internet-Draft Earned Authority: Interim Validation October 2026 RestrictedApp -> BrokerFS_i -> E_i -> R_i -> IEVService -> Gamma_{i+1} -> BrokerFS_{i+1}. Figure 62 The restricted application need not possess the broker's full credential or device privilege. B.28. 28. Windows VBS-Enclave-Assisted IMPLEMENTATION PATTERN Sensitive IEV keys, counters, receipt-chain roots, or critical predicates may be placed in a VBS-protected enclave or comparable protected environment. The host IEV may call protected enclave logic to establish: Gamma_{i+1} Figure 63 only after required predicates are satisfied. B.29. 29. Ordinary Desktop Application IMPLEMENTATION PATTERN An implementation need not use kernel modification, TEE, or virtualization. A conventional application suite may separate: * frontend; * AI/agent process; * effect broker; * IEV service; * receipt store. Das Expires 4 April 2027 [Page 134] Internet-Draft Earned Authority: Interim Validation October 2026 OS identities and access-control lists may be sufficient for a lower- assurance commercial deployment, while the same functional sequence is retained. B.30. 30. Same-Process Lower-Assurance IMPLEMENTATION PATTERN The IEV may be a module in the same process as the agent in a lower- assurance implementation: Application= {AgentModule,IEVModule,EffectModule}. Figure 64 Logical protection may be provided using cryptographic state, memory- safe encapsulation, internal capabilities, type-level state machines, or signed internal transitions. This embodiment has weaker isolation but does not alter the functional ordering. B.31. 31. Local-Plus-Remote Validator A system may combine: IEV_{local} Figure 65 and: IEV_{remote}. Figure 66 High-consequence continuation may require: Pass_{local} AND Pass_{remote}. Figure 67 Lower-consequence continuation may require only one validator according to policy. B.32. 32. Application Backend Finality A client application may never possess final authority. The authoritative state may exist only on a backend. Das Expires 4 April 2027 [Page 135] Internet-Draft Earned Authority: Interim Validation October 2026 For example: Client -> CandidateRequest -> BackendFS_i -> E_i -> R_i -> BackendIEV. Figure 68 This is especially useful for mobile apps, browser apps, SaaS products, and managed enterprise clients. B.33. 33. SEND / Communication Example Assume an application intends to send full payload M to recipient A. The first phase sends a real bounded trailer: P_0=Send(Trailer_A). Figure 69 A recipient-side or service-side observer produces: R_0=(RecipientID,EndpointID,Binding,DeliveryState,Nonce,Timestamp). Figure 70 The IEV checks, for example: RecipientID(R_0)=A Figure 71 and: Binding(R_0)=H(M). Figure 72 If valid: Das Expires 4 April 2027 [Page 136] Internet-Draft Earned Authority: Interim Validation October 2026 IEV -> CVI_{SEND} -> FS_{SEND} -> Send(M). Figure 73 If the observed recipient is B\neq A: RecipientID(R_0)=B != A, Figure 74 then ordinary full-message continuation is withheld. B.34. 34. Payment Example For a proposed payment: A=Pay(Payer,Beneficiary,Amount,Currency), Figure 75 a first real bounded phase may be a hold, beneficiary verification transfer, limited authorization, or reserved transaction. The receipt may be validated using: Beneficiary(R_0)=Beneficiary_A, Figure 76 Currency(R_0)=Currency_A, Figure 77 State(R_0) in mathcal{A}_{payment}. Figure 78 Only then may broader capture or settlement become eligible. B.35. 35. File / Data Release Example A file-release system may first transmit a manifest, ciphertext fragment, trailer, or bounded file portion. E_0=Release(BoundedObject). Figure 79 Das Expires 4 April 2027 [Page 137] Internet-Draft Earned Authority: Interim Validation October 2026 The remote system returns evidence of tenant, storage account, destination, object identifier, digest, or persistence state. After IEV validation: Gamma_{1}=CVI_{FILE} Figure 80 may enable the remaining chunks, promotion, share capability, or decryption key. B.36. 36. AI Tool-Use Example An AI agent proposes a tool invocation: A=ToolCall(Tool,Args,Destination). Figure 81 A first bounded tool effect occurs under a Finality Sink. The effect evidence is evaluated independently of the model's textual assertion of success. Thus: ModelSaysSuccess !=> IEVPass. Figure 82 Only protected evidence can satisfy required continuation predicates. B.37. 37. GPU / Accelerator Example An accelerator may complete computation without automatically authorizing data egress. Das Expires 4 April 2027 [Page 138] Internet-Draft Earned Authority: Interim Validation October 2026 Compute_i -> R_i^{device} -> IEV -> Gamma_{egress} -> EgressFS. Figure 83 Evidence may bind workload digest, device identity, firmware state, memory region, DMA destination, or output digest. B.38. 38. Database / Storage Example A provisional database state may be created first: ProvisionalCommit_i -> R_i^{db} -> IEV -> PromotionPermit_{i+1} -> DBFS -> AuthoritativeCommit. Figure 84 The same sequence applies if the validator is implemented in a database service, host daemon, VM, remote policy service, or enclave. B.39. 39. Software / Firmware Rollout Example A bounded canary activation may produce: E_i=CanaryActivation. Figure 85 Health, integrity, compatibility, and error evidence form R_i. Then: Das Expires 4 April 2027 [Page 139] Internet-Draft Earned Authority: Interim Validation October 2026 R_i -> IEV -> RolloutPermit_{i+1} -> UpdateFS. Figure 86 B.40. 40. Human Escalation in Software If the IEV identifies a mismatch, a protected UI may display the expected and observed states. The resulting human decision is returned to the IEV: HumanDecision_i -> IEV -> Gamma_{i+1}. Figure 87 Human approval does not need to operate as direct unrestricted execution authority. B.41. 41. Fully Automatic Remediation A mismatch may instead cause: IEV -> AutomatedRemediation -> RemediationProposal -> IEV. Figure 88 The IEV may then establish only a bounded remediation condition. B.42. 42. Process Crash and Recovery If a CVI is issued but consumption is unknown: Das Expires 4 April 2027 [Page 140] Internet-Draft Earned Authority: Interim Validation October 2026 CVIState=ISSUED_NOT_CONFIRMED. Figure 89 After restart the system determines whether it is: PROVEN_NOT_CONSUMED, quad PROVEN_CONSUMED, quad UNKNOWN. Figure 90 An unknown state does not automatically authorize reissuance. B.43. 43. Effect Occurred but Receipt Missing If E_i occurred but R_i was not delivered, the software system does not blindly repeat E_i. Instead it reconciles using one or more of: (D_A,i,Nonce,TransactionID,IdempotencyID,c_i). Figure 91 B.44. 44. Anti-Bypass Requirement For each act-equivalent path q: EffectCapable(q) => RequireProtectedContinuation(q) Figure 92 or the path is disabled or rendered unable to complete the relevant effect. Potential bypasses include alternate sockets, API clients, credentials, filesystem paths, database roles, debug interfaces, subprocesses, privileged helpers, device handles, or alternate IPC routes. Das Expires 4 April 2027 [Page 141] Internet-Draft Earned Authority: Interim Validation October 2026 B.45. 45. Validator-Substitution Invariance B.45.1. 45.1 Core principle The identity, process type, operating system, virtualization technology, or physical location of the IEV does not define the functional sequence. Let: mathcal{V}= { VM, MicroVM, LinuxDaemon, AndroidService, iOSLocalHelper, RemoteIEV, WindowsService, Enclave, AppProcess, DistributedValidator }. Figure 93 For each concrete implementation: v in mathcal{V}, Figure 94 define its validator function as: V^{(v)}_i(R_i,S_i^{(v)}). Figure 95 The implementation is functionally conforming when it preserves the required interface contract: mathcal{C}= { InputEvidence, ProtectedValidation, Decision, ProtectedContinuationOutput }. Das Expires 4 April 2027 [Page 142] Internet-Draft Earned Authority: Interim Validation October 2026 Figure 96 The canonical sequence is therefore invariant under validator substitution: boxed{ E_i -> R_i -> V^{(v)}_i -> Gamma^{(v)}_{i+1} -> FS_{i+1} -> E_{i+1}, quad forall v in mathcal{V}. } Figure 97 B.45.2. 45.2 Functional equivalence relation Two validator implementations v_a and v_b are functionally equivalent for the disclosed inter-phase role when: v_asim_F v_b Figure 98 if both satisfy: ValidInputContract(v), Figure 99 ProtectedDecisionState(v), Figure 100 BoundContinuation(v), Figure 101 and: NoOrdinaryNextEffectWithoutContinuation(v). Das Expires 4 April 2027 [Page 143] Internet-Draft Earned Authority: Interim Validation October 2026 Figure 102 Accordingly: ChangeValidatorImplementation !=> ChangeFunctionalSequence. Figure 103 B.46. 46. Validator Substitution Example - Linux Daemon to Isolated VM Implementation A: E_i -> R_i -> LinuxDaemonIEV -> CVI_{i+1} -> FS_{i+1}. Figure 104 Implementation B: E_i -> R_i -> VM_{IEV} -> CVI_{i+1} -> FS_{i+1}. Figure 105 The isolation boundary changes, but the causal relationship does not: Das Expires 4 April 2027 [Page 144] Internet-Draft Earned Authority: Interim Validation October 2026 R_i prec IEVPass_i prec Gamma_{i+1} prec E_{i+1}, Figure 106 where \prec denotes required causal precedence. B.47. 47. Validator Substitution Example - Android Local Service to Remote IEV Local Android realization: E_i -> R_i -> AndroidIEVService -> Gamma_{i+1} -> SystemFS. Figure 107 Remote realization: E_i -> R_i -> RemoteIEV -> SignedCVI_{i+1} -> BackendFS. Figure 108 The communication transport and trust boundary differ, but the required sequence remains: Das Expires 4 April 2027 [Page 145] Internet-Draft Earned Authority: Interim Validation October 2026 Effect -> Evidence -> IndependentValidation -> ProtectedContinuation -> NextEffect. Figure 109 B.48. 48. Validator Substitution Example - Windows Service to VBS- Assisted Validator Software service: R_i -> WindowsIEVService -> CVI_{i+1}. Figure 110 VBS-assisted implementation: R_i -> HostIEV -> VBSProtectedLogic -> CVI_{i+1}. Figure 111 Moving key material or critical predicates into a protected enclave increases assurance but does not alter phase semantics. B.49. 49. Validator Substitution Example - iOS Local/Remote Mix One implementation may use a local device component to authenticate device-side state and a remote validator to make the continuation decision: Das Expires 4 April 2027 [Page 146] Internet-Draft Earned Authority: Interim Validation October 2026 R_i -> LocalAttestation -> RemoteIEV -> Gamma_{i+1}. Figure 112 Another implementation may place all validation remotely: R_i -> RemoteIEV -> Gamma_{i+1}. Figure 113 Both preserve the inter-phase dependency when the Finality Sink still requires \Gamma_{i+1}. B.50. 50. Validator Substitution Example - Same Process to Separate Process Lower-assurance realization: AppProcess: quad R_i -> IEVModule -> State^{cont}_{i+1}. Figure 114 Higher-assurance realization: AppProcess -> R_i -> IEVProcess -> AuthenticatedCVI_{i+1}. Das Expires 4 April 2027 [Page 147] Internet-Draft Earned Authority: Interim Validation October 2026 Figure 115 The implementation changes from intra-process isolation to inter- process isolation, but the required logical order remains unchanged. B.51. 51. Validator Substitution Example - Single IEV to Threshold IEV Single validator: Pass_i=V_i(R_i,S_i^{IEV}). Figure 116 Threshold realization: SUM _{j=1}^{n}mathbf{1}[Pass_i^{(j)}=true] >= m. Figure 117 Only after the threshold rule is met is \Gamma_{i+1} established. Again: E_i -> R_i -> Validation -> Gamma_{i+1} -> E_{i+1} Figure 118 is unchanged. B.52. 52. Validator Substitution Example - Token to Protected State Implementation A uses an explicit CVI: R_i -> IEV -> CVI_{i+1} -> FS_{i+1}. Das Expires 4 April 2027 [Page 148] Internet-Draft Earned Authority: Interim Validation October 2026 Figure 119 Implementation B uses no transferable object: R_i -> IEV -> State^{cont}_{i+1}=VALID -> FS_{i+1}. Figure 120 Therefore the continuation representation may change without changing the functional sequence. B.53. 53. Validator Substitution Example - Software Key to Hardware Latch Software realization: Gamma_{i+1}=CVI_{i+1}. Figure 121 Hardware-assisted realization: Gamma_{i+1}=L_{IEV}=PASS_i. Figure 122 The Finality Sink may require: Enable_{i+1}=FSValid_{i+1} AND (L_{IEV}=PASS_i). Figure 123 The continuation mechanism changes, while the protected dependency remains. B.54. 54. Implementation Independence Statement The disclosed architecture therefore distinguishes functional role from implementation location. The following are implementation choices: Das Expires 4 April 2027 [Page 149] Internet-Draft Earned Authority: Interim Validation October 2026 * process or VM boundary; * operating system; * local or remote execution; * hardware-backed or software-only cryptography; * token or tokenless continuation; * single or distributed validator; * application-owned or platform-owned service. The functional role is instead characterized by: ObservedPriorEffect -> ProtectedIndependentValidation -> TechnicallyRequiredNextPhaseCondition. Figure 124 B.55. 55. Platform-Independent Enhanced IMPLEMENTATION PATTERN A preferred implementation includes: 1. an act-generating application or AI agent in a first protection domain; 2. a Finality Sink outside unrestricted control of the act- generating component; 3. a first real bounded effect; 4. a protected evidence path from an observer to an IEV; 5. protected validator state not arbitrarily writable by the proposer; 6. validation of actual effect evidence against expected effect conditions; 7. generation or establishment of a continuation condition bound to the prior effect evidence; 8. effectuation-time verification by the next Finality Sink; Das Expires 4 April 2027 [Page 150] Internet-Draft Earned Authority: Interim Validation October 2026 9. prevention of the next effect in the absence of the continuation condition; 10. replay protection; 11. indeterminate-state reconciliation; 12. policy and revocation revalidation; 13. optional human, automatic, or hybrid remediation; and 14. anti-bypass enforcement across act-equivalent paths. B.56. 56. Mathematical Platform-Neutral Invariant For any conforming implementation v\in\mathcal{V}, define: delta_i^{(v)}=V_i^{(v)}(R_i,S_i^{(v)}). Figure 125 Define continuation establishment as: Gamma_{i+1}^{(v)}= G^{(v)} <= ft( delta_i^{(v)}, D_A, H(R_i), P_{i+1}, p_i, r_i ). Figure 126 The next effect is permitted only when: Enable^{(v)}(E_{i+1})={} ContinuationValid(Gamma_{i+1}^{(v)}) AND PolicyCurrent(p_i) AND RevocationClear(r_i) AND DestinationValid(Dest_{i+1}) AND ScopeAuthorized(P_{i+1}). Figure 127 Das Expires 4 April 2027 [Page 151] Internet-Draft Earned Authority: Interim Validation October 2026 Thus the architecture is invariant to validator realization when these logical conditions remain enforced. B.57. 57. Final Technical Statement The IEV is not defined by whether it is a Linux daemon, Android service, iOS-associated service, Windows service, isolated VM, enclave, microVM, cloud service, application module, or distributed validator set. It is defined functionally by the protected causal relationship between an earlier real effect and authority for a later real effect. ValidatorLocation != ValidatorFunction. Figure 128 ChangeOfValidator != ChangeOfFunctionalSequence. Figure 129 The operative invariant is: boxed{ E_i -> R_i -> IEV_i -> Gamma_{i+1} -> FS_{i+1} -> E_{i+1}. } Figure 130 Das Expires 4 April 2027 [Page 152] Internet-Draft Earned Authority: Interim Validation October 2026 Accordingly, replacing one conforming validator implementation with another changes the deployment topology, assurance boundary, transport, or platform integration, but does not change the disclosed inter-phase effectuation sequence so long as the next consequential effect remains technically dependent on protected validation of the earlier real effect. Appendix C. Taint-Aware Boundary Mediation, Credential Surrogation, and Privilege Separation This appendix gives non-limiting implementation patterns for taint and provenance propagation, origin attribution, surrogate credentials, protected credential resolution, privilege-separated connectors, boundary invariance, and taint-aware IEV progression. title: "TAINT-AWARE BOUNDARY CREDENTIAL SURROGATION, PRIVILEGE- SEPARATED EFFECTUATION, AND IEV-GATED PROGRESSIVE EFFECTUATION" subtitle: "Non-Limiting Software, OS, VM, Connector, Browser, Credential-Broker and Interim Effectuation Validator Embodiment" author: "Technical Specification Draft" date: "October 1, 2026" geometry: margin=20mm fontsize: 10pt papersize: a4 header-includes: \usepackage{amsmath,amssymb,mathtools,array,longtable,booktabs,microtype,xcolor,fancyhdr,enumitem} \usepackage[T1]{fontenc} \usepackage{fvextra} \DefineVerbatimEnvironment{Highlighting}{Verbatim}{breaklines=true,breakanywhere=true,commandchars=\\\{\}} \setlist[itemize]{leftmargin=1.4em,itemsep=2pt,topsep=3pt} \setlist[enumerate]{leftmargin=1.6em,itemsep=2pt,topsep=3pt} \pagestyle{fancy} \fancyhf{} \fancyhead[L]{IEV - Taint-Aware Boundary Surrogation Embodiment} \fancyhead[R]{Technical Specification Draft} \fancyfoot[C]{\thepage} \setlength{\headheight}{14pt} \renewcommand{\arraystretch}{1.15} * | C.1. 1. Purpose and Scope This embodiment describes a layered execution-control architecture in which an act-generating component - including an AI agent, application, workflow engine, browser-driving process, tool-use system, or autonomous software component - may possess extensive computational capability while lacking unrestricted authority to cause consequential external effects. The architecture may combine, in any compatible arrangement: * isolation of the act-generating domain; * semantic, process, context, provenance, or information-flow taint; Das Expires 4 April 2027 [Page 153] Internet-Draft Earned Authority: Interim Validation October 2026 * protected process and request attribution; * restriction of direct effect-capable interfaces; * surrogate, reference, handle, or non-exportable credential representations inside the lower-trust domain; * protected substitution, exchange, activation, or use of the actual credential only at an effectuation boundary; * privilege-separated connector workers; * destination and route verification; * independent safety or risk classifiers; * a first real bounded effect; * protected evidence of what actually occurred; * independent Interim Effectuation Validator (IEV) evaluation of the resulting evidence; * protected continuation authority for a subsequent phase; and * effectuation-time revalidation at a Finality Sink. The central functional sequence is: \boxed{ \begin{aligned} A_i &\rightarrow \operatorname{OriginAttribution}_i \\ &\rightarrow \operatorname{TaintEvaluation}_i \\ &\rightarrow \operatorname{ProtectedPolicy}_i \\ &\rightarrow \operatorname{BoundaryCredentialResolution}_i \\ &\rightarrow FS_i \\ &\rightarrow E_i \\ &\rightarrow R_i \\ &\rightarrow IEV_i \\ &\rightarrow \Gamma_{i+1} \\ &\rightarrow \operatorname{EffectuationTimeRevalidation}_{i+1} \\ &\rightarrow FS_{i+1} \\ &\rightarrow E_{i+1}. \end{aligned}} The sequence is non-limiting. Compatible implementations may combine steps, distribute steps across components, or realize a protected continuation condition without an explicit transferable token. Das Expires 4 April 2027 [Page 154] Internet-Draft Earned Authority: Interim Validation October 2026 C.2. 2. Formal Notation | Symbol | Meaning | |---|---| | A_i | Candidate Act or requested consequential operation for phase i | | D_A | canonical or otherwise protected digest/binding of the Candidate Act | | \mathcal D_A | act- originating or lower-trust execution domain | | \mathcal D_P | protected execution/control domain | | FS_i | Finality Sink controlling whether phase i becomes effective | | E_i | actual real effect of phase i | | R_i | protected effect evidence or receipt corresponding to E_i | | IEV_i | Interim Effectuation Validator acting between phases i and i+1 | | S_i^{IEV} | protected IEV state at phase i | | \tau(x) | taint state associated with object, process, context, request, or act x | | \mathcal T | set of supported taint states | | \sigma_i | surrogate credential, credential handle, alias, or non-authoritative credential reference | | K_i^{real} | actual effect-capable credential or protected secret material | | \Gamma_{i+1} | generic protected continuation condition for phase i+1 | | CVI_{i+1} | one implementation of \Gamma_{i+1} as a Continuation Validation Instruction | | X_i | expected effect for phase i | | O_i | observed effect for phase i | | \epsilon_i | permitted tolerance for a comparison | | \mathcal A_i | authorized set of acceptable observed results | | p_i | policy state or policy epoch | | r_i | revocation state or revocation epoch | | Ctr_i | protected counter | | Prov_i | provenance state or digest | | B_i | protected effectuation boundary used for phase i | | q | an alternative act-equivalent effect-capable path | A taint-state set may, for example, be: \mathcal T = \{\mathrm{CLEAN},\mathrm{TAINTED},\mathrm{UNVERIFIABLE}\}. The particular names, cardinality, and ordering of taint states are non-limiting. C.3. 3. Act-Originating Domain and Protected Domain The Candidate Act may originate from an AI agent, application, model process, browser automation component, code-generation system, tool- use agent, subagent, containerized workload, virtual machine, mobile app, desktop app, or remote service. The act-originating component may execute in: \mathcal D_A, while protected effectuation, credential, policy, and validation services may execute in: Das Expires 4 April 2027 [Page 155] Internet-Draft Earned Authority: Interim Validation October 2026 \mathcal D_P. A preferred relationship is: \mathcal D_A \neq \mathcal D_P. The separation may be implemented using a separate process, operating-system identity, container, namespace, microVM, virtual machine, hypervisor partition, trusted execution environment, system service, security processor, DPU, SmartNIC, secure gateway, remote service, or another protected domain. The architecture distinguishes: \boxed{\operatorname{ProposalAuthority} \neq \operatorname{EffectuationAuthority}.} The act-generating component may construct a request without possessing the material or protected state required to complete the effect. C.4. 4. Taint Classification A process, data object, context unit, tool result, request, Candidate Act, or resource may carry a taint state: \tau(x) \in \mathcal T. Taint may represent, without limitation: * exposure to untrusted external content; * private or regulated information; * prompt-injection-capable material; * sensitive credentials or secrets; * downloaded content; * unknown or conflicting provenance; * tool output; * user-private context; * compromised or unverified execution state; Das Expires 4 April 2027 [Page 156] Internet-Draft Earned Authority: Interim Validation October 2026 * risk-relevant behavioral history. Taint may be semantic rather than purely byte-level. A summary, embedding, transformed object, retrieved memory item, or derived instruction may remain tainted even where the original bytes are not retained. C.5. 5. Taint Propagation A taint state may propagate across process, data, tool, memory, connector, network, or Candidate-Act boundaries. An illustrative propagation rule is: \tau_{out} = \operatorname{Join} \left( \tau_{process}, \tau_{input_1}, \ldots, \tau_{input_n} \right). For a downstream Candidate Act: \tau(A_{i+1}) = \operatorname{Propagate} \left( \tau(A_i), \tau(Context), \tau(ToolOutputs), \tau(Prov_i) \right). A fail-safe rule may provide: \operatorname{UnableToValidateTaint} \not\Rightarrow \mathrm{CLEAN}. Instead: \operatorname{UnableToValidateTaint} \Rightarrow \mathrm{UNVERIFIABLE}. An unverifiable state may result in denial, reduced scope, re- attestation, human review, additional validation, quarantine, or a bounded diagnostic phase. C.6. 6. Taint Representation Taint may be represented using any compatible machine-verifiable mechanism, including: * process metadata; * context metadata; * kernel labels; * LSM labels; Das Expires 4 April 2027 [Page 157] Internet-Draft Earned Authority: Interim Validation October 2026 * cgroup state; * security contexts; * protected tags; * cryptographic tags; * provenance graphs; * signed labels; * database metadata; * policy-engine state; * secure runtime state; * hypervisor metadata; * remote attestation state. The embodiment is not limited to Linux, eBPF, LSM, or any particular implementation. C.7. 7. Protected Origin Attribution A protected enforcement component may determine which process, workload, task, agent, subagent, VM, container, user, session, or execution context caused a request. Let: \operatorname{Origin}(Q) represent the protected origin attribution of request Q. Attribution may derive from: * process credentials; * UID/GID; * peer credentials; * cgroup membership; * namespace identity; Das Expires 4 April 2027 [Page 158] Internet-Draft Earned Authority: Interim Validation October 2026 * executable measurement; * code signature; * VM identity; * container identity; * attestation; * authenticated IPC; * cryptographic session identity. The protected policy may then evaluate: F\big(\operatorname{Origin}(Q),\tau(\operatorname{Origin}(Q)),Destination,Scope,Policy\big). C.8. 8. Taint-Dependent Policy A protected policy may differentiate clean, tainted, and unverifiable states. For example: \operatorname{AutoAllow}_i = \operatorname{Clean}_i \land \operatorname{NarrowPolicyMatch}_i \land \operatorname{DestinationValid}_i \land \operatorname{ScopeValid}_i. A tainted request may satisfy: \mathrm{TAINTED} \Rightarrow \neg\operatorname{AutoAllow}. An unverifiable request may similarly satisfy: \mathrm{UNVERIFIABLE} \Rightarrow \neg\operatorname{AutoAllow}. The protected decision may be selected from, for example: \{\mathrm{ALLOW},\mathrm{DENY},\mathrm{ASK},\mathrm{BOUNDED\_TRIAL},\mathrm{REDUCE\_SCOPE},\mathrm{RECONCILE}\}. C.9. 9. Surrogate Credential Concept The lower-trust domain may possess a surrogate credential or credential reference: \sigma_i. Das Expires 4 April 2027 [Page 159] Internet-Draft Earned Authority: Interim Validation October 2026 The surrogate may have the syntax or appearance of a token, key, session object, handle, cookie, credential alias, certificate reference, account reference, key slot, or credential object without granting unrestricted authority by possession alone. The actual effect-capable credential is denoted: K_i^{real}. A preferred relationship is: \boxed{\sigma_i \neq K_i^{real}.} The actual credential may be absent from the memory of the act- generating component: K_i^{real}\notin \operatorname{Memory}(\mathcal D_A). C.10. 10. Surrogate Scope and Binding A surrogate may be bound to one or more of: \sigma_i = \operatorname{Bind} (Principal,Service,CredentialClass,Session,Scope,Expiry,Nonce,Phase). The surrogate may be single-use, session-scoped, task-scoped, destination-scoped, service-scoped, phase-scoped, act-scoped, time- limited, non-bearer, or otherwise restricted. The surrogate need not contain a recoverable representation of the real credential. C.11. 11. Protected Credential Authority The actual credential may be maintained by a protected credential authority implemented as a credential daemon, HSM, TEE, secure enclave, separate process, separate VM, remote secret manager, operating-system key store, payment key service, cloud key service, security processor, or other protected component. A protected credential authority may expose operations such as: * resolve handle; * sign request; * insert credential; Das Expires 4 April 2027 [Page 160] Internet-Draft Earned Authority: Interim Validation October 2026 * unwrap phase key; * generate bounded authorization; * perform cryptographic operation; * release a one-time credential; * or use a credential without exporting it. C.12. 12. Boundary Credential Substitution or Resolution At a protected boundary B_i, the system may detect a surrogate or credential reference and, only after required checks, resolve: \sigma_i \longmapsto K_i^{real}. Equivalent terminology may include boundary credential substitution, boundary swap, late credential binding, just-in-time credential resolution, surrogate redemption, protected credential insertion, credential materialization, or protected credential activation. The act-generating component need not observe K_i^{real}. C.13. 13. Boundary Swap Predicate For an initial phase, an illustrative boundary condition is: \begin{aligned} \operatorname{SwapAllowed}_i={}& \operatorname{SurrogateValid}(\sigma_i)\\ &\land\operatorname{OriginAuthorized}_i\\ &\land\operatorname{PolicyCurrent}_i\\ &\land\operatorname{TaintPermitted}_i\\ &\land\operatorname{DestinationValid}_i\\ &\land\operatorname{ScopeValid}_i. \end{aligned} For a subsequent IEV-gated phase: \begin{aligned} \operatorname{SwapAllowed}_{i+1}={}& \operatorname{SurrogateValid}(\sigma_{i+1})\\ &\land\operatorname{ContinuationValid}(\Gamma_{i+1})\\ &\land\operatorname{PolicyCurrent}_{i+1}\\ &\land\operatorname{RevocationClear}_{i+1}\\ &\land\operatorname{DestinationCurrent}_{i+1}\\ &\land\operatorname{TaintAcceptable}_{i+1}. \end{aligned} Das Expires 4 April 2027 [Page 161] Internet-Draft Earned Authority: Interim Validation October 2026 C.14. 14. Credential Is Not Returned to the Agent A protected boundary may: 1. receive an outbound request containing or referencing \sigma_i; 2. authenticate the originating process; 3. evaluate taint and protected policy; 4. obtain or use K_i^{real} internally; 5. construct or modify the concrete outbound request; 6. transmit the request; 7. erase transient credential material where applicable; and 8. generate protected evidence of the resulting effect. At no stage need the real credential be returned to the act- generating component. C.15. 15. Finality Sink Incorporating Credential Resolution A boundary performing protected credential resolution may constitute all or part of a Finality Sink: FS_i = \{Policy,Boundary,CredentialResolution,RequestVerification,EffectGate\}. The ability to resolve \sigma_i into effect-capable use of K_i^{real} may itself be protected execution material without which the effect cannot be completed. C.16. 16. Privilege-Separated Connector Execution Connector logic may be divided into a lower-trust stub and a protected worker: Agent \rightarrow ConnectorStub \rightarrow ProtectedIPC \rightarrow Worker_j. The stub may parse typed arguments and provide them to the worker. The worker may alone possess authority to interact with external APIs, payment systems, databases, privileged files, cloud services, network destinations, or devices. Das Expires 4 April 2027 [Page 162] Internet-Draft Earned Authority: Interim Validation October 2026 Worker-specific authority may satisfy: Credentials(W_j)\subseteq AllowedCredentialSet_j. For different workers: Credentials(W_a)\cap Credentials(W_b)=\varnothing where separation is desired. C.17. 17. Three Distinct Security Functions In one embodiment, three functions are logically distinguished: 1. Privilege placement - where effect-capable code executes. 2. Credential authority - which protected credential or credential class may be used. 3. Effectuation authority - whether the concrete consequential operation may become effective. These functions may be physically separate or combined while maintaining logically distinct protected state. C.18. 18. Network Boundary The lower-trust execution domain may lack unrestricted network egress. Traffic may be forced through: \mathcal D_A \rightarrow NetworkFS \rightarrow ExternalNetwork. The network Finality Sink may evaluate: * hostname; * resolved destination; * port and protocol; * HTTP method and path; * request-body digest; * headers; Das Expires 4 April 2027 [Page 163] Internet-Draft Earned Authority: Interim Validation October 2026 * recipient identity; * credential class; * process origin; * taint state; * purpose; * policy; * continuation state. A protected rule may require both logical and resolved destination checks: \operatorname{HostnameAllowed} \land \operatorname{ResolvedDestinationAllowed}. C.19. 19. Browser Broker A browser used by an agent may be controlled through a broker outside unrestricted control of the agent. The broker may restrict raw browser-process access, debugging interfaces, unrestricted JavaScript execution, direct credential extraction, raw DOM operations, or other privileged browser capabilities. The relevant relationship is: AgentBrowserAuthority \subset BrokerBrowserAuthority. Credentials stored by a user or protected credential service may be inserted into a browser form through a protected path without exposing them to the agent. C.20. 20. Independent Safety and Risk Classifiers One or more classifiers outside the act-generating domain may evaluate prompt injection, anomalous tool output, exfiltration patterns, suspicious requests, malicious instructions, or other risk categories. For classifiers C_1,\dots,C_n: ClassifierDecision = F(C_1,\ldots,C_n). Das Expires 4 April 2027 [Page 164] Internet-Draft Earned Authority: Interim Validation October 2026 The result may be one predicate among several: PreEffectPermit_i = PolicyPermit_i \land ClassifierClear_i \land TaintCondition_i. Classifier output need not itself constitute execution authority. C.21. 21. Candidate-Act Descriptor with Taint and Provenance A Candidate-Act descriptor may be: D_i= \{D_A,Origin_i,Scope_i,Destination_i,\tau_i,H(Prov_i),PolicyEpoch_i\}. A continuation condition may bind the next phase to a specific taint or provenance state: \Gamma_{i+1} = Protect(D_A,H(R_i),\tau_i,H(Prov_i),Scope_{i+1},\ldots). C.22. 22. Real Bounded First Effect After pre-effect checks, the Finality Sink may permit a first real bounded effect E_i such as: * trailer transmission; * bounded API request; * bounded payment or reservation; * provisional database change; * canary deployment; * bounded file release; * low-energy actuator motion; * network handshake; * bounded browser submission; * limited credential use. The effect is real and externally or persistently consequential, not merely simulated. Das Expires 4 April 2027 [Page 165] Internet-Draft Earned Authority: Interim Validation October 2026 C.23. 23. Protected Effect Receipt Including Boundary Context A receipt may bind both the observed effect and the protected pathway that produced it: R_i = Protect \left( D_A, i, Origin_i, \tau_i, CredentialClass_i, BoundaryID_i, DestinationID_i, RequestDigest_i, O_i, Timestamp_i, Ctr_i \right). The receipt may therefore allow the IEV to verify what was requested, which process caused it, which taint state applied, which protected boundary authorized it, which credential class was used, where the effect occurred, and what result was observed. C.24. 24. IEV Validation of Effect and Boundary Behavior The IEV may evaluate both effect correctness and protected-path correctness. An illustrative PASS expression is: \begin{aligned} IEVPass_i={}& \operatorname{AuthValid}(R_i)\\ &\land\operatorname{ActMatch}(R_i,D_A)\\ &\land\operatorname{OriginMatch}(R_i)\\ &\land\operatorname{TaintConsistent}(R_i)\\ &\land\operatorname{BoundaryExpected}(R_i)\\ &\land\operatorname{CredentialClassAllowed}(R_i)\\ &\land\operatorname{DestinationMatch}(R_i)\\ &\land\operatorname{EffectAcceptable}(O_i,X_i)\\ &\land\operatorname{PolicyCurrent}_i\\ &\land\operatorname{RevocationClear}_i. \end{aligned} C.25. 25. Effect Comparison Modes The IEV may use one or more comparison functions. Exact equality: O_i=X_i. Tolerance: d(O_i,X_i)\leq\epsilon_i. Scalar tolerance: |O_i-X_i|\leq\epsilon_i. Das Expires 4 April 2027 [Page 166] Internet-Draft Earned Authority: Interim Validation October 2026 Range: L_i\leq O_i\leq U_i. Authorized set: O_i\in\mathcal A_i. Predicate set: \bigwedge_{k=1}^{m} P_k(O_i)=\mathrm{true}. C.26. 26. Boundary Substitution Detection Suppose a phase is expected to use protected boundary B_1, while evidence indicates use of B_2. If: B_1\neq B_2 and B_2 is not an accepted equivalent protected boundary, the IEV may set: IEVDecision_i=\mathrm{FAIL}. This addresses substitution of the protected egress or effectuation path. C.27. 27. Equivalent Boundary A named proxy, daemon, kernel hook, gateway, or hardware block is not required. Two boundaries may be treated as functionally equivalent when both preserve required properties: \operatorname{EquivalentBoundary}(B_x,B_y)=\mathrm{true} where both enforce the required set of protected predicates, such as origin attribution, taint evaluation, credential isolation, destination verification, continuation gating, evidence generation, and anti-bypass. Replacing: Proxy\rightarrow KernelGate Das Expires 4 April 2027 [Page 167] Internet-Draft Earned Authority: Interim Validation October 2026 or: LinuxDaemon\rightarrow SmartNIC or: LocalBroker\rightarrow RemoteGateway need not alter the functional architecture. C.28. 28. Boundary-Substitution Invariance Let B_i be any boundary satisfying the required Finality-Sink properties. Then: \boxed{ A_i \rightarrow B_i \rightarrow E_i \rightarrow R_i \rightarrow IEV_i \rightarrow \Gamma_{i+1} \rightarrow B_{i+1} \rightarrow E_{i+1}.} Replacing B_i with B_i' preserves the architecture when: FunctionalProperties(B_i)=FunctionalProperties(B_i'). C.29. 29. Surrogate-Representation Invariance A surrogate need not be a token. It may be a credential handle, alias, slot, object reference, signed request reference, non- exportable capability, session reference, or other protected reference. Changing: \sigma_i^{token}\rightarrow\sigma_i^{handle} need not alter the architecture when neither representation independently exposes the real credential and both require protected boundary resolution. C.30. 30. No-Explicit-Surrogate Variant An implementation may use an implicit protected credential reference rather than an explicit surrogate value. Thus: ExplicitSurrogate and: Das Expires 4 April 2027 [Page 168] Internet-Draft Earned Authority: Interim Validation October 2026 ImplicitProtectedCredentialReference are alternative realizations of late credential binding. C.31. 31. Surrogate Plus IEV Continuation Possession of a next-phase surrogate does not itself authorize effectuation: Possess(\sigma_{i+1}) \not\Rightarrow EffectAuthority_{i+1}. Instead, an illustrative expression is: \boxed{ EffectAuthority_{i+1} = \operatorname{SurrogateValid}_{i+1} \land \operatorname{ContinuationValid}(\Gamma_{i+1}) \land \operatorname{BoundaryChecksValid}_{i+1}.} C.32. 32. Taint Plus Surrogate Gating A boundary may jointly evaluate the surrogate and current taint state: \begin{aligned} Authorize_i={}& \operatorname{SurrogateValid}(\sigma_i)\\ &\land\operatorname{CredentialClassAllowed}_i\\ &\land\operatorname{TaintPolicySatisfied}(\tau_i)\\ &\land\operatorname{DestinationAllowed}_i\\ &\land\operatorname{ScopeAllowed}_i. \end{aligned} A surrogate therefore does not bypass taint policy. C.33. 33. Taint Change Between Phases Taint may change after the first real effect: \tau_{before}\neq\tau_{after}. If the later state becomes tainted or unverifiable, the IEV may withhold or reduce continuation authority. A continuation condition may specify a maximum permitted taint state: \Gamma_{i+1}\supset\tau_{max}. The Finality Sink then verifies: \tau_{current}\preceq\tau_{max}. Das Expires 4 April 2027 [Page 169] Internet-Draft Earned Authority: Interim Validation October 2026 C.34. 34. Effectuation-Time Taint Revalidation Even after IEV PASS at time t_0, the Finality Sink may evaluate current state at effectuation time t_1. \begin{aligned} Enable(E_{i+1},t_1)={}& \operatorname{ContinuationValid}(\Gamma_{i+1})\\ &\land\operatorname{TaintCurrentAcceptable}(t_1)\\ &\land\operatorname{PolicyCurrent}(t_1)\\ &\land\operatorname{RevocationClear}(t_1)\\ &\land\operatorname{DestinationCurrent}(t_1). \end{aligned} Thus: IEVPass(t_0) \not\Rightarrow IrrevocableAuthority(t_1). C.35. 35. SEND Example - Tainted Context An AI reads untrusted content and proposes: SEND(File_X,Recipient_A). The agent is marked: \tau(Agent)=\mathrm{TAINTED}. The outbound request contains or references: \sigma_{mail}. Policy may prohibit full automatic release but permit a bounded trailer: P_0=SendTrailer. At the protected boundary: \sigma_{mail}\longmapsto K_{mail}^{real}. The real credential is used transiently without being disclosed to the agent. The recipient or service returns R_0. The IEV may check: Recipient(R_0)=Recipient_A and: Das Expires 4 April 2027 [Page 170] Internet-Draft Earned Authority: Interim Validation October 2026 TaintState(R_0)=\mathrm{TAINTED}. If required predicates pass, the IEV may establish: \Gamma_1=CVI_{FULL\_SEND}. If recipient, route, destination, or boundary evidence is misaligned, the full file remains non-effective. C.36. 36. SEND With Human Review For selected high-risk effects: \mathrm{TAINTED} \land \mathrm{ExternalDisclosure} \Rightarrow \mathrm{HumanReview}. A protected UI may display intended recipient, observed recipient, taint reason, bounded-trailer result, and proposed full send. A human decision returns to the protected authority or IEV rather than directly granting unrestricted execution authority to the agent. C.37. 37. SEND Without Human Review A fully automatic policy is also supported. For example: \mathrm{TAINTED} \land \operatorname{RecipientVerified} \land \operatorname{PolicyAllows} \Rightarrow \Gamma_{FULL\_SEND}. Thus a human is optional rather than architecturally required. C.38. 38. Payment Example An agent proposes: PAY(Beneficiary_B,Amount). The agent holds or references: \sigma_{pay} rather than the actual payment credential. The Finality Sink resolves or uses the actual payment credential only for a bounded first phase. The payment rail returns R_0. The IEV may verify: Das Expires 4 April 2027 [Page 171] Internet-Draft Earned Authority: Interim Validation October 2026 Beneficiary(R_0)=B, Account(R_0)=Account_{authorized}, Currency(R_0)=Currency_{authorized}, and: State(R_0)\in AuthorizedStates. Only then may a subsequent settlement or broader transfer become eligible. C.39. 39. Browser Example An agent visits a page containing potentially malicious content, causing: \tau(Agent)=\mathrm{TAINTED}. The agent attempts an authenticated submission without access to the real password or session secret. A protected browser broker inserts the credential and performs a bounded effect. The resulting evidence R_0 is evaluated by the IEV before broader continuation. C.40. 40. Connector Example An agent invokes a connector through a narrow stub: Agent\rightarrow ConnectorStub\rightarrow Worker_{calendar}. The calendar worker may be limited to calendar credentials and denied payment credentials: CredentialClass(Worker_{calendar})=Calendar. The resulting external service effect generates R_i, and the IEV may validate the created event before permitting a dependent operation such as sending invitations or booking travel. C.41. 41. Cross-Tool Taint Propagation If Tool 1 processes tainted information and its output influences Tool 2, then: \tau(Tool2Request) = \operatorname{Join} \big(\tau(Tool1Output),\tau(Agent)\big). Das Expires 4 April 2027 [Page 172] Internet-Draft Earned Authority: Interim Validation October 2026 A later communication, payment, file upload, database mutation, or device act can therefore inherit taint lineage. C.42. 42. Taint Snapshot in Receipt Chain Each receipt may preserve a taint snapshot: R_i\supset\tau_i. A receipt chain may capture: \tau_0,\tau_1,\ldots,\tau_n. An unexpected transition such as: \mathrm{CLEAN}\rightarrow\mathrm{TAINTED} may invalidate or narrow a previously contemplated continuation. C.43. 43. Durable-State Separation Durable application state, credential state, and IEV state may be physically or logically separated: Storage_{Agent} \neq Storage_{Credentials} \neq Storage_{IEV}. This prevents an agent with write access to its workspace from automatically modifying credential secrets, policy, consumed-receipt state, or continuation state. C.44. 44. Authenticated IPC Protected services may communicate over authenticated IPC or RPC. An operation may be permitted only when: Identity(Sender)\in ACL(Operation). The mechanism may use peer credentials, signed RPC, mutual TLS, local capabilities, secure mailboxes, hypervisor-authenticated channels, or equivalent protections. C.45. 45. Human Approval as a Protected Capability Where human approval is used, a protected approval object H_i may bind: H_i = Bind(Act,Destination,Scope,Session,Expiry,UseCount). Das Expires 4 April 2027 [Page 173] Internet-Draft Earned Authority: Interim Validation October 2026 A conversational response to an AI need not itself constitute the protected approval artifact. C.46. 46. Read/Write Privilege Separation A connector may distinguish read and write authority: Permission(ReadResource)=\mathrm{true} while: Permission(ModifyResource)=\mathrm{false}. Provider credential scope need not equal the effect scope granted to the agent: ProviderCredentialScope \neq AgentEffectScope. C.47. 47. Sensitive-Content Filtering A protected connector may withhold selected high-risk content from the agent, including one-time codes, password-reset links, security secrets, payment authentication codes, recovery codes, or private keys. This filtering is optional and may be combined with taint and IEV controls. C.48. 48. Protected Inference Path Inference requests themselves may be routed through a protected proxy or policy boundary that constrains model endpoints, telemetry, destination, request size, data classification, or authentication. This expresses the general principle: AgentRequest \neq UnrestrictedNetworkAuthority. C.49. 49. Defense in Depth The architecture does not depend on any one layer providing complete protection. Conceptually: Security = f(Isolation,Taint,PrivilegeSeparation,CredentialSurrogation,BoundaryPolicy,IEV,FinalitySink,HumanApproval,Evidence,AntiBypass). Das Expires 4 April 2027 [Page 174] Internet-Draft Earned Authority: Interim Validation October 2026 A classifier may fail while credential isolation, boundary mediation, and IEV-gated continuation still restrict consequential effects. C.50. 50. Strong Next-Phase Authorization Expression A subsequent phase may require: \boxed{ \begin{aligned} Enable(E_{i+1})={}& \operatorname{OriginAuthorized}_{i+1}\\ &\land\operatorname{TaintAcceptable}_{i+1}\\ &\land\operatorname{CredentialReferenceValid}_{i+1}\\ &\land\operatorname{ContinuationValid}(\Gamma_{i+1})\\ &\land\operatorname{PolicyCurrent}_{i+1}\\ &\land\operatorname{RevocationClear}_{i+1}\\ &\land\operatorname{DestinationValid}_{i+1}\\ &\land\operatorname{ScopeAuthorized}_{i+1}\\ &\land\operatorname{CredentialClassAllowed}_{i+1}. \end{aligned}} A required predicate that is false blocks ordinary continuation. A required predicate that is unknown may trigger reconciliation, reduced scope, re-attestation, safe state, or escalation. C.51. 51. Anti-Bypass For every act-equivalent effect-capable path q: EffectCapable(q) \Rightarrow RequireEquivalentProtectedGate(q). Otherwise: Disable(q). Potential alternate paths include raw sockets, alternate HTTP clients, shell commands, browser debugging interfaces, alternate credentials, direct connector code, unrestricted subprocesses, alternate network namespaces, direct device handles, database administrator credentials, debug interfaces, or recovery interfaces. C.52. 52. Implementation Independence The architecture does not require any particular named operating system, daemon, proxy, credential broker, container manager, kernel hook, classifier, or browser. A functional relationship is preserved when: Das Expires 4 April 2027 [Page 175] Internet-Draft Earned Authority: Interim Validation October 2026 \boxed{ UntrustedOrLowerTrustActSource \rightarrow ProtectedEffectuationBoundary \rightarrow RealEffect \rightarrow ProtectedEvidence \rightarrow IndependentIEV \rightarrow ProtectedNextPhaseAuthority.} C.53. 53. Replacement Invariance Across Security Mechanisms Taint implementation may change: eBPF/LSM \rightarrow KernelLabel \rightarrow RuntimeProvenanceGraph \rightarrow CryptographicTaintTag. Isolation may change: Container\rightarrow VM\rightarrow MicroVM\rightarrow RemoteService. Credential representation may change: SurrogateToken\rightarrow CredentialHandle\rightarrow ImplicitProtectedReference. Boundary implementation may change: ForwardProxy\rightarrow KernelNetworkGate\rightarrow SmartNIC\rightarrow RemoteGateway. Validator implementation may change: LocalIEV\rightarrow RemoteIEV\rightarrow TEEIEV\rightarrow ThresholdIEV. These changes need not alter the core functional sequence. C.54. 54. Combined Invariance Function Let I denote an isolation mechanism, T a taint mechanism, S a credential-surrogation mechanism, B an effectuation boundary, and V an IEV implementation. Define: \Phi(I,T,S,B,V) as a particular implementation of the architecture. For two implementations: \Phi_1=\Phi(I_1,T_1,S_1,B_1,V_1) Das Expires 4 April 2027 [Page 176] Internet-Draft Earned Authority: Interim Validation October 2026 and: \Phi_2=\Phi(I_2,T_2,S_2,B_2,V_2), the implementations may differ while remaining functionally equivalent if both preserve: \boxed{ A_i \rightarrow ProtectedPreEffectValidation_i \rightarrow E_i \rightarrow R_i \rightarrow IndependentValidation_i \rightarrow ProtectedContinuation_{i+1} \rightarrow E_{i+1}.} C.55. 55. Non-Limiting Pseudocode - Protected Taint-Aware Boundary and IEV Workflow The following pseudocode is illustrative only. Functions may be combined, reordered where causally compatible, distributed across different components, or realized in hardware, software, firmware, a remote service, or protected state transitions. ALGORITHM TAINT_AWARE_IEV_EFFECTUATION(A_i): # Phase 1 - Candidate construction D_A := HASH(CANONICALIZE(A_i)) origin := PROTECTED_ORIGIN_ATTRIBUTION(current_request) tau_i := READ_PROTECTED_TAINT_STATE(origin, A_i) provenance:= GET_PROVENANCE(A_i) if tau_i == UNKNOWN: tau_i := UNVERIFIABLE # Phase 2 - Initial protected policy pre_decision := POLICY_EVALUATE( act_digest = D_A, origin = origin, taint = tau_i, provenance = provenance, destination = A_i.destination, requested_scope = A_i.scope, policy_epoch = CURRENT_POLICY_EPOCH(), revocation = CURRENT_REVOCATION_STATE() ) if pre_decision == DENY: return BLOCK if pre_decision == ASK: approval := PROTECTED_APPROVAL_FLOW(A_i) if NOT VALIDATE_APPROVAL(approval, D_A): Das Expires 4 April 2027 [Page 177] Internet-Draft Earned Authority: Interim Validation October 2026 return BLOCK phase_scope := SELECT_BOUNDED_PHASE(pre_decision, A_i) # Phase 3 - Protected boundary / credential resolution sigma_i := GET_CREDENTIAL_REFERENCE(A_i) if NOT SURROGATE_OR_REFERENCE_VALID(sigma_i, origin, phase_scope): return BLOCK if NOT TAINT_POLICY_SATISFIED(tau_i, phase_scope): return BLOCK_OR_REDUCE_SCOPE boundary_request := BUILD_PHASE_REQUEST(A_i, phase_scope) # Real credential remains outside act-generating domain real_credential := PROTECTED_CREDENTIAL_AUTHORITY.RESOLVE_FOR_USE( credential_reference = sigma_i, origin = origin, destination = A_i.destination, phase_scope = phase_scope ) if real_credential unavailable: return BLOCK # Phase 4 - Real bounded effect E_i := FINALITY_SINK.EFFECTUATE( request = boundary_request, credential_use = real_credential ) # Phase 5 - Protected evidence generation R_i := EFFECT_OBSERVER.CREATE_RECEIPT( act_digest = D_A, phase_id = i, origin = origin, taint = tau_i, credential_class = CLASS(real_credential), boundary_id = FINALITY_SINK.ID, destination_id = OBSERVED_DESTINATION(E_i), observed_effect = OBSERVE(E_i), request_digest = HASH(boundary_request), policy_epoch = CURRENT_POLICY_EPOCH(), counter = NEXT_PROTECTED_COUNTER() ) # Phase 6 - Independent interim validation Das Expires 4 April 2027 [Page 178] Internet-Draft Earned Authority: Interim Validation October 2026 iev_result := IEV.VALIDATE( receipt = R_i, expected_act = D_A, expected_origin = origin, expected_taint = tau_i, expected_boundary = FINALITY_SINK.ID, expected_destination = A_i.destination, expected_effect = EXPECTED_EFFECT(A_i, phase_scope), current_policy = CURRENT_POLICY_EPOCH(), current_revocation = CURRENT_REVOCATION_STATE() ) if iev_result == FAIL: return FAILURE_OR_REMEDIATION_PATH(R_i) if iev_result == INDETERMINATE: return RECONCILIATION_PATH(R_i) # Phase 7 - Next-phase continuation Gamma_next := IEV.CREATE_CONTINUATION( act_digest = D_A, prior_receipt = HASH(R_i), next_phase = i + 1, next_scope = DETERMINE_NEXT_SCOPE(R_i), next_destination = NEXT_DESTINATION(A_i), taint_bound = CURRENT_PROTECTED_TAINT_STATE(), policy_epoch = CURRENT_POLICY_EPOCH(), expiry = SHORT_EXPIRY() ) # Phase 8 - Effectuation-time revalidation if NOT FINALITY_SINK.VERIFY_CONTINUATION(Gamma_next): return BLOCK if POLICY_CHANGED() OR REVOCATION_ACTIVE(): return REVALIDATE_OR_BLOCK if TAINT_NO_LONGER_ACCEPTABLE(): return REVALIDATE_REDUCE_OR_BLOCK if DESTINATION_CHANGED(): return BLOCK # Phase 9 - Next-phase credential resolution sigma_next := GET_NEXT_PHASE_CREDENTIAL_REFERENCE(A_i) if NOT SURROGATE_OR_REFERENCE_VALID(sigma_next): return BLOCK Das Expires 4 April 2027 [Page 179] Internet-Draft Earned Authority: Interim Validation October 2026 credential_next := PROTECTED_CREDENTIAL_AUTHORITY.RESOLVE_FOR_USE( credential_reference = sigma_next, continuation = Gamma_next, next_scope = Gamma_next.scope ) if credential_next unavailable: return BLOCK # Phase 10 - Next real effect E_next := FINALITY_SINK.EFFECTUATE_NEXT_PHASE( continuation = Gamma_next, credential_use = credential_next ) return E_next C.56. 56. Non-Limiting Pseudocode - Taint Propagation FUNCTION PROPAGATE_TAINT(process_state, inputs, tool_outputs, provenance): states := [process_state.taint] FOR each input IN inputs: states.append(input.taint) FOR each output IN tool_outputs: states.append(output.taint) IF provenance missing OR provenance unverifiable: states.append(UNVERIFIABLE) return PROTECTED_TAINT_JOIN(states) One non-limiting ordering may be: \mathrm{CLEAN}\prec\mathrm{TAINTED}\prec\mathrm{UNVERIFIABLE}, although an implementation may use a lattice, labels, category sets, confidence scores, or incomparable classes instead of a total order. C.57. 57. Non-Limiting Pseudocode - Boundary Credential Resolution Das Expires 4 April 2027 [Page 180] Internet-Draft Earned Authority: Interim Validation October 2026 FUNCTION RESOLVE_CREDENTIAL_AT_BOUNDARY(request, sigma, Gamma_optional): origin := PROTECTED_ORIGIN_ATTRIBUTION(request) tau := CURRENT_PROTECTED_TAINT(origin) if NOT SURROGATE_OR_REFERENCE_VALID(sigma, origin): return DENY if NOT DESTINATION_ALLOWED(request.destination): return DENY if NOT TAINT_POLICY_SATISFIED(tau, request.scope): return DENY_OR_REDUCE_SCOPE if Gamma_optional exists: if NOT VERIFY_CONTINUATION(Gamma_optional): return DENY if Gamma_optional.destination != request.destination: return DENY if request.scope exceeds Gamma_optional.scope: return DENY credential := CREDENTIAL_AUTHORITY.GET_NONEXPORTABLE_USE(sigma) if credential unavailable: return DENY concrete_request := SUBSTITUTE_OR_APPLY_CREDENTIAL(request, credential) result := SEND_THROUGH_PROTECTED_BOUNDARY(concrete_request) ZEROIZE_TRANSIENT_SECRET_MATERIAL_WHERE_APPLICABLE() return result C.58. 58. Non-Limiting Pseudocode - IEV Validation Das Expires 4 April 2027 [Page 181] Internet-Draft Earned Authority: Interim Validation October 2026 FUNCTION IEV_VALIDATE(R_i, expected): if NOT AUTHENTICATE_RECEIPT(R_i): return FAIL if R_i.act_digest != expected.act_digest: return FAIL if R_i.phase_id != expected.phase_id: return FAIL if R_i.origin != expected.origin: return FAIL if NOT TAINT_CONSISTENT(R_i.taint, expected.taint): return FAIL_OR_RECONCILE if NOT AUTHORIZED_EQUIVALENT_BOUNDARY( actual = R_i.boundary_id, expected = expected.boundary_id): return FAIL if NOT CREDENTIAL_CLASS_ALLOWED(R_i.credential_class): return FAIL if R_i.destination_id != expected.destination_id: return FAIL if NOT EFFECT_ACCEPTABLE( observed = R_i.observed_effect, expected = expected.effect): return FAIL if NOT POLICY_CURRENT(R_i.policy_epoch): return HOLD_OR_REVALIDATE if REVOCATION_ACTIVE(): return FAIL if RECEIPT_ALREADY_CONSUMED(HASH(R_i)): return FAIL ATOMICALLY: MARK_RECEIPT_CONSUMED(HASH(R_i)) ADVANCE_PHASE() return PASS Das Expires 4 April 2027 [Page 182] Internet-Draft Earned Authority: Interim Validation October 2026 C.59. 59. Non-Limiting Pseudocode - SEND Trailer Then Full Payload FUNCTION SAFE_SEND(full_message, intended_recipient): candidate := BUILD_SEND_ACT(full_message, intended_recipient) trailer := BUILD_BOUNDED_TRAILER(candidate) trailer_result := TAINT_AWARE_IEV_EFFECTUATION(trailer) if trailer_result not proven acceptable: return BLOCK_OR_REMEDIATE R0 := GET_TRAILER_RECEIPT(trailer_result) if R0.recipient != intended_recipient: return BLOCK_OR_HUMAN_OR_AUTOMATED_REMEDIATION Gamma_full := IEV.CREATE_CONTINUATION( prior_receipt = HASH(R0), next_scope = FULL_SEND_SCOPE, destination = intended_recipient ) return FINALITY_SINK.SEND_FULL_PAYLOAD( message = full_message, continuation = Gamma_full ) C.60. 60. Non-Limiting Pseudocode - Automatic Misalignment Handling Das Expires 4 April 2027 [Page 183] Internet-Draft Earned Authority: Interim Validation October 2026 FUNCTION HANDLE_MISALIGNMENT(R_i, expected): mismatch := CLASSIFY_MISMATCH(R_i, expected) proposal := AUTOMATED_REMEDIATION_CONTROLLER.PROPOSE(mismatch) # The remediation controller does not directly receive full effect authority. validation := IEV.VALIDATE_REMEDIATION_PROPOSAL( proposal = proposal, receipt = R_i, maximum_authorized_envelope = CURRENT_MAX_ENVELOPE() ) if validation == APPROVE_REDUCED_SCOPE: return IEV.CREATE_RESTRICTED_CONTINUATION(proposal.scope) if validation == REQUERY: return AUTHORIZE_BOUNDED_DIAGNOSTIC_REQUERY() if validation == RECONCILE: return ENTER_RECONCILIATION() if validation == HUMAN_REVIEW: return PROTECTED_HUMAN_REVIEW() return TERMINATE_OR_SAFE_STATE C.61. 61. Example - Linux / VM Deployment A non-limiting Linux or VM deployment may contain: * agentd in a lower-trust namespace, container, or VM; * effect-broker as the Finality Sink; * credentiald holding real credentials or non-exportable credential- use authority; * effect-observer generating protected receipts; * ievd maintaining protected continuation state; * optional kernel, cgroup, LSM, eBPF, seccomp, or namespace mechanisms supporting attribution, isolation, or taint. Illustrative flow: Das Expires 4 April 2027 [Page 184] Internet-Draft Earned Authority: Interim Validation October 2026 agentd \rightarrow effect\text{-}broker \rightarrow E_i \rightarrow R_i \rightarrow ievd \rightarrow \Gamma_{i+1} \rightarrow effect\text{-}broker. The precise names, process topology, and Linux primitives are non- limiting. C.62. 62. Example - Android / Mobile Deployment An Android or other mobile implementation may use: * an ordinary application or isolated process as the act source; * a Binder/system-service/backend broker as the Finality Sink; * hardware-backed or server-side credential authority; * TEE or remote IEV state; * protected receipt return from the server or destination. The same functional sequence applies even where the strongest effectuation gate is server-side rather than local. C.63. 63. Example - Windows / Desktop Deployment A Windows or desktop implementation may use: * a restricted application or AppContainer-like act source; * a broker service as the Finality Sink; * a separate Windows service, enclave-assisted service, or remote validator as the IEV; * a credential broker that never returns the real credential to the application. The application may therefore prepare high-level requests without possessing unrestricted effect authority. C.64. 64. Example - iOS / Sandboxed App Deployment A sandboxed mobile application may use a remote Finality Sink and remote IEV where the application lacks system-level privilege to mediate all local resources. For example: Das Expires 4 April 2027 [Page 185] Internet-Draft Earned Authority: Interim Validation October 2026 iOSApp \rightarrow BackendFS_0 \rightarrow E_0 \rightarrow R_0 \rightarrow RemoteIEV \rightarrow \Gamma_1 \rightarrow BackendFS_1 \rightarrow E_1. A device-bound key, secure hardware identity, application attestation, or protected credential reference may supplement the remote architecture. C.65. 65. Commercial Deployment Forms The embodiment may be provided as: * an AI-agent runtime; * enterprise endpoint service; * operating-system security service; * mobile SDK plus backend; * local daemon; * microVM; * virtual appliance; * application middleware; * API gateway; * network proxy; * credential broker; * secure browser broker; * connector execution service; * DPU or SmartNIC service; * cloud control-plane component; * transaction gateway; * messaging safety layer; * payment control layer; Das Expires 4 April 2027 [Page 186] Internet-Draft Earned Authority: Interim Validation October 2026 * application helper; * remote validation service. C.66. 66. Final Technical Invariants The embodiment preserves the following distinctions: \boxed{Computation\neq AuthorityToAct.} \boxed{CredentialReference\neq ActualCredentialAuthority.} \boxed{ReceiptExistence\neq ContinuationAuthority.} \boxed{IEVPassAt(t_0)\neq IrrevocableAuthorityAt(t_1).} A preferred combined invariant is: \boxed{ \begin{aligned} Enable(E_{i+1})={}& \operatorname{OriginAuthorized}_{i+1}\\ &\land\operatorname{TaintAcceptable}_{i+1}\\ &\land\operatorname{CredentialReferenceValid}_{i+1}\\ &\land\operatorname{ContinuationValid}(\Gamma_{i+1})\\ &\land\operatorname{PolicyCurrent}_{i+1}\\ &\land\operatorname{RevocationClear}_{i+1}\\ &\land\operatorname{DestinationValid}_{i+1}\\ &\land\operatorname{ScopeAuthorized}_{i+1}\\ &\land\operatorname{CredentialClassAllowed}_{i+1}. \end{aligned}} The final causal relationship is: \boxed{ \begin{aligned} &ProtectedBoundaryValidation\\ &\quad + RealObservedEffect\\ &\quad + IndependentIEVValidation\\ &\quad + CurrentContinuationCondition\\ &\qquad \Rightarrow EligibilityForSubsequentEffectuation. \end{aligned}} This implication describes eligibility under the protected architecture; it does not require that every implementation use identical components, names, cryptographic forms, operating systems, or process boundaries. Appendix D. Equivalent-Realization and Topology-Independent Patterns This appendix consolidates topology-independent patterns from the staged-effectuation design notes. The term "equivalent realization" is used here to describe technical architecture variation; this appendix does not make legal conclusions. Das Expires 4 April 2027 [Page 187] Internet-Draft Earned Authority: Interim Validation October 2026 D.1. Purpose and Interpretive Rule The staged-effectuation architecture is defined principally by technical control over when and under what protected conditions a consequential operation becomes effective. Accordingly, physical separation between a Protected Enforcement Domain, authority generator, effectuation gate, observer, and destination is not required unless expressly stated for a particular embodiment. A protected function may be collapsed into one component, distributed across multiple components, represented by explicit cryptographic material, represented only by protected state, or enforced natively by a destination, transaction engine, operating system, hardware controller, consensus group, or finite-state machine. The following embodiments expressly describe such realizations so that topology, token format, or product-layer placement is not treated as a mandatory limitation. For embodiments that retain the central staged-effectuation invariant, a bounded real effect, protected confirmation state, or equivalent protected predecessor condition remains technically relevant to broader continuation. Certain mixed-mode embodiments below also permit lower-risk, pre-authorized, reversible, or formally constrained actions to proceed under a different path while reserving receipt-gated staged effectuation for defined consequence classes. Such mixed modes do not require every operation in a system to use the same finality path. D.2. Alternative Implementation Pattern T1 -- Monolithic Protected Executor A single protected executor may receive a proposed operation, canonicalize or otherwise identify the operation, evaluate policy, determine a bounded first-stage action, perform that action, observe or verify the result, advance protected state, and perform the broader or full effect. No inter-process, inter-device, or network- visible PED-to-capability-to-sink sequence is required. Logical separation may exist only as protected states or internal state- machine transitions. PROPOSED -> VALIDATED -> PARTIAL_EFFECT -> CONFIRMED -> FULL_EFFECT Figure 131 Das Expires 4 April 2027 [Page 188] Internet-Draft Earned Authority: Interim Validation October 2026 The monolithic executor may be a database engine, transaction engine, secure service, trusted application, TEE, HSM, secure MCU, PLC, ECU, storage controller, NIC, DPU, GPU security processor, modem/baseband, or other protected component. A transition to the broader effect is rejected unless the executor itself records the required predecessor state or confirmation predicate. Thus, physical component separation is optional; non-skippable protected state is the relevant property. D.3. Alternative Implementation Pattern T2 -- Implicit-State / No-Token Authority An embodiment need not create, transmit, expose, or store a discrete capability, Execution Handle, bearer token, signed permit, or other transferable authority object. The authority to continue may exist solely as protected state inside the enforcing component. EnableFull := (ProtectedState == CONFIRMED) AND PolicyCurrent AND RevocationClear Figure 132 Equivalent realizations include an atomic state bit, transaction role, database row state, latch value, hardware register state, monotonic counter state, secure monitor state, consensus state, memory-protection state, or an internal predicate evaluated at commit time. The proposing agent or application may never receive any authority object at all. A successful protected state transition itself may be the full-effectuation authority. D.4. Alternative Implementation Pattern T3 -- Direct Human-Signed Exact Act A protected human authority may directly sign, authenticate, or otherwise cryptographically approve the exact operation that a destination or effect-capable boundary will execute. In this embodiment, the human approval artifact itself may constitute all or part of the execution authority; a separately minted PED capability is not required. The signed object may bind a canonical act digest, operation class, recipient or beneficiary, destination, resource, payload or payload digest, amount, maximum scope, nonce, expiry, policy epoch, revocation epoch, device or authenticator identity, and where staged execution is used, the digest or identity of a prior Effect Confirmation Receipt. Human Authenticator -> Exact-Act Signature -> Destination / Sink Verification -> Effect Figure 133 Das Expires 4 April 2027 [Page 189] Internet-Draft Earned Authority: Interim Validation October 2026 The AI agent may act only as a transporter of the signed operation and need not possess authority to alter it. Any material mutation after human signing causes signature or binding verification to fail. A staged variation permits the human to sign the maximum authorized envelope initially and later sign continuation after viewing verified evidence of the bounded real effect. D.5. Alternative Implementation Pattern T4 -- Human Re-Originated Operation After AI Recommendation An AI system may be technically incapable of submitting an effect- capable operation. The AI produces only a recommendation, proposed parameters, explanation, or non-authoritative Candidate Act Descriptor. A human then opens or uses a separate trusted application and independently originates the actual SEND, payment, API operation, infrastructure mutation, data release, or physical command. The trusted application may import none, some, or all of the AI- proposed parameters. It may display the recommendation while requiring the human to re-enter, confirm, or reconstruct critical fields. The resulting human-originated act receives a new act identifier and may optionally commit to the AI recommendation digest for provenance without treating the AI recommendation as authority. The human-originated act may then use single-phase protected effectuation or any staged receipt-gated workflow disclosed herein. This embodiment distinguishes computational assistance from legal, operational, or technical origination of the consequential act. D.6. Alternative Implementation Pattern T5 -- Structural Capability / Object-Capability / Typed-Authority System Authority may be encoded structurally into the execution environment rather than represented as a per-act finality token. Examples include object capabilities, typed tool references, typed resource handles, language-level effect types, memory-safe capability references, namespace-limited descriptors, kernel-enforced file descriptors, hardware protection domains, or other references that make unauthorized resources or operations technically unrepresentable or unreachable. Das Expires 4 April 2027 [Page 190] Internet-Draft Earned Authority: Interim Validation October 2026 A Candidate Act can be constrained to the operations expressible by the currently available authority graph. Receipt verification or protected policy may expand, replace, narrow, or revoke that graph after a bounded real effect. For example, the initial graph may expose only a bounded SEND trailer method, a one-row database object, a low-amplitude actuator object, or a limited payment-hold object; successful confirmation may cause the protected runtime to expose a broader typed object or state transition. AuthorityGraph_i + ValidReceipt_i -> ProtectedTransition -> AuthorityGraph_(i+1) Figure 134 No reusable credential or independent execution handle is necessary. The inability to obtain or name an effect-capable object outside the protected graph may itself enforce non-bypassability. D.7. Alternative Implementation Pattern T6 -- Native Transactional Invariant / Commit-State Enforcement A database, payment service, message service, cloud control plane, storage engine, tool service, or other transactional destination may embed the staged-effectuation constraint directly into its native commit state machine. No external Finality Sink process, separate receipt broker, or transferable continuation capability is required where the native transaction engine itself prevents an invalid transition. PROVISIONAL -> OBSERVED / VERIFIED -> COMMITTABLE -> COMMITTED Figure 135 The confirmation evidence may be represented by an internal durable commit record, protected log sequence number, settlement reference, version counter, replicated state, sensor-backed register, or another native state transition. The full commit operation succeeds only when the native invariant is satisfied. In one realization, calling commit() while the transaction lacks the required confirmed predecessor state returns an error or leaves the transaction non- effective. Das Expires 4 April 2027 [Page 191] Internet-Draft Earned Authority: Interim Validation October 2026 D.8. Alternative Implementation Pattern T7 -- Risk-Selective or Consequence-Selective Mediation A system need not subject every operation to staged effectuation. Protected policy may partition operations into classes. A low- consequence, reversible, pre-authorized, or structurally constrained class may execute under ambient or session authority, while a higher- consequence, novel-destination, tainted, high-value, irreversible, safety-critical, or otherwise selected class is routed through receipt-gated staged effectuation. Classify(Act) -> { DIRECT_WITHIN_ENVELOPE | STAGED_EFFECTUATION | DENY } Figure 136 The classification rule itself should preferably reside in protected policy and should not be alterable by the proposing AI agent. A direct path for one class does not imply a direct path for a class whose protected policy requires staged finality. Anti-bypass controls may therefore be scoped by consequence class rather than universally applied to all operations. D.9. Alternative Implementation Pattern T8 -- Post-Effect Compensation as an Ancillary or Fallback Mode Some systems may include operations for which pre-effect staged confirmation is unavailable, impractical, or deliberately waived within a protected policy envelope. For such operations, the system may execute an authorized effect, obtain protected post-effect evidence, and then revoke, compensate, retract, roll back, quarantine, or otherwise remediate if the observed result violates a protected condition. This post-effect mode is not required to be treated as equivalent to the preferred receipt-gated pre-effectuation invariant. It may coexist with staged effectuation in the same product, with protected policy determining which consequence classes require pre-effect gating and which permit compensating control. Where both modes exist, the presence of a compensation path must not silently downgrade a class that policy marks as requiring receipt-gated continuation. Das Expires 4 April 2027 [Page 192] Internet-Draft Earned Authority: Interim Validation October 2026 D.10. Alternative Implementation Pattern T9 -- Formally Verified, Attested, or Deterministic Agent Within a Protected Envelope A formally verified, measured, attested, deterministic, policy- restricted, or otherwise trusted execution runtime may be granted a pre-authorized authority envelope broader than that granted to an ordinary probabilistic agent. The protected system may treat successful code measurement, formal proof identifier, secure-boot state, attested binary identity, deterministic policy hash, or equivalent runtime evidence as one authority predicate. Within a finite pre-authorized envelope, such a runtime may execute selected operations without generating a new human approval object for every act. Operations outside the envelope, operations having higher consequence, or operations affected by changed destination, policy, taint, revocation, or environmental state may still require staged effectuation or human approval. Attestation or formal verification therefore may change the authority source without requiring the architecture to assume that all model output is inherently authoritative. D.11. Alternative Implementation Pattern T10 -- Native Destination Policy and Destination-Local Finality The remote destination itself may combine policy evaluation, exact- act verification, effectuation gating, receipt generation, and final commitment. An upstream PED-created authority object is not mandatory where the destination has sufficient protected information to decide whether the exact request may become effective. The destination may verify a direct human signature, identity-bound request, device attestation, transaction state, policy epoch, revocation state, resource version, scope, nonce, and freshness. In a staged variation, the destination first accepts or performs a bounded real effect, records the resulting protected state, and then permits broader effect only when its own local confirmation state is satisfied. In another variation, the destination returns a signed ECR that an upstream system uses to release additional data, value, privilege, or actuator authority. Das Expires 4 April 2027 [Page 193] Internet-Draft Earned Authority: Interim Validation October 2026 D.12. Alternative Implementation Pattern T11 -- Replicated / Quorum / Consensus-Native Effectuation No single component need constitute the unique Finality Sink. Multiple replicas, validators, controllers, observers, or administrative domains may collectively determine whether an operation becomes effective. The protected continuation condition may be a quorum certificate, threshold signature, replicated log entry, consensus commit index, fault-tolerant state transition, or another aggregate state. ValidVotes / Receipts >= RequiredQuorum -> CommitCertificate / ConfirmedState -> Broader Effect Figure 137 The quorum or consensus state may itself function as the confirmation evidence and authority; a separate capability-verification stage is optional. Membership epoch, replica identity, role constraints, conflicting certificates, split-brain state, stale views, and critical-replica requirements may be bound to the protected commit condition. A later phase may depend on the accepted consensus state rather than on a receipt from one sink. D.13. Alternative Implementation Pattern T12 -- Pre-Authorized Finite Action Machine / Bounded Action Graph Before autonomous operation begins, a human, enterprise, device manufacturer, regulator, policy authority, or other protected principal may authorize a finite or otherwise bounded action graph. The graph defines states, permitted transitions, destinations, recipients, amounts, resources, APIs, device ranges, timing windows, phase limits, and terminal or safe states. G = (V, E); E_authorized is a protected subset of E Figure 138 The agent may select only a transition already represented in the protected authorized edge set. A fresh per-act authorization artifact need not be generated for every transition. The enforcing runtime validates that the requested edge originates at the current protected state and belongs to the authorized edge set; unauthorized transitions are structurally rejected. Das Expires 4 April 2027 [Page 194] Internet-Draft Earned Authority: Interim Validation October 2026 Receipts may optionally unlock later edges, consume one-time edges, advance a protected state pointer, or reduce the remaining graph. A human may authorize the entire graph initially, authorize a subgraph, or require renewed approval at designated nodes. This permits a pre- authorized finite action machine while preserving bounded authority and protected transition control. D.14. Cross-Cutting Implementation Rule for T1-T12 The preceding embodiments may be combined. For example, a monolithic destination may use no token, enforce authority as native transaction state, receive a direct human exact-act signature, operate inside a pre-authorized action graph, and use quorum replication for durable commitment. Conversely, a structural capability operating system may expose only bounded objects until a destination-local receipt or consensus state unlocks broader objects. Accordingly, the disclosure does not require any particular number of components, any transferable capability object, any particular direction of authority flow, or any specific placement of the finality decision, so long as the selected embodiment preserves the protected conditions applicable to that mode. Appendix E. Extended Domain and Workflow Catalogue The following catalogue records non-limiting workflow families used throughout the source material. It is intentionally broad so that the abstract protocol is not read as limited to messaging or payments. E.1. E01: Single-phase protected effectuation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.2. E02: Real bounded demonstration effect -> verified receipt -> full effectuation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. Das Expires 4 April 2027 [Page 195] Internet-Draft Earned Authority: Interim Validation October 2026 E.3. E03: Real demonstration effect -> receipt-gated multi-phase progressive effectuation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.4. E04: Verified demonstration effect -> protected human approval -> broader or full effectuation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.5. E05: Verified demonstration effect -> automatic protected decision -> receipt-gated continuation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.6. E06: Hybrid human + automatic receipt-gated continuation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.7. E07: Software protected enforcement domain This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. Das Expires 4 April 2027 [Page 196] Internet-Draft Earned Authority: Interim Validation October 2026 E.8. E08: Hardware protected enforcement domain This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.9. E09: Split software/hardware protected enforcement domain This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.10. E10: Receipt-conditioned hardware cryptographic key-chain effectuation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.11. E11: Threshold / multi-party cryptographic continuation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.12. E12: Message SEND demonstration / trailer-then-full effectuation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. Das Expires 4 April 2027 [Page 197] Internet-Draft Earned Authority: Interim Validation October 2026 E.13. E13: Receipt-gated file transfer and progressive file release This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.14. E14: Payment demonstration and receipt-gated full / progressive payment This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.15. E15: Escrow / conditional settlement and receipt-gated release This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.16. E16: Receipt-gated database commit, provisional persistence, and promotion This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.17. E17: Receipt-gated cloud deployment and progressive infrastructure rollout This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. Das Expires 4 April 2027 [Page 198] Internet-Draft Earned Authority: Interim Validation October 2026 E.18. E18: Receipt-gated AI model deployment, model activation, and progressive consequence release This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.19. E19: AI tool-use and external-action invocation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.20. E20: Progressive credential release This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.21. E21: Data export, progressive disclosure, and cryptographic release This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.22. E22: Storage, provisional persistence, and progressive visibility This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. Das Expires 4 April 2027 [Page 199] Internet-Draft Earned Authority: Interim Validation October 2026 E.23. E23: Robotics and progressive physical effect This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.24. E24: Hardware actuator and sensor-receipt-derived motion authority This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.25. E25: Receipt-gated vehicle effectuation and progressive vehicular authority This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.26. E26: Receipt-gated UAV and mobile-robot effectuation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.27. E27: Receipt-gated industrial, PLC, machine, and process-control effectuation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. Das Expires 4 April 2027 [Page 200] Internet-Draft Earned Authority: Interim Validation October 2026 E.28. E28: Receipt-gated telecom effectuation and progressive network authority This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.29. E29: Receipt-gated radio, satellite, and non-terrestrial-network effectuation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.30. E30: Receipt-gated GPU, accelerator, and compute-egress effectuation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.31. E31: Receipt-gated model-state update, protected memory commit, and progressive model-state effectuation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. Das Expires 4 April 2027 [Page 201] Internet-Draft Earned Authority: Interim Validation October 2026 E.32. E32: Receipt-gated software, firmware, and configuration update with progressive activation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.33. E33: Multi-destination, multi-recipient, multi-sink, and distributed receipt-gated effectuation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.34. E34: Replicated, quorum-confirmed, and consensus receipt-gated effectuation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. E.35. E35: Negative, indeterminate, conflict, reconciliation, and recovery receipt-gated effectuation This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document. Appendix F. Non-Limiting Reference Pseudocode The pseudocode in this appendix is explanatory. It does not mandate APIs, programming language, process topology, or object representation. Das Expires 4 April 2027 [Page 202] Internet-Draft Earned Authority: Interim Validation October 2026 function effectuate_phase(i, candidate, state): assert within_envelope(candidate, state.Envelope_MAX) authority = authorize_phase(i, candidate, state) if not authority.valid: return BLOCK result = FS[i].effectuate(candidate, authority) receipt = observe_and_protect(i, candidate, result) return receipt function evaluate_receipt(i, receipt, state): if not auth_valid(receipt): return FAIL_INVALID_RECEIPT if not act_match(receipt, state.D_A): return FAIL_ACT_SUBSTITUTION if not phase_match(receipt, i): return FAIL_WRONG_PHASE if consumed(receipt): return FAIL_REPLAY if not fresh(receipt): return HOLD_STALE if not sink_destination_resource_match(receipt, state): return FAIL_MISALIGNED effect = compare_effect(receipt.observed, state.expected[i]) if effect == INDETERMINATE: return RECONCILE if effect == FAIL: return remediate_or_escalate(receipt, state) if not current_policy_state_valid(state): return HOLD atomic { consume(receipt) advance_phase(i, i+1) Gamma = issue_continuation(i+1, H(receipt), state) } return Gamma function finality_sink_consume(i_plus_1, Gamma, state): if not continuation_valid(Gamma): return BLOCK if not policy_current(): return BLOCK if not revocation_clear(): return BLOCK if continuation_withdrawn(Gamma): return BLOCK if not destination_still_valid(Gamma): return BLOCK if not scope_still_authorized(Gamma): return BLOCK atomic_consume(Gamma) return FS[i_plus_1].effectuate() Figure 139: Core IEV progression Das Expires 4 April 2027 [Page 203] Internet-Draft Earned Authority: Interim Validation October 2026 function reconcile(i, identity): evidence = query_sink_destination_ledger_sensor_journal(identity) status = classify(evidence) switch status: PROVEN_EFFECTED: recovered = construct_or_recover_receipt(evidence) return evaluate_receipt(i, recovered, state) PROVEN_NOT_EFFECTED: return MAY_AUTHORIZE_NEW_BOUNDED_RETRY PARTIALLY_EFFECTED: return RESIDUAL_SCOPE_OR_COMPENSATION_OR_ESCALATION STILL_INDETERMINATE: return BLOCK_NEXT_PHASE Figure 140: Reconciliation function taint_aware_boundary(request, process_state): tau = join_taint(process_state.taint, request.input_taint, request.provenance_taint) if tau == UNVERIFIABLE: return policy_for_unknown_taint() origin = protected_origin_attribution(request) if not policy_allows(origin, tau, request.destination, request.scope): return DENY_OR_BOUNDED_TRIAL surrogate = request.credential_reference real_credential = credential_authority.resolve(surrogate, origin, request.destination, request.scope) return protected_boundary_send(request, real_credential) Figure 141: Taint-aware credential resolution Appendix G. Consolidated Functional Invariants Computation != Authority Figure 142 Receipt existence != Continuation authority Figure 143 Authenticated evidence != Consistent evidence Das Expires 4 April 2027 [Page 204] Internet-Draft Earned Authority: Interim Validation October 2026 Figure 144 IEV PASS != Infallible IEV Figure 145 Valid at issue != Valid at effectuation Figure 146 Validator unavailable != Permission to bypass validator Figure 147 Human decision != Direct unrestricted execution authority Figure 148 Automated remediation proposal != Direct unrestricted execution authority Figure 149 Change of validator placement != Change of functional sequence Figure 150 Change of token representation != Change of protected continuation semantics Figure 151 Change of proxy / boundary technology != Change of Finality-Sink role Figure 152 RealEffect[i] -> ProtectedEvidence[i] -> IndependentValidation[i] -> ProtectedContinuation[i+1] -> EffectuationTimeRevalidation[i+1] -> FinalitySink[i+1] -> RealEffect[i+1] Figure 153 Das Expires 4 April 2027 [Page 205] Internet-Draft Earned Authority: Interim Validation October 2026 Acknowledgements This draft consolidates architecture, workflow, hardening, implementation-invariance, operating-system, taint, provenance, credential-surrogation, and effectuation-boundary material developed through iterative technical drafting and public-review preparation. Any future acknowledgements of external reviewers should distinguish review input from authorship or co-development unless expressly agreed otherwise. Author's Address Sangam Das Independent Researcher Balasore Odisha India Email: info@sangamdas.com Das Expires 4 April 2027 [Page 206]