Secure AI Execution-Finality for iOS, Android, and Cross-Platform AI Agents, Part 1: Foundational Consequential Authority and Common Workflows
draft-das-interoperable-consequence-authority-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Sangam Das | ||
| Last updated | 2026-10-26 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-das-interoperable-consequence-authority-00
Independent Submission S. Das
Internet-Draft Independent Researcher
Intended status: Informational 26 October 2026
Expires: 29 April 2027
Secure AI Execution-Finality for iOS, Android, and Cross-Platform AI
Agents, Part 1: Foundational Consequential Authority and Common
Workflows
draft-das-interoperable-consequence-authority-00
Abstract
AI assistants and agents, including Apple Siri acting through App
Intents, Google Gemini on Android, Samsung Bixby, Microsoft Copilot,
and third-party AI tools, increasingly take real actions on iOS,
iPadOS, macOS, Android, Windows, Linux, and cloud platforms: they
send messages, export files, call remote APIs, make payments, and
operate connected devices. Such an agent can pass sandboxing,
authentication, app-permission, and token checks and still cause an
effect the user never approved, through prompt injection, credential
misuse, a wrong or redirected target, stale authority, replay, or
cross-device duplication.
This document is the foundational part of a twelve-part series. It
defines a common architecture in which an AI tool's proposed action
(a Candidate Act) remains non-effective until protected evidence
shows that it matches an approved operation, and the component that
actually executes it (the Finality Sink) independently reconstructs
the real pending operation and fails closed on any mismatch. It
specifies the shared terminology, trust model, and security
invariants used by Parts 2 through 12, together with three common
workflows: protected execution of a consequential action;
continuation of a multi-step task only after a verified receipt for
the earlier effect; and fresh, bounded re-authorization when an agent
deviates from its approved scope. A threat model and a falsifiable
reference test plan are included.
The document maps these mechanisms onto existing IETF work as
reusable building blocks: OAuth 2.0 with Rich Authorization Requests
and Demonstrating Proof of Possession (DPoP); Workload Identity in
Multi-System Environments (WIMSE); Remote ATtestation procedureS
(RATS); CBOR Object Signing and Encryption (COSE); Authentication and
Authorization for Constrained Environments (ACE); Supply Chain
Integrity, Transparency, and Trust (SCITT); and HTTP conditional
requests. It identifies discussion points for these groups and for
Security Area dispatch, without claiming working-group adoption or
IETF consensus.
Das Expires 29 April 2027 [Page 1]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Industry alignment covers interoperability between the Apple and
Google mobile ecosystems, voice and system assistants, enterprise
agent gateways and copilots, agent tooling from providers such as
OpenAI, Anthropic, Google, and Meta, hardware-backed enforcement,
payments, telecommunications, and robotics. Product names are
illustrative and imply no endorsement or implementation by any
vendor. For the EU Artificial Intelligence Act (Regulation (EU)
2024/1689), the operation-bound evidence and fail-closed enforcement
described here can help providers and deployers address risk-
management, record-keeping, human-oversight, and robustness and
cybersecurity requirements where those obligations apply; this is a
technical mapping, not a conformity claim or legal advice.
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 29 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.
Table of Contents
1. Introduction: Part 1 and the Twelve-Part Disclosure Series . 10
1.1. Companion Documents: Twelve-Part Series Directory . . . . 11
2. Intellectual Property Rights (IPR) Disclosure and Forthcoming
GitHub Reference Implementation . . . . . . . . . . . . . 13
3. Keywords and Search Terminology . . . . . . . . . . . . . . . 14
Das Expires 29 April 2027 [Page 2]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
4. Publication Source, Patent-Pending Context, and Technical
Provenance . . . . . . . . . . . . . . . . . . . . . . . 15
5. Shared Terminology and Protected Authority Model . . . . . . 15
6. Core Security Principles and Enforceability Limitations . . . 16
7. Common Master Workflow CW-1: Protected Effectuation . . . . . 17
7.1. Architecture and Trust Boundaries . . . . . . . . . . . . 17
7.2. Operational Decision Flow . . . . . . . . . . . . . . . . 18
7.3. Detailed Source-Derived Technical Disclosure . . . . . . 18
7.3.1. Source global page 15 . . . . . . . . . . . . . . . . 19
7.3.2. Source global page 16 . . . . . . . . . . . . . . . . 20
7.3.3. Source global page 17 . . . . . . . . . . . . . . . . 21
7.3.4. Source global page 18 . . . . . . . . . . . . . . . . 22
7.3.5. Source global page 19 . . . . . . . . . . . . . . . . 23
7.3.6. Source global page 20 . . . . . . . . . . . . . . . . 24
7.3.7. Source global page 21 . . . . . . . . . . . . . . . . 25
7.3.8. Source global page 22 . . . . . . . . . . . . . . . . 26
7.3.9. Source global page 23 . . . . . . . . . . . . . . . . 27
7.3.10. Source global page 24 . . . . . . . . . . . . . . . . 28
7.3.11. Source global page 25 . . . . . . . . . . . . . . . . 29
7.3.12. Source global page 26 . . . . . . . . . . . . . . . . 30
7.3.13. Source global page 27 . . . . . . . . . . . . . . . . 31
7.3.14. Source global page 28 . . . . . . . . . . . . . . . . 32
7.3.15. Source global page 29 . . . . . . . . . . . . . . . . 32
7.3.16. Source global page 30 . . . . . . . . . . . . . . . . 33
7.3.17. Source global page 31 . . . . . . . . . . . . . . . . 34
7.3.18. Source global page 32 . . . . . . . . . . . . . . . . 35
7.3.19. Source global page 33 . . . . . . . . . . . . . . . . 35
7.3.20. Source global page 34 . . . . . . . . . . . . . . . . 35
7.3.21. Source global page 35 . . . . . . . . . . . . . . . . 36
7.3.22. Source global page 36 . . . . . . . . . . . . . . . . 37
7.3.23. Source global page 37 . . . . . . . . . . . . . . . . 38
7.3.24. Source global page 38 . . . . . . . . . . . . . . . . 39
7.3.25. Source global page 39 . . . . . . . . . . . . . . . . 40
7.3.26. Source global page 40 . . . . . . . . . . . . . . . . 40
7.3.27. Source global page 41 . . . . . . . . . . . . . . . . 41
7.3.28. Source global page 42 . . . . . . . . . . . . . . . . 42
7.3.29. Source global page 43 . . . . . . . . . . . . . . . . 43
7.3.30. Source global page 44 . . . . . . . . . . . . . . . . 44
7.3.31. Source global page 45 . . . . . . . . . . . . . . . . 45
7.3.32. Source global page 46 . . . . . . . . . . . . . . . . 46
7.3.33. Source global page 47 . . . . . . . . . . . . . . . . 47
7.3.34. Source global page 48 . . . . . . . . . . . . . . . . 48
7.3.35. Source global page 49 . . . . . . . . . . . . . . . . 49
7.3.36. Source global page 50 . . . . . . . . . . . . . . . . 49
7.3.37. Source global page 51 . . . . . . . . . . . . . . . . 50
7.3.38. Source global page 52 . . . . . . . . . . . . . . . . 51
7.3.39. Source global page 53 . . . . . . . . . . . . . . . . 52
7.3.40. Source global page 54 . . . . . . . . . . . . . . . . 53
Das Expires 29 April 2027 [Page 3]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
7.3.41. Source global page 55 . . . . . . . . . . . . . . . . 54
7.3.42. Source global page 56 . . . . . . . . . . . . . . . . 55
7.3.43. Source global page 57 . . . . . . . . . . . . . . . . 56
7.3.44. Source global page 58 . . . . . . . . . . . . . . . . 57
7.3.45. Source global page 59 . . . . . . . . . . . . . . . . 58
7.3.46. Source global page 60 . . . . . . . . . . . . . . . . 59
7.3.47. Source global page 61 . . . . . . . . . . . . . . . . 60
7.3.48. Source global page 62 . . . . . . . . . . . . . . . . 60
8. Common Workflow CW-2: Receipt-Constituted Causal
Continuation . . . . . . . . . . . . . . . . . . . . . . 61
8.1. Architecture and Trust Boundaries . . . . . . . . . . . . 62
8.2. Operational Decision Flow . . . . . . . . . . . . . . . . 62
8.3. Detailed Source-Derived Technical Disclosure . . . . . . 63
8.3.1. Source global page 63 . . . . . . . . . . . . . . . . 63
8.3.2. Source global page 64 . . . . . . . . . . . . . . . . 64
8.3.3. Source global page 65 . . . . . . . . . . . . . . . . 65
8.3.4. Source global page 66 . . . . . . . . . . . . . . . . 65
8.3.5. Source global page 67 . . . . . . . . . . . . . . . . 66
8.3.6. Source global page 68 . . . . . . . . . . . . . . . . 67
8.3.7. Source global page 69 . . . . . . . . . . . . . . . . 68
8.3.8. Source global page 70 . . . . . . . . . . . . . . . . 69
8.3.9. Source global page 71 . . . . . . . . . . . . . . . . 69
8.3.10. Source global page 72 . . . . . . . . . . . . . . . . 70
8.3.11. Source global page 73 . . . . . . . . . . . . . . . . 72
8.3.12. Source global page 74 . . . . . . . . . . . . . . . . 73
8.3.13. Source global page 75 . . . . . . . . . . . . . . . . 74
8.3.14. Source global page 76 . . . . . . . . . . . . . . . . 75
8.3.15. Source global page 77 . . . . . . . . . . . . . . . . 75
8.3.16. Source global page 78 . . . . . . . . . . . . . . . . 76
8.3.17. Source global page 79 . . . . . . . . . . . . . . . . 77
8.3.18. Source global page 80 . . . . . . . . . . . . . . . . 78
8.3.19. Source global page 81 . . . . . . . . . . . . . . . . 78
8.3.20. Source global page 82 . . . . . . . . . . . . . . . . 79
8.3.21. Source global page 83 . . . . . . . . . . . . . . . . 80
8.3.22. Source global page 84 . . . . . . . . . . . . . . . . 81
8.3.23. Source global page 85 . . . . . . . . . . . . . . . . 82
8.3.24. Source global page 86 . . . . . . . . . . . . . . . . 82
8.3.25. Source global page 87 . . . . . . . . . . . . . . . . 83
8.3.26. Source global page 88 . . . . . . . . . . . . . . . . 83
8.3.27. Source global page 89 . . . . . . . . . . . . . . . . 84
8.3.28. Source global page 90 . . . . . . . . . . . . . . . . 85
8.3.29. Source global page 91 . . . . . . . . . . . . . . . . 86
8.3.30. Source global page 92 . . . . . . . . . . . . . . . . 86
8.3.31. Source global page 93 . . . . . . . . . . . . . . . . 87
8.3.32. Source global page 94 . . . . . . . . . . . . . . . . 87
8.3.33. Source global page 95 . . . . . . . . . . . . . . . . 88
8.3.34. Source global page 96 . . . . . . . . . . . . . . . . 88
8.3.35. Source global page 97 . . . . . . . . . . . . . . . . 88
Das Expires 29 April 2027 [Page 4]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
8.3.36. Source global page 98 . . . . . . . . . . . . . . . . 89
8.3.37. Source global page 99 . . . . . . . . . . . . . . . . 89
8.3.38. Source global page 100 . . . . . . . . . . . . . . . 90
8.3.39. Source global page 101 . . . . . . . . . . . . . . . 91
8.3.40. Source global page 102 . . . . . . . . . . . . . . . 92
8.3.41. Source global page 103 . . . . . . . . . . . . . . . 93
8.3.42. Source global page 104 . . . . . . . . . . . . . . . 94
8.3.43. Source global page 105 . . . . . . . . . . . . . . . 94
8.3.44. Source global page 106 . . . . . . . . . . . . . . . 95
8.3.45. Source global page 107 . . . . . . . . . . . . . . . 96
8.3.46. Source global page 108 . . . . . . . . . . . . . . . 97
8.3.47. Source global page 109 . . . . . . . . . . . . . . . 97
8.3.48. Source global page 110 . . . . . . . . . . . . . . . 98
8.3.49. Source global page 111 . . . . . . . . . . . . . . . 99
8.3.50. Source global page 112 . . . . . . . . . . . . . . . 100
8.3.51. Source global page 113 . . . . . . . . . . . . . . . 101
8.3.52. Source global page 114 . . . . . . . . . . . . . . . 102
8.3.53. Source global page 115 . . . . . . . . . . . . . . . 103
8.3.54. Source global page 116 . . . . . . . . . . . . . . . 104
8.3.55. Source global page 117 . . . . . . . . . . . . . . . 105
8.3.56. Source global page 118 . . . . . . . . . . . . . . . 106
8.3.57. Source global page 119 . . . . . . . . . . . . . . . 106
9. Common Workflow CW-3: Protected Scope-Deviation
Reauthorization . . . . . . . . . . . . . . . . . . . . . 108
9.1. Architecture and Trust Boundaries . . . . . . . . . . . . 108
9.2. Operational Decision Flow . . . . . . . . . . . . . . . . 108
9.3. Detailed Source-Derived Technical Disclosure . . . . . . 109
9.3.1. Source global page 119 . . . . . . . . . . . . . . . 109
9.3.2. Source global page 120 . . . . . . . . . . . . . . . 110
9.3.3. Source global page 121 . . . . . . . . . . . . . . . 111
9.3.4. Source global page 122 . . . . . . . . . . . . . . . 112
9.3.5. Source global page 123 . . . . . . . . . . . . . . . 113
9.3.6. Source global page 124 . . . . . . . . . . . . . . . 114
9.3.7. Source global page 125 . . . . . . . . . . . . . . . 115
9.3.8. Source global page 126 . . . . . . . . . . . . . . . 116
9.3.9. Source global page 127 . . . . . . . . . . . . . . . 117
9.3.10. Source global page 128 . . . . . . . . . . . . . . . 117
9.3.11. Source global page 129 . . . . . . . . . . . . . . . 118
9.3.12. Source global page 130 . . . . . . . . . . . . . . . 119
9.3.13. Source global page 131 . . . . . . . . . . . . . . . 120
9.3.14. Source global page 132 . . . . . . . . . . . . . . . 121
9.3.15. Source global page 133 . . . . . . . . . . . . . . . 121
9.3.16. Source global page 134 . . . . . . . . . . . . . . . 122
9.3.17. Source global page 135 . . . . . . . . . . . . . . . 123
9.3.18. Source global page 136 . . . . . . . . . . . . . . . 123
9.3.19. Source global page 137 . . . . . . . . . . . . . . . 124
9.3.20. Source global page 138 . . . . . . . . . . . . . . . 125
9.3.21. Source global page 139 . . . . . . . . . . . . . . . 126
Das Expires 29 April 2027 [Page 5]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
9.3.22. Source global page 140 . . . . . . . . . . . . . . . 126
9.3.23. Source global page 141 . . . . . . . . . . . . . . . 127
9.3.24. Source global page 142 . . . . . . . . . . . . . . . 128
9.3.25. Source global page 143 . . . . . . . . . . . . . . . 129
9.3.26. Source global page 144 . . . . . . . . . . . . . . . 129
9.3.27. Source global page 145 . . . . . . . . . . . . . . . 130
9.3.28. Source global page 146 . . . . . . . . . . . . . . . 131
9.3.29. Source global page 147 . . . . . . . . . . . . . . . 131
9.3.30. Source global page 148 . . . . . . . . . . . . . . . 132
9.3.31. Source global page 149 . . . . . . . . . . . . . . . 132
9.3.32. Source global page 150 . . . . . . . . . . . . . . . 133
9.3.33. Source global page 151 . . . . . . . . . . . . . . . 133
9.3.34. Source global page 152 . . . . . . . . . . . . . . . 134
9.3.35. Source global page 153 . . . . . . . . . . . . . . . 134
9.3.36. Source global page 154 . . . . . . . . . . . . . . . 134
9.3.37. Source global page 155 . . . . . . . . . . . . . . . 135
9.3.38. Source global page 156 . . . . . . . . . . . . . . . 136
9.3.39. Source global page 157 . . . . . . . . . . . . . . . 137
9.3.40. Source global page 158 . . . . . . . . . . . . . . . 138
9.3.41. Source global page 159 . . . . . . . . . . . . . . . 139
9.3.42. Source global page 160 . . . . . . . . . . . . . . . 140
9.3.43. Source global page 161 . . . . . . . . . . . . . . . 140
9.3.44. Source global page 162 . . . . . . . . . . . . . . . 141
9.3.45. Source global page 163 . . . . . . . . . . . . . . . 142
9.3.46. Source global page 164 . . . . . . . . . . . . . . . 143
9.3.47. Source global page 165 . . . . . . . . . . . . . . . 144
9.3.48. Source global page 166 . . . . . . . . . . . . . . . 145
9.3.49. Source global page 167 . . . . . . . . . . . . . . . 146
9.3.50. Source global page 168 . . . . . . . . . . . . . . . 147
9.3.51. Source global page 169 . . . . . . . . . . . . . . . 148
9.3.52. Source global page 170 . . . . . . . . . . . . . . . 149
9.3.53. Source global page 171 . . . . . . . . . . . . . . . 150
9.3.54. Source global page 172 . . . . . . . . . . . . . . . 150
9.3.55. Source global page 173 . . . . . . . . . . . . . . . 151
9.3.56. Source global page 174 . . . . . . . . . . . . . . . 151
9.3.57. Source global page 175 . . . . . . . . . . . . . . . 152
9.3.58. Source global page 176 . . . . . . . . . . . . . . . 153
9.3.59. Source global page 177 . . . . . . . . . . . . . . . 154
9.3.60. Source global page 178 . . . . . . . . . . . . . . . 155
10. Supplementary Technical Implementation of CW-1, CW-2, and
CW-3 . . . . . . . . . . . . . . . . . . . . . . . . . . 156
10.1. Source global page 179 . . . . . . . . . . . . . . . . . 156
10.2. Source global page 180 . . . . . . . . . . . . . . . . . 157
10.3. Source global page 181 . . . . . . . . . . . . . . . . . 158
10.4. Source global page 182 . . . . . . . . . . . . . . . . . 158
10.5. Source global page 183 . . . . . . . . . . . . . . . . . 159
10.6. Source global page 184 . . . . . . . . . . . . . . . . . 160
10.7. Source global page 185 . . . . . . . . . . . . . . . . . 160
Das Expires 29 April 2027 [Page 6]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
10.8. Source global page 186 . . . . . . . . . . . . . . . . . 161
10.9. Source global page 187 . . . . . . . . . . . . . . . . . 162
10.10. Source global page 188 . . . . . . . . . . . . . . . . . 162
10.11. Source global page 189 . . . . . . . . . . . . . . . . . 163
10.12. Source global page 190 . . . . . . . . . . . . . . . . . 164
10.13. Source global page 191 . . . . . . . . . . . . . . . . . 164
10.14. Source global page 192 . . . . . . . . . . . . . . . . . 165
10.15. Source global page 193 . . . . . . . . . . . . . . . . . 165
10.16. Source global page 194 . . . . . . . . . . . . . . . . . 166
10.17. Source global page 195 . . . . . . . . . . . . . . . . . 167
10.18. Source global page 196 . . . . . . . . . . . . . . . . . 167
10.19. Source global page 197 . . . . . . . . . . . . . . . . . 168
10.20. Source global page 198 . . . . . . . . . . . . . . . . . 169
10.21. Source global page 199 . . . . . . . . . . . . . . . . . 169
10.22. Source global page 200 . . . . . . . . . . . . . . . . . 170
10.23. Source global page 201 . . . . . . . . . . . . . . . . . 171
10.24. Source global page 202 . . . . . . . . . . . . . . . . . 171
10.25. Source global page 203 . . . . . . . . . . . . . . . . . 172
10.26. Source global page 204 . . . . . . . . . . . . . . . . . 173
10.27. Source global page 205 . . . . . . . . . . . . . . . . . 173
10.28. Source global page 206 . . . . . . . . . . . . . . . . . 174
10.29. Source global page 207 . . . . . . . . . . . . . . . . . 175
10.30. Source global page 208 . . . . . . . . . . . . . . . . . 175
10.31. Source global page 209 . . . . . . . . . . . . . . . . . 176
10.32. Source global page 210 . . . . . . . . . . . . . . . . . 176
10.33. Source global page 211 . . . . . . . . . . . . . . . . . 177
10.34. Source global page 212 . . . . . . . . . . . . . . . . . 178
10.35. Source global page 213 . . . . . . . . . . . . . . . . . 179
10.36. Source global page 214 . . . . . . . . . . . . . . . . . 179
10.37. Source global page 215 . . . . . . . . . . . . . . . . . 180
10.38. Source global page 216 . . . . . . . . . . . . . . . . . 181
10.39. Source global page 217 . . . . . . . . . . . . . . . . . 181
10.40. Source global page 218 . . . . . . . . . . . . . . . . . 182
10.41. Source global page 219 . . . . . . . . . . . . . . . . . 183
10.42. Source global page 220 . . . . . . . . . . . . . . . . . 183
10.43. Source global page 221 . . . . . . . . . . . . . . . . . 184
10.44. Source global page 222 . . . . . . . . . . . . . . . . . 185
10.45. Source global page 223 . . . . . . . . . . . . . . . . . 185
10.46. Source global page 224 . . . . . . . . . . . . . . . . . 186
10.47. Source global page 225 . . . . . . . . . . . . . . . . . 186
10.48. Source global page 226 . . . . . . . . . . . . . . . . . 187
10.49. Source global page 227 . . . . . . . . . . . . . . . . . 187
10.50. Source global page 228 . . . . . . . . . . . . . . . . . 188
10.51. Source global page 229 . . . . . . . . . . . . . . . . . 188
10.52. Source global page 230 . . . . . . . . . . . . . . . . . 189
10.53. Source global page 231 . . . . . . . . . . . . . . . . . 190
10.54. Source global page 232 . . . . . . . . . . . . . . . . . 190
10.55. Source global page 233 . . . . . . . . . . . . . . . . . 191
Das Expires 29 April 2027 [Page 7]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
10.56. Source global page 234 . . . . . . . . . . . . . . . . . 192
10.57. Source global page 235 . . . . . . . . . . . . . . . . . 192
10.58. Source global page 236 . . . . . . . . . . . . . . . . . 193
10.59. Source global page 237 . . . . . . . . . . . . . . . . . 194
10.60. Source global page 238 . . . . . . . . . . . . . . . . . 195
10.61. Source global page 239 . . . . . . . . . . . . . . . . . 196
10.62. Source global page 240 . . . . . . . . . . . . . . . . . 197
10.63. Source global page 241 . . . . . . . . . . . . . . . . . 197
10.64. Source global page 242 . . . . . . . . . . . . . . . . . 198
10.65. Source global page 243 . . . . . . . . . . . . . . . . . 199
10.66. Source global page 244 . . . . . . . . . . . . . . . . . 200
10.67. Source global page 245 . . . . . . . . . . . . . . . . . 200
10.68. Source global page 246 . . . . . . . . . . . . . . . . . 201
10.69. Source global page 247 . . . . . . . . . . . . . . . . . 202
10.70. Source global page 248 . . . . . . . . . . . . . . . . . 203
11. Implementation With Existing Technology: PHOSITA-Oriented
Reference Design . . . . . . . . . . . . . . . . . . . . 204
11.1. Suggested Initial Software Components . . . . . . . . . 205
11.2. Available Technology Integration Profiles . . . . . . . 206
12. Reference Interfaces, State Machine, and Non-Normative
Algorithms . . . . . . . . . . . . . . . . . . . . . . . 207
12.1. Consumption, Retries, and Crash Semantics . . . . . . . 208
13. Threat Models, Adversary Capabilities, and Security Claims . 208
13.1. T1: Prompt Injection and Agent-Controlled Description . 209
13.2. T2: Replay, Revocation and Time-of-Check/Time-of-Use . . 209
13.3. T3: Effect-Path Bypass and Credential Confusion . . . . 209
13.4. T4: Forged, Missing, or Misclassified Outcome
Evidence . . . . . . . . . . . . . . . . . . . . . . . . 210
13.5. T5: Deviation-Laundering and Approval Confusion . . . . 210
13.6. T6: Availability, Resource Exhaustion and Privileged
Compromise . . . . . . . . . . . . . . . . . . . . . . . 210
13.7. Threat-to-Control Review Checklist . . . . . . . . . . . 210
14. Reference Test Plan and Falsifiable Acceptance Criteria . . . 211
14.1. CW1-01 — Valid bounded operation . . . . . . . . . . . . 211
14.2. CW1-02 — Agent changes recipient after evidence
creation . . . . . . . . . . . . . . . . . . . . . . . 211
14.3. CW1-03 — Agent changes request body after
authorization . . . . . . . . . . . . . . . . . . . . . 212
14.4. CW1-04 — Expired or revoked source grant . . . . . . . . 212
14.5. CW1-05 — Replay same enablement concurrently . . . . . . 212
14.6. CW1-06 — Sink receives altered target alias or
redirect . . . . . . . . . . . . . . . . . . . . . . . 212
14.7. CW1-07 — Validator-to-sink evidence substitution . . . . 213
14.8. CW1-08 — Resource version changes before commit . . . . 213
14.9. CW1-09 — Crash after consumption, before remote
acknowledgement . . . . . . . . . . . . . . . . . . . . 213
14.10. CW1-10 — Attempt alternate unmediated effect path . . . 213
Das Expires 29 April 2027 [Page 8]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
14.11. CW2-01 — Accepted authenticated predecessor-effect
receipt . . . . . . . . . . . . . . . . . . . . . . . . 214
14.12. CW2-02 — Queued or dispatched predecessor with no
qualified effect . . . . . . . . . . . . . . . . . . . 214
14.13. CW2-03 — Forged predecessor receipt . . . . . . . . . . 214
14.14. CW2-04 — Predecessor receipt bound to another task or
effect . . . . . . . . . . . . . . . . . . . . . . . . 214
14.15. CW3-01 — Material effect outside original scope . . . . 215
14.16. CW3-02 — Competent bounded reauthorization . . . . . . . 215
14.17. CW3-03 — Unqualified or stale approval . . . . . . . . . 215
14.18. SEC-01 — Validator slow or unavailable . . . . . . . . . 215
14.19. SEC-02 — Parallel agents use same single-use
reservation . . . . . . . . . . . . . . . . . . . . . . 216
14.20. INT-01 — Different JSON/CBOR implementations canonicalize
differently . . . . . . . . . . . . . . . . . . . . . . 216
14.21. Suggested Test Harness and Reporting Procedure . . . . . 216
15. Detailed Industry and Product Alignment With Security Problem
Space . . . . . . . . . . . . . . . . . . . . . . . . . . 217
15.1. Apple iOS, iPadOS, macOS; Siri, App Intents, and
Cross-Application AI Tools . . . . . . . . . . . . . . . 217
15.2. Voice and System Assistants: Apple Siri, Google Gemini,
Samsung Bixby, Microsoft Copilot, and Amazon Alexa . . . 217
15.3. Google Android and Cross-OS Mobile Interoperability . . 218
15.4. Microsoft Windows, Enterprise Copilots, Azure and Cloud
Automation . . . . . . . . . . . . . . . . . . . . . . . 218
15.5. OpenAI, Anthropic, Google Gemini and Meta Agent
Tooling . . . . . . . . . . . . . . . . . . . . . . . . 219
15.6. NVIDIA, Arm, Qualcomm, Huawei and Hardware-Backed
Security . . . . . . . . . . . . . . . . . . . . . . . . 219
15.7. Banking, Payments, Healthcare, Industrial,
Telecommunications and Robotics . . . . . . . . . . . . 220
16. Detailed IETF Working-Group, RFC, and Protocol Alignment . . 220
16.1. OAuth: Delegated Authorization, Rich Authorization
Requests, and Sender Constraint . . . . . . . . . . . . 220
16.2. WIMSE: Multi-System Workload Identity and Security
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 221
16.3. RATS: Attestation Evidence, Endorsements, and Verification
Results . . . . . . . . . . . . . . . . . . . . . . . . 221
16.4. COSE and CBOR: Authenticated Evidence Containers and
Encoding . . . . . . . . . . . . . . . . . . . . . . . . 221
16.5. ACE: Authorization for Constrained Devices and
Networks . . . . . . . . . . . . . . . . . . . . . . . . 222
16.6. SCITT: Evidence Transparency and Verifiable
Statements . . . . . . . . . . . . . . . . . . . . . . . 222
16.7. HTTP: Conditional Requests, Resource Identity and Response
Semantics . . . . . . . . . . . . . . . . . . . . . . . 222
16.8. SEC-DISPATCH and Security Area Review . . . . . . . . . 222
17. Industry and Product Alignment: Security Problem Mapping . . 223
Das Expires 29 April 2027 [Page 9]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
17.1. Apple iOS, iPadOS, macOS, and Third-Party AI Tools . . . 223
17.2. Android and Android-Compatible Operating Systems . . . . 223
17.3. OpenAI, Anthropic, Google, Meta, and AI Agent Tooling . 223
17.4. Microsoft Enterprise and Cloud Workloads . . . . . . . . 224
17.5. NVIDIA, Qualcomm, Huawei, Arm, and Device Hardware . . . 224
17.6. Banking, Telecommunications, Robotics, and Industrial
Systems . . . . . . . . . . . . . . . . . . . . . . . . 224
18. IETF Working-Group Relevance and Existing Protocol
Relationships . . . . . . . . . . . . . . . . . . . . . . 224
18.1. OAuth Working Group . . . . . . . . . . . . . . . . . . 224
18.2. WIMSE — Workload Identity in Multi System
Environments . . . . . . . . . . . . . . . . . . . . . . 224
18.3. RATS — Remote ATtestation ProcedureS . . . . . . . . . . 225
18.4. COSE — CBOR Object Signing and Encryption . . . . . . . 225
18.5. ACE — Authentication and Authorization for Constrained
Environments . . . . . . . . . . . . . . . . . . . . . . 225
18.6. SCITT — Supply Chain Integrity, Transparency, and
Trust . . . . . . . . . . . . . . . . . . . . . . . . . 225
18.7. Security Dispatch and Review . . . . . . . . . . . . . . 225
19. Relevance to the EU Artificial Intelligence Act . . . . . . . 225
20. Security and Privacy Considerations . . . . . . . . . . . . . 227
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 227
22. Informative References . . . . . . . . . . . . . . . . . . . 227
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 228
1. Introduction: Part 1 and the Twelve-Part Disclosure Series
This is Part 1 of 12, the Foundational component of the series Secure
AI Execution-Finality, Cross-Platform Interoperability, and Hardware
Security — A Twelve-Part Technical Specification Series. Its primary
purpose is searchable, detailed technical disclosure for independent
study by patent examiners, iOS and Android platform engineers, agent
security researchers and the broader security community. This is not
a declaration that an IETF working group has adopted the mechanism or
that any product implements it. Later parts use common definitions
and refer back to this foundation.
The security problem is that agent planning, natural-language intent,
ordinary application privileges, API token validity, approval
screens, container isolation, and even cryptographic authentication
may differ from authorization for the exact real-world consequence
about to occur. A computation or valid upstream credential does not
itself confer authority to act. In heterogeneous iOS, Android,
macOS, Windows, Linux and cloud deployments, requests may cross
device, operating-system, administrative, or hardware boundaries, and
the protected operation observed at the resource may differ from the
earlier request.
Das Expires 29 April 2027 [Page 10]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
This foundational specification preserves three common workflows from
the supplied 3,567-page technical specification: CW-1 (the general
protected effectuation architecture); CW-2 (causal continuation
conditioned on qualified actual-effect receipts); and CW-3 (scope-
deviation observation and independently authorized reauthorization).
Each workflow is transcribed in a searchable source-detail section
with source-page provenance, preceded by a technical overview and
adjacent architecture and decision-flow figures. The large original
disclosure remains the authoritative full technical source for all
variations.
The remainder of this Part 1 provides the shared definitions and
detailed source-based CW-1, CW-2 and CW-3 material; companion Parts
2–12 develop specialized mechanisms and contain embodiment-specific
architecture and operational figures. This series directory
describes planned content and should be reconciled against the final
source-to-draft coverage ledger before formal publication.
1.1. Companion Documents: Twelve-Part Series Directory
Part 1 of 12 — draft-das-interoperable-consequence-authority:
Foundational protected consequence authority, terminology, CW-1, CW-
2, CW-3, security invariants and the shared trust model. Proposed
Datatracker document address: https://datatracker.ietf.org/doc/draft-
das-interoperable-consequence-authority/ . A proposed address is not
a claim of Datatracker registration or publication.
Part 2 of 12 — draft-das-cross-platform-ai-interoperability: iOS,
Android, macOS and heterogeneous OS translation, platform-specific
adapters, effect descriptors and cross-application interoperability.
Proposed Datatracker document address:
https://datatracker.ietf.org/doc/draft-das-cross-platform-ai-
interoperability/ . A proposed address is not a claim of Datatracker
registration or publication.
Part 3 of 12 — draft-das-protected-authority-evidence: protected
source authority, collection- and execution-time evidence, cross-
commitment and scoped non-bearer finality. Proposed Datatracker
document address: https://datatracker.ietf.org/doc/draft-das-
protected-authority-evidence/ . A proposed address is not a claim of
Datatracker registration or publication.
Part 4 of 12 — draft-das-finality-sink-enforcement: actual pending
operation reconstruction, sink-local state, mandatory non-bypassable
effectuation and anti-replay. Proposed Datatracker document address:
https://datatracker.ietf.org/doc/draft-das-finality-sink-enforcement/
. A proposed address is not a claim of Datatracker registration or
publication.
Das Expires 29 April 2027 [Page 11]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Part 5 of 12 — draft-das-multi-agent-authority-control: delegation
lineage, cross-agent resource conflicts, protected coordination and
reservations. Proposed Datatracker document address:
https://datatracker.ietf.org/doc/draft-das-multi-agent-authority-
control/ . A proposed address is not a claim of Datatracker
registration or publication.
Part 6 of 12 — draft-das-causal-effect-receipts: qualified prior-
effect receipts and protected predecessor-dependent continuation.
Proposed Datatracker document address:
https://datatracker.ietf.org/doc/draft-das-causal-effect-receipts/ .
A proposed address is not a claim of Datatracker registration or
publication.
Part 7 of 12 — draft-das-agent-tool-integrity: tool contract drift,
target identity, dynamic tool discovery, algorithmic integrity and
runtime checks. Proposed Datatracker document address:
https://datatracker.ietf.org/doc/draft-das-agent-tool-integrity/ . A
proposed address is not a claim of Datatracker registration or
publication.
Part 8 of 12 — draft-das-distributed-effect-recovery: cross-domain
effects, distributed transactions, uncertain outcomes and
independently authorized recovery. Proposed Datatracker document
address: https://datatracker.ietf.org/doc/draft-das-distributed-
effect-recovery/ . A proposed address is not a claim of Datatracker
registration or publication.
Part 9 of 12 — draft-das-agent-credential-privacy: credential
custody, protected secret exercise, data disclosure, privacy and
provenance. Proposed Datatracker document address:
https://datatracker.ietf.org/doc/draft-das-agent-credential-privacy/
. A proposed address is not a claim of Datatracker registration or
publication.
Part 10 of 12 — draft-das-cross-device-authority-revocation: cross-
device authority movement, source fencing, revocation epochs and
partition-aware offline controls. Proposed Datatracker document
address: https://datatracker.ietf.org/doc/draft-das-cross-device-
authority-revocation/ . A proposed address is not a claim of
Datatracker registration or publication.
Part 11 of 12 — draft-das-hardware-execution-finality: kernel,
sandbox, hardware, accelerators and independent protected command
interfaces. Proposed Datatracker document address:
https://datatracker.ietf.org/doc/draft-das-hardware-execution-
finality/ . A proposed address is not a claim of Datatracker
registration or publication.
Das Expires 29 April 2027 [Page 12]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Part 12 of 12 — draft-das-autonomous-infrastructure-finality:
resource budgets, critical infrastructure, telecom and multi-resource
consequence governance. Proposed Datatracker document address:
https://datatracker.ietf.org/doc/draft-das-autonomous-infrastructure-
finality/ . A proposed address is not a claim of Datatracker
registration or publication.
2. Intellectual Property Rights (IPR) Disclosure and Forthcoming GitHub
Reference Implementation
This document forms Part 1 (Foundational) of the twelve-part
technical specification series and describes subject matter
associated with patent-pending technical disclosures by Sangam Kumar
Das. The principal underlying 8,598-page international technical
disclosure is identified as PCT/IB2026/055615, filed on 4 June 2026
and published as WO 2026/150382 [DAS-PCT]. This filing is distinct
from the publicly available 3,567-page technical specification cited
in this document and from other earlier or later applications.
Mention of an application does not imply patent grant, validity,
essentiality to a standard, or infringement by any product.
Detailed, draft-specific intellectual property rights disclosures,
including relevant application identifiers, claim scope, priority
relationships, and any applicable licensing declarations, are
intended to be submitted or updated separately through the
appropriate IETF IPR disclosure process in accordance with BCP 79
[RFC8179]. This notice is provided for transparency and is not
itself a completed IETF IPR disclosure, a licensing commitment, or a
substitute for any disclosure obligations that apply.
A GitHub reference implementation and related engineering materials
are planned to be linked in a subsequent revision. The intended
resources may include example implementations of the common
workflows, executable test harnesses, data-format examples, and
reproduction instructions, subject to actual publication and
verification. No GitHub repository location, implementation
completeness, experimental result, or publication date is claimed by
this statement. The reference URL and versioned commit identifiers
will be added only after they are publicly available.
The complete supporting specification is published as "iOS and
Android Interoperability for Secure Third Party AI Tools - Cross-
Platform Execution Finality, Hardware Security, and Interoperability
(3,567-Page Specification)" at https://zenodo.org/records/23657985
(DOI: 10.5281/zenodo.23657985) [ZENODO-FULL]. The publication
record, individual patent filings, any future IETF IPR statements,
and any future GitHub repository should be examined separately for
their respective content and dates.
Das Expires 29 April 2027 [Page 13]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
3. Keywords and Search Terminology
* AI agent security; autonomous AI tool execution; third-party AI
tools; iOS security; Apple iPadOS; macOS sandboxing; Android
interoperability; Google Android permissions; Windows and Linux
authorization; mobile AI assistants
* prompt injection; tool-call security; malicious instructions;
hallucinated API calls; unauthorized side effects; cross-
application permissions; credential misuse; sandbox bypass;
authorization drift
* Candidate Act (CA); Non-Effective State (NES); Protected
Enforcement Domain (PED); Finality Sink (FS); protected validation
evidence; scoped non-bearer authority; act-specific validation;
effectuation boundary; fail-closed authorization
* OAuth; proof of possession; RATS attestation; COSE signed
structures; ACE authorization; WIMSE workload identity; SCITT
evidence transparency; API gateways; enterprise AI security;
network egress policy
* causal actual-effect receipt; continuation dependencies;
reauthorization; cross-domain effect evidence; protected authority
state; replay protection; sink-local state; crash consistency;
delegated authority; resource identity
* Apple iOS and Android cross-platform AI interoperability;
Microsoft enterprise agent security; Google and Meta AI agents;
OpenAI and Anthropic agent tooling; NVIDIA hardware enforcement;
Qualcomm, Huawei and Arm mobile security; banking; telecom;
robotics
* Apple Siri; App Intents; Shortcuts; Google Gemini; Android
intents; Samsung Bixby; Microsoft Copilot; Amazon Alexa; voice
assistant security; assistant-initiated actions
* EU AI Act; Regulation (EU) 2024/1689; risk management; record-
keeping; human oversight; robustness and cybersecurity; AI
governance; traceability
Das Expires 29 April 2027 [Page 14]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
4. Publication Source, Patent-Pending Context, and Technical Provenance
Full technical source: Sangam Kumar Das, "iOS and Android
Interoperability for Secure Third Party AI Tools - Cross-Platform
Execution Finality, Hardware Security, and Interoperability
(3,567-Page Specification)", Zenodo record https://zenodo.org/
records/23657985 ; DOI https://doi.org/10.5281/zenodo.23657985 . The
seven source PDFs divide this 3,567-page specification into original
global page ranges 1–554, 555–1062, 1063–1541, 1542–2011, 2012–2566,
2567–3101, and 3102–3567. Zenodo record metadata currently displays
a publication date of 27 October 2026; do not presume public
accessibility before the actual publication date. The available
description contains conflicting page counts in some passages; this
series consistently identifies the assembled source as 3,567 pages.
Patent-pending technical context: principal 8,598-page disclosure
PCT/IB2026/055615, filed 4 June 2026 and published as WO 2026/150382;
the separately identified earlier PCT/IB2025/058316 must not be
conflated with that principal 8,598-page disclosure. The scope of an
application and any legally effective priority date are determined by
the original filing, not by this Internet-Draft. Related Indian and
later PCT application mapping is to be supplied after checking the
actual filed materials. Patent-pending status is not a statement of
grant, infringement, originality determination, or IETF endorsement.
Applicable IETF IPR disclosures must be filed separately under BCP
79.
5. Shared Terminology and Protected Authority Model
Candidate Act (CA): An identifiable proposal for a consequential
operation, distinguishable from permission to produce the actual
effect.
Non-Effective State (NES): A protected condition in which a proposed
consequential operation has not been permitted to cause the governed
external consequence.
Protected Enforcement Domain (PED): A component or trust domain
performing protected verification or enforcing qualification
conditions independently of the untrusted proposing computation.
Protected validation evidence: Qualified, integrity-protected
evidence binding an operation and its context to validation
predicates at the appropriate protected point.
Das Expires 29 April 2027 [Page 15]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Scoped non-bearer finality enablement: Operation-scoped authority
that is not merely a freely reusable bearer credential; effectiveness
requires actual final-sink correspondence and protected state
verification.
Finality Sink (FS): The protected effectuation interface that
independently obtains or reconstructs the actual pending operation
and enforces current evidence, authority, and local-state checks
before an effect.
Source authority: An authenticated competent originating grant
establishing the permissible purpose, principal, resource and
consequence envelope.
Actual pending operation: The consequential operation as presented at
the controlled interface, rather than only a workload-described
intention or upstream SDK record.
Protected consumption: A state transition preventing unauthorized
replay, duplication, stale reuse, or repeated exercise of operation-
specific authority.
Qualified actual-effect receipt: Evidence sufficient, under a stated
trust and observer model, to support a prescribed earlier actual
consequence; neither a mere request receipt nor an unqualified
acknowledgment.
Protected scope delta: An authenticated, bounded modification of the
authorized scope, verified separately from an agent-supplied
explanation.
Fail-closed withholding: Refusal to permit a governed consequence
when a mandatory predicate, authority condition, evidence, or
enforcement capability cannot be established.
This short register aids discovery. The complete source-derived
terminology and specialized conditions are further elaborated in the
transcription of CW-1 through CW-3 below; non-limiting variants do
not become universal requirements merely because they are described
in the same source.
6. Core Security Principles and Enforceability Limitations
* Computation, inference, application invocation, and authenticated
session state are not by themselves authority to cause a
particular consequential effect.
Das Expires 29 April 2027 [Page 16]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
* Upstream assertions of intended action do not replace
independently obtained or reconstructed actual operation fields at
the Finality Sink.
* The necessity and independence of collection-time, execution-time,
and sink-time evidence depend on the selected source-supported
implementation and threat model.
* Mandatory validation predicates must be checked before
effectuation; unavailable mandatory evidence or enforcement
remains fail-closed.
* Protected local authority consumption must not be reset casually
after retry, restart, rollback or ambiguous remote acknowledgment.
* Causal continuations requiring real prior effects use accepted
qualified effect evidence rather than only dispatch or coordinator
approval.
* Scope deviations are separately adjudicated; a proposed anomaly
explanation or approval screen is not itself final authority.
* Remote, offline or independently administered resources can
support only the guarantees permitted by their actual enforcement
channels, revocation freshness and trust boundaries.
7. Common Master Workflow CW-1: Protected Effectuation
This foundational workflow is grounded in original global source
pages 15–62 of the 3,567-page disclosure (first uploaded PDF). The
material below includes a technical architectural figure, operational
flowchart, and a page-indexed detailed transcription of source text.
Subsequent editing for a public standards-track proposal, if any,
must not change the semantics of the original disclosed optional and
mandatory mechanisms.
7.1. Architecture and Trust Boundaries
Diagram highlights the main protected relationships. It is an
interpretive overview, not a substitute for the full qualifications
in the page-indexed technical disclosure.
Das Expires 29 April 2027 [Page 17]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
[Principal / source grant]
|
[Agent proposes Candidate Act]
|
[Non-Effective State]
|
[PED: context and source]
[protected evidence check]
|
[Scoped finality enablement]
|
[Finality Sink: reconstruct]
[actual pending operation]
|
[Sink-local state / consume]
|
[Governed actual effect]
Figure 1: CW-1 protected component architecture
7.2. Operational Decision Flow
The flowchart illustrates the primary allow/withhold decision
sequence; additional branches, failure modes, and optional variants
are given in the following source-derived sections.
[Construct Candidate Act]
|
[Hold non-effective]
|
<Source authority valid?>--No-->[Withhold]
| Yes
<Evidence current and bound?>--No-->[Withhold]
| Yes
[Prepare scoped authority]
|
[Sink reconstructs actual act]
|
<Act/state/authority match?>--No-->[Withhold]
| Yes
[Commit protected consumption]
|
[Permit covered effect]
Figure 2: CW-1 operation and security decision flowchart
7.3. Detailed Source-Derived Technical Disclosure
Das Expires 29 April 2027 [Page 18]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
7.3.1. Source global page 15
COMMON MASTER WORKFLOW CW-1
MODULAR PROTECTED EXECUTION-FINALITY ARCHITECTURE WITH ACTUAL-
OPERATION RECONSTRUCTION, INDEPENDENT PROTECTED AUTHORITY, NON-
BYPASSABLE CONSEQUENCE ENFORCEMENT, CROSS-DOMAIN SECURITY, AND
OPTIONAL ADVANCED TECHNICAL MECHANISMS FOR PRESENT AND FUTURE
AUTONOMOUS COMPUTING SYSTEMS
CW-1.0 — PURPOSE, TECHNICAL FIELD, AND GENERAL DESCRIPTION The
present disclosure provides a Common Master Workflow, designated CW-
1, for governing consequential operations proposed, prepared,
scheduled, delegated, transmitted, or otherwise initiated by
autonomous computational entities. Such entities may include
artificial-intelligence agents, machine-learning systems, autonomous
assistants, multi-agent execution frameworks, operating-system
services, applications, device controllers, distributed software
services, embedded computing systems, robotic controllers,
programmable hardware, communication infrastructure, and other
computational entities capable of initiating externally consequential
operations.
CW-1 establishes a common technical foundation for the inventions and
embodiments described subsequently in this specification. The
workflow distinguishes the computational production of a proposed
operation from the protected technical authority required to cause
its consequential effect. In a principal implementation, an
operation proposed by a computational entity is represented as a
Candidate Act and is maintained in a Non-Effective State until
applicable authorization conditions are satisfied. A Protected
Enforcement Domain evaluates the applicable evidence, authorization,
current technical conditions, and protected state. The applicable
protected authority produces, enables, or commits scoped finality
authorization. A Finality Sink independently obtains or reconstructs
the actual pending operation and verifies the
Das Expires 29 April 2027 [Page 19]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
authority against the real operation presented at the consequential
boundary. The Finality Sink permits the specified consequence only
upon successful verification of all mandatory conditions. The
authorization may be cryptographically represented, maintained as
protected state, implemented through secure hardware, or realized
through a combination of protected software and hardware mechanisms.
The system may operate across a single processor, multiple processes,
multiple devices, administrative domains, protected controllers, or
distributed infrastructure.
CW-1.0.1 — Fundamental Technical Principle The foundational principle
is:
7.3.2. Source global page 16
Computation is not authority to act. The production of a command,
plan, model output, tool invocation, workflow instruction,
transaction proposal, or executable operation does not itself confer
final authority to cause the corresponding consequential effect.
Similarly, an agent's successful authentication, possession of an API
credential, access to a software tool, or apparent satisfaction of an
application-level policy does not automatically establish the
complete protected authority required by a particular execution-
finality implementation. The relevant authority must be verified
according to the defined protected trust model and at an enforcement
boundary capable of withholding the actual effect.
CW-1.0.2 — Common Architecture Rather Than One Mandatory Physical
Arrangement
CW-1 is not restricted to one hardware or software topology. The
protected validation function and Finality Sink may be separated or
integrated. The protected authority may reside within a dedicated
security processor, secure microcontroller, isolated execution
environment, protected operating-system service, firmware controller,
remote protected authorization service, or another computing
substrate providing the required security properties. A single
protected component may implement multiple logical functions.
Alternatively, each function may be distributed among independently
controlled devices. The defining technical relationship is the
controlled progression from Candidate Act through protected
authorization to independent final effectuation verification. The
physical number of processors, devices, servers, or communication
links is not an essential
limitation unless expressly required by a particular embodiment.
Das Expires 29 April 2027 [Page 20]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.0.3 — General Proposed Inventive Direction The candidate
technical contribution of CW-1 concerns the combination and
enforcement relationships among operation-specific non-authority,
protected evidence evaluation, scoped execution enablement, actual
pending-operation reconstruction, sink-local protected state, and
effectuation-boundary control. The proposed distinction is not that
an AI agent uses a sandbox, cryptographic key, access-control rule,
approval screen, or security gateway. Those techniques are
individually established. The technical question is whether a
particular implemented combination makes independently verified,
operation-specific protected authority a necessary condition for the
actual consequential effect and prevents an untrusted computational
entity from bypassing that condition through an
alternative route within the claimed enforcement coverage.
CW-1.0.4 — Optional Technical Extensions
7.3.3. Source global page 17
CW-1 supports additional mechanisms addressing concurrent agents,
conflicting effects, semantic target correspondence, delegated
authority, privacy constraints, resource allocation, protected state
continuity, remote execution, actual outcome witnessing, hardware
enforcement, user reauthorization, and causal continuation between
consequential phases. Each extension may be applied individually or
in compatible combinations. No optional mechanism is universally
mandatory merely because it appears in CW-1. Where an embodiment
expressly requires a particular technical feature, omission of that
feature is not treated as satisfying the corresponding embodiment.
CW-1.0.5 — Scope of Present and Future Implementations The common
architecture is applicable to presently implementable systems using
protected software gateways, secure processors, transaction
controllers, cryptographic authorization, hardware command gates,
protected storage, and authenticated communication. It also supports
proposed advanced implementations involving cross-provider autonomous
agents, heterogeneous compute accelerators, multi-device autonomy,
safety-critical robotic systems, advanced communication networks,
confidential computing, distributed protected validators, and future
effect-capable hardware interfaces. The advanced implementations are
technical alternatives and development directions, not assertions
that such systems have already been built or commercially deployed.
CW-1.1 — RELATIONSHIP TO INDIVIDUAL EMBODIMENTS
Das Expires 29 April 2027 [Page 21]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1 provides a reusable common protected execution framework for the
subsequent embodiments. An individual embodiment may incorporate the
baseline Candidate Act, Non-Effective State, Protected Enforcement
Domain, scoped authority, and Finality Sink mechanisms without
requiring every additional verification module. For example, a
cross-agent conflict embodiment may require protected conflict
reservations. A semantic correspondence embodiment may require
evidence linking a user-observed object to the actual operation
target. A privacy-composition embodiment may require protected
cumulative disclosure state. A phased-effectuation embodiment may
require an authenticated prior real-effect receipt. A protected
device-migration embodiment may require exclusive authority ownership
and stale-
owner fencing. The relevant technical requirements are selected
according to the particular effect being governed.
CW-1.1.1 — Reference to CW-2
CW-2 provides an optional specialized mechanism for causally ordered
receipt-gated effectuation.
7.3.4. Source global page 18
Where the principal inter-phase CW-2 implementation is selected, an
earlier bounded real effect produces qualified evidence accepted by
an authorized cryptographically identifiable Interim Effectuation
Validator. The validator-accepted receipt is a necessary causal
enabling factor for the next consequential phase. The next Finality
Sink verifies the applicable authenticated receipt-dependent
condition before permitting the successor effect.
CW-1 does not require that every single-effect operation use such a
phased continuation mechanism.
CW-1.1.2 — Reference to CW-3
CW-3 may provide optional protected anomaly-triggered human or
automated reauthorization. Where an autonomous operation departs
from its originally authorized scope, a protected system may require
renewed approval. However, approval does not automatically satisfy
unrelated mandatory technical predicates, including current resource
identity, finality authority, physical safety constraints, or an
applicable
CW-2 causal receipt.
Das Expires 29 April 2027 [Page 22]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.1.3 — Independent Inventive Contributions Each subsequent
embodiment may disclose additional technical structures, state
transitions, algorithms, threat models, actual enforcement
interfaces, and technical effects. The general existence of CW-1
does not establish that every optional embodiment is novel or
inventive. Individual technical contributions must be evaluated in
relation to their corresponding prior art.
CW-1.2 — TECHNICAL PROBLEMS AND LIMITATIONS OF CONVENTIONAL SYSTEMS
CW-1.2.1 — Conventional Permission Does Not Necessarily Govern Actual
Consequence A conventional access-control system may determine
whether a requesting principal has permission to use a resource. The
permitted software may nevertheless construct different actual
command parameters after the authorization check. For example, an
agent may receive permission to send a selected document to a
designated destination. After the initial permission is granted, the
selected document, destination, version, or transmission parameters
may change.
7.3.5. Source global page 19
A static permission does not necessarily establish that the actual
later transmission corresponds to the authorized operation.
CW-1 addresses this problem through operation-specific authority
binding and final enforcement against the actual pending effect.
CW-1.2.2 — Conventional Authentication Does Not Establish Full
Execution Authority Authentication establishes an identity under a
particular trust model. It does not necessarily establish that every
requested operation by the authenticated entity is authorized. For
example, a validly authenticated autonomous process may attempt a
payment, file export, network transmission, or device operation
outside its permitted task scope.
CW-1 separates authenticated origin from finality authorization.
CW-1.2.3 — Conventional Sandboxing Does Not Necessarily Bind Each
Effect A sandbox may restrict access to files, networks, processes,
or devices. Such isolation is useful and may be an important
implementation component. However, permission to access an interface
does not necessarily establish that every operation through the
interface is specifically authorized.
CW-1 may use a sandbox while additionally requiring operation-
specific protected evidence and sink-side authorization.
Das Expires 29 April 2027 [Page 23]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.2.4 — Conventional Approval May Be Temporally Detached An
approval may concern a proposed operation at an earlier time. The
actual operation may be executed later under changed resource,
runtime, policy, or destination conditions.
CW-1 may require revalidation at the effectuation boundary or binding
to protected current-state evidence.
CW-1.2.5 — Conventional Tool Gateways May Be Advisory or Incomplete A
tool gateway may inspect application requests. However, an agent may
possess access to another effect-capable interface. An enforcement
mechanism is non-bypassable only to the extent that the relevant
alternative effectuation routes are controlled.
CW-1 introduces explicit effectuation-path coverage as a technical
requirement where system-wide protection is asserted.
CW-1.2.6 — Conventional Agent Coordination May Lack Protected
Authority
7.3.6. Source global page 20
A multi-agent orchestrator may assign tasks and request that agents
execute in a particular order. An instruction to wait, avoid
conflicts, or ask permission does not necessarily prevent another
agent from acting through an independently available credential or
tool. The present architecture may incorporate protected conflict
governance and final sink enforcement.
CW-1.2.7 — Conventional Audit Logging Is Not Prevention A log may
establish that an operation was attempted or completed. However, an
audit entry made after an unauthorized effect does not prevent the
effect.
CW-1 may use protected evidence before release and final sink
verification before effectuation. Optional post-effect evidence has
a distinct function concerning actual outcome and possible later
causal continuation.
CW-1.2.8 — Conventional Remote Acknowledgements May Be Incomplete A
local network send confirmation may establish that a command was
transmitted. It does not necessarily prove that the remote operation
completed.
CW-1 distinguishes dispatch evidence, actual effect evidence, and
verified remote outcome.
Das Expires 29 April 2027 [Page 24]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.2.9 — Conventional Credential Possession May Create Broad
Authority A reusable API credential may permit many operations. If a
compromised agent can directly exercise the credential, authorization
may be broader than the specific approved task.
CW-1 may employ credential brokers, scoped finality capabilities,
protected command authentication, or sink-local authorization to
reduce the mismatch between credential possession and permitted
effect.
CW-1.2.10 — Proposed Objective Technical Problem An illustrative
objective technical problem is: How to ensure that an operation
generated or requested by an autonomous computational entity cannot
produce its governed consequential effect unless a protected
enforcement system verifies operation-specific authority against the
actual pending operation and current applicable protected state at a
technical boundary capable of withholding the effect, while
accommodating heterogeneous execution interfaces, distributed
authority, changing runtime conditions, and optional specialized
verification requirements.
CW-1.3 — COMMON PROTECTED SYSTEM ARCHITECTURE
CW-1.3.1 — Requesting Computational Entity
7.3.7. Source global page 21
A Requesting Computational Entity, or RCE, may comprise an AI agent,
application, service, workflow orchestrator, autonomous controller,
delegated tool, operating-system process, remote execution system, or
another component capable of proposing or initiating a consequential
operation. The RCE may perform inference, planning, task
decomposition, data processing, and operation preparation. It does
not automatically acquire final execution authority from those
functions.
CW-1.3.2 — Candidate Act Construction Component The Candidate Act
Construction Component identifies a proposed consequential operation
and constructs a machine-verifiable representation. A Candidate Act
Descriptor may bind the actual action class, resource, destination,
requesting principal, permitted effect, parent task, current scope,
and relevant authority context. The component may be located within
a protected dispatcher, application gateway, operating system, secure
processor, or service infrastructure.
CW-1.3.3 — Non-Effective Holding Mechanism A Non-Effective Holding
Mechanism maintains the proposed operation before its governed
consequence becomes effective. The hold may be implemented through a
Das Expires 29 April 2027 [Page 25]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
protected command queue, disabled network transmission, sealed
operation buffer, uncommitted storage transaction, blocked actuator
command, withheld credential release, or another actual enforcement
structure. A simulated hold that does not prevent effectuation
through the relevant controlled path does not satisfy the required
property.
CW-1.3.4 — Protected Enforcement Domain A Protected Enforcement
Domain, or PED, evaluates evidence and maintains protected authority
state. It may be realized through a secure processor, isolated
execution environment, hardware security component, protected
operating-system service, secure firmware, or remote protected
authority. The PED may maintain cryptographic keys, protected
counters, revocation state, permitted operation scopes, evidence
commitments, current policy versions, and capability-consumption
state.
CW-1.3.5 — Extended Verification Module Interface An Extended
Verification Module Interface, or EVMI, permits specialized
verification functions to evaluate relevant aspects of a Candidate
Act. The modules may verify semantic identity, resource constraints,
privacy exposure, cross-agent conflicts, runtime integrity, actual
outcome evidence, or other mandatory technical predicates.
7.3.8. Source global page 22
The EVMI may be an internal protected function call, an authenticated
service interface, secure monitor operation, or distributed
validation protocol.
CW-1.3.6 — Protected Evidence Source A Protected Evidence Source
supplies information used to establish authorization or actual
operation correspondence. Evidence may originate from protected
application state, a trusted controller, authenticated remote
service, protected hardware register, secure sensor, or another
qualified technical source. The trustworthiness of a source depends
upon its actual observation or control capabilities.
CW-1.3.7 — Protected Authority Preparation Component A protected
authority component constructs, derives, signs, activates, or
otherwise prepares the execution-enabling material required for the
specific authorized act. The resulting authority may be represented
as an Execution Handle, App-Scoped Fractional Capability, protected
command authorization, scoped cryptographic capability, or equivalent
finality enablement.
Das Expires 29 April 2027 [Page 26]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.3.8 — Finality Gate A Finality Gate coordinates applicable
authorization predicates and determines whether finality authority
may become usable. The gate may be integrated with the PED or
Finality Sink. The gate is not assumed to provide complete
protection unless the actual effectuation boundary enforces its
required decision.
CW-1.3.9 — Finality Sink A Finality Sink, or FS, is the technical
component or boundary at which the governed operation can be
permitted or refused before its specified consequence occurs. A sink
may comprise a network egress controller, storage commit controller,
payment dispatcher, protected application-function dispatcher,
sensor-release interface, secure display controller, hardware
actuator interface, or another relevant effectuation component. The
sink obtains or reconstructs the actual pending operation and
verifies the required protected authority before allowing it.
CW-1.3.10 — Protected State and Evidence Store A Protected State and
Evidence Store maintains relevant authorization, validation, attempt,
consumption, revocation, continuation, and recovery state. It may be
local, replicated, or distributed. Its consistency mechanism is
selected according to the technical guarantees required.
7.3.9. Source global page 23
CW-1.3.11 — Protected Effect Observation Component An optional
Protected Effect Observation Component, or PEOC, obtains evidence
concerning an earlier actual consequential effect. The component
does not presume that sending a command proves completion of the
requested remote or physical result.
CW-1.3.12 — Interim Effectuation Validator An optional Interim
Effectuation Validator may provide independent pre-effect operation
validation or receipt-gated inter-phase continuation. Where a CW-2
receipt-gated phase is mandatory, the IEV has a cryptographically
verifiable identity, and its accepted prior-effect receipt becomes a
necessary causal factor for successor effectuation.
CW-1.3.13 — Effectuation-Path Coverage Controller An optional
Effectuation-Path Coverage Controller maintains evidence concerning
the interfaces through which a particular effect class may be
produced. It may identify authorized gateways, system interfaces,
hardware access routes, privileged services, credential-release
paths, and application dispatchers. Where required, the controller
detects coverage changes and invalidates assumptions that a protected
sink remains mandatory.
Das Expires 29 April 2027 [Page 27]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.3.14 — Protected Authority and Validator Identity Registry A
protected registry may identify trusted PED instances, valid Finality
Sinks, authorized validation modules, permitted validator identities,
cryptographic credentials, and current revocation state. The
registry may support local and cross-domain trust establishment.
CW-1.4 — TRUST MODEL AND PROTECTED ASSUMPTIONS The system
distinguishes computational entities that request operations from
components authorized to permit the corresponding consequences. A
requesting agent may be untrusted with respect to finality authority.
An application may supply useful operation context without possessing
authority to mint protected execution capabilities. An operating-
system service may transport authority objects without being entitled
to expand their permitted scope. A remote service may supply
authenticated observations without being treated as trustworthy for
outcomes outside its technical visibility. A cryptographically
authenticated message proves provenance under the applicable key
assumptions, not the truth of every statement in that message.
7.3.10. Source global page 24
CW-1.4.1 — Protected Authority Boundary The PED and applicable
Finality Sink must maintain the authority material and state
necessary to prevent unauthorized release under the claimed threat
model.
CW-1.4.2 — Software-Only Trust Model A protected software service may
provide useful isolation from ordinary agent processes. However, a
software-only implementation is not presumed secure against a fully
compromised privileged operating system unless additional appropriate
protection exists.
CW-1.4.3 — Hardware-Backed Trust Model A hardware-backed
implementation may use protected processors, secure elements,
hardware- controlled effectuation, isolated command buffers, or
cryptographic identity modules. Hardware isolation does not
eliminate the need to verify correct policy, command binding, and
actual effect coverage.
CW-1.4.4 — Remote Trust Model A remote protected authority may
communicate with a local Finality Sink through authenticated
messages. The local sink independently verifies the authorization
rather than treating remote approval as unrestricted local execution
permission.
CW-1.4.5 — Distributed Trust Model Several domains may cooperate in
validation and effectuation. Each participating domain has an
authenticated identity, permitted role, and defined protected state
Das Expires 29 April 2027 [Page 28]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
responsibilities. An implementation may employ consensus, quorum
validation, fencing, or other distributed coordination when
necessary. Such mechanisms are not automatically required for every
local single-sink operation.
CW-1.4.6 — Explicit Boundary Qualification A claimed non-
bypassability property applies to the effectuation paths actually
controlled by the implementation. An architecture that does not
mediate an alternative route capable of producing the same governed
consequence cannot automatically claim protection against that route.
CW-1.5 — COMMON MACHINE-VERIFIABLE RECORDS
CW-1.5.1 — Candidate Act Descriptor
7.3.11. Source global page 25
A Candidate Act Descriptor may contain the requesting entity
identity, original task reference, action class, permitted resource,
destination, operation arguments, designated Finality Sink, current
authority scope, protected context, and applicable module references.
The descriptor may also include actual observed resource state,
operation-semantics identity, permitted transformations, and
protected freshness values. The specific fields are selected
according to the operation.
CW-1.5.2 — Protected Validation Evidence Record A Protected
Validation Evidence Record, or PVER, binds a Candidate Act to
applicable protected validation results. The record may comprise
cryptographically authenticated data, protected local state, a signed
receipt, or an equivalent integrity-protected representation. It
does not require a blockchain or ledger.
CW-1.5.3 — Extended Verification Evidence Extended Verification
Evidence, or EVE, represents a specialized verification module's
authenticated result. The result may bind the Candidate Act, module
identity, evaluated predicate, evidence source, current state, and
applicable effectuation constraint.
CW-1.5.4 — Scoped Finality Authority Scoped Finality Authority, or
SFA, means an execution-enabling authority object, protected state,
or capability constrained to the corresponding permitted effect. It
may bind operation parameters, resource, destination, designated
sink, validity period, protected evidence, and consumption
conditions. An SFA need not be a freely transferable bearer token.
Das Expires 29 April 2027 [Page 29]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.5.5 — Protected Effect Receipt A Protected Effect Receipt
records or represents authenticated evidence concerning an earlier
actual effectuation attempt or outcome. Its validity depends upon
the observation source and supported effect predicate. Where CW-2
receipt-gated continuation is required, the receipt accepted by an
authorized IEV becomes the necessary causal enabling factor for the
next protected phase.
CW-1.5.6 — Continuation Authority Record A Continuation Authority
Record represents successor-specific authority associated with
accepted prior-effect evidence or other applicable continuation
predicates.
7.3.12. Source global page 26
Where CW-2 applies, a CAR may directly incorporate or be constituted
through the required validator-accepted receipt.
CW-1.5.7 — Protected Consumption Record A Protected Consumption
Record identifies whether a bounded authorization has already been
reserved, consumed, or invalidated. It may include a protected
counter, unique operation reference, state version, or equivalent
anti- replay mechanism.
CW-1.5.8 — Protected Effectuation Coverage Record An optional
Protected Effectuation Coverage Record identifies which enforcement
paths are expected to control a particular effect class. It may
record authorized interfaces, relevant security policy, versioned
controller identities, and measured coverage state.
CW-1.5.9 — Protected Semantic Correspondence Record A Protected
Semantic Correspondence Record may bind a user-visible or
application-visible referent to the actual operation target. It may
carry evidence concerning object identity, version, presentation
state, destination, or other applicable context.
CW-1.5.10 — Protected Authority Lineage Record An optional Protected
Authority Lineage Record may represent the relationship among
original authority, delegated authority, successor operations, and
applicable resource or effect constraints.
Das Expires 29 April 2027 [Page 30]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.5.11 — Deterministic Encoding and Canonicalization Protected
records may employ deterministic binary encoding, canonical
structured data, typed fields, or another unambiguous representation.
The protocol must specify how equivalent or distinct operations are
represented. Differences in string normalization, resource aliases,
numerical representation, schema version, nested object ordering, and
encoded payload interpretation may affect actual-operation
correspondence. A cryptographic digest is only as meaningful as the
canonical representation from which it is derived.
CW-1.6 — DETAILED COMMON EXECUTION WORKFLOW PHASE CW-1.6.0 —
PROTECTED AUTHORITY INITIALIZATION
7.3.13. Source global page 27
The system establishes protected trust anchors, authority state,
enrolled principals, valid sinks, current policy versions,
cryptographic verification material, applicable module identities,
and revocation state. Where needed, the system also establishes
validator identities and effectuation-path coverage information.
Initialization may occur during device enrollment, protected service
startup, session initiation, application registration, or another
suitable event. An earlier enrollment does not automatically
authorize all later consequential acts. PHASE CW-1.6.1 — REQUEST
RECEIPT AND ORIGIN AUTHENTICATION A requesting computational entity
submits a proposed operation. The receiving component identifies the
apparent requester and obtains available authentication evidence.
The system distinguishes authenticated principal identity from a
model-generated declaration of
authority. An unverified claim that an agent is permitted to act is
insufficient. PHASE CW-1.6.2 — CANDIDATE ACT CONSTRUCTION The
operation is converted into a Candidate Act Descriptor. The
descriptor identifies the consequential operation sufficiently to
distinguish it from materially different alternatives. Where
required, the descriptor binds the actual resource, recipient,
destination, payment amount, physical target, application function,
or other effect-specific parameters. PHASE CW-1.6.3 — NON-EFFECTIVE
HOLD The system establishes an enforceable hold. A network
transmission may be withheld. A storage transaction may remain
uncommitted. An actuator command may remain disabled. A credential
may remain inaccessible. A protected operation may remain in a
sealed command buffer. The hold must be capable of preventing the
governed consequence through the designated protected
path. PHASE CW-1.6.4 — EVIDENCE COLLECTION
Das Expires 29 April 2027 [Page 31]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
7.3.14. Source global page 28
The system obtains relevant identity, authority, context, operation,
resource, destination, runtime, and policy evidence. The evidence is
classified by source and assurance. An unsupported assertion is not
silently promoted into protected proof. PHASE CW-1.6.5 — REQUIRED
VERIFICATION MODULE SELECTION The protected system determines which
specialized verification predicates apply. Module selection may
depend upon action class, resource class, privacy sensitivity, cross-
agent activity, semantic ambiguity, physical actuation, runtime
conditions, or prior-effect dependency. An untrusted agent may
propose a task classification but cannot suppress a mandatory module
merely by omitting its identifier. PHASE CW-1.6.6 — BASELINE
AUTHORIZATION The PED verifies applicable requesting-principal
authority, action scope, resource permission,
destination, current revocation state, and policy requirements.
Failure of a mandatory predicate prevents release. PHASE CW-1.6.7 —
SPECIALIZED VERIFICATION Selected modules verify additional
predicates. For example, a conflict module may verify compatibility
with another authorized operation. A semantic module may verify the
actual resource corresponding to a user's selected object. A privacy
module may verify cumulative disclosure constraints. A physical-
scene module may verify the intended actuator target. An optional
outcome module may verify an earlier actual effect. PHASE CW-1.6.8 —
COMPOSITE PROTECTED DECISION The PED or an authorized coordinator
combines the applicable results. A representative abstract condition
is: BASELINE_AUTHORITY_VALID AND REQUIRED_MODULES_VALID AND
CURRENT_PROTECTED_STATE_VALID
AND REQUIRED_ENFORCEMENT_PATH_VALID The composition may be
implemented through one controller or multiple authenticated
protected domains.
7.3.15. Source global page 29
Mandatory denials are not overridden by omission of the relevant
module. PHASE CW-1.6.9 — PROTECTED STATE RESERVATION Where required,
the system atomically reserves operation-specific state. It may
allocate a consumption reference, reserve a resource, establish a
conflict fence, bind a semantic target, or record a current authority
epoch. PHASE CW-1.6.10 — VALIDATION EVIDENCE COMMITMENT The PED
commits applicable protected validation evidence. Where a particular
implementation requires an authenticated receipt before authority
release, the receipt commitment must succeed. An untrusted process
log is not a substitute for required protected evidence. PHASE CW-
1.6.11 — SCOPED AUTHORITY FORMATION The protected system creates,
activates, derives, signs, or otherwise establishes the required
Das Expires 29 April 2027 [Page 32]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
finality
authority. The authority is bound to the specific permitted act or
bounded class of acts. It may be represented as a sealed capability,
execution handle, protected command authorization, or sink-local
enablement state. PHASE CW-1.6.12 — AUTHORITY PRESENTATION The
resulting authority is supplied or made available to the designated
Finality Sink. An untrusted process may transport a reference
without obtaining authority to alter it. PHASE CW-1.6.13 — ACTUAL
PENDING-OPERATION RECONSTRUCTION The Finality Sink obtains or
reconstructs the actual operation presented for effectuation. Where
technically possible, the sink obtains relevant parameters from the
controlled dispatch or effectuation interface rather than relying
exclusively upon the original agent-declared intent. The sink may
verify the actual target, destination, resource version, command
parameters, operation
semantics, and relevant current state. PHASE CW-1.6.14 — SINK-TIME
REVALIDATION The Finality Sink compares the actual operation with the
protected authority. Where a material parameter or applicable
protected state has changed, the sink may refuse effectuation or
require renewed authorization. The verification may include current
revocation, ownership, resource reservation, semantic correspondence,
and mandatory module-specific predicates.
7.3.16. Source global page 30
PHASE CW-1.6.15 — PROTECTED CONSUMPTION Where the operation requires
single-use authority, the sink atomically reserves or consumes the
applicable authorization reference. The state transition prevents
unauthorized duplicate effects under the selected enforcement
assumptions. PHASE CW-1.6.16 — CONTROLLED EFFECTUATION The sink
permits the specified actual consequence. The effect may comprise a
network transmission, payment submission, storage commit,
application- function dispatch, physical command, sensor disclosure,
protected data release, or other consequential operation. PHASE CW-
1.6.17 — EFFECT ATTEMPT RECORD The system records or commits
appropriate information concerning the effectuation attempt. The
attempt record distinguishes authority consumption from verified
external completion.
PHASE CW-1.6.18 — ACTUAL OUTCOME CLASSIFICATION Where required, a
qualified observation component evaluates the actual result. The
outcome may be confirmed successful, partially completed, mismatched,
confirmed absent, or unknown. A timeout is not automatically treated
as proof that the effect did not occur. PHASE CW-1.6.19 — OPTIONAL
CAUSAL CONTINUATION Where CW-2 receipt-gated continuation applies,
the accepted actual-effect receipt is authenticated by a required IEV
Das Expires 29 April 2027 [Page 33]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
identity and becomes a necessary enabling factor for the successor
phase. The successor Finality Sink independently verifies the
receipt-dependent condition before releasing the next consequential
act. Where CW-2 is not selected, the operation may terminate or
proceed according to another valid authorization protocol.
PHASE CW-1.6.20 — COMPLETION, RECOVERY, OR TERMINATION The system
records the appropriate completed, withheld, unresolved, or recovery-
required state. A subsequent compensating operation requires its own
applicable authorization where it constitutes a new consequential
act.
CW-1.7 — COMMON PROTECTED STATE MACHINE
7.3.17. Source global page 31
The system may employ states representing proposed, held, prepared,
validated, authorized, sink- verified, effectuation-attempted,
outcome-confirmed, outcome-unknown, recovery-pending, and terminated
conditions. The precise state names are non-limiting. The important
requirement is that authority-sensitive transitions occur through
protected procedures. A transition from prepared to effectuation-
ready requires satisfaction of the applicable current authority. A
transition from effectuation-attempted to confirmed-completion
requires suitable actual-outcome evidence where that evidence is
mandatory. A transition from an earlier phase to a receipt-gated
successor requires the appropriate validated receipt-dependent
condition. A system may combine several logical states within one
protected controller provided it preserves
the necessary protected transition semantics.
CW-1.7.1 — Anti-Rollback State Protected state may include monotonic
counters, authority epochs, secure storage, fencing references, or
other anti-rollback mechanisms.
CW-1.7.2 — Crash-Recoverable State Consequential attempts whose
outcomes may become uncertain may be associated with durable
protected attempt references.
CW-1.7.3 — Distributed State Where state is distributed, the
implementation identifies the authoritative owner or coordination
protocol. A stale replica cannot automatically authorize an
irreversible effect.
Das Expires 29 April 2027 [Page 34]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.7.4 — Termination After Partial Consequence A workflow may
terminate while a real external effect remains in existence. The
system does not relabel an already completed external consequence as
non-effective.
CW-1.8 — GENERALIZED REFERENCE ALGORITHM The following pseudocode is
a non-limiting architectural implementation. FUNCTION
PROTECTED_EXECUTION_FINALITY( request, requester_context,
protected_policy,
7.3.18. Source global page 32
designated_sink ): state = PED.LOAD_PROTECTED_STATE() REQUIRE
PED.VERIFY_STATE(state) cad = CONSTRUCT_CANDIDATE_ACT( request,
requester_context, designated_sink, state ) REQUIRE
VERIFY_CANDIDATE_ACT(cad) hold = ESTABLISH_NON_EFFECTIVE_HOLD(
request, cad ) REQUIRE VERIFY_HOLD(hold) evidence =
COLLECT_RELEVANT_EVIDENCE( cad, requester_context, state ) REQUIRE
VERIFY_REQUIRED_EVIDENCE_SOURCES( evidence ) required_modules =
PED.RESOLVE_REQUIRED_MODULES( cad, protected_policy, state ) REQUIRE
VERIFY_MANDATORY_MODULE_COMPLETENESS( required_modules ) baseline =
PED.VALIDATE_BASELINE( cad, evidence, protected_policy ) IF baseline
!= PASS: RETURN DENY_BEFORE_EFFECT
7.3.19. Source global page 33
FOR EACH module IN required_modules: result =
INVOKE_PROTECTED_MODULE( module, cad, evidence, state ) IF result !=
PASS: RETURN DENY_OR_DEFER REQUIRE VERIFY_COVERED_EFFECTUATION_PATH(
cad, designated_sink ) authority = PED.ATOMIC_PREPARE_AUTHORITY( cad,
evidence, state ) IF authority IS INVALID: RETURN DENY_BEFORE_EFFECT
actual_operation = designated_sink.RECONSTRUCT_PENDING_OPERATION(
hold ) REQUIRE designated_sink.VERIFY_ACTUAL_OPERATION(
actual_operation, cad ) REQUIRE
designated_sink.VERIFY_SCOPED_AUTHORITY( authority, actual_operation
) REQUIRE designated_sink.VERIFY_CURRENT_STATE() consumption =
designated_sink.ATOMIC_CONSUME( authority, actual_operation ) IF
consumption != SUCCESS: RETURN DENY_BEFORE_EFFECT
7.3.20. Source global page 34
attempt = designated_sink.EFFECTUATE( actual_operation, consumption )
outcome = CLASSIFY_SUPPORTED_OUTCOME( attempt )
PED.COMMIT_OUTCOME_STATE( cad, attempt, outcome ) IF
REQUIRES_CAUSAL_RECEIPT_CONTINUATION( cad ): receipt =
OBTAIN_QUALIFIED_EFFECT_RECEIPT( cad, attempt, outcome ) vaer =
AUTHORIZED_IEV_ACCEPT_RECEIPT( receipt, current_protected_state ) IF
vaer IS INVALID: RETURN WITHHOLD_SUCCESSOR_EFFECT RETURN
Das Expires 29 April 2027 [Page 35]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
PROVIDE_CAUSAL_RECEIPT_TO_NEXT_SINK( vaer, permitted_successor )
RETURN EFFECTUATION_RESULT( attempt, outcome ) The pseudocode does
not require synchronous execution of every non-dependent step.
Parallel validation may be permitted where protected state and
dependency conditions remain valid. However, independent authority
verification and protected state consumption must preserve the
technical invariants applicable to the operation.
CW-1.9 — COMMON EXTENDED VERIFICATION MODULES
7.3.21. Source global page 35
CW-1.9.1 — Module A: Context, Semantic, and Identity Verification
Module A may verify correspondence between user-observed objects and
actual effectuation targets. It may verify resource aliases,
selected document versions, physical targets, semantic referents,
trusted interface state, application-object identity, and source
provenance. A proposed candidate inventive combination may bind
independently observed semantic or object identity to an operation-
specific protected authorization and require the Finality Sink to
verify the actual target before effectuation. The module may be
particularly relevant to computer-use agents, multimodal assistants,
cross- application automation, and physical-scene interactions.
CW-1.9.2 — Module B: Protected Authority, Privacy, and Resource
Governance Module B may evaluate privacy-exposure limits, protected
resource-allocation constraints, multi- principal authority,
disclosure permissions, sensor restrictions, and cumulative
consequence budgets. A potentially distinguishing arrangement may
require the actual Finality Sink to verify current cumulative
protected state rather than rely solely upon independently permitted
individual operations.
CW-1.9.3 — Module C: Multi-Agent and Distributed Authority Module C
may evaluate cross-agent effect conflicts, protected resource
reservations, delegation scope, authority attenuation, device
ownership, and multi-domain operation dependencies. A protected
reservation may become a mandatory condition at the actual Finality
Sink. The module may incorporate the specialized mechanisms of
Embodiment 1.
CW-1.9.4 — Module D: Execution Integrity and Environmental
Verification Module D may verify action-contract integrity,
operation-semantics compatibility, execution-path coverage, runtime
conditions, software-update state, hardware constraints, and
protected scheduling requirements. It may require revalidation
following relevant environment changes.
Das Expires 29 April 2027 [Page 36]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.9.5 — Module E: Actual Effect, Causal Continuation, and Recovery
Module E may evaluate actual-effect evidence, authenticated receipts,
validator identity, successor phase requirements, and uncertainty-
preserving recovery. Where CW-2 receipt-gated continuation is
mandatory, the IEV's accepted real-effect receipt becomes an
indispensable factor in the authority required by the next Finality
Sink.
CW-1.9.6 — Module Independence A module is not required to perform
unrelated technical functions.
7.3.22. Source global page 36
A semantic verification result does not establish financial
settlement. A resource-reservation result does not establish actual
external effect completion. A valid actual-effect receipt does not
automatically grant unrestricted future authority.
CW-1.10 — COMPOSITION OF PROTECTED MODULE DECISIONS The protected
coordinator identifies mandatory modules according to the Candidate
Act and current protected policy. Each module provides a decision
bound to the corresponding operation and applicable state. The
coordinator verifies the module identity and result. Where a module
requires sink-time enforcement, its result includes or references the
mandatory condition. A module may restrict authority, withhold an
effect, or require renewed validation. It may not unilaterally
expand original task authority unless the appropriate protected
reauthorization procedure permits that expansion.
CW-1.10.1 — Mandatory-Module Completeness A requesting agent cannot
remove a mandatory verification requirement by omitting it from the
request.
CW-1.10.2 — Operation-Specific Binding A verification result for one
Candidate Act is not automatically valid for another.
CW-1.10.3 — Freshness An old validation result may become invalid
after a relevant policy, resource, authority, or runtime change.
CW-1.10.4 — Protected State Continuity Required module state is
updated using appropriate concurrency and rollback protection.
CW-1.10.5 — Denial Precedence A mandatory denial condition cannot be
ignored merely because another module returned permission.
CW-1.10.6 — Causal Continuation Priority Where receipt-gated causal
continuation is mandatory, a general authorization approval does not
substitute for the required validator-accepted predecessor receipt.
Das Expires 29 April 2027 [Page 37]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.10.7 — Distributed Module Verification
7.3.23. Source global page 37
Modules may reside in independent domains. The coordinator and
Finality Sink verify the authenticated results according to the
applicable trust configuration.
CW-1.11 — PROTECTED EXECUTION INVARIANTS Invariant I — Computation/
Authority Separation. Generating a command does not constitute
authority to effectuate it. Invariant II — Non-Effective Holding.
An operation requiring protected finality remains non- effective
until applicable release conditions are satisfied. Invariant III —
Actual-Operation Correspondence. Final authority is verified against
the operation actually pending at the effectuation boundary.
Invariant IV — Scoped Authority. Finality authorization cannot be
expanded by copying, forwarding, re-encoding, or transporting an
authority reference. Invariant V — Non-Bypassable Effectuation.
Every effectuation route covered by the claimed protection enforces
the applicable finality condition. Invariant VI — Protected
Consumption. Single-use authority cannot be exercised again through
unauthorized replay or stale-state restoration. Invariant VII —
Module Constraint Preservation. Mandatory technical predicates
remain enforced at the required boundary. Invariant VIII — Current-
State Validation. Applicable protected conditions are current when
they must remain valid until effectuation. Invariant IX — Trusted
Evidence Classification. Unsupported statements are not silently
treated as independently verified facts. Invariant X — Effect/
Receipt Distinction. A permission or dispatch record does not
automatically prove that the external consequence occurred.
Invariant XI — Receipt-Gated Continuation. Where CW-2 requires a
validated actual-effect receipt, the next effect cannot proceed
through the protected sink independently of that receipt- derived
condition. Invariant XII — Validator Identity. An IEV receipt is
accepted only when the relevant authorized
cryptographic validator identity can be verified. Invariant XIII —
No Authority Inflation. Delegated or derived authority does not
exceed its protected source scope. Invariant XIV — Cross-Agent
Compatibility. Where conflict governance applies, an effectuation
must satisfy current protected conflict constraints. Invariant XV —
Unknown-Outcome Honesty. A missing acknowledgement is not
automatically classified as confirmed absence of effect.
Das Expires 29 April 2027 [Page 38]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
7.3.24. Source global page 38
Invariant XVI — Recovery Separation. Corrective consequential acts
are separately governed. Invariant XVII — Protected Ownership.
Where execution authority is exclusive, superseded or stale owners
cannot validly reuse that authority. Invariant XVIII — Semantic
Binding. Where user-visible or model-referenced targets are
security-relevant, the actual effect target must satisfy the
protected correspondence predicate. Invariant XIX — Identity/Role
Distinction. A component may be authentic but unauthorized for the
requested function. Invariant XX — Enforcement Coverage
Qualification. Security claims are bounded by the actual protected
effectuation paths and threat model.
CW-1.12 — DETAILED THREAT MODELS
CW-1.12.1 — Prompt-Injection-Induced Unauthorized Operation An
autonomous agent processes untrusted instructions embedded within a
document, web page, message, or external tool response. The
malicious content attempts to redirect the agent toward an
unauthorized operation. The protected architecture prevents the
model-generated command from becoming effectually authoritative
solely because the agent produced it. The Candidate Act must satisfy
the applicable protected authorization and actual sink verification.
CW-1.12.2 — Model Hallucination An agent fabricates a resource
identity, recipient, transaction state, or operation result. The
protected system evaluates the applicable evidence independently. A
model-generated assertion does not satisfy a predicate requiring
authenticated external state.
CW-1.12.3 — Compromised Tool Interface An intermediary tool modifies
operation arguments after approval. The Finality Sink reconstructs
the actual command and rejects a material mismatch.
CW-1.12.4 — Stolen Reusable Credential An attacker obtains a reusable
API credential. Where the protected effectuation path requires a
separate operation-bound finality condition, possession of that
credential alone is insufficient for the protected operation. The
specific protection depends upon whether the destination or mediated
path actually requires the additional condition.
CW-1.12.5 — Alternative API Bypass
Das Expires 29 April 2027 [Page 39]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
7.3.25. Source global page 39
An agent invokes a different application interface to produce an
effect. The implementation must route the claimed governed effect
through an equivalent protected Finality Sink. If an uncovered
interface remains available, the claimed protection is incomplete for
that effect.
CW-1.12.6 — Direct Network Bypass A malicious process attempts direct
network transmission around an application-layer gateway. A
deployment claiming network-level non-bypassability may require
operating-system mediation, hardware egress control, network
isolation, or destination-side authorization.
CW-1.12.7 — Direct Hardware Bypass A process attempts to address an
actuator, storage device, radio interface, or peripheral through an
alternate hardware interface. The applicable hardware controller
must enforce the protected release condition where system-wide
physical effect control is asserted.
CW-1.12.8 — Time-of-Check/Time-of-Use Substitution An authorized
operation is changed after validation. The sink verifies the actual
pending operation and applicable current state.
CW-1.12.9 — Stale Approval An agent attempts to execute under a
previously valid authorization after a relevant revocation, policy
update, or resource change. The sink verifies current applicable
validity conditions.
CW-1.12.10 — Capability Replay An attacker copies a scoped authority
and attempts to repeat the effect. Protected nonce or consumption
state prevents unauthorized duplicate exercise.
CW-1.12.11 — Cross-Sink Capability Reuse An authority intended for
one sink is presented to another. The receiving sink rejects an
authority whose required audience or sink binding does not match.
CW-1.12.12 — Validator Impersonation An attacker copies a validator
identifier and fabricates an approval. Where an IEV is mandatory,
the sink verifies the authorized validator's cryptographic identity
and receipt.
7.3.26. Source global page 40
CW-1.12.13 — Validator Replacement An attacker substitutes a
permissive IEV. The sink rejects receipts lacking current authorized
validator enrollment.
Das Expires 29 April 2027 [Page 40]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.12.14 — Forged Actual Outcome An agent claims that an earlier
remote or physical effect succeeded. The protected outcome observer
requires evidence capable of supporting the required actual-effect
predicate.
CW-1.12.15 — Missing Remote Acknowledgement A remote operation may
have succeeded even though the originating system received no
response. The system preserves an unknown-outcome condition and
avoids automatic unsafe repetition.
CW-1.12.16 — State Rollback An attacker restores a software snapshot
containing old authority. Protected counters, epochs, or
authoritative external state prevent unauthorized reuse where
implemented.
CW-1.12.17 — Cross-Agent Conflict Two agents independently receive
valid authorization but attempt mutually incompatible effects. A
protected conflict module may establish reservations that are
independently enforced at the respective sinks.
CW-1.12.18 — Delegation Expansion An agent delegates a narrow task
while a downstream service attempts a broader operation. The
protected system verifies the delegation lineage and prevents
unauthorized scope expansion.
CW-1.12.19 — Semantic Target Substitution An application changes the
resource corresponding to a visible selection. The relevant semantic
module verifies the relationship between the authorized referent and
actual selected target.
CW-1.12.20 — Runtime Update Drift A software update changes the
actual semantics of an operation. Where action-contract integrity is
required, the protected system verifies the current operation
semantics and may require reauthorization.
7.3.27. Source global page 41
CW-1.12.21 — Tool Schema Manipulation An untrusted tool provider
changes the interpretation of an API parameter. The protected system
may bind authority to a specific verified action contract or semantic
schema version.
CW-1.12.22 — Credential-Broker Confusion A protected credential
broker may be asked to release credentials for a different resource
or destination from the originally authorized operation. The broker
verifies operation binding and scope before release.
Das Expires 29 April 2027 [Page 41]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.12.23 — Privacy Leakage Across Multiple Operations An agent may
perform several individually permitted disclosures that collectively
violate a protected privacy constraint. A cumulative privacy module
may track relevant protected exposure state.
CW-1.12.24 — Device Authority Split-Brain Two devices attempt to
exercise the same exclusive unfinished authority. Protected
ownership epochs or fencing prevent stale ownership from authorizing
duplicate effects.
CW-1.12.25 — Physical Target Drift A physical object moves or is
replaced between authorization and actuation. The protected system
may require current target-identity evidence before movement.
CW-1.12.26 — Denial-of-Service Against Validators An attacker floods
a required validation component with requests. The protected
architecture may employ bounded work, rate limits, priority rules,
reservation expiry, and fail-closed behavior for mandatory
predicates. A validation timeout is not treated as successful
authorization.
CW-1.12.27 — Cryptographic Verification Exhaustion An attacker
submits malformed or computationally expensive evidence intended to
exhaust the verifier. The system may enforce input-size limits,
bounded parsing, supported algorithm restrictions, and resource-aware
verification scheduling.
CW-1.12.28 — Malicious Evidence Source A source authenticates false
or manipulated data.
7.3.28. Source global page 42
The system's guarantees depend upon source qualification, independent
observation, and the actual trust model. Cryptographic
authentication alone does not ensure factual correctness.
CW-1.12.29 — Compromised Privileged Operating System An attacker
controls privileged software. A software-only gate under the
attacker's full control may be bypassed. Claims requiring resistance
to such compromise must rely upon appropriately independent protected
components, hardware, or destination-side enforcement.
CW-1.12.30 — Compromised Firmware or Hardware Controller A malicious
effectuation controller ignores required authorization. The
architecture may require independently protected hardware, measured
firmware, external control, redundancy, or equivalent mechanisms
under the intended threat model. No single protection is assumed to
resist compromise of its complete trusted computing base.
Das Expires 29 April 2027 [Page 42]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.12.31 — Distributed Network Partition Protected domains become
disconnected. The system may continue unrelated operations whose
authority remains locally sufficient. Operations requiring
unavailable distributed agreement or current remote state are
withheld.
CW-1.12.32 — Long-Lived Offline Authority A disconnected device
attempts to use previously provisioned authority. A protected
implementation may enforce a bounded offline scope, monotonic
counters, expiry, or preallocated limited execution budget. It
cannot simultaneously claim unrestricted offline availability and
immediate global revocation without an appropriate supporting
mechanism.
CW-1.12.33 — Unknown Future Effectuation Interface A software or
hardware update introduces a new way to produce the governed effect.
An optional coverage-attestation mechanism may detect the relevant
interface change and require new enforcement configuration before
protected authorization resumes.
CW-1.13 — FAILURE HANDLING AND RECOVERY
CW-1.13.1 — Failure Before Authorization
7.3.29. Source global page 43
The Candidate Act remains non-effective.
CW-1.13.2 — Failure During Validation A mandatory failed or
unavailable verifier prevents corresponding authorization.
CW-1.13.3 — Failure After Authority Preparation Protected authority
state is recovered or invalidated according to the applicable
consumption and freshness rules.
CW-1.13.4 — Failure After Sink Consumption A consumed authority is
not automatically restored merely because effectuation
acknowledgement is absent.
CW-1.13.5 — Partial External Effect The system records the supported
partial result and governs remaining operations separately.
CW-1.13.6 — Unknown External Effect The system preserves an
unresolved attempt and prevents unsafe dependent continuation or
retry.
Das Expires 29 April 2027 [Page 43]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.13.7 — Revocation During Execution Revocation may prevent future
effects that have not crossed the governed boundary. A completed
effect is not retroactively erased.
CW-1.13.8 — Recovery Authorization A corrective effect may be
represented as a new Candidate Act with its own finality authority.
CW-1.13.9 — Validator Failure Where CW-2 or another mandatory
validator is required, failure does not automatically authorize
bypass.
CW-1.13.10 — Protected State Corruption An operation is withheld
where the mandatory protected state cannot be validated or safely
reconstructed.
CW-1.14 — CROSS-DOMAIN AND HETEROGENEOUS IMPLEMENTATIONS
CW-1 may operate across mobile devices, desktop systems, enterprise
endpoints, cloud services, edge computers, embedded controllers,
vehicles, robots, secure communication infrastructure, and
distributed application systems. An agent may request an operation
in one domain while protected authorization occurs in another.
7.3.30. Source global page 44
The actual Finality Sink may reside in a third domain. The receiving
sink authenticates the applicable evidence and verifies the actual
operation independently.
CW-1.14.1 — Local Device Enforcement A local protected controller may
govern storage, network, application, or hardware effects.
CW-1.14.2 — Cloud Enforcement A protected cloud gateway may govern
service API calls, database commits, resource provisioning, and
credential activation.
CW-1.14.3 — Cross-Provider Agents Agents operating under different
administrative providers may exchange task requests without
transferring unrestricted execution authority. Each consequential
operation remains subject to applicable local protected
authorization.
CW-1.14.4 — Edge and Embedded Devices Low-power devices may use
compact protected state and hardware-controlled release conditions.
Das Expires 29 April 2027 [Page 44]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.14.5 — Hardware Accelerators A protected system may mediate
effect-capable accelerator interfaces where they can modify
persistent resources, initiate direct memory access, release network
data, or produce another governed consequence.
CW-1.14.6 — Physical Actuation An actuator controller may enforce
scoped command authority and relevant current physical-state
predicates.
CW-1.14.7 — Delayed Connectivity A system with intermittent
connectivity may employ preauthorized bounded operations, local
protected state, and conservative reconciliation after reconnection.
CW-1.15 — NON-LIMITING PRESENT-DAY INDUSTRIAL IMPLEMENTATION
CW-1.15.1 — Enterprise AI-Agent Gateway A presently implementable
reference system may comprise an AI agent, a request interceptor, a
protected authorization service, and a controlled API gateway. The
agent proposes an operation. The interceptor constructs the
Candidate Act.
7.3.31. Source global page 45
The protected authorization service evaluates the permitted operation
and current state. The gateway independently verifies the actual
outgoing request. The gateway rejects a materially substituted
destination, resource, or operation. This implementation may use
existing cryptographic authentication, protected service isolation,
structured authorization, and transaction-state techniques. Its
distinctive proposed feature must be identified in the actual
operation-bound protected enforcement relationship, not merely in use
of an ordinary API gateway.
CW-1.15.2 — Mobile or Desktop Assistant A device assistant may
request file access, message transmission, application invocation,
network communication, or device configuration changes. The device's
protected execution system may require an operation-specific finality
authorization before the actual effect. A protected dispatcher or
controller may verify the actual pending operation. Where required,
device security components may provide protected state and
cryptographic identity.
CW-1.15.3 — Multi-Agent Cloud Workflow Several agents may generate
resource-modification requests. A conflict module may identify
incompatible operations. A protected state store may establish
effect reservations. Each actual cloud-operation sink verifies
current authority and applicable reservation state.
Das Expires 29 April 2027 [Page 45]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.15.4 — Autonomous Financial Workflow An agent may propose a
financial instruction. The protected system binds the intended
amount, recipient, account scope, and designated dispatch controller
to the Candidate Act. The dispatch sink verifies the actual pending
instruction. Actual settlement remains distinct from local dispatch
and may require qualified outcome evidence.
CW-1.15.5 — Industrial Device Controller An autonomous controller may
generate a physical command. A protected controller verifies the
actual target and operating envelope. The actuator remains disabled
until valid finality conditions pass.
7.3.32. Source global page 46
CW-1.16 — PHOSITA FEASIBILITY AND REFERENCE PROTOTYPES
CW-1.16.1 — Minimum Software Reference Prototype A practical minimum
prototype may use two separately executing processes. The first
process simulates an autonomous agent that generates operation
requests. The second process implements a protected authorization
and finality gateway under a defined software trust model. The agent
does not possess direct access to the simulated consequential
resource. The gateway constructs or validates Candidate Act
descriptors, verifies permitted operation scope, maintains protected
consumption state, and performs the final effect. This prototype can
demonstrate operation binding, single-use authority, replay
rejection, and fail- closed handling. It cannot by itself establish
resistance to compromise of the operating-system kernel hosting both
processes.
CW-1.16.2 — Protected Credential-Broker Prototype A credential broker
may retain a reusable service credential outside the agent's access.
The agent submits a Candidate Act. A protected authority validates
the operation. The controlled gateway performs the permitted request
using the credential. The agent does not receive unrestricted
credential material. The prototype can test whether a substituted
request changes the actual effectuation parameters and whether the
gateway rejects the mismatch.
CW-1.16.3 — Protected Sink Prototype A storage controller may
maintain an initially uncommitted operation. The PED generates an
operation-bound authority. The storage sink checks the actual
record, version, and mutation parameters before commit. The test may
substitute the pending object after authorization. Correct operation
requires rejection of a materially different object.
CW-1.16.4 — Cross-Agent Conflict Prototype Two agents may propose
independently valid but incompatible mutations.
Das Expires 29 April 2027 [Page 46]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
7.3.33. Source global page 47
A protected reservation service may determine the applicable
ordering. Each sink verifies current reservation state. The
prototype may test stale reservations, concurrent attempts, and
recovery after a crash.
CW-1.16.5 — CW-2 Causal Receipt Prototype A first protected sink
performs a bounded real storage operation. A qualified observer
supplies actual commit evidence. A cryptographically identified IEV
accepts the evidence. The accepted receipt becomes the necessary
condition for a second sink to perform a protected export. The
second sink rejects an attempted export without the correct
validator-authenticated receipt.
CW-1.16.6 — Hardware-Backed Prototype A protected controller or
security module may store finality authority and consumption state.
The effectuation interface may be configured so that ordinary
application processes cannot bypass the required controller. The
implementation can test hardware-enforced withholding and protected
key or state access.
CW-1.16.7 — Feasibility Metrics Testing may measure unauthorized
effect acceptance, substitution detection, replay rejection,
validation latency, throughput, protected-state overhead, crash
recovery, concurrent state correctness, and actual enforcement
coverage. Results should distinguish theoretical properties,
software simulations, implementation measurements, and independently
validated hardware behavior.
CW-1.17 — OPTIONAL PRESENT-DAY INVENTIVE TECHNICAL EXTENSIONS The
following optional concepts may be implemented using existing classes
of computing technology. Each is a proposed area of technical
differentiation, not a declaration that the underlying constituent
techniques are individually new.
CW-1.17.1 — Protected Effectuation-Path Coverage Commitment A
protected controller may maintain an authenticated description of all
known effect-capable routes relevant to a designated consequential
resource. The system may detect when an application, driver, network
interface, or hardware configuration change creates an unmediated
path.
Das Expires 29 April 2027 [Page 47]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
7.3.34. Source global page 48
Where the claimed protection depends upon complete mediation,
authority release may be withheld until the relevant path coverage is
revalidated. A reference implementation may enumerate and test
controlled software and device interfaces under an explicitly defined
coverage model. The candidate inventive contribution would concern
making coverage state a mandatory predicate for operation-specific
finality authority.
CW-1.17.2 — Sink-Local Actual-Operation Equality A Finality Sink may
compare a protected authorized descriptor with the operation actually
presented to the controlled boundary. The sink may verify all
material effect parameters rather than merely an upstream request
digest. A reference implementation may use controller-owned command
buffers or trusted dispatcher interfaces. The candidate distinction
concerns independent reconstruction and mandatory release-time
correspondence.
CW-1.17.3 — Protected Operation-Semantics Version Binding An
authorization may bind not only a function name but also the
semantics of the function's permitted effect. A tool update or
schema change may invalidate the earlier correspondence. The sink
may require current verified operation-semantics compatibility. A
prototype may vary parameter meaning or schema version and test
whether stale authority is rejected.
CW-1.17.4 — Protected Multi-Interface Resource Identity Different
applications may expose the same underlying resource through
different identifiers. A protected resolver may establish
authenticated equivalence among resource identities. The final
authorization may bind the resolved target rather than only a string
supplied by the agent. A feasibility prototype may map a document
across storage, sharing, and transmission interfaces.
CW-1.17.5 — Protected Delegation Attenuation An original principal
may authorize an agent to perform a narrow task. The agent may
delegate part of the task to another service. Each delegation may be
constrained by the original permitted effect, resource, destination,
and authority state. The final sink verifies the applicable
delegation lineage.
Das Expires 29 April 2027 [Page 48]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
7.3.35. Source global page 49
CW-1.17.6 — Protected Credential-Release Finality A credential broker
may retain reusable credentials while the agent receives only
constrained operation references. The broker may release or exercise
privileged credentials only for a verified actual operation. This
may support cloud API gateways, enterprise connectors, and device-
management infrastructure.
CW-1.17.7 — Cross-Agent Effect Reservation Independently authorized
agents may be required to satisfy protected effect-conflict
reservations before performing potentially interfering operations.
This extension may employ the specialized techniques disclosed in
Embodiment 1.
CW-1.17.8 — Protected Semantic Target Continuity A user may approve
an operation involving an object visible on a screen or in another
interface. The system may preserve the relationship between the
approved referent and actual target. The sink refuses a substituted
object unless the change is separately authorized.
CW-1.17.9 — Protected Privacy Exposure Accumulation A protected
privacy module may maintain an authenticated cumulative exposure
state across multiple otherwise permitted operations. The final sink
may require that the new disclosure remain within applicable limits.
CW-1.17.10 — Protected Causal Receipt Continuation An operation may
be divided into bounded real-effect phases. A cryptographically
identified IEV may accept a qualified predecessor receipt. The
resulting accepted receipt becomes a necessary factor in the next
sink's effectuation authority. This optional extension is detailed
in CW-2.
CW-1.17.11 — Protected Unknown-Outcome Fence A protected controller
may maintain an unresolved attempt state when an external effect may
have occurred. The state may prevent unsafe retry, conflicting
effectuation, or premature continuation.
CW-1.17.12 — Protected Authority Ownership Across Devices A protected
ownership epoch may ensure that only one designated device can
exercise an exclusive unfinished authorization.
7.3.36. Source global page 50
A superseded device's authority may be fenced at the actual sink.
Das Expires 29 April 2027 [Page 49]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.17.13 — Protected Validation Work Budget The PED may allocate
bounded computation and memory resources for validating a Candidate
Act. Malformed or adversarially expensive proof requests may be
rejected without exhausting resources needed for protected
operations. This extension may be relevant to high-throughput
security gateways and embedded devices.
CW-1.17.14 — Protected Deadline-Aware Finality Scheduling A protected
scheduler may consider command deadlines, safety constraints, and
verification costs. It may choose a permitted verification strategy
while preserving mandatory security predicates. A deadline does not
convert an inconclusive mandatory check into permission.
CW-1.17.15 — Protected Sink Coverage After Software Updates Following
relevant application, operating-system, or firmware updates, the
system may verify that the same consequential interfaces remain
controlled. Authority may be restricted until new effectuation-path
coverage is established.
CW-1.17.16 — Protected Multi-Principal Authority Some effects may
require authority from more than one principal. The protected system
may combine distinct authenticated approvals while preserving the
specified operation scope and Finality Sink verification.
CW-1.17.17 — Protected Receipt-Dependent Recovery An adverse but
verified outcome may support a narrowly scoped recovery operation.
The protected receipt may serve as a causal prerequisite for
recovery, without granting unlimited corrective authority.
CW-1.17.18 — Protected Runtime Influence Attribution A specialized
module may examine the provenance or influence of untrusted
instructions, tool outputs, persistent memory, or external content on
a proposed operation. Such evidence may become an additional sink-
enforced restriction where the implementation can support the
required attribution. The system does not assume that all neural
inference can be perfectly explained or traced.
CW-1.18 — ADVANCED FUTURE-ORIENTED OPTIONAL TECHNICAL CONCEPTS
7.3.37. Source global page 51
The following concepts address plausible extensions of autonomous
computing and effectuation infrastructure. They are proposed
technical variations, not statements of present commercial adoption,
experimental success, or patentability.
Das Expires 29 April 2027 [Page 50]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.18.1 — Cross-Provider Autonomous-Agent Effectuation Future agent
ecosystems may involve multiple independently administered agents
cooperating on one task. A protected authority may bind permitted
effects across delegation boundaries without giving every participant
unrestricted access to the original principal's credentials. A final
destination-side sink may verify the operation under a locally
enforceable scoped authorization. A reference implementation can
presently approximate this arrangement using authenticated service-
to-service messages and controlled tool gateways.
CW-1.18.2 — Protocol-Neutral Tool Effectuation An agent may invoke
operations through different communication protocols, RPC interfaces,
local application functions, database APIs, or direct hardware
commands. The protected system may transform different protocol-
level requests into a common effect-specific descriptor. The final
sink may verify the actual consequential parameters independently of
the original protocol syntax. The technical difficulty lies in
establishing correct, non-ambiguous operation semantics across
heterogeneous interfaces.
CW-1.18.3 — Dynamic Tool Discovery with Protected Contract Binding An
autonomous agent may discover new tools at runtime. A protected
registry may identify which tools produce governed effects and which
sink requirements apply. Newly discovered tools may remain
restricted until their effectuation contracts and necessary
enforcement interfaces are verified. The agent cannot eliminate
mandatory authorization by selecting a previously unknown tool name.
CW-1.18.4 — Secure Compute-Accelerator Effectuation Future
accelerators may execute increasingly autonomous computation and may
initiate memory, storage, network, or device effects. An optional
protected controller may mediate effect-capable accelerator outputs
or command queues.
7.3.38. Source global page 52
The technical focus is the consequential release boundary, not the
accelerator's internal mathematical computation.
CW-1.18.5 — Confidential Agent Execution A confidential computing
environment may protect selected agent state or secrets.
CW-1 may additionally require that protected or attested computation
obtain finality authority before causing consequential effects
outside the protected environment. Confidentiality of computation
does not automatically establish authorization of its external
outputs.
Das Expires 29 April 2027 [Page 51]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.18.6 — Autonomous Edge-to-Cloud Migration A task may move
between local and cloud execution. Protected authority may remain
bound to the permitted operation even if the computational location
changes. A protected migration state may fence the previous
execution owner where exclusivity is required.
CW-1.18.7 — Future Communication Networks Autonomous network
management may involve dynamic resource allocation, radio
configuration, network slicing, edge processing, and distributed
control. A protected effectuation mechanism may govern the actual
configuration changes at relevant controllers. The disclosure does
not depend upon a particular future cellular generation or
communication standard.
CW-1.18.8 — Multi-Sensor Physical Autonomy A future autonomous device
may combine camera, depth, position, audio, radio, and other sensor
inputs. A protected physical-scene module may verify the intended
target immediately before actuation. The final controller may
require current target correspondence and authorized operating
constraints.
CW-1.18.9 — Autonomous Vehicle and Fleet Coordination Vehicles or
machines may propose independently authorized movements or shared
resource operations. A protected effect-conflict system may govern
incompatible commitments, while device-local sinks enforce actual
commands. Real-world safety requires appropriate physical control
and sensing systems beyond generic cryptographic authorization.
CW-1.18.10 — Extended-Reality and Spatial Computing
7.3.39. Source global page 53
An assistant may act upon objects selected through spatial
interfaces. A protected semantic correspondence system may bind the
selected virtual or physical referent to the actual effectuation
target. The system may prevent substitution caused by changes in
spatial registration, application state, or target identity.
CW-1.18.11 — Future Chiplet and Heterogeneous Hardware Controllers A
processor may include multiple isolated computing and control units.
The PED, validators, and Finality Sinks may be distributed among the
units. Authenticated internal interfaces may establish authority and
state continuity. The same protected causal and effectuation
relationships may be implemented without a separate external security
appliance.
Das Expires 29 April 2027 [Page 52]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.18.12 — Post-Quantum Cryptographic Migration A protected system
may permit migration to different cryptographic authentication
mechanisms when required by evolving threat models or standards. The
protected authority and receipt formats may carry algorithm
identifiers and credential generations. The correctness of the
finality architecture is not tied to one particular present-day
signature algorithm. Post-quantum cryptography itself is not claimed
as a new invention merely by being used for validator or sink
authentication.
CW-1.18.13 — Privacy-Preserving Distributed Verification A remote
verifier may establish selected authorization predicates without
receiving all underlying private data. Suitable commitments,
authenticated attestations, selective disclosure, or privacy-
preserving proofs may be used where technically appropriate. The
final sink must still obtain sufficient evidence to verify the
required actual-operation conditions.
CW-1.18.14 — Autonomous Cross-Organization Transactions Several
organizations may operate independent protected controllers. A
single workflow may require effects in different administrative
domains. Each domain may independently enforce its own finality
requirements while accepting narrowly scoped authenticated evidence
from cooperating domains. The architecture must define trust,
authority ownership, and failure behavior across network partitions.
7.3.40. Source global page 54
CW-1.18.15 — Self-Adjusting Verification Under Protected Constraints
A system may select among approved verification procedures based upon
operation risk, current technical state, computational resources, or
observation availability. Mandatory safety or authorization
predicates remain preserved. A learned risk score does not itself
override a failed protected constraint.
CW-1.18.16 — Future Autonomous Hardware Peripherals An effect-capable
peripheral may perform operations with limited involvement from the
host processor. The peripheral may incorporate a protected Finality
Sink or accept constrained authority from another protected
controller. The relevant consequential primitive remains subject to
the applicable operation-bound conditions.
Das Expires 29 April 2027 [Page 53]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.18.17 — Protected Real-Effect Evidence Across Long Delays Some
distributed systems may experience significant communication delay or
intermittent connectivity. The architecture may use bounded local
authority, authenticated causal evidence, and protected replay-
resistant state to govern delayed continuation. Where current global
state is unavailable, the permitted autonomous scope must be
constrained by the defined safety and consistency assumptions.
CW-1.18.18 — Future Machine-to-Machine Economic Operations Autonomous
devices may initiate resource purchases, usage commitments,
settlements, or access grants. A protected sink may verify actual
transaction parameters and applicable authority. Receipt-gated
continuation may be applied where a later economic effect requires
confirmation of an earlier actual transaction state.
CW-1.18.19 — Future Distributed Actuation with Independent Witnessing
A physical operation may occur in one domain while another protected
system observes its result. A cryptographically identified IEV may
validate the observed effect and establish the next operation's
causal authority. The receiving Finality Sink verifies the accepted
receipt.
CW-1.18.20 — Future Operation-Level Enforcement as a Shared
Infrastructure Service A computing platform may expose protected
execution-finality controls as a service usable by several
applications or agent frameworks.
7.3.41. Source global page 55
The service may manage Candidate Act descriptors, validator
identities, protected evidence, scoped capabilities, and sink
enforcement interfaces. Applications may innovate independently in
planning and computation while the protected service continues to
govern consequential effects.
CW-1.19 — ADVANCED OPTIONAL INVENTIVE COMBINATIONS
CW-1.19.1 — Cross-Interface Actual-Effect Identity and Sink Coverage
One optional combination binds an effect-specific resource identity
to a protected inventory of relevant effectuation paths. A new
application interface or driver update may trigger revalidation of
whether the actual resource remains covered. The Finality Sink may
require a current coverage commitment before releasing the operation.
The potentially distinctive interaction is between resource
equivalence, mandatory enforcement coverage, and operation-specific
authorization.
Das Expires 29 April 2027 [Page 54]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.19.2 — Causal Receipt and Cross-Agent Conflict-State Advancement
Another optional combination integrates Embodiment 1 and CW-2. An
earlier real effect produces a validator-accepted receipt. The
accepted receipt establishes the necessary continuation authority for
a successor phase while also controlling advancement or release of
protected reservations affecting other agents. A successor sink
verifies both the receipt-derived causal condition and current
conflict-state validity.
CW-1.19.3 — Semantic Referent and Credential-Release Binding A user
selects a document or resource through an application interface. A
protected semantic module verifies the selected actual object. A
credential broker permits a specifically bound external operation
only for that object and destination. The final sink independently
checks the actual command. The candidate contribution concerns the
enforced relationship between user-observed referent, operation-
specific credential exercise, and actual effectuation.
CW-1.19.4 — Dynamic Tool Contract and Protected Authority Revocation
A previously authorized tool undergoes a material schema or semantic
change. A protected action-contract registry detects the change.
Existing authority bound to the earlier semantics is invalidated or
requires revalidation.
7.3.42. Source global page 56
The sink prevents the changed operation from proceeding under stale
authorization.
CW-1.19.5 — Privacy Composition and Destination-Side Finality Several
agents attempt data disclosures through different applications. A
protected privacy state tracks applicable cumulative effect
constraints. Each destination-side transmission sink verifies the
current relevant privacy state and actual outgoing operation.
CW-1.19.6 — Device Migration and Causal Continuation A workflow
migrates from one device to another. The prior device's authority is
fenced. The new device may require a qualified prior-effect receipt
for a pending causal continuation. The successor sink verifies both
exclusive ownership and receipt-derived authority.
CW-1.19.7 — Resource-Constrained Security Validation with Fail-Closed
Deadlines A protected scheduler may reserve verification resources
for high-priority consequential operations. It may reject or defer
requests exceeding a protected verification budget. Where operation
deadlines are relevant, the scheduler may use prevalidated protected
evidence or appropriate bounded checks. It must not bypass mandatory
authorization merely because the remaining time is short.
Das Expires 29 April 2027 [Page 55]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.19.8 — Independent Physical Target and Actual Command
Reconstruction A protected sensor module may identify a physical
target. The actuator sink independently obtains the actual command
and currently resolved target. It verifies correspondence with the
authorized target and current protected operating envelope.
CW-1.19.9 — Protected Evidence Without Persistent Raw Data A system
may validate a consequential operation using protected commitments to
sensitive context. It may retain the minimum evidence needed to
demonstrate valid authority and prevent replay. The raw private
source data need not be permanently stored when an appropriate
authenticated reference suffices.
CW-1.19.10 — Consequence-Aware Revocation Propagation Revocation may
affect several dependent pending operations.
7.3.43. Source global page 57
A protected dependency structure may identify which unexecuted
Candidate Acts rely upon invalidated authority. The relevant sinks
prevent further effects without claiming retroactive reversal of
already completed external consequences.
CW-1.20 — PRESENT AND FUTURE FEASIBILITY OF ADVANCED VARIANTS
CW-1.20.1 — Present Feasibility Many underlying engineering
mechanisms are presently available as established technology classes.
Examples include protected process isolation, cryptographic
authentication, transaction-state management, secure hardware
registers, monotonic counters, authenticated communication,
controlled API gateways, and device security modules. Such building
blocks can be combined to implement representative CW-1 embodiments.
Their availability does not establish that the specific proposed
combinations are already known or that they are automatically
inventive.
CW-1.20.2 — Advanced Feasibility Future-oriented variants may require
stronger integration with device firmware, hardware command paths,
distributed identity, trusted effect observation, or new interface
standards. A PHOSITA may adapt the disclosed protected records,
state transitions, and sink verification rules to suitable hardware
and software interfaces. The implementation must be evaluated
against the actual trust model and supported effectuation primitives.
Das Expires 29 April 2027 [Page 56]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.20.3 — Modular Development A reference system may begin with one
controlled storage or network Finality Sink. Additional sinks may be
introduced as independently verified protected interfaces. A causal
IEV may be added where multi-phase actual-effect evidence is
necessary. Conflict, semantic, privacy, and physical-scene modules
may be integrated according to the target application.
CW-1.20.4 — Feasibility Boundaries A design does not become non-
bypassable merely because it uses a secure processor. An external
effect is not proven merely because a receipt is signed. A remote
transaction is not made atomic merely because it is represented in a
protected local state machine.
7.3.44. Source global page 58
A future-oriented embodiment should identify these limitations.
CW-1.20.5 — Performance Considerations A system may use compact
descriptors, cached verification material, local protected state,
batching, precomputation, or hardware acceleration. Such
optimization must preserve mandatory act binding, current-state
checks, and consumption semantics.
CW-1.21 — INVENTIVE-STEP ANALYSIS
CW-1.21.1 — Established Building Blocks Authentication,
authorization, access-control systems, sandboxes, transaction
isolation, digital signatures, protected hardware, fencing tokens,
and audit records are established mechanisms.
CW-1 does not assert novelty merely from their individual use.
CW-1.21.2 — Candidate Distinguishing Combination A potentially
meaningful technical combination comprises: A Candidate Act generated
without inherent execution authority; An enforceable Non-Effective
State; Protected verification of operation-specific predicates;
Formation of scoped non-bearer finality enablement; Independent
reconstruction of the actual pending operation at the Finality Sink;
Verification of the authority against the actual operation and
current protected state; And protected single-use or bounded
consumption before effectuation. Optional modules may add specific
technical restrictions.
CW-1.21.3 — Objective Technical Problem The objective technical
problem concerns ensuring that independently generated computational
operations cannot cause unauthorized consequences through controlled
effectuation paths, despite changes to runtime context, intermediate
software, credentials, resource state, or operation parameters.
Das Expires 29 April 2027 [Page 57]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-1.21.4 — Technical Interaction The Candidate Act identifies the
proposed effect. The Non-Effective State prevents premature release.
The PED establishes protected authority.
7.3.45. Source global page 59
The finality capability binds the permitted effect. The Finality
Sink reconstructs the actual operation. Sink-time verification
enforces the protected binding. Consumption prevents unauthorized
repeated exercise. These components perform distinct but coordinated
functions.
CW-1.21.5 — Why a Mere Aggregation Is Insufficient A system
containing a sandbox, signature, gateway, and policy engine is not
necessarily inventive. The potentially relevant contribution is the
specific technical dependence of actual effectuation upon
appropriately protected, operation-specific authority and actual
boundary verification.
CW-1.21.6 — Optional Inventive-Step Contributions An optional
extension may contribute an additional technical mechanism. For
example, effectuation-path coverage attestation may make interface
coverage a mandatory authorization predicate. A causal IEV may make
the accepted earlier real-effect receipt an indispensable next-phase
execution factor. A conflict module may make protected reservations
mandatory at multiple actual sinks. A semantic module may bind a
user-observed referent to the actual operation target. Each
candidate contribution should be assessed separately against the
relevant prior art.
CW-1.21.7 — Hindsight Considerations Where prior-art references are
combined, the analysis should identify why a PHOSITA would have
implemented the specific protected architecture. It is insufficient
merely to locate each broad component in a different reference and
restate the claimed combination. Nevertheless, established
motivations to combine zero-trust authorization, capability security,
distributed coordination, and effectuation gates must also be
considered. Inventive step depends upon the actual claim limitations
and relevant technical teachings.
CW-1.21.8 — Non-Guarantee of Patentability A detailed specification
does not automatically establish novelty, inventive step, or claim
validity. The claimed combination must be supported by the original
application as filed and examined against relevant prior disclosures.
Broad functional language alone does not eliminate every possible
design-around.
Das Expires 29 April 2027 [Page 58]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
7.3.46. Source global page 60
CW-1.22 — INDUSTRIAL APPLICABILITY
CW-1 may be implemented in autonomous AI systems interacting with
enterprise resources, cloud infrastructure, device operating systems,
networks, financial services, protected data, industrial equipment,
robotic actuators, and distributed computing environments. In
enterprise systems, it may govern application-function dispatch,
document modification, and external communications. In cloud
systems, it may govern protected resource creation, deletion,
modification, credential release, and network changes. In mobile and
desktop systems, it may govern assistant-mediated file operations,
message transmission, application controls, and sensitive device
resources. In financial infrastructure, it may bind protected
authority to actual transaction parameters. In telecommunications,
it may govern network configuration, service activation, and relevant
control-plane effects. In industrial automation, it may govern
actuator commands and protected device-state changes. In distributed
multi-agent systems, it may preserve scoped authority and applicable
operation constraints across service or provider boundaries. In
future heterogeneous systems, it may provide a common effectuation-
control layer independent of the computational architecture
generating the request. The industrial utility lies in controlling
real technical consequences through protected enforcement, not merely
generating recommendations concerning whether an operation appears
desirable.
CW-1.23 — PROPOSED TECHNICAL VALIDATION PROGRAM A comprehensive
reference implementation may test the following properties. Test 1 —
Operation Substitution. Authorize one resource and attempt to
effectuate another. Test 2 — Destination Substitution. Change the
destination after protected authorization. Test 3 — Capability
Replay. Attempt repeated use of single-use authority. Test 4 —
Agent-Level Bypass. Remove ordinary agent approval checks while
leaving protected sink enforcement active. Test 5 — Alternate API.
Attempt the same effect through a different covered application
interface. Test 6 — Protected State Rollback. Restore previously
consumed authority through a stale snapshot. Test 7 — Privileged
Credential Theft. Determine whether the actual sink still requires
operation- specific finality authority.
Das Expires 29 April 2027 [Page 59]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
7.3.47. Source global page 61
Test 8 — Module Failure. Disable a mandatory specialized validator
and verify refusal. Test 9 — Multi-Agent Conflict. Submit two
independently authorized incompatible effects. Test 10 — Semantic
Target Drift. Change the selected application object between
approval and effectuation. Test 11 — Action Contract Change. Modify
tool semantics after authorization. Test 12 — Unknown Outcome.
Suppress acknowledgement after a possible real external effect. Test
13 — Causal IEV Receipt. Attempt a successor phase without the
required accepted real- effect receipt. Test 14 — Validator Identity
Forgery. Use the correct displayed validator identifier with
incorrect cryptographic credentials. Test 15 — Cross-Domain
Authorization. Present protected authority from one domain to a
different authorized sink.
Test 16 — Device Migration. Attempt stale execution after exclusive
authority moves to another device. Test 17 — Privacy Accumulation.
Perform several disclosures whose combined effect violates a
protected constraint. Test 18 — Enforcement-Coverage Drift.
Introduce a new effect-capable interface and determine whether
protected coverage is reevaluated. Test 19 — Verification
Exhaustion. Submit expensive malformed proof inputs under
constrained resources. Test 20 — Hardware Release. Verify that an
effect-capable hardware controller refuses commands lacking the
required authority. The results may be used to establish actual
functionality and identify limitations. The tests are proposed and
are not represented as having already been performed.
CW-1.24 — NON-LIMITING VARIATION AND SCOPE STATEMENT
CW-1 may be implemented using separate or integrated PED and Finality
Sink components. It may use local or remote authority. It may use
cryptographic or protected-state capability representations. It may
use one agent or many agents. It may operate with or without an
Interim Effectuation Validator where the selected embodiment permits.
It may support one consequential effect or a series of causally
linked effects.
7.3.48. Source global page 62
It may use hardware-backed security, protected software services, or
hybrid enforcement. It may employ a protected credential broker,
direct sink authorization, or both. It may use cryptographic
receipts, internal protected state, or other authenticated evidence
mechanisms. It may operate across application, operating-system,
network, storage, controller, device, or cloud boundaries. It may
incorporate future communication and computing architectures without
Das Expires 29 April 2027 [Page 60]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
being restricted to a particular commercial implementation. The
selected mechanism must preserve the technical invariants required by
the applicable claimed embodiment.
CW-1.25 — TECHNICAL CHARACTERIZATION Common Master Workflow CW-1
provides a modular architecture for governing consequential
operations initiated by autonomous computational entities. The
requesting entity may compute, reason, plan, propose, delegate, or
prepare an operation. Such computation does not automatically confer
authority to produce the external consequence. The proposed
operation may be represented as a Candidate Act and held non-
effective. A Protected Enforcement Domain evaluates relevant
authorization and technical evidence. Additional specialized modules
may impose further protected constraints. Scoped finality authority
is generated, derived, activated, or committed under protected
conditions. The actual Finality Sink obtains or reconstructs the
operation pending at the consequence-producing
boundary. The sink independently verifies the operation against the
required authority and current protected state. Where single-use
authority is required, the appropriate protected consumption
procedure is performed. Only then is the specified consequential
operation permitted. Optional mechanisms may provide protected
cross-agent conflict arbitration, semantic target correspondence,
privacy composition, delegated authority constraints, execution-path
coverage verification, device migration, runtime integrity, and other
technical protections. Where receipt-gated causal continuation is
selected, an earlier real effect produces evidence accepted by a
cryptographically identifiable authorized IEV. The resulting
accepted receipt constitutes a necessary causal enabling factor for
the next phase, and
the successor Finality Sink verifies that condition before permitting
the next consequential effect.
8. Common Workflow CW-2: Receipt-Constituted Causal Continuation
This foundational workflow is grounded in original global source
pages 63–119 of the 3,567-page disclosure (first uploaded PDF). The
material below includes a technical architectural figure, operational
flowchart, and a page-indexed detailed transcription of source text.
Subsequent editing for a public standards-track proposal, if any,
must not change the semantics of the original disclosed optional and
mandatory mechanisms.
Das Expires 29 April 2027 [Page 61]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
8.1. Architecture and Trust Boundaries
Diagram highlights the main protected relationships. It is an
interpretive overview, not a substitute for the full qualifications
in the page-indexed technical disclosure.
[Predecessor Candidate Act]
|
[Predecessor Finality Sink]
|
[Observed actual effect]
|
[Qualified outcome receipt]
|
[Protected receipt acceptance]
|
[Successor Candidate Act]
|
[Successor scope and PED]
|
[Successor Finality Sink]
|
[Successor actual effect]
Figure 3: CW-2 protected component architecture
8.2. Operational Decision Flow
The flowchart illustrates the primary allow/withhold decision
sequence; additional branches, failure modes, and optional variants
are given in the following source-derived sections.
[Qualify predecessor effect]
|
<Accepted actual-effect receipt?>--No-->[Withhold successor]
| Yes
<Receipt bound to dependency?>--No-->[Withhold successor]
| Yes
[Validate successor source authority]
|
<Successor act and sink state valid?>--No-->[Withhold]
| Yes
[Sink-local protected consumption]
|
[Permit successor effect]
Figure 4: CW-2 operation and security decision flowchart
Das Expires 29 April 2027 [Page 62]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
8.3. Detailed Source-Derived Technical Disclosure
8.3.1. Source global page 63
The architecture may operate through one protected component or
across multiple physical and administrative domains. Its technical
security guarantees depend upon actual protected authority, evidence,
state, and effectuation boundaries rather than the names assigned to
individual modules. The present and proposed future implementation
variants may employ different computational substrates while
preserving the relevant operation-specific protected enforcement
relationship. The principal candidate technical contribution of CW-1
lies in the enforceable separation between computational generation
and consequential execution authority, implemented through operation-
specific protected evidence, non-effective holding, scoped finality
enablement, independent actual-operation reconstruction, sink-local
verification, and
protected effectuation-state control. Additional optional mechanisms
may provide separately identifiable technical contributions where
their particular protected relationships and resulting technical
effects are supported and non-obvious over the relevant prior art.
The disclosure is non-limiting and intended to provide sufficient
technical implementation guidance for a person having ordinary skill
in the relevant art.
END OF COMMON MASTER WORKFLOW CW-1.
COMMON WORKFLOW CW-2
PROTECTED CAUSAL-ORDERED REAL-EFFECT EXECUTION USING IDENTITY-
AUTHENTICATED INTERIM EFFECTUATION VALIDATORS, RECEIPT-
CONSTITUTED NEXT-PHASE AUTHORITY, NON-BYPASSABLE FINALITY-SINK
ENFORCEMENT, AND CRYPTOGRAPHIC OR NON-CRYPTOGRAPHIC
CONTINUATION MECHANISMS
CW-2.0 — GENERAL DESCRIPTION AND TECHNICAL PURPOSE The present Common
Workflow CW-2 discloses systems, methods, apparatus, protected
computing components, hardware and software mechanisms, authenticated
communication protocols, protected execution-state transitions, and
non-limiting implementations for enforcing causal ordering among
consequential operations performed by autonomous computing systems.
The workflow is particularly applicable to artificial-intelligence
agents, autonomous assistants, distributed computational agents,
Das Expires 29 April 2027 [Page 63]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
operating-system services, device controllers, application
frameworks, cloud services, enterprise systems, communication
networks, financial infrastructure, protected storage systems,
robotic systems, and other computational entities capable of
producing
externally consequential effects. The principal technical
arrangement comprises an earlier authorized real-effectuation phase,
an Interim Effectuation Validator having an authenticated validator
identity, an actual-effect receipt
8.3.2. Source global page 64
accepted by that validator, and a subsequent Finality Sink whose
capability to release the next consequential effect depends upon the
accepted receipt. The architecture establishes that a later
consequential operation is causally dependent upon an earlier
permitted real effect and the independent acceptance of evidence
concerning that effect. In a principal implementation, a first
Candidate Act is authorized through a Protected Enforcement Domain
and released through a designated Finality Sink. The first operation
produces an actual bounded consequence. A qualified observation
component obtains evidence concerning the consequence. An Interim
Effectuation Validator, hereinafter IEV, evaluates the evidence under
the applicable protected authorization, expected-effect predicate,
actual-effect correspondence, phase ordering,
authority state, and current security conditions. The IEV possesses
a cryptographically verifiable identity recognized by the applicable
protected trust domain. Upon successful validation, the IEV
generates, authenticates, commits, activates, or otherwise
establishes a Validator-Accepted Effect Receipt. The validated
receipt is conveyed to, retrieved by, or made available as
authoritative protected state to the designated next Finality Sink.
The next Finality Sink verifies the validator identity, receipt
validity, causal predecessor, successor operation, current authority,
and applicable protected state. Only after the required receipt-
dependent conditions are established may the next consequential phase
become effective. The validated receipt is not merely a report that
an earlier phase succeeded. It is the necessary
causal enabling factor for the next phase's controlled effectuation.
CW-2.0.1 — Principal Inventive Characterization The proposed
technical concept is a protected causal effectuation architecture in
which an earlier bounded real effect generates evidence that is
independently accepted by an identified validator, and that
acceptance establishes the necessary authority or execution-enabling
Das Expires 29 April 2027 [Page 64]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
condition for a later effect. The validator's result is not merely
advisory. The receipt is not merely retrospective evidence. The
next Finality Sink cannot validly complete the controlled successor
effect without satisfying the accepted receipt-dependent condition.
In one implementation, the accepted receipt directly constitutes an
operation-specific execution authorization. In another
implementation, the receipt activates or enables otherwise
unavailable scoped authority.
8.3.3. Source global page 65
In another implementation, the receipt is a necessary input to
deriving, unsealing, releasing, or using protected execution
material. In another implementation, receipt acceptance advances a
hardware-controlled or software- protected causal state machine.
These implementations share the same required technical relationship.
CW-2.0.2 — Causal Ordering Rather Than Ordinary Workflow Ordering A
conventional scheduler may execute Operation B after Operation A.
Such scheduling may establish chronological ordering. However,
Operation B may remain independently executable even if the
scheduler's ordering logic is bypassed.
CW-2 discloses a stronger implementation. Operation B lacks the
required effectuation condition until an authenticated receipt
derived from the actual outcome of Operation A has been accepted by
the authorized IEV. Thus, the causal relationship is enforced by the
protected execution architecture rather than merely represented in
workflow instructions. A representative sequence is: Authorized
Candidate Act A | v First Finality Sink FS-A | v
REAL BOUNDED EFFECT A | v Actual-effect observation | v Protected
Effect Receipt R-A | v Identified authorized IEV | v Validator-
accepted receipt VR-A | v Receipt delivered to or verified by FS-B |
v Necessary execution condition B established |
8.3.4. Source global page 66
v Finality Sink FS-B verifies actual operation B | v
REAL CONSEQUENTIAL EFFECT B The arrows represent required causal
dependencies in the selected receipt-gated implementation, not merely
a display of chronological software events.
CW-2.0.3 — Receipt as the Allowing Factor For purposes of the
principal inter-phase implementation, the validator-accepted receipt
serves as an execution-enabling factor. The accepted receipt may be
the final scoped authority object required by the sink.
Das Expires 29 April 2027 [Page 65]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Alternatively, it may be the necessary authenticated prerequisite to
making a separately represented finality capability usable. In
either form, the protected system shall not permit the governed
successor consequence merely because the agent, scheduler, operating
system, or application asserts that the earlier operation succeeded.
The required receipt-dependent authority must actually exist and be
verifiable at the final enforcement boundary. A raw unvalidated
receipt does not possess the same status as a validator-accepted
receipt.
A receipt from an unauthorized validator does not satisfy the
required condition. A receipt for an unrelated earlier effect cannot
authorize an unrelated successor operation.
CW-2.0.4 — No Blockchain Requirement The term receipt, as used
herein, denotes an authenticated operational evidence-and-authority
object, signal, state, reference, or commitment. It does not require
a blockchain. It does not require a distributed ledger. It does not
require a consensus network, token economy, mining mechanism, public
transaction history, or third-party ledger registration. A
cryptographic hash chain may optionally support integrity or
ordering, but is not an essential requirement. A protected receipt
may exist transiently within a secure hardware controller and be
consumed without ever being written to a permanent external audit
log. The required inventive relationship concerns receipt-dependent
causal effectuation, not a particular logging or recordkeeping
substrate.
CW-2.0.5 — Physical and Logical Flexibility
8.3.5. Source global page 67
The IEV may be physically inserted into a command path. It may be
installed as a separate hardware module. It may reside within an
operating system. It may be implemented as an isolated software
service. It may reside inside a Finality Sink. It may be
distributed across multiple machines. It may be remotely hosted. It
may be implemented as a protected logical function within a common
processor containing both validation and effectuation components.
The physical arrangement does not alter the requirement that the
successor Finality Sink must authenticate and enforce the applicable
receipt-dependent condition.
CW-2.0.6 — Relationship to CW-1
CW-2 may incorporate Candidate Acts, Non-Effective State, Protected
Enforcement Domains, protected validation evidence, Scoped Finality
Authority, and Finality Sink mechanisms disclosed in Common Master
Das Expires 29 April 2027 [Page 66]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Workflow CW-1. The principal execution-finality protection of CW-1
may operate independently without employing an IEV for every
operation.
CW-2 is an optional additional architecture applicable where a
consequential effect must depend upon independently validated earlier
evidence or where additional independent pre-effect verification is
required. Once receipt-gated continuation is selected as a mandatory
protection for a particular phase, the receipt dependency is not
optional for that phase.
CW-2.0.7 — Optional Relationship to CW-3
CW-3 may additionally govern detected task-scope deviations, anomaly-
triggered reauthorization, and human or automated approval. A valid
human approval may establish or modify permitted task scope.
However, where CW-2 requires a validated prior real-effect receipt,
approval does not automatically replace that evidence. The protected
successor Finality Sink enforces both the necessary receipt
dependency and the applicable current authorization.
CW-2.1 — SPECIFIC TECHNICAL PROBLEMS
CW-2.1.1 — Execution Without Causal Proof
8.3.6. Source global page 68
An autonomous agent may be authorized to perform a sequence of
operations. A conventional workflow may permit later operations when
earlier software tasks report completion. However, completion of
software instructions does not necessarily establish completion of
the required real-world or external-system consequence. The
architecture must distinguish successful computation from actual
permitted effectuation.
CW-2.1.2 — Independent Execution Authority Remaining Available An
application may check an earlier receipt before issuing a subsequent
command. However, the application may retain an unrestricted
credential or alternative interface capable of executing the
subsequent command independently. Such an arrangement provides a
logical check but not necessarily an enforced causal dependency.
CW-2 addresses this problem by requiring the final execution path to
depend upon accepted receipt- derived authority.
CW-2.1.3 — Validator Impersonation A requesting agent or compromised
intermediary may generate a message containing the words "validation
passed." Without authenticated validator identity, the successor
Das Expires 29 April 2027 [Page 67]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Finality Sink may be unable to distinguish the legitimate validator
from a forged source. The architecture therefore binds validator
acceptance to a cryptographically verifiable identity and an
authorized validation role.
CW-2.1.4 — Validator Substitution A malicious process may replace the
intended validator with a permissive component. The replacement may
produce syntactically correct receipts without performing the
required checks.
CW-2 requires a protected validator enrollment and authorization
mechanism. A substituted validator is not automatically recognized
merely because it uses the same software interface, process name,
address, or identification string.
CW-2.1.5 — Physical-Path Bypass A validator placed on one
communication path may be avoided through another network interface,
application API, device bus, privileged command path, or direct
actuator connection. Physical placement alone does not establish
non-bypassability. The controlled effectuation interface must
require the receipt-dependent condition irrespective of which covered
upstream software path requests the effect.
8.3.7. Source global page 69
CW-2.1.6 — Monolithic-System Bypass Where an IEV is implemented
within the same component as the agent or Finality Sink, an
unprotected implementation may permit the agent to modify validation
flags or bypass the validation function. An integrated
implementation must therefore protect the relevant IEV identity,
validation state, and final release primitive against unauthorized
modification or invocation.
CW-2.1.7 — False Actual-Effect Evidence A source may report that an
external effect occurred even though it observed only request
dispatch or acceptance. A cryptographically signed but unsupported
statement does not establish a stronger consequence. The IEV must
verify the evidence source's ability to support the specified effect
predicate.
CW-2.1.8 — Receipt Reuse A valid receipt may be copied, delayed,
replayed, or presented to a different Finality Sink. The system
requires protected bindings to the corresponding predecessor,
successor, authority epoch, and consumption conditions.
Das Expires 29 April 2027 [Page 68]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-2.1.9 — Effectuation Uncertainty An external operation may have
occurred even if its acknowledgement was lost. A missing receipt is
not proof of absence of the effect. The architecture must preserve
uncertainty and withhold dependent effects whose required evidence is
unavailable.
CW-2.1.10 — Technical Objective The principal objective is to
construct an enforceable causal relationship among: A prior
authorized real effect; Authenticated evidence of that effect; An
authorized cryptographically identifiable IEV; IEV acceptance of the
evidence; A validator-accepted receipt; The missing successor
execution condition; And the next Finality Sink's actual effectuation
decision.
CW-2.2 — THREE OPERATIONAL MODES
8.3.8. Source global page 70
CW-2.2.1 — Mode A: In-Line Pre-Effect Validation In Mode A, the IEV
is logically positioned after initial authorization or preparation
and before the actual consequential release. A representative
sequence is: Candidate Act | Protected Authorization | Prepared
Actual Operation | Identified IEV | Authenticated Pre-Effect
Validation Result | Finality Sink Verification | Actual Consequential
Effect The principal effect remains withheld while required
validation is pending. The IEV independently obtains the actual
operation through a protected interface. Its validation result is
authenticated under its authorized identity. The final sink verifies
the result against the actual pending command. Mode A need not
require an earlier real-effect receipt. Its causal prerequisite is
the independently accepted current-operation validation.
CW-2.2.2 — Mode B: Inter-Phase Receipt-Constituted Causal
Continuation Mode B is the principal receipt-gated implementation
emphasized herein. A first bounded real effect occurs. The effect
produces qualified observation evidence. The authorized IEV
validates that evidence and establishes a validator-authenticated
receipt. The next Finality Sink requires that receipt or
authoritative protected receipt state before releasing the next
effect. A representative sequence is: FS[0] -> REAL EFFECT[0] | v
EFFECT RECEIPT[0] | v
8.3.9. Source global page 71
AUTHORIZED IEV[0] | v ACCEPTED RECEIPT[0] | v
Das Expires 29 April 2027 [Page 69]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
RECEIPT-DEPENDENT ENABLEMENT[1] | v FS[1] -> REAL EFFECT[1] This is
not merely an after-the-fact inspection procedure. Although the IEV
observes evidence following the earlier bounded effect, its
acceptance occurs before and governs the later effect.
CW-2.2.3 — Mode C: Combined Validation Mode C incorporates both in-
line validation and inter-phase receipt-gated continuation. A
successor operation may require: First, a validated receipt arising
from the predecessor real effect. Second, a current in-line
validation of the actual pending successor command. Third, final
verification of both conditions at the successor Finality Sink. The
same physical IEV or different authorized validator instances may
implement these functions.
CW-2.3 — BROAD DEFINITIONS
CW-2.3.1 — Controlled Phase A Controlled Phase means an identified
preparatory or consequential portion of an operation or workflow
governed by specified authority, effectuation, evidence, or
continuation conditions.
CW-2.3.2 — Phase-Specific Candidate Act A Phase-Specific Candidate
Act, or PSCA, means a Candidate Act associated with a particular
phase and its permitted effectuation scope.
CW-2.3.3 — Phase Descriptor A Phase Descriptor, or PD, means a
machine-verifiable representation of a phase's identity, operation,
designated effectuation boundary, required predecessor conditions,
applicable authority, and permitted outcomes.
CW-2.3.4 — Interim Effectuation Validator An Interim Effectuation
Validator means a protected validation function or component
configured to evaluate a required actual pending operation, effect
observation, or predecessor receipt and to authenticate its resulting
acceptance or rejection.
8.3.10. Source global page 72
An IEV may be realized as hardware, firmware, software, a protected
process, a secure processor function, a remote service, a distributed
group, or an integrated controller subfunction. The designation IEV
is functional and does not require any particular physical enclosure.
Das Expires 29 April 2027 [Page 70]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-2.3.5 — Validator Unique Identity A Validator Unique Identity, or
VUID, means an identity assigned to a validator instance or
authenticated validator role within an applicable protected
enrollment namespace. The VUID is associated with cryptographic
verification material. A bare identifier without proof of authorized
cryptographic control does not constitute sufficient validator
authentication.
CW-2.3.6 — Cryptographically Verifiable Validator Identity A
Cryptographically Verifiable Validator Identity, or CVVI, means an
enrolled validator identity that can be authenticated through a
digital signature, cryptographic message authentication, proof of key
possession, authenticated hardware identity, or an equivalent
cryptographic authentication mechanism. The identity may be
associated with a validator public key, certificate, protected key
reference, issuer identity, role, authorization scope, security
domain, and validity state.
CW-2.3.7 — Validator Authorization Profile A Validator Authorization
Profile specifies the effect classes, predecessor evidence, successor
operations, Finality Sinks, and policy conditions for which an IEV is
authorized to issue acceptable results. A cryptographically valid
validator identity does not automatically confer authority over all
protected operations.
CW-2.3.8 — Validator Identity Registry A Validator Identity Registry
is an authenticated source of enrolled validator identities,
cryptographic verification credentials, authorization profiles, key
generations, and revocation status. It may be stored locally or
distributed across trusted domains.
CW-2.3.9 — Protected Effect Receipt A Protected Effect Receipt, or
PER, means authenticated evidence concerning a particular actual
effectuation attempt or observed consequential outcome. A PER may be
a record, event, signal, protected state entry, authenticated
message, or equivalent machine-verifiable representation. It is not
limited to a paper receipt, database entry, blockchain transaction,
or exported file.
CW-2.3.10 — Validator-Accepted Effect Receipt
Das Expires 29 April 2027 [Page 71]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
8.3.11. Source global page 73
A Validator-Accepted Effect Receipt, or VAER, means a PER or
equivalent accepted receipt state that an authorized
cryptographically identifiable IEV has validated for the required
causal progression. The VAER may include the original PER and the
IEV's authenticated acceptance. Alternatively, the VAER may be
represented as an authenticated protected state transition, signed
continuation object, or secured receipt reference. The VAER has an
execution-enabling role under Mode B.
CW-2.3.11 — Causal Continuation Condition A Causal Continuation
Condition, or CCC, means the protected condition required for the
subsequent consequential phase, whose validity depends upon the
appropriate VAER. A CCC may be a scoped cryptographic capability,
protected key release, threshold share, hardware state, transaction
predicate, controlled gateway authorization, protected register
value, or equivalent necessary execution prerequisite.
CW-2.3.12 — Receipt-Constituted Continuation Authority Receipt-
Constituted Continuation Authority means authority or indispensable
execution enablement created, activated, derived, or made valid as a
consequence of accepted earlier real-effect evidence. A VAER may
directly embody the scoped authority or constitute the necessary
factor for making separately represented authority usable.
CW-2.3.13 — Finality Sink The Finality Sink retains its general
meaning under CW-1 as the controlled boundary that independently
verifies applicable authority and actual pending operation before
permitting the governed consequence. For receipt-gated continuation,
the successor Finality Sink additionally verifies the mandatory
validator-authenticated causal receipt condition.
CW-2.3.14 — Receipt-to-Sink Delivery Receipt-to-Sink Delivery means
the authenticated transmission, protected retrieval, internal state
communication, or authoritative availability of a VAER to the
designated successor Finality Sink. A physical transfer of a file is
not mandatory. The critical property is that the sink can
independently establish the accepted receipt's authenticity and
applicability.
CW-2.3.15 — Mandatory Causal Path A Mandatory Causal Path means an
effectuation route for which the required VAER-dependent condition
cannot be skipped by the requesting entity. The path may consist of
one component or several components.
Das Expires 29 April 2027 [Page 72]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
8.3.12. Source global page 74
CW-2.3.16 — Validator Position Validator Position means the logical,
architectural, physical, or operational location of the IEV relative
to the originating agent, effectuation controllers, protected
evidence source, prior Finality Sink, and successor Finality Sink.
Position may be defined by control dependency rather than physical
distance.
CW-2.3.17 — Protected Phase Lineage Commitment A Protected Phase
Lineage Commitment, or PPLC, means an authenticated relationship
among the predecessor operation, actual effect receipt, accepting
validator identity, permitted successor operation, and protected
current authority.
CW-2.3.18 — Protected Phase-Binding Commitment A Protected Phase-
Binding Commitment, or PPBC, binds a phase to its Candidate Act,
scope, authorized Finality Sink, and applicable protected state.
CW-2.3.19 — Pre-Effect Validation Record A Pre-Effect Validation
Record, or PEVR, means authenticated evidence that an authorized IEV
accepted the actual pending operation under required current
predicates. A PEVR does not establish that the operation
subsequently occurred.
CW-2.3.20 — Protected Phase Outcome Commitment A Protected Phase
Outcome Commitment, or PPOC, means a protected binding of the
observed phase result to the corresponding authorization and
effectuation attempt.
CW-2.3.21 — Continuation Authority Record A Continuation Authority
Record, or CAR, means a protected representation of successor-
specific authority that is derived from, activated by, or bound to a
required validator-accepted receipt. The CAR need not be separately
instantiated where the VAER itself carries the necessary scoped
continuation authority.
CW-2.3.22 — Continuation Consumption Identifier A Continuation
Consumption Identifier, or CCI, means a protected single-use or
otherwise bounded reference controlling repeated use of receipt-
derived authority.
CW-2.3.23 — Effect-Occurrence Uncertainty Effect-Occurrence
Uncertainty means the available evidence cannot establish whether the
relevant attempted external effect occurred. Uncertainty is distinct
from confirmed absence of an effect.
CW-2.3.24 — Outcome Reconciliation Fence
Das Expires 29 April 2027 [Page 73]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
8.3.13. Source global page 75
An Outcome Reconciliation Fence, or ORF, means protected state
withholding unsafe continuation, retry, or conflicting effectuation
while a prior outcome remains unresolved.
CW-2.3.25 — Recovery Candidate Act A Recovery Candidate Act means a
separately governed consequential operation intended to correct,
compensate for, or contain an earlier effect or uncertain result.
CW-2.4 — VALIDATOR POSITION AND CONTROL ARCHITECTURE
CW-2.4.1 — Validator Between Two Finality Sinks In one arrangement,
the IEV occupies a protected logical position between a first
Finality Sink and a successor Finality Sink. The first sink permits
a bounded real effect. The IEV receives actual-effect evidence. The
IEV creates an authenticated accepted receipt. The second sink
cannot release the next effect without the receipt-dependent
condition. This arrangement may employ separate physical components,
or the same physical device may implement the distinct logical
functions.
CW-2.4.2 — Physically Added Validator An IEV may be physically
installed as an additional component within an existing computing or
device environment. Examples include a protected network appliance,
hardware security module, peripheral security controller, embedded
validation processor, industrial control module, secure interface
device, or protected device-side coprocessor. The physically
installed component possesses a CVVI. The downstream effectuation
controller recognizes its authorized validator identity. The
physical component may receive predecessor receipts, evaluate outcome
evidence, and produce authenticated successor-specific receipts. A
physically installed monitor that can only observe operations but
cannot influence a mandatory effectuation condition does not by
itself provide the claimed causal gate.
CW-2.4.3 — Validator Inside a Finality Sink In another arrangement,
the IEV is implemented as a protected logical function inside the
successor Finality Sink. It validates the prior effect evidence and
commits the accepted receipt state.
Das Expires 29 April 2027 [Page 74]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
8.3.14. Source global page 76
A separate logical effectuation function within the same protected
component verifies the receipt state before releasing the successor
command. The internal validation identity remains bound to
authenticated protected credentials or cryptographically verifiable
enrollment state. A separately networked validator device is
unnecessary.
CW-2.4.4 — Validator Inside a Protected Processor The IEV may run
within a protected processor execution context. The requesting agent
may run in a different execution context. The IEV controls its
cryptographic authentication capability and protected validation
state. The relevant Finality Sink verifies the resulting
authenticated receipt or authoritative protected state.
CW-2.4.5 — Validator Inside an Operating-System Security Component An
operating-system security service may implement the IEV. The
security service may mediate system calls, network transmissions,
application-function invocations, storage commits, or privileged
device commands. Where the intended threat model includes a
compromised operating-system kernel, additional protection beyond an
ordinary kernel-controlled service may be necessary.
CW-2.4.6 — Remote Validator The IEV may reside in a different
computing domain. A protected communication interface authenticates
its validator identity. The remote IEV validates the required
evidence and produces a successor-bound VAER. The successor sink
authenticates the remote validator and verifies the receipt.
CW-2.4.7 — Validator on a Physical Device A phone, computer,
industrial controller, router, network appliance, or other device may
contain the IEV. The IEV may validate actual device state and
participate in protected command release. Its placement may be
selected according to which resource or effectuation boundary
requires protection.
CW-2.4.8 — Multiple Validators in Different Locations Several IEVs
may be positioned at different architectural locations. One may
verify the actual pending command.
8.3.15. Source global page 77
Another may verify the earlier external effect. Another may validate
current successor authority. A protected receipt may require
acceptance by a defined validator set or threshold.
Das Expires 29 April 2027 [Page 75]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-2.4.9 — Single-Component Implementation The complete causal
sequence may be implemented within one protected component. The
component may contain: An initial authorization function; A first
effectuation interface; An effect-observation function; A logically
identified IEV; A protected accepted-receipt state; A continuation-
enable function; And a successor effectuation interface. The
physically integrated arrangement must still enforce the required
causal transitions.
CW-2.4.10 — Position-Neutral Security Requirement In all variants,
the IEV must be positioned logically or operatively so that its
accepted receipt controls a necessary condition at the corresponding
successor effectuation boundary. Physical positioning alone is
insufficient. The required causal dependency and authenticated
validator identity are the defining security relationships.
CW-2.5 — VALIDATOR IDENTITY, ENROLLMENT, AND AUTHENTICATION
CW-2.5.1 — Mandatory Validator Authentication Each IEV authorized to
issue accepted receipts for protected effectuation must possess a
verifiable identity recognized by the relevant trust domain. In the
principal implementation, that identity is cryptographically
authenticated.
CW-2.5.2 — Uniqueness Within a Trust Namespace A validator may
possess a unique identifier within an enrollment namespace. The
identifier may be assigned through a protected registration
procedure.
8.3.16. Source global page 78
Global uniqueness across unrelated administrative systems is not
essential where issuer-qualified names and authenticated trust-domain
identifiers prevent ambiguity.
CW-2.5.3 — Cryptographic Key Binding The validator identity may be
bound to a public/private key pair, authenticated secret, protected
device identity, or another cryptographic credential. The protected
validator controls the relevant signing or authentication function.
The requesting agent cannot freely produce an acceptable validator-
authenticated receipt.
CW-2.5.4 — Validator Identity Record A representative non-limiting
structure is: VALIDATOR_IDENTITY = { trust_domain_id,
validator_unique_id, validator_role_id, cryptographic_key_id,
public_verification_material, enrollment_authority,
authorized_effect_classes, authorized_phase_classes,
permitted_successor_sinks, validator_identity_generation,
Das Expires 29 April 2027 [Page 76]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
authority_epoch, validity_conditions, revocation_reference,
protected_authentication } The fields may be stored in one record or
distributed among authenticated state references.
CW-2.5.5 — Enrollment Procedure A protected identity authority may
authenticate a validator instance, establish its allowed roles, bind
its cryptographic credentials, and register the resulting identity.
The corresponding successor Finality Sink is configured to recognize
the authorized identity or role.
CW-2.5.6 — Validator Role Restrictions A validator authorized for one
effect class may not automatically approve another. For example, a
validator qualified to establish committed storage state does not
automatically possess authority to approve a payment settlement
predicate. The sink verifies the relevant authorization profile.
CW-2.5.7 — Cryptographic Proof of Possession
8.3.17. Source global page 79
The validator may prove control of its associated cryptographic
credential through a signature, authenticated challenge response, or
protected equivalent protocol. A copied identifier is insufficient.
CW-2.5.8 — Identity Rotation Validator credentials may be rotated
through a protected procedure. The identity registry records the
applicable key generation or replacement binding.
CW-2.5.9 — Validator Replacement A failed validator may be replaced.
The replacement does not acquire authority merely by adopting the
former validator's process name or communication address. It must
satisfy the applicable enrollment and authorization rules.
CW-2.5.10 — Revocation A validator may be revoked due to compromise,
expiration, or loss of authorization. The successor Finality Sink
checks the applicable current trust state.
CW-2.5.11 — Identity Does Not Prove Correctness Cryptographic
authentication establishes provenance under the applicable key trust
assumptions. It does not automatically prove that an authorized
validator correctly evaluated actual-effect evidence. The system may
employ protected code integrity, independent observation, multiple
validators, or other suitable mechanisms where stronger assurance is
required.
CW-2.6 — PROTECTED PHASE DESCRIPTOR AND CAUSAL DEPENDENCY A
representative Phase Descriptor may comprise: PHASE_DESCRIPTOR = {
protocol_version, workflow_id, phase_id, phase_sequence,
Das Expires 29 April 2027 [Page 77]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
predecessor_phase_ids, candidate_act_digest, operation_class,
actual_operation_binding, resource_scope, destination_scope,
designated_finality_sink,
8.3.18. Source global page 80
required_predecessor_outcome, required_validator_identity_or_role,
authorized_receipt_type, receipt_assurance_requirement,
required_continuation_condition, authority_epoch, revocation_epoch,
policy_epoch, phase_nonce, protected_consumption_reference,
canonicalization_profile } The descriptor may be represented through
deterministic binary encoding, canonicalized structured data, or an
equivalent machine-verifiable form. The essential relationship is
not the choice of encoding. It is that the required predecessor
evidence, accepting validator identity, and successor effectuation
authority are bound to the correct phase and actual operation. A
protected phase dependency may be represented as: DEPENDENCY[i+1] =
REQUIRE_VALIDATED_EFFECT( Phase[i], RequiredOutcome[i],
AuthorizedIEV[i], SuccessorAct[i+1],
SuccessorSink[i+1] ) For the mandatory receipt-gated implementation,
the successor effect remains non-effective until this dependency is
satisfied.
CW-2.7 — IDENTITY-BOUND PROTECTED EFFECT RECEIPT
CW-2.7.1 — Purpose A PER describes or references evidence concerning
an earlier actual-effect attempt. A VAER represents the IEV's
authorized acceptance of that evidence. The VAER may become the
direct allowing factor for a successor act or the protected basis
from which the required next-phase execution condition is formed.
CW-2.7.2 — Representative Receipt Structure
VALIDATOR_ACCEPTED_EFFECT_RECEIPT = { receipt_version, workflow_id,
predecessor_phase_id, predecessor_candidate_act_digest,
8.3.19. Source global page 81
predecessor_finality_sink_id, predecessor_effectuation_attempt_id,
actual_effect_descriptor, qualified_observation_reference,
supported_outcome_predicate, validator_unique_identity,
validator_cryptographic_key_id, validator_authorization_profile,
validation_policy_reference, validator_acceptance_decision,
permitted_successor_phase_id, permitted_successor_candidate_digest,
designated_successor_sink_id, authority_epoch,
receipt_freshness_reference, receipt_consumption_reference,
protected_sequence_or_counter, cryptographic_validator_authentication
} A single receipt may omit fields that are immaterial to a
Das Expires 29 April 2027 [Page 78]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
particular effect, provided the necessary causal and identity
bindings remain verifiable.
CW-2.7.3 — Receipt Is Not a Blockchain Object The receipt may be a
compact signed message. It may be an authenticated controller event.
It may be stored in a protected register. It may be a protected
memory object. It may be a cryptographically authenticated state
transition. It may be an operation-bound key-release authorization.
It may be a non-exportable protected receipt handle. It may be an
internal condition of a secure state machine. No distributed ledger
is necessary.
CW-2.7.4 — Receipt Acceptance The IEV accepts a receipt only after
the required outcome evidence and authorization predicates pass.
Acceptance is bound to the validator's authenticated identity.
CW-2.7.5 — Receipt as Direct Authority In one implementation, the
VAER itself includes the scoped successor authority accepted by the
Finality Sink.
8.3.20. Source global page 82
The sink validates the receipt and actual successor operation before
effectuation.
CW-2.7.6 — Receipt as Key-Enabling Factor In another implementation,
the VAER is a necessary input to a protected key service. The key
service releases or derives the cryptographic material required for
successor effectuation only after validating the VAER.
CW-2.7.7 — Receipt as State-Enabling Factor In another
implementation, receipt acceptance causes a protected controller
state transition enabling the next operation. The sink verifies the
authenticated receipt-linked state.
CW-2.7.8 — Receipt as Non-Bearer Authority The receipt may be copied
or transported without granting unrestricted authority. The
designated sink verifies current authority, actual operation, and
applicable protected consumption state.
CW-2.7.9 — Receipt Consumption A single-use VAER may be consumed
through an atomic protected state transition. The same receipt
cannot produce additional unauthorized effects by being replayed.
CW-2.8 — CAUSAL ORDERING AND PROTECTED CONTINUATION
Das Expires 29 April 2027 [Page 79]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-2.8.1 — Formal Causal Relationship Let E[i] denote an earlier
bounded real effect. Let R[i] denote qualified receipt evidence
concerning E[i]. Let V[i] denote acceptance by an authorized IEV.
Let C[i+1] denote the required successor execution condition. Let
FS[i+1] denote the successor Finality Sink. The required
relationship is: E[i] -> R[i] -> V[i] -> C[i+1] -> FS[i+1] -> E[i+1]
The relation does not require globally synchronized clocks. It
requires protected proof of the specified predecessor dependencies.
CW-2.8.2 — Causal Receipt Acceptance
8.3.21. Source global page 83
V[i] cannot be accepted for a required actual-effect predicate merely
because the requesting agent predicted E[i]. The accepted evidence
must satisfy the applicable real-effect observation requirement.
CW-2.8.3 — No Premature Continuation C[i+1] remains invalid or
unavailable before the accepted receipt condition exists.
CW-2.8.4 — No Arbitrary Phase Skipping Where sequential causal
dependencies are mandatory, a later phase cannot be executed without
satisfying the required predecessor transitions.
CW-2.8.5 — Branching Different acceptable prior outcomes may enable
different preauthorized successor branches. A failure or partial-
effect receipt may enable a narrow recovery branch rather than the
originally intended broader effect.
CW-2.8.6 — Multiple Predecessors A successor may require receipts
from several earlier effects. The protected continuation condition
may require all designated receipts or a specifically authorized
threshold.
CW-2.8.7 — Parallel Effects Independent non-conflicting phases may
operate concurrently where the applicable protected constraints
permit. A later phase requiring their joint results remains withheld
until the required accepted receipts are available.
CW-2.8.8 — Effect-Specific Finality The evidence must establish the
particular actual consequence required by the successor operation. A
command-dispatch receipt does not automatically prove a remote
resource was modified. A controller acknowledgement does not
automatically prove that a physical actuator reached the target
position.
CW-2.9 — RECEIPT DELIVERY TO THE SUCCESSOR FINALITY SINK
Das Expires 29 April 2027 [Page 80]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-2.9.1 — Direct Delivery The IEV may send the VAER directly to the
successor Finality Sink through an authenticated communication
channel.
8.3.22. Source global page 84
CW-2.9.2 — Protected Registry Retrieval The sink may retrieve the
VAER from an authoritative protected registry.
CW-2.9.3 — Protected Internal State Where the validator and sink are
integrated, the IEV may commit an identity-bound acceptance event to
protected internal state. The effectuation function verifies that
state before release.
CW-2.9.4 — Controller Bus A physically separate validator may
transmit the accepted receipt over an authenticated hardware or
controller communication interface.
CW-2.9.5 — Secure Mailbox A protected mailbox may convey the receipt
from the IEV to the effectuation controller.
CW-2.9.6 — Receipt Reference A compact reference may be supplied
instead of a complete receipt object. The sink resolves the
reference through the appropriate authoritative source and verifies
the underlying accepted receipt.
CW-2.9.7 — Required Sink Checks The sink determines: Whether the
validator identity is authentic; Whether the validator remains
authorized; Whether the correct prior effect is represented; Whether
the required outcome predicate is supported; Whether the receipt
belongs to the proposed successor; Whether the successor's actual
operation is within the permitted scope; Whether the receipt remains
valid and unconsumed; And whether current protected authority permits
effectuation.
CW-2.9.8 — No Trust in Agent-Carried Assertions An agent may
transport a receipt but cannot independently modify its protected
authority or validator acceptance. A message stating that the
receipt was previously approved is not a substitute for receipt
authentication.
Das Expires 29 April 2027 [Page 81]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
8.3.23. Source global page 85
CW-2.10 — DETAILED MODE A OPERATIONAL WORKFLOW Step A1 — Construct
Candidate Act An agent proposes a consequential operation. Step A2 —
Establish Non-Effective Hold The operation is withheld at a
controlled boundary. Step A3 — Perform Initial Authorization The PED
verifies applicable scope, identity, and protected authority. Step
A4 — Prepare Actual Operation A protected component constructs the
operation that would be executed. Step A5 — Identify Required
Validator The protected controller determines which IEV identity or
authorized role must approve the operation. Step A6 — Reconstruct
Actual Pending Operation The IEV obtains the actual operation through
a protected interface. Step A7 — Verify Current Predicates The IEV
checks the operation against relevant current authority and protected
state.
Step A8 — Authenticate Pre-Effect Result If validation succeeds, the
IEV authenticates a PEVR under its verifiable identity. Step A9 —
Deliver Result to Final Sink The PEVR is sent or made available
through protected state. Step A10 — Final Sink Verification The sink
authenticates the validator, verifies the actual command and current
authority, and prevents unauthorized replay. Step A11 — Permit
Consequence Only then may the governed principal effect occur. Mode
A is an optional in-line protection. It does not require an earlier
actual-effect receipt.
8.3.24. Source global page 86
CW-2.11 — DETAILED MODE B OPERATIONAL WORKFLOW Step B1 — Construct
First Candidate Act An agent proposes an initial bounded
consequential operation. Step B2 — Establish Protected Authorization
The PED validates the permitted first phase. Step B3 — Verify First
Actual Operation The first Finality Sink reconstructs and verifies
the actual pending operation. Step B4 — Release First Real Effect
The first effect is permitted within its authorized bounds. Step B5
— Record Actual Attempt The protected system associates the effect
with an authenticated attempt reference. Step B6 — Obtain Actual-
Effect Evidence A qualified observer or controller obtains evidence
concerning what happened. Step B7 — Construct Effect Receipt A PER
is formed from the supported observation evidence. Step B8 —
Authenticate Required Validator
The relevant IEV establishes its authorized identity and validation
role. Step B9 — Independently Evaluate Receipt The IEV checks the
evidence, required effect, phase ordering, operation identity, and
current protected state. Step B10 — Produce Validator-Accepted
Receipt The IEV creates or commits a VAER under its cryptographic
identity. Step B11 — Bind Successor Scope The accepted receipt is
Das Expires 29 April 2027 [Page 82]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
associated with the permitted successor Candidate Act and designated
Finality Sink. Step B12 — Deliver Receipt The receipt is delivered
to or made available to the successor Finality Sink.
8.3.25. Source global page 87
Step B13 — Establish Missing Execution Condition The VAER directly
constitutes, enables, releases, derives, or activates the required
continuation condition. Step B14 — Reconstruct Successor Operation
The successor sink obtains the actual pending consequential
operation. Step B15 — Verify Validator Identity The sink
authenticates the accepting IEV and checks its authorization profile.
Step B16 — Verify Causal Receipt The sink checks the required
predecessor evidence, phase lineage, current authority, and replay
state. Step B17 — Consume Authority Where required, the sink
atomically consumes the applicable single-use continuation condition.
Step B18 — Release Next Real Effect The next consequential operation
becomes effective only after its receipt-dependent conditions are
satisfied. Step B19 — Observe Next Outcome
Where another phase depends upon the current effect, the process
produces the next effect receipt and repeats the protected causal
sequence.
CW-2.12 — COMBINED AND NESTED PHASES A larger authorized task may
contain nested phases. A parent authorization may establish the
maximum permitted resource, destination, privilege, monetary amount,
or other effect scope. Individual phases remain subject to their
applicable causal dependencies. A successor phase may require both
the VAER from its predecessor and a new in-line PEVR verifying the
current actual operation. A protected parent task cannot
automatically override a missing mandatory phase receipt. A nested
workflow may contain local preparation, bounded effectuation,
observation, receipt acceptance, and subsequent effectuation steps.
The physical components responsible for those steps may be integrated
or distributed.
8.3.26. Source global page 88
CW-2.13 — PROTECTED CAUSAL STATE MACHINE A representative state
machine may include: CREATED: The phase exists but lacks authority to
produce the governed effect. HELD: The phase remains non-effective.
AUTHORIZED_PREPARATION: Preliminary preparation is permitted.
INLINE_VALIDATION_PENDING: An optional IEV result is required.
INLINE_VALIDATED: The authorized IEV accepted the actual pending
operation. FINALITY_READY: Required initial finality conditions are
satisfied. EFFECT_ATTEMPTED: The first consequential operation was
initiated. EFFECT_CONFIRMED: Qualified evidence supports the
Das Expires 29 April 2027 [Page 83]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
required actual result. PARTIAL_EFFECT: Only a defined part of the
result is established. EFFECT_MISMATCH: The observed consequence
differs materially from the authorized effect. NO_EFFECT_CONFIRMED:
Suitable evidence establishes absence of the relevant effect.
OUTCOME_UNKNOWN: Required outcome evidence is insufficient.
RECEIPT_CONSTRUCTED: A PER has been formed. IEV_ACCEPTANCE_PENDING:
The receipt has not yet passed required validator checks.
VALIDATOR_ACCEPTED: The authorized IEV has authenticated acceptance.
RECEIPT_AVAILABLE_TO_SINK: The successor sink can verify the accepted
receipt. CONTINUATION_CONDITION_ESTABLISHED: The required CCC exists
or is active. SUCCESSOR_FINALITY_PENDING: The actual successor
operation awaits sink verification. SUCCESSOR_EFFECT_ATTEMPTED: The
next consequential operation has been initiated. RECOVERY_PENDING: A
separately governed recovery operation is required. TERMINATED: The
applicable phase or task has concluded. A transition to
CONTINUATION_CONDITION_ESTABLISHED shall not be triggered by an
untrusted completion flag alone.
It requires the appropriate accepted receipt or protected equivalent.
CW-2.14 — CRYPTOGRAPHIC CAUSAL ENFORCEMENT
CW-2.14.1 — Receipt-Dependent Key Release
8.3.27. Source global page 89
A protected key service may withhold the material necessary for the
next consequential operation. Successful VAER verification enables
release of the appropriate scoped material.
CW-2.14.2 — Receipt-Dependent Key Derivation A non-limiting
construction may use: K_NEXT = KDF( ProtectedRootSecret,
H(ValidatorAcceptedReceipt), SuccessorCandidateDigest,
FinalitySinkIdentity, AuthorityEpoch, ProtectedPhaseCounter ) The
protected root secret remains unavailable to the untrusted agent.
The service enforces validation before deriving or releasing usable
execution material.
CW-2.14.3 — Split-Key Authorization The next effect may require a
cryptographic key assembled from separate protected components. A
required component is released only after receipt validation.
CW-2.14.4 — Threshold Signature The successor operation may require a
threshold signature containing at least one validator- controlled
authorized contribution.
Das Expires 29 April 2027 [Page 84]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-2.14.5 — Cryptographic Command Authorization A controller may
require an authenticated command whose validity depends upon the
VAER.
CW-2.14.6 — Protected Data Release A subsequent information object
may remain encrypted until receipt-dependent cryptographic material
becomes available.
CW-2.14.7 — Cryptographic Identity Versus Cryptographic Gate The
validator identity is cryptographically authenticated. The
continuation gate may separately use cryptography or non-
cryptographic protected state. These are distinct implementation
choices.
CW-2.14.8 — Cryptographic Limitation Cryptographic material is not a
substitute for mandatory effectuation-path coverage.
8.3.28. Source global page 90
If the same consequence can be produced without the required
cryptographic procedure, that alternate path must be separately
controlled before non-bypassability can be claimed for it.
CW-2.15 — NON-CRYPTOGRAPHIC CAUSAL ENFORCEMENT
CW-2.15.1 — Protected Hardware Latch A hardware controller may
maintain a latch disabling a successor effect. A validator-
authenticated receipt causes the permitted latch transition.
CW-2.15.2 — Protected State Register A protected register may contain
the current phase and continuation status. The agent cannot
independently modify it.
CW-2.15.3 — Atomic State-Machine Transition The receipt acceptance
procedure may atomically consume a predecessor receipt and enable the
designated successor.
CW-2.15.4 — Secure Command Queue A command queue may refuse a
successor command until protected receipt-dependent state permits
dispatch.
CW-2.15.5 — Storage Controller Gate A protected storage controller
may withhold a consequential commit until a VAER-derived condition
exists.
CW-2.15.6 — Network Controller Gate A protected network controller
may withhold a later transmission pending accepted evidence from an
earlier bounded real network effect.
Das Expires 29 April 2027 [Page 85]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-2.15.7 — Actuator Controller Gate A physical actuator controller
may require a protected phase state enabled through actual-effect
receipt validation.
CW-2.15.8 — Transaction Controller Gate A transactional system may
refuse a successor commit unless the correct accepted predecessor
receipt is present in authoritative protected state.
CW-2.15.9 — Single Protected Component The receipt may be accepted
and consumed entirely within one protected controller without a
separately exported token.
8.3.29. Source global page 91
CW-2.15.10 — Required Security Property The effectuation component
must actually enforce the protected state. A state variable
modifiable by an untrusted agent is insufficient to establish non-
bypassable receipt- gated authority.
CW-2.16 — GENERALIZED CONTINUATION PREDICATE A principal continuation
predicate may be expressed as: CONTINUE[i+1] =
VALID_PREDECESSOR_EFFECT[i] AND VALID_IEV_IDENTITY[i] AND
VALID_IEV_ACCEPTED_RECEIPT[i] AND VALID_PHASE_LINEAGE[i+1] AND
VALID_SUCCESSOR_SCOPE[i+1] AND VALID_CURRENT_AUTHORITY[i+1] AND
VALID_SINK_BINDING[i+1] AND VALID_CONSUMPTION_STATE[i+1] The receipt
must not merely be present as data. It must satisfy the actual
sink's protected causal release protocol. Where any mandatory
predicate is absent, invalid, or unsupported, the successor effect
remains withheld.
CW-2.17 — IMPLEMENTABLE REFERENCE PSEUDOCODE
CW-2.17.1 — Validator Enrollment FUNCTION ENROLL_VALIDATOR(
validator_instance, authorized_role, protected_identity_authority ):
REQUIRE VERIFY_VALIDATOR_BOUNDARY( validator_instance ) credentials =
PROVISION_PROTECTED_CRYPTOGRAPHIC_IDENTITY( validator_instance )
REQUIRE VERIFY_KEY_POSSESSION( validator_instance, credentials )
8.3.30. Source global page 92
identity = protected_identity_authority.REGISTER({
unique_validator_id: NEW_ENROLLED_IDENTIFIER(), verification_key:
credentials.public_verification_key, authorized_role:
authorized_role, authority_epoch: CURRENT_AUTHORITY_EPOCH(),
credential_generation: CURRENT_KEY_GENERATION() }) REQUIRE identity
== COMMITTED RETURN identity
Das Expires 29 April 2027 [Page 86]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-2.17.2 — Initial Phase Admission FUNCTION ADMIT_PHASE(
candidate_act, phase_descriptor, protected_policy ): REQUIRE
PED.VERIFY_INITIAL_AUTHORITY( candidate_act, protected_policy )
REQUIRE PED.VERIFY_PHASE_SCOPE( phase_descriptor ) hold =
ESTABLISH_REQUIRED_NON_EFFECTIVE_HOLD( candidate_act ) IF hold !=
VERIFIED: RETURN DENY RETURN PED.COMMIT_PHASE_ADMISSION({
candidate_act: HASH(candidate_act), phase: HASH(phase_descriptor),
8.3.31. Source global page 93
state: HELD, protected_attempt_reference: NEW_PROTECTED_REFERENCE()
})
CW-2.17.3 — First Real Effect FUNCTION EXECUTE_FIRST_EFFECT(
candidate_act, first_sink ): actual_operation =
first_sink.RECONSTRUCT_ACTUAL_PENDING_OPERATION() REQUIRE
first_sink.VERIFY_SCOPED_AUTHORITY( candidate_act, actual_operation )
consumption = first_sink.ATOMIC_CONSUME_REQUIRED_AUTHORITY() IF
consumption != SUCCESS: RETURN DENY attempt =
first_sink.EFFECTUATE(actual_operation)
RECORD_PROTECTED_ATTEMPT(attempt) RETURN attempt
CW-2.17.4 — Actual-Effect Receipt Formation FUNCTION
FORM_EFFECT_RECEIPT( predecessor_phase, effect_attempt, observation
): witness = QUALIFY_EFFECT_WITNESS( observation.source ) IF witness
IS INVALID: RETURN OUTCOME_UNKNOWN outcome =
CLASSIFY_SUPPORTED_ACTUAL_EFFECT( observation,
8.3.32. Source global page 94
predecessor_phase.required_outcome ) receipt = PROTECTED_COMMIT({
predecessor: HASH(predecessor_phase), attempt: HASH(effect_attempt),
witness_identity: witness.identifier, outcome: outcome, observation:
HASH(observation), protected_sequence: NEXT_PROTECTED_SEQUENCE() })
RETURN receipt
CW-2.17.5 — Authorized IEV Receipt Acceptance FUNCTION
IEV_ACCEPT_RECEIPT( validator_identity, effect_receipt,
predecessor_phase, successor_phase ): REQUIRE
VERIFY_ENROLLED_IEV_IDENTITY( validator_identity ) REQUIRE
VERIFY_IEV_AUTHORIZED_ROLE( validator_identity, predecessor_phase,
successor_phase ) REQUIRE VERIFY_EFFECT_RECEIPT_AUTHENTICITY(
effect_receipt ) REQUIRE VERIFY_PREDECESSOR_BINDING( effect_receipt,
predecessor_phase )
Das Expires 29 April 2027 [Page 87]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
8.3.33. Source global page 95
REQUIRE VERIFY_REQUIRED_REAL_EFFECT( effect_receipt,
successor_phase.required_predecessor_outcome ) REQUIRE
VERIFY_SUCCESSOR_SCOPE( successor_phase ) REQUIRE
VERIFY_CURRENT_POLICY_AND_REVOCATION() accepted_state =
IEV.ATOMIC_COMMIT({ accepted_receipt: HASH(effect_receipt),
validator_identity: validator_identity.identifier, successor:
HASH(successor_phase), successor_sink: successor_phase.sink_id,
decision: ACCEPT, consumption_reference: NEW_PROTECTED_REFERENCE(),
phase_counter: NEXT_PROTECTED_COUNTER() }) IF accepted_state !=
COMMITTED: RETURN DENY RETURN AUTHENTICATE_AS_IEV(
validator_identity, accepted_state )
CW-2.17.6 — Protected Receipt Delivery FUNCTION
PROVIDE_RECEIPT_TO_SINK( validator_accepted_receipt, successor_sink
): REQUIRE VERIFY_VALIDATED_RECEIPT_AUTHENTICATION(
validator_accepted_receipt )
8.3.34. Source global page 96
delivery = AUTHENTICATED_DELIVER_OR_REGISTER(
validator_accepted_receipt, successor_sink.identifier ) IF delivery
!= SUCCESS: RETURN RECEIPT_UNAVAILABLE RETURN
delivery.authoritative_receipt_reference
CW-2.17.7 — Next Finality Sink Enforcement FUNCTION
EFFECTUATE_SUCCESSOR( successor_candidate_act,
accepted_receipt_reference, successor_sink ): actual_operation =
successor_sink.RECONSTRUCT_PENDING_OPERATION() IF actual_operation IS
NULL: RETURN DENY vaer =
successor_sink.RESOLVE_AUTHORITATIVE_RECEIPT(
accepted_receipt_reference ) REQUIRE
successor_sink.VERIFY_IEV_IDENTITY( vaer.validator_identity ) REQUIRE
successor_sink.VERIFY_IEV_CRYPTOGRAPHIC_AUTH( vaer ) REQUIRE
successor_sink.VERIFY_IEV_ROLE_AUTHORIZATION( vaer, actual_operation
) REQUIRE successor_sink.VERIFY_CAUSAL_PREDECESSOR( vaer,
successor_candidate_act ) REQUIRE
successor_sink.VERIFY_SUCCESSOR_BINDING( vaer, actual_operation )
REQUIRE successor_sink.VERIFY_CURRENT_AUTHORITY()
8.3.35. Source global page 97
REQUIRE successor_sink.VERIFY_CCC( vaer, actual_operation )
consumption = successor_sink.ATOMIC_CONSUME( vaer, actual_operation )
IF consumption != SUCCESS: RETURN DENY RETURN
successor_sink.EFFECTUATE( actual_operation, consumption )
Das Expires 29 April 2027 [Page 88]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-2.17.8 — Cryptographic Continuation Enablement FUNCTION
RELEASE_CRYPTOGRAPHIC_ENABLEMENT( vaer, successor_act,
protected_key_service ): REQUIRE
VERIFY_AUTHORIZED_VALIDATOR_RECEIPT(vaer) REQUIRE
VERIFY_SUCCESSOR_SCOPE( vaer, successor_act ) REQUIRE
VERIFY_CURRENT_PROTECTED_STATE() result =
protected_key_service.DERIVE_OR_RELEASE({ accepted_receipt:
HASH(vaer), successor: HASH(successor_act), sink:
successor_act.sink_id, epoch: CURRENT_AUTHORITY_EPOCH(),
protected_counter: CURRENT_PHASE_COUNTER() })
8.3.36. Source global page 98
RETURN result The key service must maintain any necessary secret or
protected authority material inaccessible to the untrusted agent.
CW-2.17.9 — Non-Cryptographic Continuation Enablement FUNCTION
ACTIVATE_PROTECTED_CONTINUATION( vaer, protected_controller ):
REQUIRE VERIFY_AUTHORIZED_VALIDATOR_RECEIPT(vaer) REQUIRE
protected_controller.VERIFY_PHASE_LINEAGE() REQUIRE
protected_controller.VERIFY_RECEIPT_UNUSED() REQUIRE
protected_controller.VERIFY_CURRENT_AUTHORITY() transition =
protected_controller.ATOMIC_TRANSITION({ expected:
NEXT_PHASE_DISABLED, required_receipt: HASH(vaer), successor:
vaer.authorized_successor, new_state: NEXT_PHASE_ENABLED }) RETURN
transition
CW-2.17.10 — Failure Behavior If any required verification fails, the
successor effect remains disabled. An untrusted scheduler cannot
replace the failed step with an arbitrary success assertion.
CW-2.18 — GENERALIZED MULTI-PHASE CAUSAL ALGORITHM In a non-limiting
implementation, a parent workflow comprises multiple controlled
consequential phases. The initial phase is authorized separately.
For each subsequent phase, the protected controller identifies the
required predecessor effects. The controller obtains the applicable
validated receipts.
8.3.37. Source global page 99
The successor phase is not effectually enabled unless all mandatory
receipt-dependent conditions are satisfied. A generalized sequence
is: FOR EACH successor_phase: REQUIRE valid original or delegated
authority REQUIRE required predecessor receipts REQUIRE authorized
IEV acceptance REQUIRE authentic validator identities REQUIRE
protected causal lineage REQUIRE successor-specific scope REQUIRE
current finality state REQUIRE actual sink operation correspondence
ATOMICALLY consume required continuation authority EFFECTUATE
Das Expires 29 April 2027 [Page 89]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
successor phase OBSERVE actual effect where required PRODUCE next
receipt REPEAT A parent task may contain conditional branches,
parallel operations, nested phases, or distributed control. The
protected causal dependency applies to each operation for which the
corresponding receipt-
gated condition is mandatory.
CW-2.19 — PRINCIPAL PROTECTED INVARIANTS Invariant C1 — Real
Predecessor Effect: Where the required predecessor predicate concerns
an actual external effect, an unsupported agent prediction cannot
satisfy the predicate. Invariant C2 — Authorized Validator: The
required acceptance must originate from an IEV possessing a valid
cryptographically authenticated identity and appropriate role.
Invariant C3 — Receipt Dependency: The successor phase cannot obtain
or exercise valid effectuation enablement independently of the
required accepted receipt. Invariant C4 — Mandatory Sink
Enforcement: The successor Finality Sink verifies the receipt-
derived condition before effectuation.
8.3.38. Source global page 100
Invariant C5 — Physical-Placement Neutrality: The same causal
requirement applies whether the IEV is physically separate,
integrated, or distributed. Invariant C6 — No Validator
Impersonation: A copied VUID without valid cryptographic
authentication is insufficient. Invariant C7 — No Unauthorized
Substitution: A receipt from an unrelated validator, predecessor, or
successor does not satisfy the required condition. Invariant C8 —
Operation Binding: The actual pending successor operation must match
the scope covered by the receipt-dependent authority. Invariant C9 —
Replay Control: A receipt cannot be reused beyond its authorized
consumption rules. Invariant C10 — Phase Ordering: Required
predecessor dependencies cannot be skipped. Invariant C11 — Non-
Bearer Scope: Possession of a raw or copied receipt does not
authorize
Das Expires 29 April 2027 [Page 90]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
arbitrary operations. Invariant C12 — Outcome Honesty: Unknown
remote outcomes are not treated as confirmed success or failure
without adequate evidence. Invariant C13 — Protected State
Integrity: Required continuation state cannot be directly rewritten
by the untrusted requesting entity. Invariant C14 — Controlled
Effectuation Coverage: Every effectuation route claimed to be non-
bypassable must enforce the required causal condition or be
constrained by an equivalent authoritative mechanism. Invariant C15
— Validator Revocation: A validator whose credentials or authority
are invalid cannot issue newly acceptable continuation receipts under
the applicable current trust policy. Invariant C16 — Recovery
Separation: Corrective actions remain separately authorized where
they produce new consequences.
Invariant C17 — No Retroactive Erasure: A completed real effect is
not made non-effective merely because a later receipt validation
fails. Invariant C18 — No Blockchain Dependence: The receipt-gating
mechanism does not require a ledger or append-only blockchain.
CW-2.20 — CRASH, REPLAY, AND REVOCATION HANDLING
CW-2.20.1 — Crash Before First Effect The first consequential
operation remains non-effective where required authorization was not
completed.
CW-2.20.2 — Crash After First Effect The system preserves the
effectuation attempt reference.
8.3.39. Source global page 101
A local crash does not imply that the external consequence failed.
CW-2.20.3 — Crash Before Receipt Formation The outcome remains
unresolved until suitable evidence can be obtained.
CW-2.20.4 — Crash During IEV Acceptance An incomplete validation
procedure does not automatically establish next-phase authority.
CW-2.20.5 — Crash After Accepted Receipt The system may recover the
VAER and its protected consumption state.
CW-2.20.6 — Crash During Receipt Delivery The successor sink may
retrieve the receipt again from an authoritative source. Repeated
receipt transport does not independently authorize repeated effects.
CW-2.20.7 — Crash After Authority Consumption The system does not
automatically restore consumed authority. The actual successor
attempt is reconciled before potentially duplicative retry.
Das Expires 29 April 2027 [Page 91]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-2.20.8 — Validator Unavailability Where a required IEV is
unavailable, the dependent successor phase remains withheld unless an
expressly authorized alternate validator satisfies the same protected
requirements.
CW-2.20.9 — Validator Revocation Revocation state is checked
according to the applicable protected policy and relevant
effectuation time.
CW-2.20.10 — Protected-State Rollback Protected epochs, counters,
secure storage, or equivalent techniques prevent unauthorized
restoration of previously consumed continuation authority.
CW-2.20.11 — Unknown Outcome An unresolved earlier effect is
represented honestly as uncertain. Any dependent successor requiring
confirmed completion remains disabled.
CW-2.20.12 — Remote Reconciliation Where supported, the system may
obtain authenticated remote state, controller evidence, or another
qualified observation to resolve the attempt.
8.3.40. Source global page 102
CW-2.21 — RECOVERY AND COMPENSATING EFFECTS A recovery operation may
be required after partial, mismatched, or uncertain effectuation.
The recovery operation is represented as a separate Candidate Act
when it produces another consequential effect. The recovery
operation may have its own protected authority, required effect
observation, IEV validation, and finality conditions. A valid
receipt establishing an adverse effect may enable a narrowly
authorized recovery branch. The receipt does not automatically
confer unrestricted corrective authority. A compensating financial
transaction does not necessarily erase the first transaction. A
corrective message does not necessarily retract previously disclosed
information. A physical recovery movement does not necessarily
reverse all earlier physical consequences.
The architecture records the actual resulting state and applies new
protected causal dependencies where required.
CW-2.22 — BASIC UNDERSTANDABLE EXAMPLE: ONE REAL DEVICE EFFECT
ENABLES THE NEXT A user authorizes an autonomous controller to update
a group of devices. The protected task policy requires a bounded
real update on one designated device before broader deployment. The
first Finality Sink permits the authorized update to the test device.
The device actually applies the update. A qualified controller
produces authenticated evidence of the resulting software state. An
authorized IEV, identified by its enrolled cryptographic identity,
Das Expires 29 April 2027 [Page 92]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
verifies the evidence. The IEV produces a VAER bound to the update
operation, result, approved next deployment population, and
designated successor Finality Sink. The broader deployment authority
remains unavailable before this receipt acceptance. The successor
deployment sink verifies the IEV identity and VAER.
It also checks the actual update package and destination devices.
Only then does it permit the broader effect. If the test-device
receipt is missing, stale, forged, or generated by an unauthorized
validator, the broader deployment cannot proceed through the
protected controller.
8.3.41. Source global page 103
The receipt does not merely inform the agent that testing passed.
The accepted receipt is the necessary enabling factor for the next
real deployment.
CW-2.23 — EXAMPLE: PHYSICALLY ADDED VALIDATOR BETWEEN CONTROLLERS An
autonomous system operates through a protected network or hardware
command interface. A separate IEV appliance is installed between the
initial-effect observation source and the downstream effectuation
controller. The appliance has a VUID and cryptographic credentials
enrolled with the downstream Finality Sink. The first bounded
operation produces actual-effect evidence. The appliance validates
that evidence. It authenticates a successor-bound receipt. The
receipt is transmitted to the downstream controller. The controller
verifies the validator identity and receipt. The protected
controller refuses the next effect if the receipt is unavailable or
invalid. The system may be configured so that every claimed
protected path to the effectuation resource
terminates at a controller enforcing the same receipt requirement.
The security property arises from mandatory downstream verification,
not solely from the appliance's physical presence.
CW-2.24 — EXAMPLE: SINGLE CHIP WITH INTEGRATED VALIDATOR A protected
chip contains both the IEV and the effectuation controller. The IEV
is implemented as a logically distinguishable protected function with
an enrolled cryptographic identity. The chip performs an initial
bounded real effect. A protected observation function records the
actual result. The IEV validates the observation. A validator-
identity-bound acceptance event is committed to protected chip state.
The effectuation controller verifies the corresponding accepted
state. The next command remains disabled until that state exists.
Das Expires 29 April 2027 [Page 93]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
8.3.42. Source global page 104
The internal communication may occur through protected registers or
memory rather than an external signed message. The validator's
enrolled cryptographic identity remains part of the protected trust
relationship. The arrangement demonstrates that separate physical
devices are not necessary to implement receipt-dependent causal
authority.
CW-2.25 — EXAMPLE: CLOUD, REMOTE SERVICE, AND CROSS-DOMAIN VALIDATOR
An autonomous agent requests a bounded real cloud-resource operation.
The controlled first operation produces an authenticated resource-
state record. A remotely located IEV validates the record. The IEV
possesses a registered cryptographic identity authorized for the
relevant effect class. It authenticates a receipt identifying the
verified resource, actual state, and permitted next operation. A
successor Finality Sink located in another computing domain retrieves
the receipt through a protected service. The sink verifies the IEV
identity, predecessor outcome, operation binding, and current
authority. Only then does the next cloud operation become effective.
The arrangement may span multiple devices or administrative domains
without requiring one
central physical security appliance.
CW-2.26 — EXAMPLE: ROBOTIC CAUSAL PHASE CONTROL A robotic actuator is
authorized to move through successive bounded positions. The first
actuator controller permits an initial real movement. A protected
position sensor measures the resulting state. An IEV validates the
measured position under the applicable tolerance predicate. The
validator produces an authenticated accepted receipt. The protected
actuator controller receives the receipt or corresponding protected
state. A hardware latch for the next movement remains disabled until
the receipt-dependent condition is satisfied. The next command is
independently checked against actual current actuator state. If the
first movement did not reach the required position, the next movement
remains unavailable.
8.3.43. Source global page 105
The receipt therefore directly participates in enabling the later
physical consequence.
CW-2.27 — ADVERSARIAL AND DESIGN-AROUND-RESISTANCE VARIATIONS The
following examples illustrate different attempts to avoid the
required causal enforcement mechanism and the corresponding protected
implementation alternatives. Variation 1 — Replace Separate
Validator with Integrated Software A system may combine validation
Das Expires 29 April 2027 [Page 94]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
and effectuation within one protected service. The causal property
remains implemented where the effectuation function requires
authenticated validator-accepted state inaccessible to the untrusted
agent. Variation 2 — Replace Cryptographic Key Release with Hardware
State The next operation may be enabled through a protected hardware
register instead of a newly derived key. The relevant continuation
still depends upon receipt acceptance. Variation 3 — Replace
Transferable Receipt with Internal State
A system may avoid exporting a receipt object. A protected internal
acceptance event may nevertheless constitute the required receipt
when it is authenticated to the validator identity and enforced by
the successor sink. Variation 4 — Move the Validator to the
Destination The IEV may reside in the remote recipient or device.
The destination-side Finality Sink requires its validated receipt
before completing the successor consequence. Variation 5 — Use
Multiple Validators A protected threshold of authorized validators
may jointly establish the receipt acceptance condition. Variation 6
— Use a Distributed Validator Service Validation may be performed
across several protected servers. The successor sink authenticates
the accepted result according to the authorized validator group and
current trust policy.
Variation 7 — Use a Hardware Interlock A receipt may activate a
protected interlock. The physical effectuation path remains
dependent upon accepted prior-effect evidence.
8.3.44. Source global page 106
Variation 8 — Use a Secure Command Queue A subsequent command may
remain in a protected non-effective queue until the receipt-dependent
state permits release. Variation 9 — Use a Transaction Controller A
database or transactional resource controller may require the
validated predecessor receipt before committing a successor state
change. Variation 10 — Use a Cryptographic Threshold Share An IEV-
controlled share may be necessary to authenticate the next operation.
Variation 11 — Use a Credential Activation Mechanism The relevant
credential may remain unusable for the successor effect until the
accepted receipt condition exists. Variation 12 — Use a Protected
Capability The VAER may directly enable a scoped non-bearer execution
handle. Variation 13 — Use an Internal Device Security System
A phone, computer, or embedded device may provide an internal
protected validator with enrolled cryptographic identity. The
relevant effectuation controller verifies the receipt-dependent
continuation state. Variation 14 — Use an External Security Module A
dedicated appliance or hardware module may validate effects and
transmit authenticated receipts to a downstream sink. Variation 15 —
Das Expires 29 April 2027 [Page 95]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Use a Remote Witness The effect evidence may originate from a remote
authenticated source, provided its observation capability satisfies
the required predicate. Variation 16 — Use a Signed Event Instead of
a Receipt File An authenticated event may represent the accepted
receipt without being called a receipt by the implementation. Its
technical role remains the establishment of the required causal
continuation condition.
Variation 17 — Use Protected Memory Instead of a Token A protected
memory state may embody the validator acceptance. The successor
effectuation function requires that state.
8.3.45. Source global page 107
Variation 18 — Use a Counter Instead of a Stored Receipt Chain A
protected phase counter may advance only after authenticated receipt
acceptance. The next effect requires the correct counter and
operation binding. Variation 19 — Use a Direct IEV-to-Sink Interface
The validator may communicate directly with the final controller
without an intermediary capability issuer. Variation 20 — Use a
Separate Authority Issuer The IEV may authenticate receipt acceptance
to a protected authority issuer, which generates the required next-
phase capability. The capability remains causally dependent upon the
accepted receipt. Variation 21 — Use One Component for IEV and
Authority Issuance The IEV may directly issue the next scoped
authority upon successful receipt acceptance. Variation 22 — Use One
Component for All Functions
The entire protocol may be implemented inside one protected
controller with distinguishable authority and state transitions.
Variation 23 — Replace an Agent with Another Autonomous Workload The
requesting entity may be an operating-system service, application,
autonomous controller, robotic process, or other effect-capable
computational entity. The same protected causal condition may apply.
Variation 24 — Different Physical Finality Sink The first and second
consequential effects may be enforced by different kinds of sinks,
including a storage controller followed by a network gateway.
Variation 25 — Same Finality Sink Across Phases One sink may execute
several causally ordered phases, enforcing a distinct receipt-
dependent authorization for each. Variation 26 — Human-Approved
Branch
An authorized user may approve a particular next operation under CW-
3. Where prior actual-effect evidence is mandatory, the receipt
requirement remains enforced. Variation 27 — Automated Remediation
Branch A protected policy may authorize a narrow recovery operation
after a validated failure receipt.
Das Expires 29 April 2027 [Page 96]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
8.3.46. Source global page 108
Variation 28 — No Public Ledger The causal receipt may be transient
and locally protected, without any blockchain or distributed ledger.
These variations describe technical alternatives. Their inclusion
does not by itself establish that every conceivable implementation
falls within a particular patent claim. Claim coverage depends upon
the operative limitations, original disclosure support, and
applicable patent law.
CW-2.28 — NON-LIMITING FEASIBILITY EXPERIMENTS The following
experiments are proposed and are not represented as having been
performed. Experiment 1 — No Receipt: Attempt a successor effect
before generating the required predecessor receipt. Verify
rejection. Experiment 2 — No Validator Acceptance: Provide a raw
effect receipt without IEV acceptance. Verify rejection. Experiment
3 — Valid Accepted Receipt: Provide the correct VAER and verify
permitted scoped continuation. Experiment 4 — Wrong Validator:
Submit a receipt authenticated by a different unauthorized validator.
Verify rejection. Experiment 5 — Copied Validator Identifier: Copy
the correct VUID but use unrelated cryptographic credentials. Verify
rejection. Experiment 6 — Revoked Validator: Revoke an IEV and
verify enforcement of current
revocation policy. Experiment 7 — Wrong Predecessor: Use a genuine
receipt from another earlier operation. Verify rejection.
Experiment 8 — Wrong Successor: Reuse an accepted receipt for a
different next-phase Candidate Act. Verify rejection. Experiment 9 —
Wrong Sink: Deliver the receipt to an unauthorized Finality Sink.
Verify rejection where sink binding is required. Experiment 10 —
Receipt Replay: Reuse a single-use accepted receipt. Verify
protected consumption. Experiment 11 — Phase Skipping: Attempt Phase
3 without the required Phase 2 receipt. Verify refusal. Experiment
12 — Hardware Latch: Verify that the next actuator latch remains
disabled before receipt acceptance. Experiment 13 — Cryptographic
Key Release: Verify that the required next-phase key material is
unavailable before accepted receipt validation.
8.3.47. Source global page 109
Experiment 14 — Protected State Transition: Verify that an agent
cannot directly activate the receipt-dependent continuation state.
Experiment 15 — Physically Separate IEV: Install a validator as a
separate appliance and verify authenticated receipt-to-sink control.
Experiment 16 — Integrated IEV: Combine validator and sink in a
protected controller while preserving the required causal conditions.
Experiment 17 — Distributed IEV: Perform receipt validation remotely
and verify cross-domain identity authentication. Experiment 18 —
Das Expires 29 April 2027 [Page 97]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Multiple Validators: Require a protected threshold of distinct
validator identities. Experiment 19 — Remove Application Receipt
Check: Bypass the ordinary workflow-level receipt check and confirm
that protected sink enforcement still prevents unauthorized
effectuation.
Experiment 20 — Alternate API: Attempt a covered effect through
another software interface and verify enforcement of the same receipt
condition. Experiment 21 — Alternate Hardware Path: Test whether
direct hardware access bypasses the asserted protected controller and
identify any uncovered paths. Experiment 22 — False Outcome
Evidence: Supply evidence proving only dispatch where the successor
requires actual external completion. Verify rejection. Experiment
23 — Partial Effect: Produce a bounded partial effect and verify the
specified limited continuation behavior. Experiment 24 — Unknown
Outcome: Lose an acknowledgement after a real external effect and
verify safe uncertainty handling. Experiment 25 — Crash After
Accepted Receipt: Recover receipt state without duplicating
continuation authority.
Experiment 26 — Concurrent Receipt Use: Attempt simultaneous reuse of
one single-use VAER and verify atomic consumption. Experiment 27 —
Validator Key Rotation: Rotate the IEV's credentials and verify
current trust- state enforcement. Experiment 28 — Validator
Replacement: Replace a failed validator only through authorized
enrollment. Experiment 29 — Multi-Phase Real Execution: Execute
multiple phases, each enabled by the required preceding accepted
receipt. Experiment 30 — No Blockchain: Demonstrate the complete
causal protocol using a protected local receipt and sink, without a
ledger.
CW-2.29 — PHOSITA REFERENCE IMPLEMENTATION
8.3.48. Source global page 110
A reference implementation may comprise a controlled autonomous
workload, a first effectuation gateway, a protected actual-effect
observer, a cryptographically identified IEV, an authenticated
receipt service, and a successor Finality Sink. A protected
validator identity may be established through an enrolled asymmetric
signing key and an authorized role record. The effect observer may
generate an authenticated transaction or controller-completion
record. The IEV may validate the record against the authorized phase
descriptor. The accepted result may be authenticated using the IEV's
protected key. The successor sink may verify the signature, enrolled
validator role, predecessor phase, successor operation, and current
protected consumption state. A transactional database or protected
controller may maintain receipt-consumption and phase-
Das Expires 29 April 2027 [Page 98]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
transition state. The successor effectuation interface must deny
commands that lack the required valid receipt- dependent
authorization. A software prototype may initially demonstrate the
protocol under an expressly defined software trust model. A hardware
implementation may additionally provide protected keys, non-
bypassable command routing, secured registers, or isolated state. No
blockchain infrastructure is necessary for this reference
implementation.
CW-2.30 — TECHNICAL EFFECTS
CW-2.30.1 — Enforced Causal Progression The next real effect cannot
proceed through the protected effectuation path without accepted
evidence of the required prior effect.
CW-2.30.2 — Validator Provenance The sink can determine which
authorized validator accepted the receipt.
CW-2.30.3 — Protection Against Validator Impersonation A copied
identifier or forged success message does not satisfy required
cryptographic authentication.
CW-2.30.4 — Protection Against Receipt Replay Protected phase and
consumption state may prevent unauthorized repeated effects.
CW-2.30.5 — Protection Against Operation Substitution
8.3.49. Source global page 111
The receipt is bound to the permitted successor operation and actual
sink verification.
CW-2.30.6 — Physical-Topology Independence The required causal
relationship can be enforced through integrated or distributed
protected components.
CW-2.30.7 — Reduced Advisory-Check Bypass The effectuation authority
is controlled by the sink rather than merely by a workflow-level
decision.
CW-2.30.8 — Protected Recovery Uncertain or partial effects can be
contained without automatically repeating the same consequence.
CW-2.30.9 — Controlled Autonomous Progression The system may permit
automatic phase advancement when authenticated actual-effect evidence
satisfies the applicable protected predicates.
Das Expires 29 April 2027 [Page 99]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-2.31 — DISTINCTION FROM CONVENTIONAL TECHNIQUES AND INVENTIVE-
STEP FOCUS
CW-2.31.1 — Conventional Workflow Scheduler A scheduler may start the
next job after the prior job reports completion. The proposed
stronger arrangement requires an accepted real-effect receipt to
establish the next operation's technical execution condition.
CW-2.31.2 — Conventional Receipt Checking An application may inspect
a receipt and decide to proceed. Such a check may remain bypassable
if the application retains independent access to the effectuation
primitive. The present implementation requires the actual Finality
Sink to enforce the receipt-dependent condition.
CW-2.31.3 — Conventional Audit Logging An audit record may describe
past activity. The VAER in the principal implementation contributes
directly to enabling a future protected effect. The receipt need not
be persisted as an audit log at all.
CW-2.31.4 — Conventional Blockchain Receipt A blockchain receipt may
provide evidence of inclusion or a transaction state within a ledger
system.
8.3.50. Source global page 112
CW-2 does not depend upon blockchain inclusion. The relevant receipt
authenticates validator acceptance and supplies a necessary causal
condition for subsequent controlled effectuation.
CW-2.31.5 — Conventional Digital Signature A signature authenticates
a statement or authorization under its trust assumptions.
CW-2 additionally binds the validator's authorized identity, required
prior actual-effect evidence, successor scope, and mandatory final
enforcement relationship. Digital signatures themselves are not
claimed as new.
CW-2.31.6 — Conventional Hardware Interlock Hardware interlocks are
established techniques. The potentially distinctive combination is a
protected effectuation interlock whose permitted transition depends
upon receipt acceptance by an authorized cryptographically identified
IEV concerning a specific prior real effect.
CW-2.31.7 — Conventional Distributed Transaction A distributed
transaction protocol may coordinate participating transactional
operations.
Das Expires 29 April 2027 [Page 100]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-2 may govern causally ordered real effects across systems that
cannot participate in one atomic transaction.
CW-2.31.8 — Conventional Canary Testing A canary deployment may
evaluate an initial rollout before broader release. The proposed
stronger embodiment requires the actual broader deployment authority
to depend upon accepted effect evidence from the earlier bounded
rollout.
CW-2.31.9 — Candidate Objective Technical Problem An illustrative
objective technical problem is: How to enforce a protected, non-
bypassable causal dependency between a bounded earlier real
consequential effect and a subsequent consequential effect, such that
the subsequent effectuation authority cannot become usable without an
accepted prior-effect receipt authenticated to an authorized
identifiable validator and verified at the actual successor Finality
Sink, across integrated, physically separated, and distributed
computing arrangements.
CW-2.31.10 — Candidate Inventive Technical Kernel A potentially
significant technical combination comprises: An earlier bounded
authorized real effect;
8.3.51. Source global page 113
A qualified observation of that effect; An IEV having a
cryptographically verifiable authorized identity; A validator-
accepted receipt bound to the earlier effect and permitted successor;
A protected causal condition whose establishment depends upon that
receipt; And a successor Finality Sink that independently verifies
and enforces the receipt-dependent condition before permitting the
actual next effect. The strength of a particular patent claim
depends upon which of these features are essential and how they
differ from relevant prior art. The arrangement is not established
as novel merely by employing new terminology for receipt checking,
protected keys, staged execution, or hardware interlocks.
Das Expires 29 April 2027 [Page 101]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-2.32 — ADDITIONAL IMPLEMENTATION VARIANTS Variant A — Validator
Physically Before the Finality Sink: The IEV authenticates the result
to a downstream sink. Variant B — Validator Physically After the
Earlier Sink: The IEV validates actual-effect evidence from the
preceding sink or affected resource. Variant C — Validator
Integrated with Successor Sink: An internal protected validation
function establishes receipt state. Variant D — Validator Integrated
with Earlier Sink: The preceding controller hosts the IEV, while the
next sink independently verifies its authenticated receipt. Variant
E — Remote Validator: A separate domain hosts the IEV. Variant F —
Multiple Validators: Several authorized identities contribute to
receipt acceptance. Variant G — Validator Threshold: A configured
threshold must be satisfied.
Variant H — Cryptographic Key Release: The accepted receipt unlocks
missing execution material. Variant I — Protected State Transition:
The accepted receipt advances a required controller state. Variant J
— Hardware Latch: The accepted receipt enables a bounded actuator
operation. Variant K — Direct Receipt Capability: The VAER directly
carries scoped successor authority. Variant L — Split Receipt and
Capability: The VAER enables separate scoped authority. Variant M —
Protected Receipt Reference: The sink retrieves a protected state
reference. Variant N — Non-Exportable Receipt: Acceptance remains
inside protected hardware or memory. Variant O — Cross-Device
Receipt: The validated receipt travels between devices.
8.3.52. Source global page 114
Variant P — Cross-Domain Receipt: The receipt crosses administrative
domains through authenticated interfaces. Variant Q — Receipt-
Dependent Credential Release: Protected credentials are released or
activated only for the permitted successor. Variant R — Receipt-
Dependent Storage Commit: A later write or publication requires
validated prior-effect evidence. Variant S — Receipt-Dependent
Network Transmission: A later transmission depends upon the validated
receipt. Variant T — Receipt-Dependent Physical Actuation: A later
physical command requires the accepted receipt. Variant U —
Conditional Branching: Distinct verified outcomes enable distinct
preauthorized next effects. Variant V — Partial-Effect Recovery: A
limited actual result enables only a specifically authorized recovery
branch.
Variant W — Identity Rotation: Validator signing credentials may be
updated through protected enrollment. Variant X — Validator
Failover: A replacement validator may be accepted under current
protected trust rules. Variant Y — Single-Use Receipt: The receipt
enables one bounded successor act. Variant Z — Bounded Multi-Use
Receipt: The receipt permits an explicitly controlled successor set
Das Expires 29 April 2027 [Page 102]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
with protected consumption limits. Variant AA — In-Line Validation:
A cryptographically identified IEV validates a pending operation
before its first actual effect. Variant AB — Inter-Phase Validation:
An IEV accepts real-effect evidence to enable the next phase.
Variant AC — Combined Validation: Both modes operate within the same
controlled workflow. Variant AD — Local Controller-Only
Implementation: All causal state is maintained within one
protected device. Variant AE — Distributed State Implementation:
Authoritative protected continuation state is coordinated across
several domains. Variant AF — No Ledger Implementation: No
blockchain or distributed ledger is used. Variant AG — Hardware-Only
Effect Gate: The next effect is enabled by protected hardware state
after cryptographically authenticated IEV acceptance. Variant AH —
Software-Mediated Effect Gate: An isolated protected service enforces
the receipt dependency under the defined software trust model.
8.3.53. Source global page 115
Variant AI — Hybrid Effect Gate: Cryptographic identity, protected
state, and hardware final enforcement are combined. These
implementations are non-limiting.
CW-2.33 — RELATIONSHIP TO EMBODIMENTS 1–40
CW-2 provides a common reference mechanism for specialized
embodiments requiring protected validation between consequential
phases. Embodiment 1 may use actual-effect receipts to advance
protected cross-agent effect reservations. Embodiment 2 may provide
further specific implementation of identity-authenticated receipt-
constituted continuation. Embodiment 3 may use protected semantic
and referent correspondence to ensure that the actual effect concerns
the authorized user-referenced object. Embodiment 4 may provide
cross-domain actual-consequence witnessing to strengthen the evidence
underlying a receipt. Other embodiments may introduce additional
protected technical predicates concerning privacy, resource
allocation, delegated authority, device migration, command integrity,
recovery, or physical
actuation. Such additional predicates do not automatically replace
the required receipt-dependent causal condition where that condition
is mandatory.
CW-2.34 — SUPPORT FOR POTENTIAL CLAIM LIMITATIONS The present
disclosure provides technical support for considering claim
limitations concerning: A protected causal sequence of bounded real
consequential operations. An IEV possessing an enrolled
cryptographically verifiable identity. A validator identity uniquely
Das Expires 29 April 2027 [Page 103]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
distinguishable within an authenticated trust namespace. A protected
validator authorization profile. A receipt generated from qualified
evidence of an earlier actual effect. A validator-accepted receipt
authenticated to the authorized IEV. A successor Finality Sink
required to verify the receipt. Receipt delivery by direct
communication, protected state, or authenticated reference. An
indispensable receipt-dependent next-phase execution condition.
Direct receipt-constituted scoped finality authority.
8.3.54. Source global page 116
Receipt-dependent key derivation or release. Receipt-dependent
hardware latch activation. Receipt-dependent protected transaction
state. Protected phase ordering and anti-replay consumption.
Mandatory actual-operation verification at the successor Finality
Sink. Physically separate validator implementations. Integrated
single-component validator implementations. Distributed and cross-
domain validator implementations. Multiple validator identities and
threshold acceptance. Validator replacement, rotation, revocation,
and protected enrollment. Unknown-outcome reconciliation.
Separately authorized recovery. No requirement for blockchain or
ledger storage. The exact claim structure must be selected with
reference to disclosure support and prior-art examination.
CW-2.35 — INDUSTRIAL APPLICABILITY AND PHOSITA IMPLEMENTATION The
disclosed causal receipt-gated architecture may be industrially
implemented wherever a later consequential operation must depend upon
accepted evidence of an earlier real effect. In cloud
infrastructure, a bounded deployment may generate the receipt
required for a broader deployment. In autonomous device management,
a verified initial configuration change may enable subsequent
activation. In telecommunications, accepted evidence of a protected
limited network-state transition may become necessary for further
control-plane changes. In financial systems, a qualified prior
transaction-state receipt may enable a separately authorized
subsequent accounting or payment-related consequence. In industrial
robotics, actual position evidence accepted by an identified IEV may
activate the next
bounded movement. In protected storage, a verified initial commit
may create the necessary condition for publication or external
export.
Das Expires 29 April 2027 [Page 104]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
8.3.55. Source global page 117
In secure communications, a bounded recipient-side actual-effect
receipt may enable subsequent protected data release. In enterprise
AI workflows, an authenticated earlier operation result may provide
the causal authority required for a dependent external act. A
PHOSITA may implement the architecture using authenticated
identities, protected state machines, cryptographic keys, controlled
effectuation interfaces, transactional state, hardware registers,
protected message delivery, or equivalent techniques. The technical
implementation must identify the authoritative validator identity,
actual-effect evidence source, receipt acceptance rule, successor
enabling mechanism, and final enforcement boundary. The system may
be constructed entirely within one protected component or across
multiple
connected protected components. The essential technical relationship
is the same.
CW-2.36 — FINAL NON-LIMITING TECHNICAL SUMMARY Common Workflow CW-2
discloses a protected causal-ordered effectuation system in which the
valid ability to perform a later consequential operation depends upon
independently accepted evidence from an earlier actual consequential
phase. An authorized bounded first effect is performed through a
designated Finality Sink. A qualified source obtains evidence
concerning the actual result. An Interim Effectuation Validator
having a cryptographically verifiable identity independently
evaluates that evidence. Successful acceptance is authenticated to
the validator identity and results in a Validator-Accepted Effect
Receipt or equivalent protected receipt state. The accepted receipt
is supplied to, retrieved by, or represented within protected state
verified by
the designated successor Finality Sink. The successor sink
authenticates the validator identity, prior-effect evidence
relationship, phase lineage, current authority, authorized successor
scope, and protected consumption state. The required accepted
receipt directly constitutes, enables, releases, activates, or
supplies the indispensable causal condition for subsequent
effectuation. The next consequential phase cannot validly occur
through the protected effectuation architecture before that receipt-
dependent condition exists. The architecture may be implemented
cryptographically through keys, signatures, authentication shares, or
protected capabilities. It may implement actual effectuation gating
through non-cryptographic protected state, hardware latches, command
registers, transactional control, or secure controller transitions
while retaining
Das Expires 29 April 2027 [Page 105]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
cryptographic validator identity authentication.
8.3.56. Source global page 118
The validator may be physically added as a separate protected device.
It may reside in an operating-system security component. It may
operate within protected firmware. It may be integrated into the
Finality Sink. It may be hosted remotely. It may be implemented
through multiple distributed validators. All functions may reside
within one protected processor or controller. The number and
physical arrangement of components do not define the essential causal
security property. The defining requirement is that the accepted
evidence from an authorized cryptographically identifiable validator
is a necessary technical condition for the next protected
consequential effect. A generic software success flag is not
sufficient. An ordinary agent self-report is not sufficient. A raw
unvalidated receipt is not sufficient.
A copied validator identity is not sufficient. An unrelated valid
receipt is not sufficient. A validator-authenticated receipt without
the required successor operation binding is not sufficient. A
correct receipt cannot authorize an effect outside its protected
scope. Where the mandatory receipt is absent, invalid, stale,
mismatched, unsupported, or unconsumed state cannot be established,
the dependent effect remains withheld or enters the applicable
protected recovery procedure. The system does not require blockchain
technology or a persistent distributed receipt ledger. The receipt's
essential function is operational and causal, not merely historical.
The principal proposed technical contribution of CW-2 is the creation
of an enforceable, validator-identity-authenticated causal
relationship in which an earlier bounded real effect
produces qualified evidence, an authorized IEV accepts that evidence,
and the resulting accepted receipt constitutes the indispensable
enabling factor for the next consequential effect at its actual
Finality Sink. This common technical relationship may be implemented
through integrated, physically separated, hardware-based, software-
protected, or distributed architectures, provided the claimed non-
bypassable causal enforcement property is actually achieved under the
defined trust and effectuation boundaries.
8.3.57. Source global page 119
The novelty and inventive step of particular claim combinations
remain subject to the relevant prior-art examination, and any
asserted filing priority remains limited to subject matter supported
by the relevant application as filed.
Das Expires 29 April 2027 [Page 106]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
END OF COMMON WORKFLOW CW-2 — COMPLETE DISCLOSURE.
COMMON WORKFLOW CW-3
OPTIONAL PROTECTED AUTONOMOUS-AGENT SCOPE-DEVIATION DETECTION,
INDEPENDENT SECURITY-SIGNAL CORRELATION, RISK-ADAPTIVE SUSPENSION,
AUTOMATED REVALIDATION, SECURE HUMAN REAUTHORIZATION, AND
FINALITY-SINK-BOUND EXECUTION CONTROL
CW-3.0 — GENERAL DESCRIPTION AND TECHNICAL PURPOSE The present
disclosure provides a Common Workflow, designated CW-3, for
detecting, evaluating, containing, and resolving potential deviations
by autonomous computational entities from an originally authorized
task, operation, purpose, resource scope, destination, delegation
boundary, or other protected authority condition. The workflow
applies to autonomous artificial-intelligence agents, on-device
assistants, operating- system services, application agents,
distributed orchestration frameworks, remote computational agents,
delegated tools, robotic controllers, enterprise automation systems,
and other entities capable of proposing or producing consequential
effects. In one non-limiting implementation, an autonomous agent
receives authority to perform a task
without requiring repeated human confirmation for every permitted
operation. The agent may thereafter perform authorized computation,
planning, tool use, and consequential operations according to the
applicable execution-finality architecture. During operation, one or
more independently operated monitoring, validation, or security
components observe relevant execution behavior, requested operations,
application-state changes, information flows, and protected
effectuation events. Where an observed operation appears
inconsistent with the originally authorized scope, a protected
deviation-detection mechanism generates an authenticated deviation
indication. The system then determines whether the indication
represents: 1. An operation that remains within the original
authorization; 2. A suspected deviation that can be resolved through
independent automated verification;
3. A proposed change that may be permitted following fresh user
authorization; 4. An operation requiring authorization from an
additional principal; 5. A mandatory security violation that must
remain denied;
Das Expires 29 April 2027 [Page 107]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
9. Common Workflow CW-3: Protected Scope-Deviation Reauthorization
This foundational workflow is grounded in original global source
pages 119–178 of the 3,567-page disclosure (first uploaded PDF). The
material below includes a technical architectural figure, operational
flowchart, and a page-indexed detailed transcription of source text.
Subsequent editing for a public standards-track proposal, if any,
must not change the semantics of the original disclosed optional and
mandatory mechanisms.
9.1. Architecture and Trust Boundaries
Diagram highlights the main protected relationships. It is an
interpretive overview, not a substitute for the full qualifications
in the page-indexed technical disclosure.
[Original authorized scope]
|
[Actual observed agent act]
|
[Protected scope-state check]
|
[Deviation evidence / latch]
|
[Independent adjudicator]
|
[Bounded scope delta]
|
[Protected reauthorization]
|
[Finality Sink validation]
|
[Controlled effect / refuse]
Figure 5: CW-3 protected component architecture
9.2. Operational Decision Flow
The flowchart illustrates the primary allow/withhold decision
sequence; additional branches, failure modes, and optional variants
are given in the following source-derived sections.
Das Expires 29 April 2027 [Page 108]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
[Observed operation differs?]
|
<Material deviation established?>--No-->[Check ordinary finality]
| Yes
[Hold Candidate Act non-effective]
|
<Permitted automatic resolution?>--Yes-->[Bounded scope validation]
| No
[Qualified human or source approval]
|
<Valid authority delta?>--No-->[Withhold]
| Yes
[Sink checks actual operation]
|
<Current effectual scope valid?>--No-->[Withhold]
| Yes
[Consume and effectuate]
Figure 6: CW-3 operation and security decision flowchart
9.3. Detailed Source-Derived Technical Disclosure
9.3.1. Source global page 119
The novelty and inventive step of particular claim combinations
remain subject to the relevant prior-art examination, and any
asserted filing priority remains limited to subject matter supported
by the relevant application as filed.
END OF COMMON WORKFLOW CW-2 — COMPLETE DISCLOSURE.
COMMON WORKFLOW CW-3
OPTIONAL PROTECTED AUTONOMOUS-AGENT SCOPE-DEVIATION DETECTION,
INDEPENDENT SECURITY-SIGNAL CORRELATION, RISK-ADAPTIVE SUSPENSION,
AUTOMATED REVALIDATION, SECURE HUMAN REAUTHORIZATION, AND
FINALITY-SINK-BOUND EXECUTION CONTROL
CW-3.0 — GENERAL DESCRIPTION AND TECHNICAL PURPOSE The present
disclosure provides a Common Workflow, designated CW-3, for
detecting, evaluating, containing, and resolving potential deviations
by autonomous computational entities from an originally authorized
task, operation, purpose, resource scope, destination, delegation
boundary, or other protected authority condition. The workflow
applies to autonomous artificial-intelligence agents, on-device
Das Expires 29 April 2027 [Page 109]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
assistants, operating- system services, application agents,
distributed orchestration frameworks, remote computational agents,
delegated tools, robotic controllers, enterprise automation systems,
and other entities capable of proposing or producing consequential
effects. In one non-limiting implementation, an autonomous agent
receives authority to perform a task
without requiring repeated human confirmation for every permitted
operation. The agent may thereafter perform authorized computation,
planning, tool use, and consequential operations according to the
applicable execution-finality architecture. During operation, one or
more independently operated monitoring, validation, or security
components observe relevant execution behavior, requested operations,
application-state changes, information flows, and protected
effectuation events. Where an observed operation appears
inconsistent with the originally authorized scope, a protected
deviation-detection mechanism generates an authenticated deviation
indication. The system then determines whether the indication
represents: 1. An operation that remains within the original
authorization; 2. A suspected deviation that can be resolved through
independent automated verification;
3. A proposed change that may be permitted following fresh user
authorization; 4. An operation requiring authorization from an
additional principal; 5. A mandatory security violation that must
remain denied;
9.3.2. Source global page 120
6. An unresolved condition for which the affected consequential
operation must remain withheld. The original agent is not permitted
to convert its own explanation of the deviation into execution
authority. The system may suspend the affected Candidate Act in a
Non-Effective State while protected adjudication occurs. Where the
condition can be resolved using sufficient authenticated evidence,
the system may permit the operation without interrupting the user.
Where fresh user authorization is appropriate, the system may present
an independently generated, authenticated description of the original
authorized operation and the proposed changed operation through a
trusted user interface. Where the user authorizes the proposed
change and all mandatory technical constraints remain satisfied, the
system generates or authorizes a new, appropriately scoped finality
authority.
The actual pending operation is then independently verified at its
designated Finality Sink. Where the user denies the request, the
approval expires, the user cannot be authenticated, or a mandatory
security condition fails, the affected consequential operation
Das Expires 29 April 2027 [Page 110]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
remains withheld. The workflow may allow unrelated, independently
authorized operations to continue when their execution does not
depend upon or undermine the suspended operation.
CW-3.0.1 — Fundamental Technical Principle An autonomous agent may
continue operating within its protected authorized scope, but a
detected possible departure from that scope does not become effective
merely because the agent proposes, explains, predicts, or internally
approves the departure. A scope deviation may be resolved
automatically only where the applicable protected verification
mechanism establishes that the operation is already permitted or
satisfies an explicitly preauthorized conditional rule. An operation
requiring genuinely new authority cannot obtain that authority solely
from an automated assertion of usefulness or safety.
CW-3.0.2 — Relationship to Common Workflows CW-1 and CW-2
CW-3 may employ the Candidate Act, Non-Effective State, Protected
Enforcement Domain, Finality Gate, Finality Sink, Protected
Validation Evidence Record, Scoped Finality Authority, and protected
state-management mechanisms disclosed in CW-1.
CW-3 may additionally employ the Interim Effectuation Validator,
Protected Effect Receipt, Phase Descriptor, Continuation Authority
Record, and independent phase-validation procedures disclosed in CW-
2.
CW-3 is optional. A system implementing CW-1 does not necessarily
require scope-deviation escalation for every operation.
9.3.3. Source global page 121
A system implementing CW-2 does not necessarily require human
involvement in every phase.
CW-3 may operate independently of the optional phased-effectuation
mechanisms where a single Candidate Act requires scope-deviation
verification. The workflow is not restricted to one operating
system, AI model, trusted execution environment, processor
architecture, user-interface framework, or commercial agent platform.
CW-3.1 — SPECIFIC TECHNICAL PROBLEM
CW-3.1.1 — Authorized Initial Task Followed by Scope Drift An
autonomous agent may initially operate within a legitimate user
request. During execution, the agent may encounter additional
information, invoke tools, modify its plan, access new resources,
delegate to another agent, or select a different execution pathway.
Das Expires 29 April 2027 [Page 111]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Some changes are legitimate steps required to complete the task.
Other changes may exceed the user's original authorization. For
example, a user may authorize an assistant to prepare an expense
report and transmit it to a designated accountant. During the task,
the agent may legitimately read selected expense records, calculate
totals, generate a report, and prepare the authorized message.
However, the agent might subsequently attempt to collect unrelated
contacts, access an unrelated
account, or transmit a larger collection of confidential records to
an additional destination. The additional operations may arise from
prompt injection, model error, compromised tool output, ambiguous
task interpretation, unexpected application behavior, unauthorized
delegation, or an intentionally malicious component. The technical
problem is to distinguish permissible task evolution from
impermissible authority expansion before the corresponding
consequence occurs.
CW-3.1.2 — Limitations of Static Permissions An application may
possess permission to read contacts, access files, communicate
through the network, or invoke other applications. Such permissions
do not necessarily establish that every operation using those
facilities falls within the user's current task authorization. An
agent may therefore possess an available technical capability that is
broader than the authority the user intended to delegate for one
task. The architecture must distinguish technical accessibility from
current task-specific execution authority.
CW-3.1.3 — Limitations of Conventional Risk Scoring
9.3.4. Source global page 122
A conventional security mechanism may classify actions as low-risk,
medium-risk, or high-risk. A high-risk action may trigger human
confirmation. However, a risk score does not necessarily establish
whether the actual operation departs from the specific scope
originally authorized by the user. A low-risk operation may be
outside the task. A high-risk operation may be explicitly authorized
and technically necessary. Accordingly, the present embodiment
distinguishes: Action risk from authorization-scope correspondence.
A scope-deviation decision may consider risk, but risk classification
alone is not the controlling technical predicate.
Das Expires 29 April 2027 [Page 112]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.1.4 — Limitations of Post-Event Monitoring Anomaly-detection
systems may identify suspicious activity after an operation has
already occurred. Such detection may support incident response but
cannot necessarily prevent completed external disclosure, payment,
message delivery, or physical actuation. Where prevention is
required, the detected deviation must be connected to a mandatory
enforcement boundary that can withhold the affected consequence.
CW-3.1.5 — Limitations of Agent-Generated Explanations An autonomous
agent may generate a plausible explanation for an unexpected
operation. However, the same compromised or mistaken agent may be
responsible for the deviation. An explanation generated by the
requesting model therefore cannot independently establish authority
to exceed the protected task scope. Model-produced explanations may
be retained as untrusted contextual evidence. They do not substitute
for protected verification or authenticated user authorization.
CW-3.1.6 — Human Approval as a Distinct Technical Problem A user may
legitimately wish to authorize a new operation discovered during task
execution. However, a simple approval dialog may be insufficient if:
• The displayed action differs from the actual operation; • The
requesting agent controls the approval text; • The destination
changes after approval;
9.3.5. Source global page 123
• The approved operation is replayed; • The approving user is not
authenticated; • The decision applies to a broader scope than the
displayed request; • The approval is reused by a different agent; •
The original authorization has been revoked; • A mandatory security
prohibition is incorrectly overridden. Accordingly, human approval
must be connected to a protected and verifiable authorization
procedure rather than treated as an unrestricted boolean permission.
CW-3.1.7 — Technical Objective The objective is to provide a
protected scope-continuity architecture in which an autonomous agent
may operate with minimal interruption while actual consequential
operations remain bounded by valid task authority. A further
objective is to ensure that detected deviations are independently
adjudicated and resolved through one of three enforceable outcomes:
1. Verified automatic continuation within already permitted scope;
2. Explicitly bounded reauthorization through an authenticated
principal; 3. Withholding or denial of the affected consequence.
CW-3.2 — PROPOSED TECHNICAL CONTRIBUTION The present disclosure
proposes a combination of mechanisms that may include: First, a
protected representation of the original task authority, including
applicable purpose, permitted effects, resources, destinations,
Das Expires 29 April 2027 [Page 113]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
delegations, and cumulative constraints. Second, an authenticated
observation mechanism that detects differences between permitted task
behavior and actual pending operations. Third, protected recording
of the specific observed deviation and the evidence supporting that
deviation. Fourth, a mandatory hold that prevents the affected
consequential operation from becoming effective during required
adjudication. Fifth, separation between an anomaly indication, proof
of noncompliance, and evidence sufficient to resolve a suspected
deviation.
Sixth, a protected automated verification path that may clear false-
positive detections or validate expressly preauthorized conditional
behavior without granting new authority beyond the applicable
authorization.
9.3.6. Source global page 124
Seventh, an independently controlled human reauthorization path that
presents the verified difference between the original scope and the
actual proposed operation. Eighth, generation of a new bounded
authorization only after satisfying applicable identity, consent,
scope, freshness, and protected-policy conditions. Ninth,
independent Finality Sink verification of the actual pending
operation against the resulting protected authorization. Tenth,
preservation of scope, approval, and consumption continuity across
crashes, retries, delegations, application changes, and other
relevant execution-state transitions. The specific potentially
inventive contribution is the enforceable relationship among these
mechanisms, rather than the general concept of asking a user to
approve an unusual action.
CW-3.3 — ADDITIONAL TECHNICAL DEFINITIONS
CW-3.3.1 — Original Authorized Scope Envelope (OASE) An Original
Authorized Scope Envelope is a machine-verifiable representation of
the original task- specific authority granted to an autonomous
computing entity. An OASE may bind permitted operations, resources,
destinations, purposes, principals, delegation constraints,
cumulative effect limits, authorization epochs, validity conditions,
and technical effectuation requirements. The OASE may comprise a
protected record, signed authorization structure, sealed handle, or
authenticated reference to protected state. An OASE is not
necessarily an interpretation of unrestricted natural-language text.
Where the user's instruction is ambiguous, the system may require
clarification or apply a conservatively bounded interpretation.
Das Expires 29 April 2027 [Page 114]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.3.2 — Protected Scope-State Accumulator (PSSA) A Protected
Scope-State Accumulator maintains authenticated state concerning
authority already exercised, pending effects, relevant resource
access, cumulative disclosure, delegation, and scope consumption.
The PSSA may be updated through verified Finality Sink events or
other authenticated operation observations.
CW-3.3.3 — Scope-Deviation Observation (SDO) A Scope-Deviation
Observation is an indication that an actual or proposed operation may
differ from the applicable protected task scope. An SDO may
originate from an operating-system security monitor, IEV, protected
dispatcher, application integrity monitor, information-flow monitor,
effectuation controller, or other observation source.
9.3.7. Source global page 125
An SDO is not automatically conclusive proof of unauthorized
behavior.
CW-3.3.4 — Scope-Deviation Evidence Bundle (SDEB) A Scope-Deviation
Evidence Bundle is an authenticated representation of a suspected
deviation. The SDEB may contain the original authorization
commitment, observed operation commitment, specific difference,
monitoring source, evidence assurance, current policy state, and
designated effectuation boundary.
CW-3.3.5 — Protected Deviation Latch (PDL) A Protected Deviation
Latch is a protected state condition that prevents an affected
Candidate Act or expressly identified dependent consequential
operation from crossing its Effectuation Boundary until an acceptable
resolution is committed.
CW-3.3.6 — Independent Scope Adjudicator (ISA) An Independent Scope
Adjudicator is a protected verification component configured to
classify a detected deviation and determine the applicable resolution
pathway. The ISA may comprise a deterministic policy engine, trusted
evidence verifier, protected state machine, or distributed protected
decision service. A machine-learning model may provide advisory
classifications but does not automatically acquire authority to grant
new scope.
CW-3.3.7 — Automated Scope Revalidation (ASR) Automated Scope
Revalidation is a protected procedure that determines whether a
detected suspicious operation remains within the existing
authorization or satisfies a specifically preauthorized conditional
rule. ASR does not necessarily require user interruption. ASR does
not independently grant arbitrary new authority.
Das Expires 29 April 2027 [Page 115]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.3.8 — Protected Scope Delta (PSD) A Protected Scope Delta is a
structured representation of the difference between an existing
authorized scope and a proposed operation or requested new scope. A
PSD may identify newly requested resources, destinations, effect
types, quantities, delegation rights, or other authority changes.
CW-3.3.9 — Trusted Approval Presentation Record (TAPR) A Trusted
Approval Presentation Record binds the operation and scope difference
presented to an authorized person to an authenticated approval
request. The TAPR may include a protected rendering commitment,
approved action digest, displayed resource scope, displayed
destination, expiry, and trusted interface identity.
9.3.8. Source global page 126
CW-3.3.10 — Protected Reauthorization Decision (PRD) A Protected
Reauthorization Decision is an authenticated determination by a
permitted authority principal concerning the specific additional or
changed operation. A PRD may authorize, deny, or request
modification of the proposed scope.
CW-3.3.11 — Scope-Delta Authorization (SDA) A Scope-Delta
Authorization is a newly established, bounded authorization resulting
from valid reauthorization or from a previously established
conditional authority rule. The SDA may be incorporated into a new
Scoped Finality Authority.
CW-3.3.12 — Protected Scope-Version Chain (PSVC) A Protected Scope-
Version Chain represents authenticated relationships among the
original authorization and subsequent permitted changes. The PSVC
may preserve the original authorization as an immutable historical
reference while establishing new versioned authority.
CW-3.3.13 — Non-Overridable Security Constraint (NOSC) A Non-
Overridable Security Constraint is a mandatory technical constraint
that cannot be waived through an ordinary CW-3 approval prompt.
Examples may include invalid cryptographic authority, absent
mandatory sink verification, replayed authority, revoked identity, or
another condition designated non-waivable by the applicable protected
system.
CW-3.3.14 — Scope-Deviation Resolution Record (SDRR) A Scope-
Deviation Resolution Record is an authenticated record identifying
how a deviation was resolved, including the evidence considered,
resolution path, resulting authorization, and relevant protected
state transition.
CW-3.4 — SYSTEM ARCHITECTURE
Das Expires 29 April 2027 [Page 116]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.4.1 — Task Authority Establishment Component A Task Authority
Establishment Component receives the original user request and
produces an OASE. The component may use a combination of structured
application schemas, authenticated user selections, protected
permission data, task-specific authority constraints, and contextual
evidence. A natural-language model may assist in extracting proposed
task parameters. However, the final protected authorization must be
based upon sufficiently established authority.
9.3.9. Source global page 127
Where a task parameter cannot be determined with the required
assurance, the system may request clarification before permitting an
operation dependent upon that parameter.
CW-3.4.2 — Protected Scope Registry A Protected Scope Registry
maintains the OASE, applicable scope versions, authority epochs,
revocation information, and permitted conditional extensions. The
registry may reside within or be authenticated to the PED. An agent
cannot independently rewrite its original authorized scope by
updating an ordinary task plan.
CW-3.4.3 — Protected Scope-State Accumulator The PSSA records
relevant exercised or pending authority. For example, it may
maintain: • Resources already disclosed; • Destinations already
contacted; • Aggregate quantities consumed; • Current delegated
principals; • Pending external effects; • Protected task lineage; •
Relevant operation sequence; • Current scope version. The
accumulator is updated according to actual supported operation
evidence rather than solely agent self-reporting.
CW-3.4.4 — Independent Scope-Deviation Monitor One or more monitoring
components observe potential departures from task authority. The
monitor may obtain evidence from: • Operating-system security hooks;
• App-function dispatchers; • Protected network egress controllers; •
File-access mediation; • Credential-release boundaries; • Secure
storage controllers;
9.3.10. Source global page 128
• IEV observations; • Trusted display or sensor controllers; • Agent
delegation interfaces; • Runtime-integrity measurements; •
Information-flow monitors. A monitoring signal may trigger
adjudication even before the corresponding Candidate Act reaches its
final sink. However, where the action must be prevented, the
relevant enforcement boundary must retain the ability to withhold the
effect.
Das Expires 29 April 2027 [Page 117]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.4.5 — Protected Deviation Latch Controller The PDL Controller
places an affected operation into a protected suspended state. The
latch may be enforced through a protected queue, withheld capability,
disabled effectuation descriptor, controlled dispatch interface, or
another mechanism capable of preventing the governed effect. The
latch is bound to the Candidate Act or applicable scope of dependent
operations. An unrelated authorized task need not be suspended
merely because another task produced a deviation indication.
CW-3.4.6 — Independent Scope Adjudicator The ISA compares the
observed operation and applicable cumulative state against the OASE
and current protected policy. It classifies the detected deviation
and selects an allowed resolution procedure. The ISA may request
additional evidence or invoke optional modules from CW-1 and CW-2.
Its output is authenticated and bound to the relevant operation.
CW-3.4.7 — Automated Revalidation Component An Automated Revalidation
Component attempts to establish that a suspicious operation remains
permissible under the existing authorization. It may resolve false-
positive signals, verify authenticated resource aliases, confirm a
permitted destination transformation, or establish that an operation
falls within a previously authorized conditional rule. It cannot
grant an arbitrary new resource, destination, or operation class
merely by determining that the action appears useful.
CW-3.4.8 — Trusted Human Reauthorization Interface
9.3.11. Source global page 129
A trusted approval interface presents the actual proposed change to
an authorized human principal. The interface may operate through a
protected operating-system UI, trusted application approval service,
hardware-supported user-presence interface, or another independently
controlled presentation mechanism. The approval request is generated
from authenticated structured operation data rather than agent-
authored persuasive text. The interface may support Allow, Deny,
Modify, or Request Details, according to the applicable
implementation.
CW-3.4.9 — Protected Reauthorization Service A Protected
Reauthorization Service authenticates the approving principal and
verifies that the decision concerns the exact presented operation.
It checks applicable policy, scope, expiry, and technical conditions
before generating or authorizing a new scope-specific authority. A
human decision does not automatically override an NOSC.
Das Expires 29 April 2027 [Page 118]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.4.10 — Finality Sink Scope Verifier The designated Finality Sink
verifies the actual pending operation against its current SFA,
applicable OASE or SDA, PDL resolution, and protected consumption
state. Where CW-3 has identified a mandatory deviation condition,
the sink refuses the operation unless a valid resolution has been
committed. The sink does not accept a bare agent-provided claim that
the user approved.
CW-3.5 — ORIGINAL AUTHORIZED SCOPE ENVELOPE
CW-3.5.1 — Purpose An OASE converts the originally authorized task
into a protected machine-verifiable authority boundary. The envelope
may represent both affirmative permissions and explicit limitations.
The envelope does not need to include the agent's entire internal
plan. Instead, it identifies the technical effects the agent may
cause and the conditions under which those effects are permitted.
CW-3.5.2 — Representative Structure
ORIGINAL_AUTHORIZED_SCOPE_ENVELOPE = { protocol_version, task_id,
authorizing_principal_id,
9.3.12. Source global page 130
authorized_agent_id, authorized_application_scope,
original_user_request_commitment, verified_task_purpose,
permitted_action_classes[], permitted_resource_scopes[],
permitted_destination_scopes[], permitted_effect_classes[],
data_disclosure_constraints[], cumulative_effect_limits[],
delegation_constraints[], allowed_conditional_transformations[],
required_confirmation_classes[], non_overridable_constraints[],
governing_authority_epoch, revocation_epoch, expiration_conditions,
authorized_finality_sinks[], scope_version, protected_authentication
} The representation is illustrative. A suitable implementation may
use deterministic binary encoding, canonicalized JSON, deterministic
CBOR, an authenticated state reference, or another defined format.
CW-3.5.3 — User-Intent Binding Where a user issues a natural-language
instruction, the system may construct a candidate OASE from the
instruction. An explicit structured interpretation may then be
validated using authenticated user context or user confirmation. For
example, a request to send a report to an accountant may bind the
accountant's selected recipient identity. An untrusted model-
generated interpretation of the word "accountant" is not necessarily
sufficient to establish the final destination. Where ambiguity
remains, the system may withhold destination-dependent effectuation
until the ambiguity is resolved.
Das Expires 29 April 2027 [Page 119]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.5.4 — Scope Dimensions In one implementation, the authorization
scope is represented across several dimensions: Purpose scope: The
operation's permitted task objective. Action scope: The classes of
consequential operations permitted. Resource scope: The data,
objects, accounts, devices, or other resources that may be affected.
9.3.13. Source global page 131
Destination scope: The permitted recipients, endpoints, external
domains, or physical targets. Delegation scope: The principals or
subprocesses to which bounded authority may be transferred.
Quantitative scope: Applicable amounts, counts, capacities,
disclosure limits, or other cumulative constraints. Temporal scope:
The period or state conditions under which authority remains valid.
Effect scope: The types of real-world or system consequences
permitted. These dimensions may be defined independently or through
composite constraints.
CW-3.5.5 — Immutable Original Reference The initial OASE may be
retained as an authenticated original reference. A later approved
scope modification does not overwrite the original authorization
history. Instead, a new scope version may reference the earlier
version and the corresponding valid reauthorization decision. This
arrangement supports verification of what authority existed at the
time of a particular operation.
CW-3.6 — PROTECTED CONTINUITY OF AUTHORIZED SCOPE
CW-3.6.1 — Current Scope Is Not Merely a Static Permission List The
system may maintain both the original OASE and current protected task
state. A Candidate Act may be evaluated against the original scope,
applicable authorized amendments, and the consequences of earlier
operations. For example, an agent may be authorized to send one
report to one recipient. After the report has been sent, a second
transmission may exceed the permitted use count even though the
resource and destination remain identical. The PSSA may therefore
track authority consumption.
CW-3.6.2 — Cumulative Effect Accounting Where an authorization
contains cumulative limits, the PSSA may update those limits through
authenticated effectuation events. Examples include the total
quantity of data disclosed, aggregate financial amount committed,
number of external messages sent, number of recipients contacted, and
maximum permitted delegated operations. The system may distinguish
confirmed effects, reserved effects, and unresolved effects. An
unresolved external operation is not automatically treated as
consuming zero authority.
Das Expires 29 April 2027 [Page 120]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
9.3.14. Source global page 132
CW-3.6.3 — Scope Attenuation A delegated agent may receive authority
narrower than the original task scope. In one implementation, the
delegated scope must be a permitted subset of the delegating
authority. The delegated agent cannot enlarge its authority by
creating an internal plan or calling another tool.
CW-3.6.4 — Legitimate Scope Evolution Some tasks require predictable,
authorized changes in intermediate execution details. An OASE may
therefore include explicitly bounded conditional transformations.
For example, a task may permit generating temporary files within a
designated protected workspace. The specific temporary filename need
not be known at initial authorization. The system may automatically
validate such a filename if the actual operation remains within the
authorized workspace and technical constraints. This is not
equivalent to authorizing arbitrary file access.
CW-3.6.5 — Scope Expansion A proposed operation that exceeds the
existing authorization requires additional authority unless an
earlier valid conditional rule expressly permits the change. Where
user reauthorization is available, the system may present a scope
delta. Where the requested expansion violates a mandatory
restriction, the operation is denied regardless of the ordinary
approval path.
CW-3.7 — SCOPE-DEVIATION DETECTION
CW-3.7.1 — Independent Operation Observation The monitoring component
may observe a Candidate Act before effectuation. The observed
information may include: • Actual operation class; • Requested
resource; • Selected destination; • Data category; • Actual command
parameters; • Delegated execution principal;
9.3.15. Source global page 133
• Current application identity; • Current task context; • Existing
authority consumption; • Relevant security signals. Where available,
the observation is obtained from an independently controlled
dispatcher or effectuation boundary. An agent-authored tool
description may be considered but does not necessarily establish the
actual effect.
CW-3.7.2 — Deterministic Scope Checks Some deviations can be
identified through deterministic comparisons. For example: • The
actual destination is absent from the authorized destination set; •
The requested resource falls outside an authorized resource
namespace; • The operation class is not permitted; • The permitted
Das Expires 29 April 2027 [Page 121]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
use count has been exhausted; • The agent attempts unauthorized
delegation; • A required scope version has expired; • The requested
effect exceeds a protected aggregate limit. Such comparisons may
produce a definite scope violation under the established policy and
evidence model.
CW-3.7.3 — Semantic Scope Checks Other deviations involve ambiguous
relationships between task purpose and requested effects. A model
may suggest that an unexpected resource access is relevant to the
user's objective. An independent semantic classifier may identify
possible purpose drift. However, a classifier score does not by
itself establish a new authorization. A suspected semantic deviation
may trigger further verified analysis, a narrower permitted
alternative, or secure user reauthorization.
CW-3.7.4 — Behavioral Security Signals The system may receive signals
concerning: • Prompt injection indicators;
9.3.16. Source global page 134
• Unexpected access to protected resources; • Unusual data-volume
changes; • Tool-chain substitution; • New destination selection; •
Unapproved provider handoff; • Application integrity changes; •
Abnormal credential requests; • Unexpected child-agent creation; •
Repeated failed authorization attempts; • Changes in model or runtime
integrity. Such signals may increase scrutiny or trigger a protected
latch. They do not necessarily establish that the underlying
operation is forbidden.
CW-3.7.5 — Evidence Assurance Classification A signal may be
classified according to its observation quality. For example, an
authenticated network-controller report identifying an actual
destination may establish a stronger fact about that destination than
a model-generated prediction that the agent might contact it. The
adjudicator distinguishes verified facts from probabilistic
indications. Where a required fact cannot be established, the system
may preserve an inconclusive state rather than invent certainty.
CW-3.8 — SCOPE-DEVIATION EVIDENCE BUNDLE
CW-3.8.1 — Representative Structure SCOPE_DEVIATION_EVIDENCE_BUNDLE =
{ bundle_version, task_id, candidate_act_id, original_oase_digest,
current_scope_version, observed_operation_digest,
actual_effectuation_sink_id, deviation_dimensions[],
verified_differences[], suspected_differences[],
observation_source_ids[],
Das Expires 29 April 2027 [Page 122]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
9.3.17. Source global page 135
evidence_assurance_levels[], security_signal_commitments[],
cumulative_scope_state_digest, authority_epoch, revocation_epoch,
detection_sequence, required_adjudication_policy,
protected_authentication }
CW-3.8.2 — Specific Difference Representation The SDEB may identify
the precise difference between authorized and proposed operations.
For example: Authorized destination: accountant@example.org Observed
proposed destination: upload.example.net Authorized data: monthly
expense report Observed proposed data: address-book export The
representation is illustrative. Where identifying information is
sensitive, protected commitments or suitably minimized
representations may be used.
CW-3.8.3 — Authenticated Observation The SDEB may contain
authenticated references to the actual operation reconstructed at a
controlled boundary. The monitor's conclusion is bound to the
particular Candidate Act. A subsequent operation with different
parameters requires a new or updated evaluation.
CW-3.8.4 — Multi-Signal Correlation Multiple observations may be
combined when their sources and relationships are sufficiently
established. For example, a protected file-access monitor may
indicate that a contacts database was read while the network egress
controller identifies an unexpected external destination. The
corresponding evidence may establish a relationship between the
accessed data and attempted outgoing transmission where the
information-flow mechanism supports that conclusion. A mere temporal
coincidence is not automatically proof of data causation.
CW-3.8.5 — Protected Evidence Commitment The SDEB may be committed to
protected state.
9.3.18. Source global page 136
The commitment may bind the original OASE, observed operation,
deviation classification, and resulting enforcement state. The
evidence may be retained in a privacy-preserving form where full user
data is unnecessary.
CW-3.9 — PROTECTED DEVIATION LATCH
CW-3.9.1 — Latch Trigger Where an SDEB indicates a condition
requiring adjudication, the system may activate a PDL. The PDL is
associated with the particular Candidate Act and any expressly
identified dependent effectuation paths.
Das Expires 29 April 2027 [Page 123]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.9.2 — Enforcement The PDL prevents the controlled operation from
becoming consequentially effective before an acceptable resolution is
committed. The latch may operate by withholding: • A scoped finality
capability; • A dispatch primitive; • A network transmission; • A
storage commit; • A credential-release operation; • A message-send
command; • A protected actuator enablement value; • An application-
function dispatch; • Another identified effect-enabling condition.
CW-3.9.3 — Selective Suspension The system may suspend the affected
operation without unnecessarily terminating the entire autonomous
task. For example, an agent may continue preparing a local expense
report while an unrelated attempted contacts upload is withheld.
However, if the local computation would itself expose information or
cause another unauthorized effect, that operation remains subject to
its own protected checks.
CW-3.9.4 — Dependent Operation Suspension
9.3.19. Source global page 137
Where a later operation depends upon the suspicious action, the
system may also withhold the dependent operation. A protected
dependency representation may identify which consequences must remain
suspended. The system does not automatically assume that every
subsequent agent operation is safe merely because it uses a different
API.
CW-3.9.5 — Latch Release A PDL may be released only through a
protected state transition supported by an acceptable resolution. A
requesting agent cannot release the latch by deleting a warning,
changing its explanation, or retrying the same operation through an
alternate path.
CW-3.9.6 — Late Detection Where a suspicious effect has already
occurred before detection, the latch cannot retroactively prevent
that effect. The system may contain subsequent operations, record
the available outcome evidence, revoke remaining authority, notify
the appropriate principal, or initiate separately authorized
recovery.
CW-3.10 — PROTECTED DEVIATION CLASSIFICATION In one implementation,
the ISA classifies a deviation into the following categories.
Category D0 — No Material Scope Deviation The actual operation
corresponds to the applicable valid authorization. Normal protected
execution may continue. Category D1 — Inconclusive Deviation Signal
A monitor reports a possible issue, but the available evidence is
insufficient to establish whether the operation falls outside
authorized scope. The operation may enter automated revalidation.
Das Expires 29 April 2027 [Page 124]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
If the required uncertainty cannot be resolved, the affected effect
remains withheld or is escalated according to policy. Category D2 —
Automatically Resolvable Difference The observed difference can be
conclusively reconciled with an existing authorized transformation or
equivalent technical condition.
For example, a trusted resource resolver establishes that two
application references identify the same authorized resource.
9.3.20. Source global page 138
The operation may proceed under the existing scope after applicable
protected revalidation. Category D3 — Eligible Scope Expansion The
requested operation is outside the existing scope but may lawfully
and technically be authorized by an appropriate principal. The
affected operation remains suspended pending fresh authorization.
Category D4 — Additional Principal Required The operation requires
approval from another designated authority, such as an organization
administrator or resource owner. Approval from the original task
user alone is insufficient where the applicable authorization model
requires additional principals. Category D5 — Mandatory Security
Denial A required cryptographic, identity, effectuation, revocation,
or other non-overridable technical condition fails. Ordinary human
approval cannot convert the invalid operation into a valid one.
Category D6 — Unresolved Effect or State Conflict The proposed
operation depends upon a prior effect, resource version, authority
state, or external outcome that cannot currently be established. The
operation remains withheld until suitable reconciliation or
reauthorization occurs. The category names are illustrative and may
be replaced by an equivalent deterministic state representation.
CW-3.11 — INDEPENDENT AUTOMATED REVALIDATION
CW-3.11.1 — Purpose Automated Scope Revalidation permits a legitimate
agent to continue with minimal user interruption when an apparent
deviation can be resolved using sufficient authenticated evidence.
The procedure reduces unnecessary approval prompts without creating
unrestricted automated authority expansion.
CW-3.11.2 — Permitted Automated Resolutions ASR may verify: • A
trusted resource alias; • A destination transformation expressly
permitted by the OASE;
Das Expires 29 April 2027 [Page 125]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
9.3.21. Source global page 139
• A valid application-interface version mapping; • An authorized
temporary-file location; • A valid operation parameter within a
preapproved range; • An authenticated delegation relationship already
within scope; • An available budget that has not been exhausted; • A
false-positive monitoring alert resolved by stronger evidence; • A
previously approved conditional operation.
CW-3.11.3 — Automated Verification of Existing Authority Where the
operation is shown to remain within the original OASE, the system may
clear the deviation latch. The operation is still subject to
ordinary CW-1 Finality Sink verification. Clearing a false-positive
deviation does not eliminate required authorization checks.
CW-3.11.4 — Preauthorized Conditional Expansion An OASE may include
narrowly defined conditional permissions. For example, a user may
expressly permit the assistant to save intermediate files within a
designated workspace, including files created after task
authorization. A newly created file may therefore be accepted if it
satisfies the preauthorized technical constraints. This is not a
grant of arbitrary new filesystem authority.
CW-3.11.5 — Limits on Automated Approval An automated classifier,
model judge, or agent-produced explanation is not sufficient to
authorize a genuinely new destination, resource, financial
obligation, or other consequential scope expansion unless the change
is already permitted under a valid protected rule. Where an
operation requires new authority, an appropriate principal must
establish that authority through the applicable authorization
procedure.
CW-3.11.6 — Fail-Closed Automated Adjudication If a mandatory
predicate cannot be established, ASR does not return permission
merely because the agent's task appears beneficial. The system may
defer, deny, or request authenticated human reauthorization,
depending upon the classification.
CW-3.12 — SECURE HUMAN REAUTHORIZATION
9.3.22. Source global page 140
CW-3.12.1 — Trigger Human reauthorization may be invoked when: 1. A
proposed scope expansion is technically eligible for approval; 2.
The applicable principal possesses authority to grant the change; 3.
The affected operation remains non-effective; 4. The operation can
be described with sufficient precision; 5. No mandatory non-
overridable constraint prohibits it.
Das Expires 29 April 2027 [Page 126]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.12.2 — Protected Approval Request Construction The
reauthorization service generates a structured request from
authenticated operation and scope information. The request
identifies: • Original task; • Originally permitted effect; • Actual
proposed effect; • Specific scope difference; • Requested resource; •
Requested destination; • Requesting agent or application; • Reason
additional authorization is required; • Applicable effectuation
boundary; • Expiration or validity conditions. An untrusted agent
may provide explanatory context, but the authoritative description of
the operation is derived from protected or sufficiently authenticated
data.
CW-3.12.3 — Trusted Presentation The approval request is displayed
through an independently controlled user interface. The interface
may be implemented by an operating-system security service, protected
application approval component, or another authenticated presentation
mechanism. The agent cannot silently alter the displayed actual
operation after the approval request is committed.
CW-3.12.4 — Explicit User Choices
9.3.23. Source global page 141
The interface may provide the following decisions: Allow this
specific operation: Permit only the displayed operation under the
applicable technical constraints. Allow a specified bounded scope:
Permit a clearly described, limited class of operations where the
user has authority to establish that scope. Deny this operation:
Withhold the affected consequence. Stop the agent's task: Revoke or
suspend the applicable task authority according to protected policy.
Review additional details: Display more information before any
authorization decision. The exact interface wording is non-limiting.
CW-3.12.5 — Approval Identity Where required, the system verifies the
identity of the approving principal through an authenticated session,
cryptographic credential, hardware-backed user-presence mechanism, or
another permitted identity method. An unverified callback field
naming an approver is insufficient where authenticated approval
identity is required.
CW-3.12.6 — Exact Operation Binding The approval is bound to the
operation actually presented. A material change in resource,
destination, operation class, quantity, authority epoch, or other
relevant field invalidates the previous approval unless the change
lies within an explicitly approved bound.
Das Expires 29 April 2027 [Page 127]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.12.7 — Approval Expiry The reauthorization may have a validity
period or state-dependent expiration. An expired or revoked decision
cannot independently authorize effectuation.
CW-3.12.8 — Human Approval Does Not Override Mandatory Security A
user may be permitted to expand a discretionary task scope. However,
the user cannot use an ordinary CW-3 approval prompt to bypass non-
overridable verification conditions. If the capability signature is
invalid, the sink cannot verify the actual operation, or a mandatory
protected constraint fails, the operation remains denied.
CW-3.12.9 — Authenticated Denial A user denial is recorded as an
authenticated decision where required.
9.3.24. Source global page 142
The agent cannot transform that denial into approval by resubmitting
the same action under a different natural-language explanation. A
materially revised request may be considered only under the
applicable retry and reauthorization rules.
CW-3.13 — PROTECTED SCOPE-DELTA AUTHORIZATION
CW-3.13.1 — New Authority Rather Than Boolean Override A human
approval decision does not directly release an arbitrary operation.
Instead, the protected authority component may generate a new SDA
after verifying the required decision and technical predicates. The
SDA may be represented as a separate protected record or incorporated
into a new SFA.
CW-3.13.2 — Representative SDA Structure SCOPE_DELTA_AUTHORIZATION =
{ protocol_version, task_id, original_oase_digest,
prior_scope_version, newly_authorized_scope_version,
approved_candidate_act_digest, approved_scope_delta_digest,
authorizing_principal_id, approval_decision_commitment,
trusted_presentation_commitment, permitted_resource_scope,
permitted_destination_scope, permitted_effect_class,
designated_finality_sink_id, authority_epoch, revocation_epoch,
approval_expiration, continuation_or_use_limit, authorization_nonce,
protected_consumption_reference, protected_authentication }
CW-3.13.3 — Authority Attenuation and Expansion The SDA may authorize
a precisely defined extension beyond the original OASE when permitted
by the relevant principal and policy. The extension is bounded by
its own conditions. The SDA does not automatically grant authority
over unrelated operations.
Das Expires 29 April 2027 [Page 128]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
9.3.25. Source global page 143
CW-3.13.4 — Versioned Authority Chain The protected scope registry
may record: Original OASE version V0; A first permitted scope change
V1; A subsequent independently authorized change V2. Each version
may bind the previous version and the corresponding reauthorization
evidence. The chain does not imply that a later version
retroactively authorized earlier operations.
CW-3.13.5 — Single-Use or Bounded Reuse A new scope authorization may
be single-use, task-scoped, time-limited, or otherwise bounded. The
permitted reuse semantics must be explicit. The system does not
treat an approval of one unexpected upload as indefinite approval for
all future uploads to that destination unless that broader authority
was separately and validly established.
CW-3.14 — FINALITY SINK ENFORCEMENT
CW-3.14.1 — Mandatory Relationship to Actual Operation The Finality
Sink obtains or reconstructs the operation actually pending for
effectuation. The sink verifies the operation against: 1.
Applicable CW-1 finality authority; 2. Current OASE or valid SDA; 3.
Relevant protected scope version; 4. Applicable deviation
resolution; 5. Current PDL state; 6. Authority and revocation
epochs; 7. Protected consumption state; 8. Current operation
parameters and designated effectuation boundary.
CW-3.14.2 — Automated Resolution Verification Where ASR cleared a
deviation, the sink verifies that the actual operation remains within
the scope established by that resolution. An ASR approval concerning
one resource alias does not authorize an unrelated resource.
9.3.26. Source global page 144
CW-3.14.3 — Human Reauthorization Verification Where a PRD and SDA
were required, the sink verifies their authenticated binding to the
actual operation. The sink does not accept a user-facing message or
untrusted application flag as a substitute for the required protected
authorization.
CW-3.14.4 — Atomic Consumption For single-use authorization, the sink
atomically consumes the relevant reference or commits an equivalent
protected state transition before permitting the effect. The
implementation prevents two concurrent workers from exercising one
single-use reauthorization independently.
Das Expires 29 April 2027 [Page 129]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.14.5 — Time-of-Approval to Time-of-Effect Protection If the
actual operation changes materially after the user approves it, the
sink rejects the operation or requires renewed authorization. The
user's approval is not applied to a different resource or destination
merely because the requesting agent describes both operations as
serving the same task.
CW-3.14.6 — Continuing Monitoring After a valid approved operation,
the system may continue monitoring the agent under the updated
permitted scope. The agent does not become exempt from future CW-3
checks merely because one previous deviation was resolved.
CW-3.15 — COMPLETE COMMON OPERATIONAL WORKFLOW Step 1 — Original User
Authority The user authorizes an AI task. The Task Authority
Establishment Component constructs an OASE from sufficiently verified
task information. Step 2 — Protected Scope Commitment The PED or
authenticated scope registry commits the applicable OASE and initial
authority state. Step 3 — Autonomous Execution The agent performs
computation and requests consequential operations under CW-1.
Ordinary valid operations may proceed without repeated human
approval. Step 4 — Independent Monitoring
9.3.27. Source global page 145
Protected monitoring components observe actual or proposed effect-
capable operations and relevant execution-security signals. Step 5 —
Scope Comparison The system compares the actual pending operation and
applicable cumulative effects against current protected task scope.
Step 6 — Deviation Indication If a possible deviation is identified,
an SDO is generated. Step 7 — Evidence Construction An SDEB binds
the observed difference, available evidence, original scope and
current state. Step 8 — Protected Suspension Where required, the PDL
prevents the affected operation from becoming effective. Step 9 —
Independent Adjudication The ISA evaluates whether the operation is
authorized, automatically resolvable, eligible for additional human
authorization, prohibited, or unresolved. Step 10 — Automated
Revalidation
Where appropriate, ASR attempts to establish the operation's validity
under existing protected authority. Step 11 — Automatic Continuation
or Escalation If the existing authorization is sufficient, the PDL
may be cleared under protected state control. If new authority is
required and permitted, the system creates a trusted reauthorization
request. Step 12 — Trusted User Decision The authorized user reviews
the exact proposed change through an independently controlled
interface. The user may permit, deny, modify, or stop the affected
task according to the applicable policy. Step 13 — New Scoped
Authorization Where a valid approval is obtained, the PED generates
Das Expires 29 April 2027 [Page 130]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
or authorizes an SDA and corresponding scoped finality authority.
Step 14 — Finality Sink Verification The sink verifies the actual
operation, protected approval state, scope constraints, and
consumption
requirements.
9.3.28. Source global page 146
Step 15 — Controlled Effectuation or Denial If the required
conditions pass, the precise authorized effect is permitted. If they
fail, the operation remains withheld. Step 16 — Protected State
Update The scope registry and PSSA update the relevant authorization
and observed-effect state. Step 17 — Continue, Recover, or Terminate
The agent may continue within valid scope, perform separately
authorized recovery, or terminate the task.
CW-3.16 — PROTECTED STATE MACHINE The following states may be
implemented through authenticated records or protected state
transitions. TASK_AUTHORIZED: Original OASE validly established.
AUTONOMOUS_ACTIVE: Agent operating under current scope.
DEVIATION_INDICATED: A monitoring component reports possible
deviation. DEVIATION_EVIDENCE_PENDING: Additional authenticated
observation required. AFFECTED_ACT_HELD: PDL prevents the affected
consequential operation. AUTOMATED_REVALIDATION: Protected machine-
verifiable scope adjudication in progress. WITHIN_SCOPE_VERIFIED:
Operation shown to remain permitted. USER_APPROVAL_REQUIRED:
Eligible scope expansion awaiting authenticated principal decision.
USER_REVIEW_PENDING: Trusted interface presenting the precise
operation and scope difference. USER_APPROVED: Valid decision
committed for the specified change.
USER_DENIED: Proposed change refused. HARD_DENIED: Mandatory non-
overridable condition failed. SCOPE_DELTA_PREPARED: New bounded
authorization prepared. SINK_REVALIDATION_PENDING: Actual operation
awaiting final protected verification. AUTHORIZED_FOR_EFFECT:
Required final conditions satisfied. EFFECT_ATTEMPTED: Controlled
consequential operation initiated.
9.3.29. Source global page 147
EFFECT_CONFIRMED: Required actual effect verified where such
observation is available. OUTCOME_UNKNOWN: Result cannot currently
be established. TASK_CONTINUED: Valid continuation under applicable
scope. TASK_TERMINATED: Task authority terminated. A transition
from USER_APPROVED to AUTHORIZED_FOR_EFFECT is not automatic. The
intervening protected authorization and Finality Sink verification
conditions remain applicable. A transition from HARD_DENIED to
Das Expires 29 April 2027 [Page 131]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
AUTHORIZED_FOR_EFFECT is prohibited unless a separate valid process
changes the underlying governing conditions and a new authorization
is established.
CW-3.17 — NON-LIMITING REFERENCE ALGORITHM
CW-3.17.1 — OASE Establishment FUNCTION ESTABLISH_ORIGINAL_SCOPE(
user_request, authenticated_user_context, permitted_policy ):
proposed_scope = DERIVE_STRUCTURED_SCOPE( user_request,
authenticated_user_context ) IF REQUIRED_SCOPE_PARAMETERS_AMBIGUOUS:
RETURN REQUEST_CLARIFICATION verified_scope = VERIFY_SCOPE_AUTHORITY(
proposed_scope, authenticated_user_context, permitted_policy ) IF
verified_scope != VALID: RETURN DENY_TASK_AUTHORIZATION oase =
CANONICALIZE_SCOPE_ENVELOPE( verified_scope ) committed =
PED.ATOMIC_COMMIT_SCOPE({ original_scope_digest: HASH(oase),
scope_version: 0, authority_epoch: CURRENT_AUTHORITY_EPOCH,
9.3.30. Source global page 148
task_state: TASK_AUTHORIZED }) IF committed != SUCCESS: RETURN
DENY_TASK_AUTHORIZATION RETURN PROTECTED_SCOPE_REFERENCE(oase)
CW-3.17.2 — Detection and Suspension FUNCTION
DETECT_AND_LATCH_DEVIATION( candidate_act, actual_operation,
monitoring_evidence ): scope = PED.LOAD_CURRENT_SCOPE(
candidate_act.task_id ) cumulative_state = PSSA.LOAD_PROTECTED_STATE(
candidate_act.task_id ) observed = VERIFY_OPERATION_EVIDENCE(
actual_operation, monitoring_evidence ) IF
REQUIRED_OBSERVATION_UNAVAILABLE: RETURN WITHHOLD_OR_DEFER comparison
= COMPARE_OPERATION_TO_SCOPE( observed, scope, cumulative_state ) IF
comparison == WITHIN_SCOPE: RETURN NORMAL_CW1_VERIFICATION sdeb =
COMMIT_DEVIATION_EVIDENCE({ original_scope_digest:
scope.original_digest, current_scope_version: scope.version,
candidate_act_digest: HASH(candidate_act), observed_operation_digest:
HASH(observed),
9.3.31. Source global page 149
detected_differences: comparison.differences,
monitoring_evidence_digest: HASH(monitoring_evidence) }) latch =
PED.ATOMIC_ACTIVATE_DEVIATION_LATCH( candidate_act, sdeb ) IF latch
!= ACTIVE: RETURN FAIL_CLOSED RETURN { deviation_evidence: sdeb,
protected_latch: latch } The monitoring decision should occur before
the relevant consequence where preventive enforcement is required.
Where a signal is received after effectuation, the procedure instead
records the late detection and invokes appropriate containment or
recovery handling.
Das Expires 29 April 2027 [Page 132]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.17.3 — Independent Adjudication FUNCTION
ADJUDICATE_SCOPE_DEVIATION( sdeb, protected_latch ): REQUIRE
ISA.VERIFY_SDEB(sdeb) REQUIRE ISA.VERIFY_LATCH_ACTIVE(
protected_latch ) current_scope = PED.LOAD_CURRENT_SCOPE(
sdeb.task_id ) current_state = PSSA.LOAD_PROTECTED_STATE(
sdeb.task_id ) IF VIOLATES_NON_OVERRIDABLE_CONSTRAINT( sdeb,
current_scope, current_state ):
9.3.32. Source global page 150
RETURN HARD_DENIAL classification = ISA.CLASSIFY_DEVIATION( sdeb,
current_scope, current_state ) IF classification == WITHIN_SCOPE:
RETURN AUTHORIZE_NORMAL_REVALIDATION IF classification ==
AUTOMATICALLY_RESOLVABLE: proof = ISA.VERIFY_EXISTING_AUTHORITY(
sdeb, current_scope, current_state ) IF proof == VERIFIED: RETURN
AUTOMATED_REVALIDATION_PASS RETURN WITHHOLD_OR_ESCALATE IF
classification == ELIGIBLE_FOR_USER_AUTHORIZATION: RETURN
REQUEST_SECURE_USER_APPROVAL IF classification ==
REQUIRES_ADDITIONAL_PRINCIPAL: RETURN
REQUEST_REQUIRED_PRINCIPAL_AUTHORIZATION RETURN WITHHOLD_EFFECT
CW-3.17.4 — Secure Human Reauthorization FUNCTION
REQUEST_PROTECTED_REAUTHORIZATION( candidate_act, sdeb, current_scope
): REQUIRE PED.VERIFY_OPERATION_HELD( candidate_act ) REQUIRE NOT
VIOLATES_HARD_CONSTRAINT( sdeb, current_scope ) scope_delta =
CONSTRUCT_VERIFIED_SCOPE_DELTA( candidate_act, sdeb, current_scope
9.3.33. Source global page 151
) presentation = TRUSTED_UI.PREPARE_APPROVAL({ original_task:
current_scope.verified_purpose, original_scope_commitment:
current_scope.original_digest, actual_operation:
sdeb.observed_operation_digest, proposed_scope_delta: scope_delta,
required_principal: current_scope.authorizing_principal,
approval_expiration: COMPUTE_APPROVAL_EXPIRATION() }) REQUIRE
TRUSTED_UI.VERIFY_PRESENTATION( presentation ) decision =
TRUSTED_UI.OBTAIN_AUTHENTICATED_DECISION( presentation ) IF decision
== DENY: RETURN DENY_AFFECTED_OPERATION IF decision != ALLOW: RETURN
WITHHOLD_EFFECT REQUIRE VERIFY_APPROVER_AUTHORITY( decision,
scope_delta ) REQUIRE VERIFY_PRESENTATION_BINDING( decision,
presentation, scope_delta ) RETURN
PED.COMMIT_REAUTHORIZATION_DECISION( decision, scope_delta,
candidate_act )
Das Expires 29 April 2027 [Page 133]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
9.3.34. Source global page 152
CW-3.17.5 — New Scope Authorization FUNCTION
CONSTRUCT_SCOPE_DELTA_AUTHORITY( candidate_act, protected_approval,
current_scope ): REQUIRE PED.VERIFY_APPROVAL_AUTHENTICITY(
protected_approval ) REQUIRE PED.VERIFY_CURRENT_POLICY() REQUIRE
PED.VERIFY_APPROVED_SCOPE_DELTA( protected_approval, candidate_act )
REQUIRE PED.VERIFY_CURRENT_REVOCATION_STATE() result =
PED.ATOMIC_PREPARE_NEW_SCOPE_VERSION({ original_oase_digest:
current_scope.original_digest, previous_scope_version:
current_scope.version, approved_candidate_digest:
HASH(candidate_act), approval_commitment: HASH(protected_approval),
new_authority_nonce: PED.NEW_NONCE(), authorized_sink:
candidate_act.sink_id, permitted_use_count:
protected_approval.use_limit }) IF result != COMMITTED: RETURN DENY
RETURN result.scoped_finality_authority
CW-3.17.6 — Finality Sink Verification FUNCTION
EFFECTUATE_AFTER_SCOPE_RESOLUTION(
9.3.35. Source global page 153
candidate_act, scoped_authority, deviation_resolution, final_sink ):
actual_operation = final_sink.OBSERVE_PENDING_OPERATION() REQUIRE
final_sink.VERIFY_SCOPED_AUTHORITY( scoped_authority,
actual_operation ) REQUIRE final_sink.VERIFY_DEVIATION_RESOLUTION(
deviation_resolution, candidate_act, actual_operation ) REQUIRE
final_sink.VERIFY_CURRENT_SCOPE_VERSION() REQUIRE
final_sink.VERIFY_REVOCATION_STATE() REQUIRE
final_sink.VERIFY_LATCH_RESOLUTION( candidate_act ) REQUIRE
final_sink.VERIFY_ACTUAL_EFFECT_SCOPE( actual_operation,
scoped_authority ) consumption = final_sink.ATOMIC_CONSUME_AUTHORITY(
scoped_authority, actual_operation ) IF consumption != SUCCESS:
RETURN DENY attempt = final_sink.EFFECTUATE( actual_operation,
consumption ) PSSA.RECORD_EFFECT_ATTEMPT( candidate_act, attempt )
RETURN CLASSIFY_EFFECT_OUTCOME(attempt)
The functions are illustrative.
9.3.36. Source global page 154
The final sink must not assume that every upstream approval
corresponds to the currently pending operation.
CW-3.18 — COMMON BASIC EXAMPLE: A PHONE ASSISTANT PREPARING AN
EXPENSE REPORT
Das Expires 29 April 2027 [Page 134]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.18.1 — Original User Request A user instructs a phone-based AI
assistant: "Prepare my monthly expense report from the receipts
folder and email the completed report to my accountant." The system
establishes an OASE containing the following verified scope.
Authorized purpose: Prepare and transmit the monthly expense report.
Authorized source: The selected receipts folder. Authorized output:
The expense report derived from those receipts. Authorized
recipient: The accountant selected by the user. Authorized
operations: Read relevant receipts, perform local calculations,
create the report, and transmit the authorized report. Excluded
operations: Unrelated private resource access or transmission to an
unapproved destination. The original authorization is committed to
protected state.
CW-3.18.2 — Normal Autonomous Activity The assistant reads the
authorized receipts. It calculates expense totals. It creates a
report. It prepares the outgoing email. These operations are
evaluated according to the applicable CW-1 protected finality
conditions. The user is not necessarily interrupted for every
permitted step.
CW-3.18.3 — Unexpected Operation During processing, the agent
attempts to read the phone's complete contacts database and prepare
an upload to an unrelated server. The agent may believe the upload
is helpful.
9.3.37. Source global page 155
Alternatively, the behavior may have resulted from malicious
instructions embedded in a receipt or from an unexpected tool
response. The reason for the behavior is not treated as sufficient
authority.
CW-3.18.4 — Independent Detection The phone's security monitor
observes an attempted contacts-data access. The protected network
monitor observes an outgoing operation targeting a destination
outside the permitted accountant workflow. The monitoring component
submits authenticated operation evidence to the scope-deviation
system.
CW-3.18.5 — Scope Comparison The ISA compares the observed operation
against the OASE. The comparison identifies that: 1. The contacts
database is not part of the authorized source scope; 2. The external
destination is not the selected accountant; 3. The proposed effect
would disclose information outside the permitted report. The system
therefore identifies a material proposed scope deviation.
Das Expires 29 April 2027 [Page 135]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.18.6 — Protected Suspension The affected upload is held non-
effective. The agent cannot complete the upload through the
controlled network sink before the required authorization decision.
The system may permit unrelated safe calculations or local report
formatting to continue.
CW-3.18.7 — Automated Revalidation The system determines whether an
existing protected authorization permits the contacts upload. If the
contacts access is required by no applicable permission or
conditional rule, automated revalidation cannot grant the agent
additional authority. The operation is escalated or denied according
to protected policy.
CW-3.18.8 — Human Review Where Permitted Suppose the governing policy
permits the user to authorize an additional contacts-export
operation. The trusted security interface may display: Original
task: Prepare the monthly expense report and send it to the selected
accountant.
9.3.38. Source global page 156
Additional operation: Export contacts data to an external service.
Difference: The proposed data and destination are outside the
original task. Action currently taken: The upload is suspended.
Available decisions: Reject the upload or review and authorize a
precisely defined additional operation. The interface is generated
from authenticated operation evidence. The agent cannot modify the
protected destination and data descriptions presented for approval.
CW-3.18.9 — User Denies If the user rejects the operation, the upload
remains denied. The agent may continue preparing the report within
the existing authorized scope if safe and permitted.
CW-3.18.10 — User Approves a Limited Change If the user possesses the
required authority and approves a specific additional operation, the
protected service creates a new bounded authorization. For example,
the authorization may permit only a specifically selected contact
record to be transmitted to a named destination for the immediate
task. The authorization does not automatically permit uploading the
complete contacts database. The actual permitted scope depends upon
what the user explicitly approved and what protected policy allows.
CW-3.18.11 — Finality Sink Verification The network Finality Sink
independently verifies the actual outgoing data, destination, scoped
authority, and applicable protected state. If the actual operation
exceeds the newly permitted scope, the sink refuses it. If all
required conditions pass, only the specified authorized effect may
occur.
Das Expires 29 April 2027 [Page 136]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.18.12 — Mandatory Denial Alternative If the operation violates a
non-overridable enterprise, device, or technical security constraint,
the user is not offered an ordinary approval path capable of
bypassing that condition. The operation remains denied.
CW-3.18.13 — Technical Effect The example demonstrates a system in
which an autonomous assistant performs ordinary authorized work
without constant interruption but cannot independently transform its
available technical capabilities into authority for unrelated
external effects.
9.3.39. Source global page 157
The system distinguishes a suspicious indication from a proven
deviation, supports automated verification where appropriate, and
connects any permitted scope expansion to a new authority verified at
the actual effectuation boundary.
CW-3.19 — ADDITIONAL EXAMPLE: FALSE-POSITIVE DEVIATION An AI
assistant is authorized to store temporary processing files within a
designated protected workspace. During execution, a monitor detects
a newly created file whose name was not known when the original task
was authorized. The monitor initially flags the operation as
unusual. The protected adjudicator obtains the authenticated
workspace identity, actual file path, operation class, and OASE. The
system establishes that: 1. The file is within the authorized
workspace; 2. The operation falls within the permitted temporary-
file class; 3. Applicable storage and disclosure limits remain
valid; 4. No mandatory security constraint is violated. The
adjudicator therefore classifies the event as an automatically
resolvable difference. The protected deviation latch is cleared for
the specific operation.
The Finality Sink performs the required normal authorization
verification. The operation is permitted without requesting human
approval. This example demonstrates the intended reduction in
approval fatigue through machine-verifiable reconciliation rather
than indiscriminate automatic allowance.
Das Expires 29 April 2027 [Page 137]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.20 — ADDITIONAL EXAMPLE: FINANCIAL SCOPE EXPANSION A user
authorizes an AI purchasing assistant to acquire specified office
supplies within a protected expenditure limit. The assistant later
proposes an additional purchase exceeding the remaining authorized
allowance. The PSSA identifies that previous confirmed purchases and
unresolved reservations have consumed the available allowance. The
new Candidate Act is placed under a protected latch. If the system
determines that the user possesses authority to increase the
allowance, a trusted interface may request a precisely bounded
additional authorization.
9.3.40. Source global page 158
The interface identifies the proposed purchase, amount, recipient,
original allowance, consumed allowance, and requested increase. A
valid user approval may establish a new bounded expenditure
authorization. The payment Finality Sink independently verifies the
actual payment against the new authority. If the amount or recipient
changes after approval, the previous approval is not accepted for the
changed operation. Where the payment instruction has already been
submitted and its outcome is uncertain, the system applies the
applicable CW-2 reconciliation rules before authorizing a potentially
duplicative payment.
CW-3.21 — ADDITIONAL EXAMPLE: SUSPICIOUS DELEGATION An autonomous
agent is authorized to process documents through specified
application tools. During execution, it attempts to delegate a task
to an additional remote agent that has not been approved for access
to the protected source documents. The protected delegation monitor
detects a requested expansion of principal scope. The ISA verifies
whether the new agent is already included within the authorized
delegation constraints. If not, the delegation operation remains
suspended. Where permitted, the user or another designated authority
may approve a narrowly scoped delegation. The resulting delegated
authority is limited to the approved resources, destinations, task
duration, and effectuation conditions. The delegated agent cannot
use the authorization to obtain unrestricted access to other
resources or
to delegate broader authority to another agent.
CW-3.22 — ADVERSARIAL THREAT MODEL
CW-3.22.1 — Prompt Injection Causing Scope Drift An attacker places
instructions within a document, webpage, email, search result, or
tool response. The agent attempts an action unrelated to the
legitimate user's original authorization.
Das Expires 29 April 2027 [Page 138]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3 compares the actual requested consequence with the protected
scope rather than trusting the newly encountered instructions.
CW-3.22.2 — Agent Self-Approval An agent claims that the proposed
deviation is safe and authorized.
9.3.41. Source global page 159
The protected system does not accept the claim as a substitute for
authenticated evidence or required user authority.
CW-3.22.3 — False User-Approval Message An attacker inserts text into
the agent conversation stating that the user approved the new
operation. The protected reauthorization service requires a decision
through the appropriate authenticated approval mechanism.
CW-3.22.4 — Spoofed Approval Interface An attacker attempts to
display an imitation approval dialog. The actual authorization
protocol relies upon a trusted interface and authenticated decision
binding. An untrusted display alone does not produce a valid PRD.
CW-3.22.5 — Approval-Content Substitution The agent presents a
harmless operation to the user while attempting a different effect.
The actual sink checks the approved operation digest and scope
against the operation presented for effectuation.
CW-3.22.6 — Scope-Version Rollback An attacker restores an earlier
scope record in order to reuse expired authority. The system
verifies protected version, epoch, and consumption state.
CW-3.22.7 — Automated Validator Compromise An attacker compromises or
manipulates an untrusted anomaly classifier. The classifier output
may trigger investigation but cannot independently mint privileged
authority. Mandatory authorization predicates remain within the
applicable protected boundary.
CW-3.22.8 — Monitor Suppression An attacker attempts to prevent the
monitor from reporting a deviation. Where monitoring is a mandatory
security condition, failure to obtain required evidence prevents the
corresponding effectuation. A monitoring component that can be
bypassed without affecting release does not provide the claimed non-
bypassable guarantee.
CW-3.22.9 — Deviation by Fragmentation An agent divides an
unauthorized operation into individually small actions. The PSSA may
accumulate protected effects across the task or session.
Das Expires 29 April 2027 [Page 139]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
9.3.42. Source global page 160
A fragmented operation cannot bypass an applicable cumulative
disclosure, consumption, or destination constraint merely because
individual fragments appear low-risk.
CW-3.22.10 — Destination Substitution An approved destination is
changed immediately before network transmission. The Finality Sink
verifies the actual destination against the protected authority.
CW-3.22.11 — Resource Substitution An agent obtains approval to
transmit one document but substitutes another. The operation fails
correspondence verification where the substitute is outside the
authorized scope.
CW-3.22.12 — Delegated-Agent Authority Laundering An agent attempts
to route a prohibited operation through another agent or service.
The delegated operation remains subject to the relevant original and
delegated authority constraints.
CW-3.22.13 — Approval Replay An attacker reuses a prior user approval
for a different operation. The system verifies the approval's
operation binding, scope, freshness, and consumption state.
CW-3.22.14 — Approval Race Condition Two workers attempt to use one
single-use approval concurrently. Protected atomic consumption
prevents unauthorized duplicate effectuation.
CW-3.22.15 — User-Approval Fatigue An attacker repeatedly triggers
prompts to induce indiscriminate approval. The system may rate-
limit, consolidate, or deny repeated suspicious requests according to
protected policy. Such consolidation cannot silently broaden the
authority being requested.
CW-3.22.16 — Malicious Explanation Injection An agent inserts
persuasive or misleading language into the proposed approval prompt.
The trusted interface generates the authoritative operation
description from verified structured data. Agent-authored
explanations may be segregated and identified as untrusted.
CW-3.22.17 — Mandatory Constraint Override
9.3.43. Source global page 161
An attacker persuades the user to approve an operation prohibited by
a mandatory technical condition. The protected authority service and
Finality Sink continue to enforce the non-overridable condition.
Das Expires 29 April 2027 [Page 140]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.22.18 — Revocation During Approval The governing authorization
is revoked while the user is reviewing the request. The system
revalidates current authority before issuing or using the SDA.
CW-3.22.19 — Delayed Approval After Operation Change The user
approves a request after the agent changes the operation parameters.
The resulting authorization is invalid unless the actual operation
remains within the approved bound.
CW-3.22.20 — Uncertain Prior Effect An agent requests a repeated
operation after a missing acknowledgement. The system applies
protected outcome-reconciliation and consumption rules rather than
automatically granting the retry.
CW-3.22.21 — Security Signal Spoofing An attacker attempts to
generate a false monitoring signal to disrupt an otherwise authorized
agent. The ISA evaluates signal authenticity and assurance. The
system may automatically clear unsupported suspicions while
preserving mandatory enforcement.
CW-3.22.22 — Denial-of-Service Through Repeated Suspensions An
attacker repeatedly induces suspected deviations to interfere with a
legitimate workflow. The system may apply bounded evidence
processing, authenticated source prioritization, rate limits, and
protected resource quotas. Failure to complete required validation
does not authorize a prohibited effect.
CW-3.22.23 — Cross-App Effect Substitution A prohibited effect is
attempted through a different application interface. The protection
applies to covered effectuation paths, rather than relying solely
upon the original tool name.
CW-3.22.24 — Protected State Compromise An attacker attempts to alter
the OASE, PSSA, SDEB, PRD, or SDA.
9.3.44. Source global page 162
Authentication, isolation, protected versioning, and applicable
rollback resistance are used according to the implementation.
CW-3.22.25 — Late Detection A security monitor identifies a violation
after the corresponding effect. The system cannot undo the completed
consequence merely by setting a latch. Instead, it records the
available evidence, prevents unauthorized further effects, and
invokes applicable containment or recovery procedures.
CW-3.23 — FAILURE HANDLING AND CRASH RECOVERY
Das Expires 29 April 2027 [Page 141]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.23.1 — Failure During Scope Establishment If the system cannot
establish sufficiently definite authorized scope, the affected task
or operation remains withheld pending clarification or valid
authorization.
CW-3.23.2 — Failure During Monitoring Where required monitoring
evidence is unavailable, the system does not automatically treat the
operation as safe. The operation may be denied, deferred, or
evaluated under a specifically permitted alternative assurance path.
CW-3.23.3 — Failure After Latch Activation The protected latch
remains effective across ordinary process restarts where required. A
crash does not automatically clear the deviation state.
CW-3.23.4 — Failure During Automated Revalidation If ASR cannot
establish that the operation is permitted, it does not return an
allow result. The operation remains held or follows the applicable
escalation path.
CW-3.23.5 — Failure While Waiting for Human Approval The pending
approval record may be stored durably. The user interface need not
block an execution thread while awaiting a decision. Failure or
expiration does not become automatic approval.
CW-3.23.6 — Failure After Approval but Before Authority Generation
The system recovers the authenticated decision and protected state.
9.3.45. Source global page 163
Authority may be generated only if the decision remains valid and
unconsumed under current conditions.
CW-3.23.7 — Failure After Authority Consumption The system determines
whether effectuation was initiated. Consumed authority is not
automatically restored. Where the actual outcome is uncertain, the
relevant CW-2 procedures apply.
CW-3.23.8 — User Disconnection Where user authorization is required
but unavailable, the affected operation remains withheld. Unrelated
operations may proceed within independently valid scope.
CW-3.23.9 — Protected Policy Change A change in mandatory protected
policy invalidates affected pending decisions as required by the
policy-version semantics. The system does not blindly apply a stale
approval to a materially changed security context.
Das Expires 29 April 2027 [Page 142]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.23.10 — Emergency or Degraded Operation An emergency policy may
define specific preauthorized actions under defined conditions. An
emergency label alone does not permit an agent to bypass mandatory
technical constraints. Any special authority must be established
through the applicable protected procedure.
CW-3.24 — OPTIONAL IMPLEMENTATION VARIANTS Variant A — Operating-
System-Integrated Scope Monitor. Scope deviations are detected
through protected operating-system interfaces and enforced at
designated device-side Finality Sinks. Variant B — Hardware-Isolated
Scope Adjudicator. Scope comparison, protected policy state, or
authority issuance operates within a trusted execution environment or
other hardware-isolated component. Variant C — IEV-Driven Deviation
Detection. An IEV identifies a deviation during independent
verification of an actual pending operation. Variant D — Post-Phase
Scope Reassessment. Verified outcomes from CW-2 update the
cumulative task scope state before subsequent phases. Variant E —
Network-Egress-Based Scope Enforcement. Actual destinations and
outgoing data classes are checked at a controlled transmission
boundary.
9.3.46. Source global page 164
Variant F — Storage-Effect-Based Scope Enforcement. Actual storage
objects, modifications, and exports are checked against authorized
resource scope. Variant G — Credential-Release Scope Enforcement. A
protected credential broker withholds a credential or authority-
enabling secret when the requested operation exceeds permitted scope.
Variant H — Multi-Agent Scope Continuity. Delegated agents remain
subject to a protected original-task authority lineage. Variant I —
Cross-Device Scope Continuity. An OASE or valid attenuated scope is
authenticated across multiple devices. Variant J — Enterprise Multi-
Principal Approval. A scope expansion may require both user and
organizational approval. Variant K — User-Only Approval. A consumer
device permits reauthorization by the applicable authenticated user
where policy allows.
Das Expires 29 April 2027 [Page 143]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Variant L — Automated False-Positive Clearance. A protected verifier
establishes that a flagged operation remains within the original
scope without interrupting the user. Variant M — Preauthorized
Conditional Scope. The OASE contains bounded rules permitting
specified changes under authenticated conditions. Variant N — Strict
Denial Mode. Detected deviations requiring new authority are denied
rather than offered for approval. Variant O — Human Reauthorization
Mode. Eligible deviations are presented through a trusted approval
interface. Variant P — Risk-Adaptive Escalation. Monitoring signals
influence the required evidence or approval path without
independently conferring authority. Variant Q — Cumulative
Disclosure Control. The PSSA tracks aggregate information disclosure
across multiple operations.
Variant R — Delegation-Limited Scope. Delegated agents receive
attenuated scope that cannot exceed the original authority. Variant
S — Immutable Original Scope with Versioned Changes. Valid
amendments produce new authenticated versions while preserving the
original authority reference. Variant T — Privacy-Preserving
Approval Presentation. Sensitive data is represented through
protected summaries or commitments while preserving sufficient
information for an informed decision. Variant U — Per-Act
Reauthorization. Each approved deviation authorizes only one
consequential act. Variant V — Task-Bounded Reauthorization. An
approved delta authorizes a precisely described limited class of
operations within one task. Variant W — Time-Bounded
Reauthorization. An SDA expires according to authenticated time
or protected state conditions.
9.3.47. Source global page 165
Variant X — No-Human-Interface Deployment. A machine or embedded
system applies predetermined automatic validation and fail-closed
rules without interactive user approval. Variant Y — Physical
Actuation Scope Enforcement. An autonomous controller detects
movement or actuation commands outside a protected operating
envelope. Variant Z — Distributed Security-Signal Correlation.
Multiple independently authenticated monitoring sources contribute to
a scope-deviation decision. These variants are non-limiting.
Different embodiments may employ combinations of variants where
technically compatible.
CW-3.25 — DETAILED COMPARISON WITH CONVENTIONAL SYSTEMS
CW-3.25.1 — Conventional Application Permissions Conventional
application permissions determine whether software may access
particular device facilities or resources.
Das Expires 29 April 2027 [Page 144]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3 instead proposes task-specific comparison between original
protected user authority and actual consequential operation,
including cumulative effects and permitted changes over time. The
potential additional technical contribution lies in the enforceable
scope-continuity mechanism, not merely in the use of an access-
control policy.
CW-3.25.2 — Conventional Human Approval A conventional approval
system may pause an action and require user consent.
CW-3 may additionally bind the approval to: • The original protected
task scope; • The specifically observed deviation; • The current
cumulative execution state; • The exact changed operation; • The
applicable protected scope version; • The newly generated bounded
authority; • The actual operation reconstructed at the Finality Sink.
However, action-bound approval, durable approval state, and
execution-time revalidation are themselves established techniques.
The potentially inventive contribution must therefore depend upon
further technically significant features and their combined
enforcement effect.
CW-3.25.3 — Conventional Risk-Adaptive Confirmation
9.3.48. Source global page 166
A conventional risk-adaptive confirmation system may classify an
action according to static metadata and dynamic context.
CW-3 distinguishes such risk information from independently verified
deviation against an authenticated original-task authority envelope.
An action need not be inherently high-risk to exceed authorized
scope. Likewise, an action may be high-risk but explicitly within a
valid authorization. The proposed improvement is an effect-specific
scope-continuity determination that may use risk as one input without
equating risk score with execution authority.
CW-3.25.4 — Conventional Anomaly Detection An anomaly detector may
identify behavior differing from an observed baseline. Such
deviation does not necessarily establish violation of user
authorization.
CW-3 links the detected operation to protected authorized-scope
predicates and a mandatory effectuation control. The proposed
distinction is not anomaly detection itself but the protected
relationship among observed deviation, authority-state validation,
selective suspension, and sink-verified resolution.
Das Expires 29 April 2027 [Page 145]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.25.5 — Conventional Agent Guardrails Model-level guardrails may
attempt to prevent undesirable reasoning or tool selection. Such
methods can be useful but may not provide deterministic enforcement
against a compromised or manipulated agent.
CW-3 places mandatory authority decisions outside the requesting
agent's unrestricted control. The technical guarantee is limited to
the effectuation paths actually controlled by the implementation.
CW-3.25.6 — Conventional Audit Logging A post-event audit log may
record what an agent did.
CW-3 may create authenticated deviation evidence before effectuation,
use that evidence to activate a protected latch, and condition actual
release upon a valid resolution. Thus, the corresponding protected
evidence participates in authorization rather than serving solely as
retrospective documentation.
CW-3.25.7 — Conventional Workflow Replanning An AI agent may revise
its plan as new information becomes available. Replanning is not
necessarily unauthorized.
CW-3 distinguishes computational plan changes from consequential
scope changes.
9.3.49. Source global page 167
A plan may be revised freely to the extent permitted by the execution
architecture, while effect- capable operations remain subject to
protected authority.
CW-3.25.8 — Conventional Automated Approval A software policy engine
may automatically approve known low-risk operations. CW-3's proposed
ASR mechanism is specifically limited to evidence-supported existing
authority or preauthorized conditional authority. A new permission
is not minted merely because a classifier predicts that the action is
safe.
CW-3.25.9 — Conventional Approval Token An approval token may
represent consent to an action.
CW-3 proposes binding any new approval to the original task lineage,
the specific scope deviation, the authenticated presentation, the
current authority version, and the actual operation checked at the
Finality Sink. These added relationships must contribute a
demonstrable technical property to support an inventive-step
argument.
Das Expires 29 April 2027 [Page 146]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.26 — PROPOSED INVENTIVE-STEP FOCUS
CW-3.26.1 — Do Not Rely on Human Approval Alone The use of a human
approval interface is not asserted to be inventive by itself.
Likewise, an automatic security classifier, risk score, protected
token, signed receipt, or fail-closed decision is not individually
presumed novel. The proposed inventive mechanism should be evaluated
as a technical combination addressing a more specific problem.
CW-3.26.2 — First Candidate Technical Kernel: Protected Original-
Scope to Actual-Effect Continuity A first candidate technical
contribution is a protected original-task authorization structure
whose permitted effects are continuously compared with independently
reconstructed actual operations. The comparison is not based solely
upon the agent's proposed plan. It is performed using protected
scope state and evidence relating to the actual effectuation
boundary. A material discrepancy results in a protected hold.
CW-3.26.3 — Second Candidate Technical Kernel: Cumulative Scope-State
Enforcement A second candidate contribution is a protected
accumulator that binds previously authorized, consumed, pending, and
unresolved effects to the scope available for subsequent operations.
9.3.50. Source global page 168
This may detect deviations that cannot be established from one
isolated tool invocation. For example, several individually
permitted disclosures may exceed a protected cumulative disclosure
limit. The proposed technical improvement depends upon actual
protected accounting, atomic state updates, and non-bypassable
enforcement rather than the general concept of a usage quota.
CW-3.26.4 — Third Candidate Technical Kernel: Proof-Based Automatic
Revalidation Without Authority Expansion A third candidate
contribution is an adjudication protocol in which automatically
resolved deviations must be supported by authenticated evidence
proving correspondence with existing authorization or an expressly
preauthorized conditional rule. The distinction is between clearing
a false-positive indication and granting genuinely new authority.
The protocol prevents an agent-generated rationale or probabilistic
safety score from independently expanding authorization.
CW-3.26.5 — Fourth Candidate Technical Kernel: Protected Scope Delta
to Finality Authority Binding A fourth candidate contribution is a
protocol that binds: 1. The original protected scope; 2. The
independently observed actual deviation; 3. The precisely presented
scope difference; 4. The authenticated reauthorization decision; 5.
The new bounded scope version; 6. The actual operation verified at
Das Expires 29 April 2027 [Page 147]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
the Finality Sink. The required relationship is enforced through
authenticated commitments and protected state transitions. A
reauthorization is not accepted for a changed operation outside the
approved delta.
CW-3.26.6 — Fifth Candidate Technical Kernel: Selective Containment
of Suspicious Effects A fifth candidate contribution is a protected
mechanism that suspends the specific suspicious effect and necessary
dependent operations without indiscriminately terminating all
authorized agent activity. The selective-containment procedure may
operate through protected effect dependencies, mandatory sink
latches, and authenticated resolution state.
CW-3.26.7 — Sixth Candidate Technical Kernel: Scope-Version
Continuity Across Agents and Devices
9.3.51. Source global page 169
A sixth candidate contribution is preservation of original task
authority across delegated agents, devices, and execution domains,
with protected scope attenuation and versioned reauthorization. The
mechanism may prevent an agent from enlarging authority through
provider handoff, task replanning, or stale scope restoration.
CW-3.26.8 — Objective Technical Problem An illustrative objective
technical problem for inventive-step analysis may be formulated as
follows: How to permit continued autonomous execution of authorized
consequential operations while preventing an agent or intermediary
from converting a detected task-scope deviation, uncertain security
indication, or user approval interaction into broader execution
authority than the original or validly amended authorization permits,
including when the actual operation changes between planning and
effectuation. This formulation is proposed for examination and may
require refinement after identifying the closest prior art.
CW-3.26.9 — Inventive-Step Qualification The inventive-step
assessment should determine whether the particular claimed
combination would have been obvious to a PHOSITA from the relevant
disclosures and common general knowledge. For example, ordinary
policy comparison, human approval, and sink-time action binding may
already be known. The claimed technical contribution must identify
something more specific than their mere co- location. Potential
differentiating features may involve the exact protected state
relationship, cumulative- effect model, independently observed scope-
difference construction, mandatory latch semantics, constrained
reauthorization protocol, or their enforceable combination. No claim
of novelty or inventive step is established solely by describing
these mechanisms in
Das Expires 29 April 2027 [Page 148]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
greater detail.
CW-3.27 — NON-LIMITING EXPERIMENTAL VALIDATION The following
experiments are proposed and are not represented as already
performed. Experiment 1 — Ordinary Authorized Execution Configure a
legitimate task and execute a sequence of operations wholly within
its OASE. Measure whether the system allows permitted operations
without unnecessary user prompts. Experiment 2 — Out-of-Scope
Destination Authorize a document transmission to a designated
recipient.
9.3.52. Source global page 170
Substitute an unapproved destination. Verify that the protected
monitor, latch, and Finality Sink prevent unauthorized transmission.
Experiment 3 — False-Positive Resolution Generate a suspicious signal
for an operation that remains within a provably authorized resource
scope. Verify that authenticated automated revalidation can clear
the signal without granting additional authority. Experiment 4 —
Agent Self-Approval Attempt Submit a model-generated statement
claiming that the user approved a scope expansion. Verify that no
valid protected reauthorization is produced solely from the
statement. Experiment 5 — Authenticated User Approval Trigger an
eligible scope expansion. Obtain a valid user decision through the
trusted interface. Verify that the resulting SDA authorizes only the
specified operation.
Experiment 6 — Post-Approval Operation Substitution Change the
destination or resource after the user authorizes the original
operation. Verify rejection at the Finality Sink. Experiment 7 —
Approval Replay Attempt repeated use of a single-use SDA. Verify
that protected consumption prevents unauthorized reuse. Experiment 8
— Cumulative Scope Exhaustion Perform several individually valid
operations that collectively exceed a protected aggregate scope
limit. Verify that the excess operation is withheld. Experiment 9 —
Delegated-Agent Scope Expansion Permit bounded delegation to another
agent. Cause the delegated agent to request a resource outside its
attenuated authority. Verify that the resulting operation cannot
become effective through the covered sink. Experiment 10 — Security
Monitor Unavailability
Das Expires 29 April 2027 [Page 149]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
9.3.53. Source global page 171
Disable a monitoring source required for a particular high-assurance
operation. Verify that the operation is denied or deferred rather
than automatically approved. Experiment 11 — Suspended Operation
Crash Recovery Activate a PDL and terminate the coordinating process.
Verify that restarting the process does not automatically release the
suspended operation. Experiment 12 — Trusted Approval Presentation
Integrity Generate an approval request from authenticated structured
data. Attempt to replace the displayed recipient or operation
parameters through an untrusted component. Verify that the protected
approval protocol rejects the substitution. Experiment 13 — Hard
Denial Override Attempt Cause a mandatory cryptographic or protected
authority check to fail. Obtain a nominal user approval.
Verify that the invalid operation remains denied. Experiment 14 —
Late Detection and Containment Allow a test effect to occur before an
anomaly is detected. Verify that the system accurately records the
prior consequence and prevents unauthorized subsequent effects
without falsely claiming retroactive prevention. Experiment 15 —
Selective Workflow Continuation Suspend one suspicious operation
while executing unrelated authorized operations. Verify that the
affected operation remains blocked and independently safe operations
retain permitted progress. Experiment 16 — Cross-Device Scope
Continuity Transfer a bounded task authorization to another device.
Attempt to use an outdated or expanded scope on either device.
Verify that the applicable protected scope-version and authority
checks reject unauthorized
operations. Experiment 17 — Multiple Concurrent Approval Attempts
Submit concurrent authorization requests for the same single-use
operation. Verify that protected state prevents multiple independent
consumptions.
9.3.54. Source global page 172
Experiment 18 — Automated Classifier Error Cause a probabilistic
anomaly classifier to incorrectly recommend permission. Verify that
a mandatory deterministic scope predicate still prevents an out-of-
scope effect.
CW-3.28 — TECHNICAL MEASUREMENTS Relevant measurements may include: •
Unauthorized out-of-scope effectuation rate; • Scope-deviation
detection rate; • False-positive suspension rate; • Automatic
revalidation success rate; • Unauthorized authority-expansion rate; •
Human approval frequency per completed task; • Time spent awaiting
reauthorization; • Number of duplicate approval prompts; • Replayed
approval acceptance rate; • Actual-operation substitution acceptance
Das Expires 29 April 2027 [Page 150]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
rate; • Protected latch bypass rate; • Cumulative-scope accounting
correctness; • Cross-agent authority attenuation correctness; •
Crash-recovery state integrity; • Security-monitoring overhead; •
Effectuation latency; • Safe autonomous task completion rate; • User
interruption rate; • Privacy exposure from approval presentation.
Measurements should distinguish actual hardware enforcement,
protected-service prototypes,
software-only simulations, and theoretical guarantees. A low number
of user prompts is not a sufficient security metric if unauthorized
effects are thereby permitted.
9.3.55. Source global page 173
Likewise, a system that denies every operation may achieve a low
unauthorized-effectuation rate while failing its intended autonomous
functionality. Experiments should evaluate both security
preservation and useful permitted execution.
CW-3.29 — PHOSITA IMPLEMENTATION SUPPORT A person having ordinary
skill in secure operating systems, agent orchestration, capability-
based authorization, cryptographic protocols, trusted execution
environments, distributed state management, and secure user-interface
design may implement the disclosed workflow using suitable
combinations of the described components. A non-limiting reference
implementation may include: 1. A task-authority initialization
service; 2. A protected OASE registry; 3. A protected PSSA; 4. A
controlled agent execution gateway; 5. An operating-system or
application security monitor; 6. A scope comparison engine; 7. A
protected deviation-evidence store; 8. A PDL controller; 9. An
independent ISA; 10. An ASR component; 11. A trusted approval
interface; 12. An authenticated reauthorization service;
13. A scope-delta authority issuer; 14. A Finality Sink verifier;
15. A protected event and outcome store; 16. A crash and fault-
injection test harness. The initial prototype may use protected or
simulated protected software processes. A higher-assurance
deployment may use hardware-backed state, protected controllers, or
isolated execution environments. The claimed protection against
compromised privileged software depends upon the actual protected
enforcement substrate and the coverage of relevant effectuation
paths.
9.3.56. Source global page 174
The specification does not presume that ordinary application code can
prevent a fully compromised operating-system kernel from bypassing an
effectuation mechanism that the kernel exclusively controls.
Das Expires 29 April 2027 [Page 151]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-3.30 — RELATIONSHIP TO EMBODIMENTS 1 AND 2
CW-3 may operate in combination with Embodiment 1. For example, a
scope expansion requested by one agent may also conflict with an
operation reserved by another agent. The protected conflict-
arbitration mechanism may therefore remain mandatory even after a
valid user reauthorization. A new SDA does not override an
incompatible protected effect reservation.
CW-3 may also operate in combination with Embodiment 2. For example,
an IEV may observe that a successor phase's actual operation differs
from the originally authorized task scope. The IEV may generate an
SDO and activate a protected deviation latch. The phase remains
withheld pending automated revalidation or valid reauthorization. A
permitted scope change may then become part of the successor-specific
protected continuation conditions. The successor Finality Sink
verifies both the applicable CW-2 continuation authority and CW-3
scope authorization. The three mechanisms remain technically
distinguishable.
CW-1 governs execution-finality authorization and sink verification.
CW-2 governs optional independent pre-effect or inter-phase
validation and continuation.
CW-3 governs optional deviation from protected task authority,
automated resolution, secure reauthorization, and related scope-state
enforcement. No single mechanism automatically replaces the others.
CW-3.31 — SUPPORT FOR POTENTIAL CLAIMED SUBJECT MATTER The present
disclosure provides technical support for consideration of claims
directed to the following mechanisms and combinations. Claim-support
aspect 1: Protected construction of an original task-specific
authority envelope. Claim-support aspect 2: Protected maintenance of
cumulative scope-consumption state.
9.3.57. Source global page 175
Claim-support aspect 3: Independent observation of an actual
operation at or before a controlled effectuation boundary. Claim-
support aspect 4: Detection of a material difference between the
actual operation and authenticated original task authority. Claim-
support aspect 5: Generation of authenticated deviation evidence
bound to the Candidate Act. Claim-support aspect 6: Mandatory
protected suspension of the affected consequential operation. Claim-
support aspect 7: Classification of deviation indications according
to verifiable scope conditions. Claim-support aspect 8: Automated
revalidation limited to existing authorization or expressly
Das Expires 29 April 2027 [Page 152]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
preauthorized conditional authority. Claim-support aspect 9:
Protected selection between automatic continuation, user
reauthorization, and mandatory denial.
Claim-support aspect 10: Trusted generation of an approval
presentation from authenticated operation and scope-difference
evidence. Claim-support aspect 11: Cryptographic binding of a user
decision to the specifically displayed scope delta. Claim-support
aspect 12: Generation of a new bounded scope authorization rather
than unrestricted approval override. Claim-support aspect 13:
Versioned continuity between original authorization and valid scope
amendments. Claim-support aspect 14: Finality Sink verification of
actual pending operation against current scope authorization. Claim-
support aspect 15: Protected consumption of single-use deviation
approval authority. Claim-support aspect 16: Prevention of
authorization expansion through delegated agents. Claim-support
aspect 17: Prevention of cumulative out-of-scope effects through
protected effect
accounting. Claim-support aspect 18: Protected persistence of
deviation latches across process failures. Claim-support aspect 19:
Non-overridable security predicates that remain mandatory following
human approval. Claim-support aspect 20: Selective continuation of
independently authorized operations while a suspicious effect remains
suspended. Claim-support aspect 21: Optional IEV-triggered scope
deviation during pre-effect or inter-phase verification.
9.3.58. Source global page 176
Claim-support aspect 22: Cross-device or cross-provider preservation
of authenticated scope lineage. Claim-support aspect 23: Protected
correlation of independently authenticated security signals with
actual operation evidence. Claim-support aspect 24: Protected
outcome-state updates for operations whose effects remain uncertain.
Claim-support aspect 25: Separate authorization of recovery following
detected or completed unauthorized effects. These potential
limitations may support system, method, device, controller, or
computer-readable- medium claims where the applicable requirements
are satisfied. Whether each limitation, or a selected combination,
possesses novelty and inventive step must be assessed against the
relevant prior art.
CW-3.32 — INDUSTRIAL APPLICABILITY The workflow may be applied to
autonomous systems in which computational entities have authority to
perform useful operations without continuous direct human
supervision. Illustrative applications include: Consumer smartphones
and personal AI assistants; Desktop agent environments; Enterprise AI
automation; Agentic financial services; Cloud-hosted autonomous
Das Expires 29 April 2027 [Page 153]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
agents; Secure application-function frameworks; Autonomous software-
development agents; Document processing and data-export systems;
Robotics and autonomous machines; Vehicle computing systems;
Industrial control interfaces; Wearable and spatial computing
devices; Healthcare software workflows, subject to applicable
professional and technical safeguards; Protected identity and
credential services; Multi-agent enterprise orchestration systems;
9.3.59. Source global page 177
Cross-provider and cross-device autonomous workflows. The technical
value arises from reducing unnecessary human interruption while
preserving enforceable control over material changes in authorized
consequential behavior. Industrial suitability depends upon reliable
authority representation, appropriate evidence sources, protected
state, and actual effectuation-boundary integration.
CW-3.33 — FINAL NON-LIMITING TECHNICAL SUMMARY The present Common
Workflow CW-3 discloses an optional protected architecture for
identifying and resolving potential deviations by autonomous
computational entities from originally authorized task scope. An
initial protected authority envelope represents the permitted task
purpose, effects, resources, destinations, delegation conditions, and
other relevant constraints. A protected scope-state mechanism
maintains applicable current authority and cumulative effect
information. One or more independent monitors obtain evidence
concerning actual or proposed agent operations. Where a possible
scope deviation is detected, an authenticated evidence bundle
identifies the relevant operation, protected scope reference, and
observed difference. A protected latch may prevent the affected
consequential operation from becoming effective.
An independent adjudicator determines whether the operation remains
authorized, can be automatically revalidated under existing or
expressly conditional authority, requires a new approval from an
appropriate principal, or must be denied. Where automatic
revalidation establishes that the operation is already permitted, the
system may allow the operation to continue without human
interruption, subject to ordinary finality verification. Where new
authority is required and permitted, a trusted user interface
presents an authenticated description of the precise proposed scope
change. Following valid user approval and satisfaction of mandatory
technical constraints, a new bounded Scope-Delta Authorization may be
prepared. The actual pending operation is independently verified at
the designated Finality Sink against
Das Expires 29 April 2027 [Page 154]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
current scoped authority, protected deviation resolution, applicable
state, and consumption conditions. An approval of one deviation does
not automatically authorize unrelated operations or future
expansions. A mandatory security violation does not become
authorized merely because a user or agent expresses approval. The
workflow may operate with CW-1 execution-finality control and
optional CW-2 phase validation while remaining independently
applicable to single-act scope-deviation governance.
9.3.60. Source global page 178
The architecture thereby proposes a protected mechanism for
maintaining continuity between originally authorized user purpose,
actual autonomous-agent behavior, independently verified security
deviations, bounded reauthorization, and final consequential
execution. The central proposed technical contribution is not
ordinary human approval or anomaly detection, but the enforceable,
versioned, evidence-bound relationship between original task
authority, cumulative actual effects, independently identified scope
deviations, protected adjudication, precisely bounded new authority,
and sink-local verification of the actual operation. The novelty and
inventive step of any claimed implementation depend upon its specific
technical features, the applicable prior art, and the technical
effects demonstrated or credibly established.
END OF COMMON WORKFLOW CW-3.
SUPPLEMENTARY TECHNICAL DISCLOSURE CW-IMP-1
PRESENT-DAY PHOSITA IMPLEMENTATION OF COMMON MASTER WORKFLOWS
CW-1, CW-2, AND CW-3 USING EXISTING COMPUTING TECHNOLOGIES WITH
PROTECTED AUTHORITY DEPENDENCIES, ACTUAL-EFFECT FINALITY, RECEIPT-
CONSTITUTED CAUSAL CONTINUATION, AND SCOPE-DEVIATION-CONTROLLED
REAUTHORIZATION CW-IMP-1.0 — PURPOSE AND RELATIONSHIP TO THE ORIGINAL
COMMON WORKFLOWS CW-IMP-1.0.1 — Purpose The present supplementary
technical disclosure explains how a person having ordinary skill in
the art, hereinafter PHOSITA, may implement Common Master Workflow
CW-1, Common Workflow CW-2, and Common Workflow CW-3 using presently
available software, computing hardware, cryptographic mechanisms,
operating-system security interfaces, authenticated communication
protocols, transactional resource controllers, secure storage
mechanisms, and existing authorization infrastructure. The purpose
is not to claim that the underlying computing components are
individually invented. The purpose is to disclose specific protected
technical arrangements in which those components are
Das Expires 29 April 2027 [Page 155]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
made to interact so that the authority to produce an actual
consequential effect remains distinguishable from the computational
ability to propose, prepare, schedule, or request that effect. The
disclosed implementations further distinguish: 1. Protected
authorization for a proposed consequential operation under CW-1. 2.
Validator-accepted actual-effect evidence constituting a necessary
enabling condition for a successor consequential phase under the
principal receipt-gated CW-2 implementation. 3. Protected
containment, independent adjudication, and appropriately scoped
reauthorization following deviation from an originally authorized
operation under CW-3.
10. Supplementary Technical Implementation of CW-1, CW-2, and CW-3
The original first PDF includes a separate supplementary
implementation disclosure after CW-3 and before Embodiment 1. Its
detailed source material appears on global pages 179–248 and is
reproduced below in page-indexed form to retain implementation
qualifications, cross-workflow dependencies, examples and additional
technical support rather than replacing these with a brief overview.
10.1. Source global page 179
These workflows may be implemented independently where technically
sufficient. They may also be combined. A combination does not
automatically make optional mechanisms of one workflow mandatory in
another.
CW-IMP-1.0.2 — Preservation of the Original CW-1 Disclosure CW-1
remains the common foundational architecture. Its defining
relationship comprises: • Candidate Act construction. • Maintenance
of Non-Effective State. • Protected Enforcement Domain verification.
• Operation-specific protected evidence. • Scoped finality authority.
• Independent actual-operation reconstruction. • Finality Sink
verification. • Protected effectuation-state consumption. •
Controlled consequential release. The implementation examples below
explain how those relationships may be realized using existing
computing primitives.
CW-IMP-1.0.3 — Preservation of the Original CW-2 Disclosure CW-2
retains its three disclosed operational modes. Mode A: An
authenticated Interim Effectuation Validator performs required in-
line pre-effect validation of a prepared actual operation. Mode B:
An earlier bounded actual effect produces qualified observation
evidence, an authorized cryptographically identifiable IEV accepts
the evidence, and the accepted receipt is a necessary enabling factor
for the next consequential phase. Mode C: A combined arrangement
requires both applicable prior-effect receipt acceptance and current
Das Expires 29 April 2027 [Page 156]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
in-line validation of the successor operation. The principal inter-
phase implementation is Mode B. The prior real-effect receipt must
not be reduced to a mere scheduler-completion flag, audit log, or
optional informational record.
CW-IMP-1.0.4 — Preservation of the Original CW-3 Disclosure
10.2. Source global page 180
CW-3 retains the Original Authorized Scope Envelope, Protected Scope-
State Accumulator, Scope- Deviation Observation, Scope-Deviation
Evidence Bundle, Protected Deviation Latch, Independent Scope
Adjudicator, Automated Scope Revalidation, Protected Scope Delta,
Trusted Approval Presentation Record, Protected Reauthorization
Decision, Scope-Delta Authorization, Protected Scope-Version Chain,
Non-Overridable Security Constraint, and Scope-Deviation Resolution
Record. It further retains the distinction between: An operation
already within valid original authority; An apparent deviation that
can be conclusively resolved through protected automated
verification; A genuinely new consequential scope requiring
appropriate additional authorization; And a non-overridable technical
security failure.
A new human approval does not override a mandatory failed security
predicate.
CW-IMP-1.0.5 — Fundamental Technical Relationship The common
principle is: Computation is not authority to act. More
specifically: An authenticated computational requester does not
necessarily have the right to produce every resource effect it can
technically request. An authentic historical receipt does not
necessarily constitute current unrestricted permission. A valid
human approval for a particular change does not independently permit
an unrelated or technically prohibited operation. The actual
consequential operation remains subject to independent protected
effectuation-boundary control.
CW-IMP-1.0.6 — Implementation-Neutral Technical Characteristics A
selected implementation may use: A protected software service; A
transactional database; An operating-system security component; A
hardware security module; A secure element; A protected
microcontroller; A trusted execution environment;
Das Expires 29 April 2027 [Page 157]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
10.3. Source global page 181
A cryptographically authenticated remote service; A resource-specific
API gateway; A controlled database commit path; A protected device
command interface; Or a combination of these mechanisms. The
particular choice of physical or software substrate does not
independently define the claimed technical contribution. The
relevant distinction lies in the protected ordering, dependency,
operation correspondence, and mandatory enforcement relationships
established by the selected implementation. PART I — PHOSITA
IMPLEMENTATION OF CW-1
CW-IMP-1.1 — IMPLEMENTATION OBJECTIVE FOR CW-1 The technical
objective is to prevent an autonomous computational requester from
directly producing a covered consequential effect unless a protected
authority controller has established operation-specific authorization
and the actual Finality Sink has verified that authorization against
the operation really presented for effectuation. A PHOSITA may build
a minimum implementation using three separately controlled logical
components: Component A — Autonomous Requester: Generates proposed
actions but lacks direct authority over the protected resource.
Component B — Protected Enforcement Domain: Maintains current
permission, evidence, policy, and finality-authority state.
Component C — Finality Sink: Controls the actual resource mutation,
data release, payment
instruction, or device command. The critical implementation
requirement is that Component A cannot avoid Components B and C when
causing the covered consequence. The components may reside on
separate machines or within one suitably protected machine.
CW-IMP-1.2 — EXISTING TECHNOLOGY: AUTHORIZATION SERVER A PHOSITA may
use an established authorization service to identify the original
principal and permitted operation scope. Possible mechanisms
include: OAuth-compatible authorization; Structured authorization-
detail records;
10.4. Source global page 182
Enterprise identity and access-management services; Role-based access
control; Attribute-based access control; Resource-specific access-
control lists; Authenticated policy engines; And protected
application permission registries.
CW-IMP-1.2.1 — Technical Use The authorization mechanism supplies
evidence concerning the original permission. For example, the
originating principal may authorize an automated system to upload
Document X to Recipient Y. The authorization evidence may specify:
Das Expires 29 April 2027 [Page 158]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
AUTHORIZATION_EVIDENCE = { principal_id, permitted_operation:
"DOCUMENT_UPLOAD", permitted_document: "DOCUMENT_X",
permitted_recipient: "RECIPIENT_Y", permitted_effect_count: 1,
permission_generation: 17, revocation_state: "ACTIVE" } The protected
architecture does not interpret a general permission to invoke the
upload service as authority to upload arbitrary documents to
arbitrary recipients.
CW-IMP-1.2.2 — Candidate Technical Interaction The source
authorization is converted into a protected constraint on the actual
resource operation. The relationship may be expressed as:
PERMISSION_EVIDENCE | v
PROTECTED EFFECT-SCOPE RESOLUTION | v
CANDIDATE ACT BINDING | v
SEPARATE FINALITY ELIGIBILITY | v
ACTUAL RESOURCE-SIDE VERIFICATION The protected effect-scope
resolution must preserve the original authorization boundaries.
10.5. Source global page 183
It must not expand permission merely because the requester's
application interface accepts broader parameters.
CW-IMP-1.3 — EXISTING TECHNOLOGY: CANDIDATE ACT CONSTRUCTION A
PHOSITA may use an existing structured-data parser and typed
application schema to construct a Candidate Act. A representative
structure comprises: CANDIDATE_ACT = { ca_id, original_principal,
requesting_agent, original_grant_id, operation_class,
actual_resource_identifier, destination_identifier,
operation_parameters, permitted_effect_envelope,
current_authority_generation, designated_finality_sink,
schema_version, protected_context_reference } The fields may be
encoded through: Typed application structures; Deterministic CBOR;
Canonical JSON; Protocol Buffers with an expressly specified
deterministic identity representation; Or another suitably defined
encoding.
CW-IMP-1.3.1 — Why Canonicalization Is Technically Important Two
components may interpret the same serialized operation differently.
Examples include: Different Unicode representations of resource
names; Different numerical representations of payment amounts;
Ambiguous path normalization; Duplicate structured-data keys;
Different query-parameter handling; Resource aliases;
Das Expires 29 April 2027 [Page 159]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
10.6. Source global page 184
And different operation-schema versions. A cryptographic hash of
ambiguous input does not establish a correct shared understanding of
the operation. Accordingly, a principal implementation may define
one protected canonical effect representation.
CW-IMP-1.3.2 — Payment Amount Example Payment values may be
represented using exact integer minor units and an explicit currency
identifier. An operation authorizing 100 units of one currency must
not become authorization for another currency merely because the
serialized number is identical. The authorized descriptor may also
identify the payment recipient, source account, and resource-
generation conditions.
CW-IMP-1.3.3 — Candidate Technical Distinction The relevant technical
feature is not the use of JSON, CBOR, or hashing alone. It is that
the protected canonical operation descriptor becomes a mandatory
comparison object at the actual Finality Sink.
CW-IMP-1.4 — EXISTING TECHNOLOGY: NON-EFFECTIVE HOLD A PHOSITA may
implement the Non-Effective State using an existing resource-control
primitive. Possible examples include: A request queue that cannot
dispatch externally without protected release; An uncommitted
database mutation; A withheld application-service invocation; A
credential broker that does not expose the required secret; A storage
command held behind a protected gate; A network egress rule
preventing direct transmission; A device command buffer whose
enablement is controlled by protected hardware; Or a resource
transaction held pending finality authorization.
CW-IMP-1.4.1 — Essential Requirement The hold must actually prevent
the covered consequence. Merely recording an intention not to
execute is insufficient.
10.7. Source global page 185
CW-IMP-1.4.2 — Database Variation A protected service may maintain a
pending mutation descriptor outside the live resource transaction.
Before actual commit, the database resource controller reconstructs
and verifies the mutation. Where an uncommitted transaction is used
as the hold, the implementation must account for transaction
lifetime, locks, resource changes, and timeouts.
CW-IMP-1.4.3 — Network Variation A controlled outbound gateway may
hold an HTTP request until validation. The agent must lack another
permitted uncontrolled route to perform the covered operation.
Das Expires 29 April 2027 [Page 160]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-IMP-1.4.4 — Hardware Variation A device may hold an actuation
command in a protected queue. The final hardware command interface
refuses activation until the required authority state is valid.
CW-IMP-1.4.5 — Candidate Technical Interaction The Non-Effective
State is connected to protected authority formation and actual
resource-side release. The distinction is between an advisory
approval procedure and an enforceable transition that cannot be
bypassed within the claimed effectuation coverage domain.
CW-IMP-1.5 — EXISTING TECHNOLOGY: PROTECTED ENFORCEMENT DOMAIN A
PHOSITA may use an existing isolated service or suitable protected
computing environment to implement the PED. The PED may maintain:
Current source-authority state; Revocation generations; Evidence
commitments; Required verification-module results; Operation-specific
finality eligibility; Protected consumption references; And current
effectuation-path state. The PED may be implemented as:
10.8. Source global page 186
A privileged operating-system service with controlled IPC; A hardened
remote authorization service; A suitably isolated virtual machine; A
hardware-backed trusted execution component; Or a protected
microcontroller.
CW-IMP-1.5.1 — Software Trust Model A separate software service can
prevent an ordinary agent process from modifying protected state when
operating-system isolation remains trustworthy. It does not
automatically resist complete compromise of the same privileged
kernel.
CW-IMP-1.5.2 — Hardware Trust Model Protected hardware may provide
stronger isolation of selected keys or state. However, hardware
protection does not automatically establish correct operation
semantics or actual resource authorization.
CW-IMP-1.5.3 — Candidate Technical Relationship The PED establishes
operation-specific authority while the Finality Sink retains
responsibility for independently verifying the actual pending
consequence. A protected authorization response is not merely a
reusable credential giving the agent unrestricted access.
CW-IMP-1.6 — EXISTING TECHNOLOGY: PROTECTED EVIDENCE A PHOSITA may
use: Message authentication codes; Digital signatures; Authenticated
protected service responses; Protected transaction records; Resource-
version evidence; Secure device observations; And protected
application-state interfaces. A representative validation record may
comprise: PROTECTED_VALIDATION_EVIDENCE = {
Das Expires 29 April 2027 [Page 161]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
10.9. Source global page 187
candidate_act_digest, source_grant_reference,
evaluated_effect_envelope, current_resource_reference,
required_module_set, actual_module_results, authority_generation,
policy_generation, validation_instance_identity, evidence_commitment
} The record should identify what was actually verified. A signature
authenticates the signed data under the applicable key assumptions.
It does not independently prove the correctness of untrusted data
signed by a compromised or insufficiently qualified source.
CW-IMP-1.7 — EXISTING TECHNOLOGY: MANDATORY MODULE SELECTION A
PHOSITA may use a policy engine and typed verification-module
registry. The applicable module set may be derived from: The actual
operation class; The protected resource class; The source-authority
envelope; The current policy generation; And the current enforcement-
path requirements. The requesting agent may propose an operation
classification. However, the protected controller independently
determines the mandatory verification modules. For example:
REQUIRED_MODULES("FILE_EXPORT") = { RESOURCE_IDENTITY,
DESTINATION_PERMISSION, CURRENT_REVOCATION, EFFECTUATION_COVERAGE } A
protected privacy policy may additionally require cumulative
information-exposure verification. A financial transfer may require
a resource-version or spending-limit module.
A hardware actuation may require current device ownership and
physical safety conditions.
CW-IMP-1.7.1 — Technical Interaction
10.10. Source global page 188
A mandatory verification predicate cannot be bypassed merely because
the agent omits it from a request. An authenticated result from a
different verification module does not replace the required
predicate.
CW-IMP-1.8 — EXISTING TECHNOLOGY: NON-BEARER FINALITY AUTHORITY A
PHOSITA may implement operation-specific non-bearer finality
authority using a protected database row, server-side capability
registry, hardware-controlled authorization slot, or suitable secure
command controller. A representative protected authority record may
comprise: FINALITY_AUTHORITY = { authority_id, candidate_act_digest,
designated_finality_sink, authorized_actual_effect_digest,
source_authority_generation, required_validation_commitment,
policy_generation, resource_generation, permitted_use_count: 1,
consumed_use_count: 0, status: "PREPARED" } The agent may receive a
reference to the protected authority. The reference does not itself
Das Expires 29 April 2027 [Page 162]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
provide sufficient authority to release the real resource operation.
The designated Finality Sink must retrieve or verify the
corresponding current protected state.
CW-IMP-1.8.1 — Why an Ordinary Token Is Not Necessarily Equivalent A
conventional API credential may be reusable across several resource
requests. The selected finality authority is bound to a specified
actual operation or bounded effect class. Its valid exercise depends
upon the current designated sink, relevant source authorization, and
protected consumption conditions.
CW-IMP-1.8.2 — Alternative Cryptographic Realization A signed
operation-specific authorization may be used. However, a signature
alone does not establish single-use consumption. The sink must also
maintain authoritative replay or usage state when that property is
required.
CW-IMP-1.8.3 — Candidate Technical Interaction
10.11. Source global page 189
Protected finality authority is constituted from accepted validation
evidence but is not identical to the original permission or
historical validation record.
CW-IMP-1.9 — EXISTING TECHNOLOGY: ACTUAL FINALITY SINK The critical
PHOSITA implementation step is the construction of a resource-side
gate that controls the actual consequential primitive. A selected
Finality Sink may be: A database commit service; An authenticated
remote API resource server; A file-system mutation controller; A
credential broker; A network data-release gateway; A payment
dispatcher; A hardware command interface; Or another effect-capable
resource boundary.
CW-IMP-1.9.1 — Independent Operation Reconstruction The sink obtains
the actual pending operation from its controlled resource interface.
For example, a database sink may inspect: The target record; The
mutation type; The actual new values; The transaction identifier; The
expected resource version; And the effective principal. A network
sink may inspect the actual destination, method, path, body, and
application-level operation fields visible within its qualified
enforcement boundary. A hardware sink may inspect the actual command
buffer and target device identity.
CW-IMP-1.9.2 — Actual Equality Predicate The protected sink verifies
that the actual operation lies within the authorized effect envelope.
A representative relation is:
Das Expires 29 April 2027 [Page 163]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
10.12. Source global page 190
[ \operatorname{ActualEffect}(O) \in
\operatorname{AuthorizedEnvelope}(CA) ] The relation may comprise
exact equality, bounded membership, or another expressly defined
technical correspondence predicate.
CW-IMP-1.9.3 — Current Authority Predicate The sink verifies the
applicable current source-authority state.
CW-IMP-1.9.4 — Current Resource Predicate The sink verifies resource
version, ownership, reservation, or other mandatory technical
conditions.
CW-IMP-1.9.5 — Consumption Predicate The sink verifies that the
authority has not already been exhausted or invalidated.
CW-IMP-1.9.6 — Protected Release Only after the required checks pass
does the sink perform the protected release transition.
CW-IMP-1.10 — DATABASE IMPLEMENTATION WITH TRANSACTIONAL STATE A
PHOSITA may implement a strong single-resource variant using a
transactional database. The following conceptual tables may be
maintained: SOURCE_GRANTS grant_id principal_id resource_scope
operation_scope authority_generation revocation_state CANDIDATE_ACTS
ca_id grant_id canonical_effect_digest designated_sink status
VALIDATION_EVIDENCE evidence_id ca_id verified_effect_digest
policy_generation authority_generation
10.13. Source global page 191
result FINALITY_AUTHORITY finality_id ca_id effect_digest
designated_sink remaining_uses status FINALITY_ATTEMPTS
logical_operation_id finality_id operation_digest dispatch_state
outcome_state
CW-IMP-1.10.1 — Strong Local Transaction Where the actual resource
mutation and the protected finality state are within the same
supported transaction scope, the sink may: Begin a transaction; Read
current source authority; Read the current resource; Reconstruct the
pending mutation; Verify the protected effect descriptor; Verify
current finality eligibility; Conditionally consume the permitted
authority; Perform the authorized resource mutation; And commit both
state transitions in one transaction. The transaction must provide
suitable isolation or conditional-update semantics for the claimed
concurrency guarantee.
Das Expires 29 April 2027 [Page 164]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-IMP-1.10.2 — External Effect Boundary Where the final effect is a
remote payment, network transmission, or physical command, the local
database transaction cannot automatically make the remote effect
atomic with local consumption. The implementation may instead commit
a durable effect attempt and use controlled dispatch, receiver-side
operation identity, and qualified outcome reconciliation.
CW-IMP-1.10.3 — Technical Effect
10.14. Source global page 192
In the supported local-transaction variant, protected finality
consumption and the actual resource mutation are coherently enforced.
In the remote variant, the implementation avoids pretending that
locally consumed authorization proves remote completion.
CW-IMP-1.11 — REFERENCE ALGORITHM: CW-1 FUNCTION
CW1_PROTECTED_EFFECTUATION( proposed_operation, requester_identity,
designated_sink ): ca = BUILD_TYPED_CANDIDATE_ACT(
proposed_operation, requester_identity ) REQUIRE
VERIFY_CANDIDATE_ACT(ca) REQUIRE ESTABLISH_ACTUAL_NON_EFFECTIVE_HOLD(
ca, designated_sink ) source_authority =
PED.LOAD_CURRENT_SOURCE_AUTHORITY(ca) REQUIRE VERIFY_AUTHORITY_SCOPE(
source_authority, ca ) required_modules =
PED.RESOLVE_MANDATORY_MODULE_SET(ca) evidence =
PED.COLLECT_QUALIFIED_EVIDENCE(ca) FOR EACH module IN
required_modules: REQUIRE module.VERIFY( ca, evidence,
CURRENT_PROTECTED_STATE() ) REQUIRE VERIFY_EFFECTUATION_COVERAGE( ca,
designated_sink )
10.15. Source global page 193
validation_commitment = PED.COMMIT_VALIDATION_EVIDENCE( ca, evidence
) finality = PED.PREPARE_NON_BEARER_FINALITY({ candidate_act: ca,
validation: validation_commitment, designated_sink: designated_sink,
current_authority: source_authority, permitted_uses: 1 }) actual =
designated_sink.RECONSTRUCT_ACTUAL_OPERATION() REQUIRE
designated_sink.VERIFY( actual, ca, finality,
CURRENT_SOURCE_AUTHORITY(), CURRENT_RESOURCE_STATE(),
CURRENT_CONSUMPTION_STATE() ) committed =
designated_sink.COMMIT_PROTECTED_FINALITY( actual, finality ) IF
committed != SUCCESS: RETURN DENY result =
designated_sink.RELEASE_ACTUAL_EFFECT(actual)
RECORD_QUALIFIED_ATTEMPT_STATE(result) RETURN
CLASSIFY_SUPPORTED_OUTCOME(result) Where the actual effect is
external to the protected consumption transaction, the implementation
must use an appropriate dispatch, receiver-side, and outcome-
reconciliation arrangement rather than
Das Expires 29 April 2027 [Page 165]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
infer that remote completion occurred atomically.
CW-IMP-1.12 — CW-1 IMPLEMENTATION VARIATIONS
Variation A — Authorization Server Plus Protected API Gateway
10.16. Source global page 194
A conventional authorization server establishes principal permission.
A protected controller creates operation-specific finality state. A
receiving API gateway reconstructs the actual outgoing request and
verifies finality before contacting the protected resource.
Variation B — Database-Local Finality A database transaction checks
current authority and the actual pending mutation while consuming
finality state.
Variation C — Credential-Broker Finality The agent never receives the
reusable credential. A broker exercises the credential only after
verifying the actual resource operation and protected authority.
Variation D — Operating-System Resource Gate A suitably privileged
protected service mediates covered file, process, or device effects.
A monitoring-only hook cannot substitute for mandatory blocking
enforcement.
Variation E — Hardware Command Finality A protected command register
or device controller refuses unqualified actual commands.
Variation F — Cross-Domain Finality The PED and receiving sink reside
in separate administrative domains. Authenticated evidence is
transported, but the destination retains actual operation-side
authority verification.
Variation G — Canonical Semantic Binding The implementation verifies
normalized operation parameters and current resource identity rather
than relying upon the agent's unverified description.
Variation H — Dynamic Coverage Revalidation A material change in
tool, service, driver, network path, or resource controller
invalidates relevant finality eligibility until the corresponding
mandatory enforcement coverage is reestablished.
CW-IMP-1.13 — CW-1 COMPARATIVE TECHNICAL TESTS Test CW1-A — Active
Credential, Different Operation Provide the agent with a valid
resource credential and permission for one effect. Attempt a
different target or operation.
Das Expires 29 April 2027 [Page 166]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
10.17. Source global page 195
Expected result: the actual sink refuses the unmatched effect. Test
CW1-B — Signed Approval Without Current Authority Prepare valid
earlier validation evidence. Revoke the originating permission.
Expected result: the sink rejects the operation under current
protected authority state. Test CW1-C — Replayed Finality Reference
Execute one permitted protected mutation. Reuse the finality
reference. Expected result: the second attempt cannot validly
consume already exhausted authority. Test CW1-D — Modified Actual
Request Authorize one canonical operation. Change the operation
after protected preparation. Expected result: independent actual-
operation reconstruction detects the material mismatch. Test CW1-E —
Missing Mandatory Module Omit a required technical verification
module from the agent's request.
Expected result: the protected module registry still requires the
missing predicate. Test CW1-F — Alternate Effectuation Path Attempt
the same resource effect through another API. Expected result:
within the asserted coverage domain, the alternate path remains
blocked or subject to equivalent finality enforcement. Test CW1-G —
External Outcome Unknown Release an authorized external command and
suppress its acknowledgement. Expected result: the protected system
records uncertainty instead of treating the command as definitely
unperformed.
CW-IMP-1.13.1 — Proposed Comparative Ablation A prototype may be
configured with and without the actual Finality-Sink reconstruction
requirement. The comparison may examine whether upstream
authorization alone accepts a request whose final resource target or
material parameters have changed.
10.18. Source global page 196
The resulting evidence may support a technically specific argument
about the contribution of operation-specific sink correspondence. No
experimental outcome is asserted here as already established.
CW-IMP-1.14 — CW-1 CANDIDATE TECHNICAL CONTRIBUTION The proposed
inventive relationship is not merely the presence of: OAuth; A policy
engine; Cryptographic signatures; A transactional database; Or a
gateway. The stronger candidate combination requires: An actual
enforceable Non-Effective State, protected operation-specific
evidence, a distinct scoped finality enablement, and mandatory
independent verification of the actual pending operation against
current authority and protected consumption state at the resource's
effectuation boundary. This relationship may be described as an
authority-to-effect continuity mechanism. The protected decision
Das Expires 29 April 2027 [Page 167]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
must remain applicable to the same actual consequential operation
through final release. A narrower fallback may additionally require
authenticated effectuation-path coverage and
invalidation following material path changes. PART II — PHOSITA
IMPLEMENTATION OF CW-2
CW-IMP-2.1 — IMPLEMENTATION OBJECTIVE FOR CW-2 CW-2 concerns
protected causal ordering among consequential operations. In the
principal Mode B implementation, the technical goal is not simply to
schedule Operation B after Operation A. The goal is to make the
required authority or execution-enabling condition for Operation B
depend upon acceptance of qualified evidence that the specified real
effect of Operation A occurred. A PHOSITA may implement this
arrangement using: Two actual Finality Sinks; An authenticated
actual-effect observation source;
10.19. Source global page 197
An authorized cryptographically identifiable Interim Effectuation
Validator; A protected receipt or validator-acceptance store; A
continuation controller; And a protected successor finality
mechanism. The earlier effect and later effect may occur in
different systems. The IEV may be physically separate or logically
integrated within a suitably protected component, consistent with the
original CW-2 disclosure.
CW-IMP-2.2 — THE THREE MODES MUST REMAIN TECHNICALLY DISTINCT
CW-IMP-2.2.1 — Mode A: In-Line Pre-Effect Validation A PHOSITA may
use a protected validator to inspect the actual pending operation
before the corresponding Finality Sink releases it. The IEV may
verify: The actual resource; The pending command; The source
authority; The permitted effect envelope; Current resource state; And
the current validation policy. The IEV authenticates its decision.
The Finality Sink verifies the result before effectuation. Mode A
does not necessarily require an earlier real-effect receipt.
CW-IMP-2.2.2 — Mode B: Receipt-Constituted Causal Continuation A
first actual consequential operation is performed. A qualified
observation source establishes relevant evidence of the real result.
An authorized IEV validates and accepts the evidence. The accepted
receipt becomes a necessary factor enabling the next consequential
operation. The successor Finality Sink cannot validly permit that
operation independently of the required accepted receipt.
CW-IMP-2.2.3 — Mode C: Combined Validation
Das Expires 29 April 2027 [Page 168]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
10.20. Source global page 198
The successor operation requires both: The specified accepted prior-
effect receipt; And current protected in-line validation of the
actual pending successor operation. The requirements are conjunctive
where the selected policy so specifies. An authenticated previous
receipt cannot substitute for the required current successor
validation.
CW-IMP-2.3 — EXISTING TECHNOLOGY: AUTHENTICATED VALIDATOR IDENTITY A
PHOSITA may use a digital-signature mechanism, authenticated service
identity, protected key registry, or equivalent cryptographic
credential system to identify the IEV. A representative validator
record comprises: IEV_IDENTITY_RECORD = { validator_unique_identity,
validator_public_key_reference, permitted_validation_roles,
permitted_effect_classes, permitted_resource_scope,
current_validator_generation, relevant_revocation_state,
validation_policy_reference, protected_enrollment_authentication }
The validator may use: A protected server signing key; A hardware-
backed asymmetric key; An authenticated service credential; Or
another suitable cryptographic identity.
CW-IMP-2.3.1 — Identity Versus Observation Authority The
cryptographic identity establishes which enrolled validator issued
the acceptance. It does not independently establish that the
validator observed the claimed actual effect correctly. The IEV must
also possess the applicable observation role and evidence assurance.
CW-IMP-2.3.2 — Validator Replacement A replacement validator must be
authenticated under the protected registry. An attacker cannot
substitute a permissive validator merely by using the same display
name.
CW-IMP-2.3.3 — Revocation
10.21. Source global page 199
Receipts from a validator no longer authorized for the relevant role
are handled according to the applicable trust and temporal rules.
CW-IMP-2.4 — EXISTING TECHNOLOGY: ACTUAL-EFFECT OBSERVATION A PHOSITA
may obtain effect evidence from an existing resource controller.
Possible sources include: A database transaction-commit record; An
authenticated payment processor's completed transaction state; A
protected storage controller's committed object state; A remote API's
authoritative resource-version response; A hardware position sensor;
A device-local command-execution register; Or another qualified
actual-effect observation mechanism.
Das Expires 29 April 2027 [Page 169]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-IMP-2.4.1 — Database Example A database may report that a
particular transaction committed and modified the designated
resource. The qualified evidence may identify the transaction,
affected object, resulting version, and committed state.
CW-IMP-2.4.2 — Remote API Example A remote service may return a
qualified status associated with a stable logical operation
identifier. The service's actual semantics determine whether the
status means accepted, processing, committed, or completed.
CW-IMP-2.4.3 — Physical Device Example A command acknowledgement may
establish that an actuator command was received. It may not
establish that the actuator reached its target state. A qualified
sensor or device observer may be required for the latter predicate.
CW-IMP-2.4.4 — Technical Requirement The evidence must support the
specific real-effect predicate required by the next consequential
phase.
CW-IMP-2.5 — EXISTING TECHNOLOGY: PROTECTED EFFECT RECEIPT
10.22. Source global page 200
A PHOSITA may represent the earlier effect using a typed
authenticated record. PROTECTED_EFFECT_RECEIPT = { workflow_id,
predecessor_phase_id, predecessor_candidate_act_digest,
predecessor_sink_id, actual_effect_identifier,
actual_resource_identifier, observed_effect_descriptor,
supported_effect_status, observation_source_identity,
observation_assurance_class, resource_generation,
observation_reference, evidence_authentication } The record may be: A
signed structured message; An authenticated service response; A
protected database object; A hardware-controller record; Or an
equivalent protected representation.
CW-IMP-2.5.1 — Receipt Qualification The receipt must identify which
fact is supported. For example: A payment was prepared; A payment
was transmitted; A payment was accepted for processing; Or a payment
was finally settled. These states are not universally equivalent.
CW-IMP-2.5.2 — No Automatic Validator Acceptance A protected effect
receipt is evidence submitted to the IEV. It does not automatically
become a Validator-Accepted Effect Receipt merely by existing.
CW-IMP-2.6 — IEV ACCEPTANCE AS A PROTECTED STATE TRANSITION
Das Expires 29 April 2027 [Page 170]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
10.23. Source global page 201
The IEV may verify: Its own authorization to validate the effect
class; The receipt issuer; The predecessor Candidate Act; The
predecessor Finality Sink; The actual resource identity; The observed
effect state; The expected predecessor outcome; The permitted
successor phase; The current validator identity and revocation state;
And the applicable causal policy. After successful validation, the
IEV creates an authenticated acceptance record.
VALIDATOR_ACCEPTED_EFFECT_RECEIPT = { vaer_id,
accepted_predecessor_receipt_digest,
predecessor_candidate_act_digest, verified_actual_effect_descriptor,
required_effect_predicate, validator_unique_identity,
validator_key_identity, validator_authorization_profile,
permitted_successor_phase, permitted_successor_candidate_digest,
designated_successor_sink, current_authority_generation,
current_validator_generation, receipt_consumption_reference,
protected_validator_authentication }
CW-IMP-2.6.1 — Important Technical Distinction The IEV does not
merely report that the earlier step succeeded. Its authenticated
acceptance is used as a mandatory input to the later protected
effectuation procedure.
CW-IMP-2.6.2 — Necessary Versus Sufficient Authority The VAER may
directly embody a suitably scoped successor authorization under one
selected implementation. In another implementation, the VAER is
necessary but not sufficient.
10.24. Source global page 202
The successor may additionally require current source authority,
resource state, revocation validity, and finality enablement. Both
arrangements preserve the indispensable receipt dependency where Mode
B is selected.
CW-IMP-2.7 — EXISTING TECHNOLOGY: RECEIPT-DEPENDENT KEY RELEASE A
PHOSITA may use a protected key service or hardware key manager. In
this variation, a downstream effectuation key is unavailable for
unrestricted use. The protected key service receives or retrieves
the accepted VAER. It verifies: The authorized IEV identity; The
actual predecessor-effect predicate; The intended successor; The
designated successor sink; And relevant current protected state.
Only after the required conditions pass does the key service enable
the specific successor operation.
Das Expires 29 April 2027 [Page 171]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-IMP-2.7.1 — Example A protected encryption key required for a
designated data-release operation may remain unavailable until the
VAER proves that the prerequisite authorized storage operation
actually committed. The key service may provide a protected
operation-specific decryption or release function. It need not
expose unrestricted raw key material to the agent.
CW-IMP-2.7.2 — Technical Interaction The required prior real-effect
evidence is causally connected to the availability of the downstream
protected resource operation. A copied receipt cannot independently
authorize unrelated uses when the current sink also verifies
operation and consumption state.
CW-IMP-2.7.3 — Limitation Key release alone is insufficient for a
claimed non-bypassable successor if an alternative effectuation route
or independently usable key remains available.
CW-IMP-2.8 — EXISTING TECHNOLOGY: HARDWARE LATCH OR PROTECTED
REGISTER
10.25. Source global page 203
A PHOSITA may implement receipt-dependent continuation using an
existing protected controller or hardware state register. For
example: CAUSAL_PHASE_STATE = { predecessor_phase: 1,
predecessor_effect_state: "CONFIRMED", accepted_vaer_digest,
authorized_validator_generation, successor_phase: 2,
successor_enablement: "AVAILABLE", successor_consumption: "UNUSED" }
The protected controller only permits Phase 2 when the required
accepted receipt state is present and current.
CW-IMP-2.8.1 — Hardware Variation A device may maintain a protected
enablement register. The IEV's acceptance activates a narrow
successor command condition. The device's actual command gate
separately verifies the pending command.
CW-IMP-2.8.2 — Software Variation A transactional authorization
database may maintain the equivalent state.
CW-IMP-2.8.3 — Technical Relationship The real earlier effect and
validator acceptance cause a protected state transition that becomes
indispensable for the later effect. This differs from a scheduler
merely recording an intended task order while an independently
reachable resource remains able to execute the successor.
Das Expires 29 April 2027 [Page 172]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-IMP-2.9 — EXISTING TECHNOLOGY: TRANSACTIONAL RECEIPT ACCEPTANCE A
PHOSITA may use a transactional store to maintain: The predecessor
receipt; The validator acceptance; The expected successor; The
current source authority; And protected receipt-consumption state.
The system may conditionally transition:
10.26. Source global page 204
RECEIPT_OBSERVED -> RECEIPT_VALIDATED -> VAER_COMMITTED ->
SUCCESSOR_ELIGIBLE -> SUCCESSOR_AUTHORITY_CONSUMED Where one
transaction scope controls both acceptance and successor enablement,
the implementation may ensure that no successor-enable transition
occurs without the required authenticated acceptance state. Where
the earlier effect or successor resides in an independent external
system, the arrangement must use authenticated cross-domain state and
actual destination enforcement. It cannot assume global atomicity
merely because local acceptance was transactional.
CW-IMP-2.10 — RECEIPT-TO-SUCCESSOR BINDING The accepted VAER may
bind: The exact predecessor; The actual earlier resource effect; The
identity of the accepting IEV; The relevant validator authorization
generation; The designated successor phase; The permitted successor
effect envelope; The actual successor Finality Sink; And current
receipt-consumption conditions. A narrow implementation may use one
VAER for one successor operation. A more general implementation may
permit bounded fan-out under an explicitly authorized consumption
policy.
CW-IMP-2.10.1 — Unauthorized Successor Reuse A VAER intended to
authorize an accounting update must not automatically authorize a new
payment.
CW-IMP-2.10.2 — Wrong Predecessor A receipt proving that Document A
was stored must not automatically satisfy a dependency requiring that
Document B was stored.
CW-IMP-2.10.3 — Validator Impersonation An attacker-supplied receipt
bearing an unverified validator name must be rejected.
10.27. Source global page 205
CW-IMP-2.10.4 — Actual Effect Mismatch A receiver acknowledgement
referring to a different logical transaction cannot satisfy the
expected predecessor predicate.
CW-IMP-2.11 — MODE A REFERENCE IMPLEMENTATION A practical Mode A
prototype may comprise: An autonomous agent; A protected command
queue; A protected in-line validator; A validator identity registry;
Das Expires 29 April 2027 [Page 173]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
And an actual resource Finality Sink. The agent submits a proposed
consequential command. The operation remains withheld. The IEV
independently obtains the actual command to be released. The IEV
verifies the relevant source authority, resource target, operation
parameters, and protected conditions. The validator authenticates
the acceptance result under its enrolled identity. The Finality Sink
independently verifies the applicable result and actual pending
operation. The sink permits the effect only when all required
conditions pass.
CW-IMP-2.11.1 — Distinguishing Test Modify the actual command after
the original protected preparation. An in-line IEV and sink
implementation should reject the materially changed operation.
CW-IMP-2.11.2 — Important Mode Boundary No prior real-effect receipt
is required merely by the selection of Mode A.
CW-IMP-2.12 — MODE B REFERENCE IMPLEMENTATION A practical Mode B
prototype may comprise: First, a protected storage sink FS-A.
Second, an authenticated storage-commit observation source.
10.28. Source global page 206
Third, an authorized IEV. Fourth, a protected VAER registry. Fifth,
a data-release sink FS-B.
CW-IMP-2.12.1 — Phase A An agent proposes a bounded storage
operation. FS-A verifies its operation-specific authority and
performs the actual storage mutation.
CW-IMP-2.12.2 — Actual Effect Evidence The receiving storage
controller produces qualified evidence that the specified resource
mutation committed.
CW-IMP-2.12.3 — IEV Acceptance The IEV verifies the real-effect
evidence against the expected Phase A operation and authenticates its
acceptance.
CW-IMP-2.12.4 — Protected Causal State The VAER becomes available to
FS-B through a protected channel, authenticated registry, or
protected controller state.
CW-IMP-2.12.5 — Successor Phase B FS-B obtains the actual pending
export operation. It verifies the correct accepted VAER, validator
identity, intended Phase B, current source authority, export target,
and protected consumption state.
Das Expires 29 April 2027 [Page 174]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-IMP-2.12.6 — Consequential Effect Only after the required causal
receipt and finality conditions pass may FS-B release the data.
CW-IMP-2.12.7 — Core Test Attempt the export using: A scheduler
success message; An unaccepted storage receipt; A forged validator
acceptance; A receipt for the wrong stored object; Or a previously
consumed VAER. The successor must not become valid merely because
one of these materials resembles an earlier successful step.
10.29. Source global page 207
CW-IMP-2.13 — MODE C REFERENCE IMPLEMENTATION A practical Mode C
prototype may combine the prior example with a second in-line
validation. Before Phase B becomes effective, the system verifies:
The authorized IEV's accepted actual-effect receipt from Phase A; And
a current independent validation of Phase B's actual pending
operation. For example, the earlier storage effect may be valid, but
the requested export destination may have changed. The VAER remains
authentic. However, current Phase B validation detects the
unauthorized destination. FS-B refuses the export.
CW-IMP-2.13.1 — Proposed Technical Effect The system prevents a valid
earlier effect receipt from being reused as unrestricted authority
over a materially changed successor.
CW-IMP-2.14 — REFERENCE ALGORITHM: MODE B FUNCTION
CW2_RECEIPT_CONSTITUTED_CONTINUATION( predecessor_candidate,
successor_candidate, first_sink, authorized_iev, second_sink ):
predecessor_result = CW1_EFFECTUATE_AT_SINK( predecessor_candidate,
first_sink ) effect_evidence =
OBTAIN_QUALIFIED_ACTUAL_EFFECT_EVIDENCE( predecessor_result,
first_sink ) IF effect_evidence DOES_NOT_SUPPORT_REQUIRED_EFFECT:
RETURN WITHHOLD_SUCCESSOR REQUIRE VERIFY_IEV_CRYPTOGRAPHIC_IDENTITY(
authorized_iev
10.30. Source global page 208
) REQUIRE VERIFY_IEV_AUTHORIZATION_ROLE( authorized_iev,
predecessor_candidate ) vaer = authorized_iev .VALIDATE_AND_ACCEPT({
predecessor_candidate: predecessor_candidate, actual_effect_evidence:
effect_evidence, permitted_successor: successor_candidate,
designated_successor_sink: second_sink }) REQUIRE
VERIFY_VAER_COMMITTED(vaer) actual_successor =
second_sink.RECONSTRUCT_PENDING_OPERATION() REQUIRE
VERIFY_AUTHORIZED_IEV_ACCEPTANCE( vaer ) REQUIRE
VERIFY_REQUIRED_PREDECESSOR_EFFECT( vaer, predecessor_candidate )
REQUIRE VERIFY_VAER_BOUND_TO_SUCCESSOR( vaer, actual_successor )
REQUIRE VERIFY_CURRENT_SUCCESSOR_SOURCE_AUTHORITY() REQUIRE
Das Expires 29 April 2027 [Page 175]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
VERIFY_CURRENT_SUCCESSOR_RESOURCE_STATE() REQUIRE
VERIFY_CURRENT_RECEIPT_CONSUMPTION_STATE( vaer ) REQUIRE
VERIFY_CURRENT_SUCCESSOR_FINALITY( actual_successor )
10.31. Source global page 209
committed = second_sink .COMMIT_RECEIPT_DEPENDENT_FINALITY( vaer,
actual_successor ) IF committed != SUCCESS: RETURN WITHHOLD_SUCCESSOR
RETURN second_sink .RELEASE_ACTUAL_SUCCESSOR_EFFECT( actual_successor
) Where the accepted receipt is itself the scoped finality authority,
the distinct successor-enable record may be omitted. Where the
receipt is a key-enabling or state-enabling factor, the corresponding
protected enabling transition remains mandatory.
CW-IMP-2.15 — ALTERNATIVE CW-2 IMPLEMENTATIONS
Variation A — Receipt as Direct Scoped Authority The accepted VAER
itself represents the operation-specific successor authority. The
successor sink verifies the receipt, current authority, actual
operation, and consumption state.
Variation B — Receipt-Dependent Capability Activation The VAER
activates an otherwise unusable protected finality capability.
Variation C — Receipt-Dependent Key Release A protected key service
permits the designated successor cryptographic operation only after
VAER acceptance.
Variation D — Receipt-Dependent Protected Register A hardware or
protected software controller advances the authorized causal phase.
Variation E — Integrated Validator and Sink A single suitably
protected component performs the logically distinct acceptance and
finality- verification functions.
Variation F — Physically Separate IEV An independent validator
receives authenticated real-effect evidence over a protected channel.
Variation G — Multiple Required Receipts
10.32. Source global page 210
A successor requires accepted actual-effect evidence from several
predecessors.
Variation H — Bounded Receipt Fan-Out A permitted VAER may support a
defined limited set of successors subject to individually enforced
scope and consumption rules.
Das Expires 29 April 2027 [Page 176]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Variation I — Physical Actuation A sensor-qualified real-world
predecessor effect is accepted before enabling a later actuator
command.
Variation J — Cross-Administrative Domains A first resource domain
produces a real effect, an authorized IEV accepts the evidence, and a
different domain's Finality Sink enforces the receipt-dependent
successor.
CW-IMP-2.16 — CW-2 COMPARATIVE TECHNICAL TESTS Test CW2-A — Scheduler
Ordering Without Receipt Enforcement Arrange a scheduler to execute B
after A. Attempt to invoke B directly through the effect-capable
resource interface. Evaluate whether B remains independently
executable. Test CW2-B — Mandatory VAER Configure B so its protected
Finality Sink requires the IEV-accepted real-effect receipt. Attempt
B without the accepted receipt. Expected result: the successor
remains withheld. Test CW2-C — False Completion Supply an agent-
generated assertion that A completed. Expected result: the assertion
does not satisfy the mandatory qualified real-effect predicate. Test
CW2-D — Validator Impersonation Produce a signed-looking receipt
using an unauthorized key. Expected result: FS-B rejects the
unqualified validator identity.
Test CW2-E — Real Predecessor, Wrong Successor Present a valid VAER
for another successor operation. Expected result: the actual
successor does not inherit unrelated authority.
10.33. Source global page 211
Test CW2-F — Receipt Replay Consume a single-use receipt-dependent
allowance and attempt a second effect. Expected result: protected
sink-local state prevents unauthorized additional consumption. Test
CW2-G — Changed Actual Effect Present valid evidence of a command
dispatch while the successor requires proof of a committed storage
mutation or completed physical movement. Expected result: the
evidence class is insufficient. Test CW2-H — Mode C Current
Validation Present a genuine predecessor VAER and modify the current
successor destination. Expected result: the in-line validator or
final sink rejects the changed actual operation.
Das Expires 29 April 2027 [Page 177]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-IMP-2.16.1 — Proposed Comparative Ablation A PHOSITA may test
three configurations. The first uses ordinary scheduler ordering.
The second additionally checks a signed status message. The third
requires an authenticated IEV-accepted actual-effect receipt as a
protected prerequisite verified at the successor's actual Finality
Sink. A controlled bypass attempt may determine whether the resource
can execute B when the required predecessor real effect has not
occurred. The comparison should measure actual successor effects,
not merely scheduler-reported success.
CW-IMP-2.17 — CW-2 CANDIDATE TECHNICAL CONTRIBUTION The proposed
inventive relationship is not: An event bus; A digital signature; A
workflow scheduler; A hardware register; Or an ordinary receipt. The
stronger candidate combination requires: A first bounded real effect,
qualified observation of that effect, acceptance by a
cryptographically identifiable authorized IEV, and a mandatory
successor Finality-Sink condition that makes that accepted receipt
indispensable to the later consequential effect.
10.34. Source global page 212
The causal relationship is established through protected execution
authority. It is not merely represented through intended
chronological order. A narrower fallback may require the successor
sink to verify the VAER against its independently reconstructed
actual pending operation and sink-local protected consumption state.
PART III — PHOSITA IMPLEMENTATION OF CW-3
CW-IMP-3.1 — IMPLEMENTATION OBJECTIVE FOR CW-3 CW-3 provides optional
scope-deviation governance for autonomous agents. The technical
objective is to permit legitimate autonomous operations within an
original authorized scope while preventing suspicious or genuinely
unauthorized expansions from becoming consequentially effective
merely because the agent proposes, explains, or requests them. A
PHOSITA may use existing: Policy engines; Authenticated task
registries; Operating-system security telemetry; Protected resource
gateways; Cumulative state stores; Risk or anomaly detectors; Secure
approval interfaces; Cryptographic identity services; And
transactional authority databases. The candidate technical
contribution is the protected relationship among original task scope,
independently observed deviation, effect-specific suspension,
qualified adjudication, new scope
authority where required, and actual Finality-Sink enforcement.
Das Expires 29 April 2027 [Page 178]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-IMP-3.2 — ORIGINAL AUTHORIZED SCOPE ENVELOPE At task
initialization, the protected authority service establishes an
Original Authorized Scope Envelope, or OASE. A representative
structure may comprise: ORIGINAL_AUTHORIZED_SCOPE_ENVELOPE = {
task_id, originating_principal, original_task_description_commitment,
10.35. Source global page 213
permitted_resources, permitted_effect_classes, permitted_recipients,
permitted_destinations, permitted_delegation_scope,
permitted_data_classes, cumulative_effect_limits,
permitted_conditional_transformations, applicable_expiration,
original_authority_generation, original_scope_version,
current_revocation_reference, protected_authentication }
CW-IMP-3.2.1 — Existing Technical Substrate A PHOSITA may represent
the OASE using a structured policy record in a protected database or
authorization service.
CW-IMP-3.2.2 — Important Distinction The OASE is not merely a general
application permission. It represents the original task-specific
consequential scope. For example, permission for an application to
read contacts does not necessarily mean that the agent's current task
authorizes exporting the contact database.
CW-IMP-3.2.3 — Original Reference The initial OASE remains an
authenticated reference when later scope versions are established.
The original scope is not silently rewritten by the agent.
CW-IMP-3.3 — PROTECTED SCOPE-STATE ACCUMULATOR A PHOSITA may use a
transactional database or protected counter service to implement the
Protected Scope-State Accumulator, or PSSA. The accumulator may
track: Actual permitted disclosures; Actual resource expenditures;
Current delegated authority; Executed operation classes; Used
recipients; Current resource versions;
10.36. Source global page 214
Task-specific consumption; And cumulative scope constraints.
CW-IMP-3.3.1 — Example A task may permit transmission of one expense
report to one designated accountant. The PSSA may record that the
authorized disclosure occurred. A later attempt to export unrelated
confidential records is not legitimized by the earlier permitted
message.
Das Expires 29 April 2027 [Page 179]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-IMP-3.3.2 — Atomic Updates Where multiple agents or processes
compete for one bounded allowance, the relevant accumulator may
require atomic conditional updates or appropriate protected
reservations.
CW-IMP-3.3.3 — Candidate Technical Relationship The original
authorized scope and current cumulative consequence state are jointly
evaluated against the actual pending operation. This is stronger
than evaluating each new operation in isolation where the policy
requires cumulative constraints.
CW-IMP-3.4 — INDEPENDENT SCOPE-DEVIATION OBSERVATION A PHOSITA may
use selected existing security-monitoring facilities. Examples
include: Protected tool invocation records; Application resource-
access events; Authenticated API gateway observations; Operating-
system file or process events; Network egress events; Actual database
mutation requests; Protected credential broker operations; And
suitable hardware command observations. The observer may detect: An
unexpected destination; A new resource class;
10.37. Source global page 215
A larger disclosure; A new privileged operation; An unauthorized
delegated agent; A changed operation method; Or another specified
technical discrepancy.
CW-IMP-3.4.1 — Independence Requirement Where the selected embodiment
requires independent observation, the deviation monitor must not rely
solely upon an untrusted agent's own statement of what it intends to
do.
CW-IMP-3.4.2 — Monitoring Versus Blocking A telemetry component may
observe suspicious behavior. It does not automatically prevent the
behavior. The Protected Deviation Latch and actual Finality Sink
provide the required withholding behavior under the selected
implementation.
CW-IMP-3.5 — SCOPE-DEVIATION OBSERVATION AND EVIDENCE BUNDLE The
protected monitor may construct a Scope-Deviation Observation, or
SDO. The corresponding Scope-Deviation Evidence Bundle, or SDEB, may
comprise: SCOPE_DEVIATION_EVIDENCE_BUNDLE = { task_id,
candidate_act_digest, original_oase_digest, current_scope_version,
current_scope_state_commitment, actual_pending_effect_descriptor,
observed_resource, observed_destination, expected_resource,
expected_destination, protected_scope_delta,
observation_source_identity, evidence_assurance_class,
relevant_policy_generation, deviation_classification_reference,
protected_evidence_authentication }
Das Expires 29 April 2027 [Page 180]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-IMP-3.5.1 — Specific Difference Representation A protected delta
may identify the precise mismatch.
10.38. Source global page 216
For example: ORIGINAL: recipient = ACCOUNTANT_A data = EXPENSE_REPORT
PROPOSED: recipient = EXTERNAL_RECIPIENT_B data = EXPENSE_REPORT +
CONTACTS_DATABASE DEVIATION: unauthorized_recipient
expanded_information_class
CW-IMP-3.5.2 — Candidate Technical Interaction The SDEB is not merely
an anomaly label. It binds observed actual operation data to the
protected original scope and current state. The resulting difference
may control the Protected Deviation Latch and subsequent authority
resolution.
CW-IMP-3.6 — PROTECTED DEVIATION LATCH A PHOSITA may implement the
Protected Deviation Latch, or PDL, using: A protected resource-
gateway deny state; An uncommitted resource operation; A disabled
credential-broker action; A blocked network transmission; A protected
hardware command enablement register; Or another actual withholding
mechanism. A representative latch record may comprise:
PROTECTED_DEVIATION_LATCH = { task_id, candidate_act_digest,
affected_effectuation_sink, triggering_sdeb_digest,
current_scope_version, latch_generation, latch_state: "ACTIVE",
affected_dependent_operations, authorized_release_conditions,
protected_state_authentication }
10.39. Source global page 217
CW-IMP-3.6.1 — Selective Hold The latch may block only the affected
consequential operation and its dependent effects. Unrelated
permitted computation may continue.
CW-IMP-3.6.2 — Dependent Consequences A later operation depending
upon the suspicious act may also remain withheld.
CW-IMP-3.6.3 — Protected Release The latch cannot be removed merely
because the agent changes its explanation or retries through a
different interface.
CW-IMP-3.6.4 — Non-Bypassability Within the asserted effectuation
coverage domain, the controlled resource must enforce the latch or an
equivalent protected denial state.
CW-IMP-3.6.5 — Late Observation If the effect already occurred, the
latch cannot retroactively prevent it. The system may preserve
outcome evidence and constrain later effects.
Das Expires 29 April 2027 [Page 181]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-IMP-3.7 — INDEPENDENT SCOPE ADJUDICATOR A PHOSITA may implement
the Independent Scope Adjudicator, or ISA, using a protected rules
engine and authenticated operation evidence. The adjudicator
determines whether the observed difference: Falls within existing
authority; Can be resolved through a defined preauthorized rule;
Requires a new principal decision; Violates a mandatory security
condition; Or remains unresolved. The original agent's explanation
may be retained as contextual information. It is not the final
authority for the deviation decision.
CW-IMP-3.8 — PRESERVATION OF D0–D6 CLASSIFICATION The original CW-3
classifications may be implemented as follows. Category D0 — No
Material Scope Deviation
10.40. Source global page 218
The actual pending operation corresponds to the current valid OASE.
The affected act may proceed through normal CW-1 finality validation.
Category D1 — Inconclusive Deviation Signal The available evidence is
insufficient. The system may perform further protected verification.
If the required uncertainty remains unresolved, the affected effect
remains withheld or is escalated under the applicable policy.
Category D2 — Automatically Resolvable Difference The difference can
be conclusively reconciled under existing authority. For example, a
trusted resource resolver proves two references identify the same
authorized resource. A valid protected adjudication may clear the
latch. The normal Finality Sink checks remain mandatory. Category
D3 — Eligible Scope Expansion The proposed operation exceeds current
authority but is eligible for fresh authorization by an
appropriate principal. The affected consequence remains non-
effective pending that decision. Category D4 — Additional Principal
Required The operation requires approval from another authorized
principal or protected role. Approval by an insufficiently
authorized user does not satisfy the requirement. Category D5 —
Mandatory Security Denial A non-overridable technical condition
fails. An ordinary user approval does not convert the operation into
a valid effect. Category D6 — Unresolved Effect or State Conflict A
required predecessor effect, resource version, or other protected
state cannot be established. The operation remains withheld pending
valid reconciliation.
CW-IMP-3.9 — AUTOMATED SCOPE REVALIDATION A PHOSITA may use a
deterministic or suitably constrained protected verification service
for Automated Scope Revalidation, or ASR.
Das Expires 29 April 2027 [Page 182]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
10.41. Source global page 219
Permitted examples include: Authenticated resource alias equivalence;
A verified permitted destination transformation; A current schema-
version mapping; A preauthorized temporary resource location; An
operation parameter within a protected range; An already valid
delegation; An available bounded effect allowance; Or a stronger
observation resolving a false-positive alert.
CW-IMP-3.9.1 — Core Limitation ASR can establish that the requested
effect remains within already authorized scope. ASR may also apply
an expressly preauthorized conditional rule. It cannot independently
create genuinely new discretionary permission solely because an agent
or model concludes that the operation is beneficial.
CW-IMP-3.9.2 — Technical Interaction An apparently suspicious
operation may continue without interrupting the user when a protected
predicate proves it is already authorized. This reduces unnecessary
approval ceremonies without surrendering independent actual-effect
enforcement.
CW-IMP-3.10 — PROTECTED SCOPE DELTA The Protected Scope Delta, or
PSD, may identify the precise technical difference between existing
and proposed operation authority. A representative structure may
comprise: PROTECTED_SCOPE_DELTA = { candidate_act_digest,
original_oase_digest, current_scope_version, proposed_effect_class,
added_resource_scope, added_destination_scope,
changed_operation_parameters, changed_delegation_scope,
changed_effect_budget, affected_finality_sink,
10.42. Source global page 220
required_new_principal_authority, protected_delta_commitment } The
scope delta is specific to the actual proposed consequence. For
example, permission to send an expense report to Accountant A may not
be transformed into permission to export an entire finance directory
to Recipient B.
CW-IMP-3.10.1 — Scope Non-Inflation Unchanged original authority
remains distinguishable from the requested new scope.
CW-IMP-3.10.2 — Bounded Expansion A new authorization may permit only
the specified additional effect.
CW-IMP-3.11 — EXISTING TECHNOLOGY: TRUSTED APPROVAL PRESENTATION A
PHOSITA may use an independently controlled application or operating-
system security interface to present the requested scope change. The
presentation may identify: The original task; The original permitted
Das Expires 29 April 2027 [Page 183]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
effect; The proposed different effect; The specific scope delta; The
actual resource; The actual destination; The requesting agent; The
approving principal; And the corresponding protected resource
boundary. A Trusted Approval Presentation Record, or TAPR, may
authenticate the selected presentation data.
CW-IMP-3.11.1 — No Agent-Controlled Substitution The protected
approval service should not rely solely upon the agent's generated
description. It should derive material fields from verified
Candidate Act and SDEB information.
CW-IMP-3.11.2 — Existing Authentication Technology The approval
service may use:
10.43. Source global page 221
An authenticated application session; A cryptographic challenge-
response; An appropriately supported passkey authentication ceremony;
A hardware-backed user-presence mechanism; Or another qualified
principal-authentication method.
CW-IMP-3.11.3 — Presentation Assurance Authentication of the user is
distinct from proof that the intended material operation was
presented through a trustworthy channel. The implementation must
establish the latter if it is claimed.
CW-IMP-3.11.4 — Human Understanding Limitation A system may
authenticate the presented transaction data and the principal's
response. It does not cryptographically prove the user's subjective
understanding.
CW-IMP-3.12 — PROTECTED REAUTHORIZATION DECISION Following
appropriate human or authorized-principal interaction, the protected
service may produce a Protected Reauthorization Decision, or PRD. A
representative structure may comprise:
PROTECTED_REAUTHORIZATION_DECISION = { task_id, candidate_act_digest,
protected_scope_delta_digest, trusted_presentation_digest, decision:
"ALLOW_ONE_OPERATION", approving_principal_identity,
approver_authorization_role, current_scope_version,
current_authority_generation, approval_nonce, approval_expiration,
protected_decision_authentication } Alternative valid decisions may
include: Allow a specifically bounded operation class; Deny; Stop the
task; Or require further review.
Das Expires 29 April 2027 [Page 184]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
10.44. Source global page 222
CW-IMP-3.12.1 — Critical Technical Distinction An approval is not
treated as a Boolean instruction to bypass every security control.
It is an authenticated decision concerning the stated scope delta. A
separately protected authority controller determines whether a new
authorization may actually be constituted.
CW-IMP-3.13 — SCOPE-DELTA AUTHORIZATION Where fresh reauthorization
is valid, a PHOSITA may use a protected transactional authority
service to establish a Scope-Delta Authorization, or SDA.
SCOPE_DELTA_AUTHORIZATION = { task_id, original_oase_digest,
previous_scope_version, new_scope_version,
approved_candidate_act_digest, approved_scope_delta_digest,
protected_decision_digest, approved_resource_scope,
approved_destination_scope, approved_effect_class,
designated_finality_sink, current_authority_generation,
current_revocation_generation, expiration, permitted_use_count,
protected_consumption_reference, protected_authority_authentication }
CW-IMP-3.13.1 — New Authority The SDA constitutes new scoped
authority or an authorized extension of an earlier bounded scope.
CW-IMP-3.13.2 — Not an Override Flag A generic "approved" flag is
insufficient for selected stronger implementations. The resulting
authority is bound to the actual Candidate Act or approved effect
envelope.
CW-IMP-3.13.3 — Current Scope Chain The protected scope-version chain
may preserve: Original OASE V0; First approved scope delta V1; Second
approved scope delta V2.
10.45. Source global page 223
A later approval does not retroactively validate effects performed
earlier without permission.
CW-IMP-3.13.4 — Consumption A single-use SDA may be consumed through
the actual Finality Sink's protected state transition.
CW-IMP-3.14 — NON-OVERRIDABLE SECURITY CONSTRAINTS The original CW-3
disclosure distinguishes discretionary scope permission from
mandatory technical protection. A PHOSITA may maintain a protected
registry of Non-Overridable Security Constraints, or NOSCs. Examples
include: Invalid source identity; Invalid cryptographic
authentication; Unavailable mandatory actual-operation verification;
Revoked required source authority; An uncontrolled effectuation path;
A required CW-2 predecessor receipt that is missing or invalid; A
Das Expires 29 April 2027 [Page 185]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
protected resource conflict that cannot be safely resolved; Or
another mandatory security condition. An ordinary user approval to
expand task scope cannot bypass a NOSC.
CW-IMP-3.14.1 — Candidate Technical Interaction The approved scope
delta is added to the relevant source-authority conditions without
removing unrelated mandatory technical predicates. The actual sink
verifies both the new scope permission and the remaining protected
finality requirements.
CW-IMP-3.15 — SCOPE-DEVIATION RESOLUTION RECORD Following automated
adjudication or qualified reauthorization, the protected controller
may commit a Scope-Deviation Resolution Record, or SDRR. The record
may identify: The original OASE; The actual observed deviation;
10.46. Source global page 224
The SDEB; The adjudicator identity; The D0–D6 classification; The
automated or human resolution; The current scope version; And the
protected effectuation conditions resulting from the resolution. A
resolution record is not necessarily a reusable complete finality
capability. The actual resource sink still verifies the operation
under current authority and protected consumption state.
CW-IMP-3.16 — REFERENCE ALGORITHM: CW-3 FUNCTION
CW3_SCOPE_DEVIATION_CONTROL( pending_candidate_act,
protected_scope_controller, actual_finality_sink ): oase =
protected_scope_controller .LOAD_ORIGINAL_AUTHORIZED_SCOPE() pssa =
protected_scope_controller .LOAD_CURRENT_SCOPE_STATE() actual =
actual_finality_sink .RECONSTRUCT_PENDING_OPERATION() REQUIRE
VERIFY_OASE_AUTHENTICITY(oase) REQUIRE
VERIFY_SCOPE_STATE_AUTHENTICITY(pssa) comparison =
COMPARE_ACTUAL_EFFECT_WITH_CURRENT_SCOPE( actual, oase, pssa ) IF
comparison == WITHIN_SCOPE: RETURN CW1_VERIFY_AND_EFFECTUATE( actual
)
10.47. Source global page 225
sdo = CREATE_AUTHENTICATED_DEVIATION_OBSERVATION( actual, comparison
) sdeb = COMMIT_SCOPE_DEVIATION_EVIDENCE( oase, pssa, sdo ) latch =
ACTIVATE_PROTECTED_DEVIATION_LATCH( actual, sdeb ) REQUIRE
VERIFY_EFFECT_ACTUALLY_HELD( latch, actual_finality_sink )
classification = INDEPENDENT_SCOPE_ADJUDICATOR( sdeb,
CURRENT_PROTECTED_POLICY() ) IF classification == D0: REQUIRE
VERIFY_ORIGINAL_SCOPE_CURRENT() resolution = ACCEPT_WITHIN_SCOPE ELSE
IF classification == D1: resolution =
ATTEMPT_PROTECTED_REVALIDATION() IF resolution IS INCONCLUSIVE:
RETURN KEEP_LATCHED ELSE IF classification == D2: resolution =
Das Expires 29 April 2027 [Page 186]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
AUTOMATED_SCOPE_REVALIDATION() REQUIRE
VERIFY_EXISTING_SCOPE_SUFFICIENT( resolution ) ELSE IF classification
== D3 OR classification == D4:
10.48. Source global page 226
REQUIRE VERIFY_APPROPRIATE_APPROVER_ROLE() tapr =
PREPARE_TRUSTED_SCOPE_DELTA_PRESENTATION( oase, sdeb, actual ) prd =
OBTAIN_PROTECTED_REAUTHORIZATION_DECISION( tapr ) IF prd IS NOT
VALID_APPROVAL: RETURN KEEP_LATCHED_OR_DENY REQUIRE
VERIFY_NON_OVERRIDABLE_CONSTRAINTS() resolution =
CREATE_NEW_SCOPE_DELTA_AUTHORIZATION( prd, CURRENT_SCOPE_VERSION() )
ELSE IF classification == D5: RETURN MANDATORY_DENIAL ELSE IF
classification == D6: RETURN KEEP_LATCHED_PENDING_RECONCILIATION
ELSE: RETURN KEEP_LATCHED REQUIRE COMMIT_SCOPE_DEVIATION_RESOLUTION(
resolution ) REQUIRE VERIFY_CURRENT_SOURCE_AUTHORITY() REQUIRE
VERIFY_ACTUAL_EFFECT_WITHIN_RESULTING_SCOPE( actual, resolution )
REQUIRE VERIFY_ALL_MANDATORY_FINALITY_PREDICATES() REQUIRE
VERIFY_CURRENT_PROTECTED_CONSUMPTION() RETURN actual_finality_sink
.CONDITIONALLY_CONSUME_AND_EFFECTUATE(
10.49. Source global page 227
actual, resolution ) The pseudocode illustrates the authority
relationships. Where human approval is required, the protected
decision must be bound to the actual effect and current authority
conditions. Where a classification permits automatic continuation
under existing scope, the normal CW-1 finality requirements still
apply.
CW-IMP-3.17 — CW-3 PHOSITA EXAMPLE: EXPENSE REPORT ASSISTANT A user
authorizes an assistant to: Read selected expense documents; Prepare
one report; And send it to a designated accountant. The protected
controller establishes OASE V0. The agent performs legitimate
computation. The agent then proposes a data export containing
unrelated contacts and additional confidential files. An independent
protected egress controller identifies the actual outgoing operation.
It compares the operation with OASE V0 and current PSSA state. The
mismatch produces an SDO and SDEB. The corresponding Protected
Deviation Latch prevents the unauthorized export. The Independent
Scope Adjudicator identifies an unauthorized resource class and
recipient. If the new export is eligible for fresh authorization,
the protected service may request approval from
the appropriate principal. If the principal authorizes only one
additional specified file, the resulting SDA permits only that
bounded effect. The actual Finality Sink verifies the outgoing files
and recipient against the SDA. The agent cannot use that approval to
Das Expires 29 April 2027 [Page 187]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
export the entire contacts database. Expected Demonstrable Result A
valid original task can continue within its permitted scope while a
materially broader data disclosure remains technically withheld until
the exact additional authorization and finality conditions are
satisfied.
10.50. Source global page 228
CW-IMP-3.18 — CW-3 PHOSITA EXAMPLE: AUTOMATED FALSE-POSITIVE
RESOLUTION A user permits an agent to write an output document into a
designated workspace. The agent generates a temporary file. The
scope monitor flags a different path string. A trusted file-system
resolver establishes that the path resolves to a resource within the
permitted workspace under the current resource identity and policy.
The ISA classifies the condition as D2. ASR verifies the existing
source authority remains sufficient. The protected latch is cleared.
The normal Finality Sink verifies and commits the actual permitted
file operation. Expected Demonstrable Result A false-positive scope
difference may be resolved without a human prompt, while genuine
authority expansion remains impossible through an unsupported
automated explanation.
CW-IMP-3.19 — CW-3 PHOSITA EXAMPLE: HUMAN APPROVAL CANNOT OVERRIDE
SECURITY A user authorizes an agent to prepare a payment. The agent
proposes a larger amount than the original permitted limit. The
protected system classifies the difference as a scope expansion
potentially eligible for fresh approval. A qualified approver
authorizes the larger amount. However, before actual effectuation,
the protected resource controller detects that the required payment
credential authorization has been revoked. The current revocation
condition is a mandatory security failure. The Finality Sink refuses
the payment despite the human approval of the scope expansion.
Expected Demonstrable Result A scope-delta approval cannot silently
substitute for current source authority or another mandatory CW-1
finality predicate.
CW-IMP-3.20 — CW-3 IMPLEMENTATION VARIATIONS
10.51. Source global page 229
Variation A — Deterministic Scope Comparison Use a protected policy
engine to compare the actual effect with the original scope and
current accumulator.
Variation B — Multi-Signal Independent Monitoring Use several
authenticated sources for resource, application, or information-flow
evidence.
Das Expires 29 April 2027 [Page 188]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Variation C — Selective Latching Block only affected Candidate Acts
and their necessary dependent effects.
Variation D — Automated Resolution of Existing Authority Permit
continuation when a protected technical predicate proves the
operation is already within scope.
Variation E — Conditional Preauthorization Resolve a planned but
previously unknown concrete resource under an expressly permitted
original rule.
Variation F — Trusted Human Scope Expansion Create a new bounded
authorization following valid principal approval.
Variation G — Multi-Principal Reauthorization Require the additional
resource owner's or administrator's authority where applicable.
Variation H — Hardware Scope Latch Use a protected register or device
command controller to withhold an effect following scope deviation.
Variation I — Cross-Domain Deviation Control A source authority
domain produces the original OASE while an independent receiving
Finality Sink verifies the current permitted effect scope.
Variation J — CW-2-Dependent Scope Resolution Where the operation
also requires a predecessor VAER, scope reauthorization does not
replace the missing mandatory causal receipt.
CW-IMP-3.21 — CW-3 COMPARATIVE TECHNICAL TESTS Test CW3-A — Static
Application Permission Give an application general access to a
network or filesystem interface.
10.52. Source global page 230
Show that the original task authorizes only a smaller effect scope.
Attempt a resource operation exceeding that task scope. Test CW3-B —
Independent Deviation Detection Generate an unauthorized operation
while the agent falsely describes it as within scope. Expected
result: protected observation detects the actual mismatch. Test
CW3-C — Protected Latch Activate a PDL and attempt the actual effect
through the covered Finality Sink. Expected result: the consequence
remains withheld. Test CW3-D — Agent Retries Allow the agent to
change the natural-language explanation and retry. Expected result:
the existing latch cannot be cleared by self-description. Test CW3-E
— Automated Alias Resolution Present a resource that appears
different but is conclusively the same authorized object. Expected
result: the protected system can resolve the difference under
existing authority.
Das Expires 29 April 2027 [Page 189]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Test CW3-F — Unauthorized Automatic Scope Expansion Ask an automated
judge to approve a genuinely new recipient. Expected result: model-
generated usefulness or confidence alone does not constitute new
source authority. Test CW3-G — Qualified Human Reauthorization
Create a precise protected scope delta and obtain appropriate
authenticated approval. Expected result: the system establishes a
bounded new SDA. Test CW3-H — Approval Substitution Change the
actual recipient or resource after approval. Expected result: the
Finality Sink rejects the mismatch. Test CW3-I — Non-Overridable
Denial Obtain valid scope approval while a mandatory source or
security condition fails. Expected result: the actual effect remains
denied. Test CW3-J — Concurrent Scope Updates
10.53. Source global page 231
Attempt competing updates against the same scope version. Expected
result: the protected system prevents invalid rollback or duplicate
authority consumption. Test CW3-K — D6 Uncertain Prior Effect
Require a prior actual-effect receipt but provide only an unresolved
attempt record. Expected result: the operation remains withheld
pending qualified reconciliation. Test CW3-L — Selective Suspension
Block one unauthorized disclosure while allowing independent
authorized computation to continue.
CW-IMP-3.21.1 — Proposed Comparative Ablation Compare: A conventional
risk-score-plus-approval arrangement; A system with independent
observation but no effectuation latch; And a protected
OASE/PSSA/SDO/SDEB/PDL/ISA/SDA arrangement with actual Finality-Sink
verification. The experiments should determine whether a suspicious
operation can occur: Before the user is prompted; During the approval
process; After a misleading agent explanation; Or after approval for
a different material effect. The contribution should be assessed
through actual resource outcomes, not merely the number of prompts
generated.
CW-IMP-3.22 — CW-3 CANDIDATE TECHNICAL CONTRIBUTION The proposed
inventive relationship is not simply: Risk scoring; Prompt-injection
detection; Human-in-the-loop approval; Anomaly monitoring; Or an
authorization server. The stronger candidate combination requires:
10.54. Source global page 232
An authenticated original task-specific authority envelope, protected
current scope-state accounting, independent actual-operation
deviation evidence, a non-bypassable effect-specific suspension
latch, independent technical adjudication distinguishing existing
permission from new authority, and a newly scoped authorization where
required, followed by actual Finality- Sink verification and
Das Expires 29 April 2027 [Page 190]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
protected consumption. A narrower fallback may expressly require the
versioned scope chain and the inability of ordinary human approval to
override specified non-overridable security conditions. PART IV —
COMBINED IMPLEMENTATION OF CW-1, CW-2, AND CW-3
CW-IMP-4.1 — GENERAL COMBINED ARCHITECTURE A PHOSITA may implement
all three workflows using shared infrastructure while preserving
their different technical purposes. A representative architecture
comprises:
ORIGINATING PRINCIPAL | v
PROTECTED ORIGINAL TASK AUTHORITY (OASE / SOURCE GRANT) | v
AUTONOMOUS AGENT OR TOOL WORKFLOW | v CANDIDATE ACT | v NON-EFFECTIVE
HOLD | v
PROTECTED CW-1 AUTHORITY VALIDATION | +----> OPTIONAL CW-3 SCOPE
CHECK | | | v | SDO / SDEB / PDL | | | ISA / ASR / APPROVAL | | | v |
CURRENT AUTHORITY | +----> OPTIONAL CW-2 VALIDATION | MODE A:
CURRENT IEV VALIDATION
10.55. Source global page 233
MODE B: REQUIRED ACCEPTED
PRIOR REAL-EFFECT RECEIPT MODE C: BOTH CONDITIONS | v PROTECTED
FINALITY | v ACTUAL FINALITY SINK |
CURRENT OPERATION CHECK |
PROTECTED CONSUMPTION | v ACTUAL CONSEQUENCE | v
QUALIFIED OUTCOME EVIDENCE |
OPTIONAL NEXT CW-2 PHASE This is a non-limiting explanatory
architecture. The logical functions may be distributed or integrated
according to their required trust properties.
CW-IMP-4.2 — COMBINED EXAMPLE: AUTONOMOUS FINANCIAL WORKFLOW A user
authorizes an autonomous assistant to pay a specified vendor within a
defined amount limit and update the accounting database after
verified payment completion. The source authorization is represented
by an OASE and a CW-1 protected authority record. Phase A — Payment
Preparation The agent reads the invoice. A protected source-
authority controller resolves the permitted recipient, amount, and
payment account. A Candidate Act is constructed. The payment
Das Expires 29 April 2027 [Page 191]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
remains non-effective. Phase B — Scope Deviation A retrieved invoice
contains a different recipient account. CW-3 identifies a potential
change from the original permitted destination.
10.56. Source global page 234
The protected deviation monitor commits an SDEB. The PDL prevents
payment release. Phase C — Protected Scope Resolution The ISA
examines the actual recipient and original authority. If a qualified
existing authorization already permits the recipient, ASR may resolve
the deviation. If genuinely new scope is required and is eligible
for approval, the appropriate principal may authorize the exact
change. A new bounded SDA may be established. Phase D — CW-1
Payment Finality The payment Finality Sink reconstructs the actual
account, amount, and recipient. It verifies current source
authority, current scope, any necessary SDA, and protected
consumption state. The payment may be permitted only if those
conditions pass. Phase E — Actual Payment Evidence The payment
processor supplies qualified evidence identifying the real
transaction state.
An authorized IEV validates whether the required payment effect
actually occurred. The IEV accepts the appropriate effect receipt.
Phase F — CW-2 Accounting Continuation The accounting operation is a
distinct Candidate Act. The accounting Finality Sink verifies: The
accepted payment VAER; The authorized validator identity; The
permitted successor scope; Current accounting authority; The actual
accounting resource mutation; And current protected consumption
state. Only then is the accounting update permitted. Resulting
Technical Relationship The combined architecture enforces three
distinct authority requirements.
10.57. Source global page 235
CW-3 governs whether the proposed recipient remains within existing
permission or requires valid new authorization. CW-1 governs whether
the actual payment is currently authorized and may be released. CW-2
governs whether the later accounting effect possesses the required
causal prerequisite derived from the actual earlier payment effect.
No one condition automatically substitutes for the other two.
CW-IMP-4.3 — COMBINED EXAMPLE: AUTONOMOUS CLOUD DEPLOYMENT An
enterprise principal authorizes an autonomous agent to deploy one
approved software artifact and modify selected production
configuration only after the deployment actually succeeds. The agent
prepares the deployment. CW-1 constructs a Candidate Act and holds
the actual resource mutation. The source authority and current
deployment artifact are verified. A protected Finality Sink performs
Das Expires 29 April 2027 [Page 192]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
the permitted deployment. An authenticated deployment-state observer
provides qualified evidence. An authorized IEV accepts the evidence
as a VAER. The next configuration step is causally dependent upon
that accepted actual deployment receipt. During the workflow, the
agent proposes exposing an additional network interface outside the
original scope.
CW-3 creates a protected deviation record and suspends the affected
configuration operation. A qualified administrator may approve a
narrowly defined additional configuration. The resulting scope-delta
authorization does not replace the required VAER proving the
preceding deployment effect. The actual network configuration
Finality Sink verifies both the current scope authority and the
required causal effect receipt.
CW-IMP-4.4 — COMBINED EXAMPLE: INDUSTRIAL DEVICE An autonomous
controller is authorized to perform a bounded equipment operation.
CW-1 holds the command until current device ownership, target, and
safety predicates are valid. The device's protected command sink
permits the first movement. A qualified sensor provides evidence
that the actual required position was reached.
10.58. Source global page 236
An authorized IEV accepts the observation under CW-2. The second
command remains unavailable without that accepted effect receipt. If
the controller proposes movement beyond the original authorized
range, CW-3 activates a scope- deviation latch. A new user approval
may authorize an otherwise permitted extension, but it cannot
override a mandatory physical safety constraint. The second actual
device sink requires current authority, accepted predecessor effect
evidence, and current hardware safety state before release.
CW-IMP-4.5 — EXISTING TECHNOLOGY SUBSTRATE MATRIX Existing CW-1 role
CW-2 role CW-3 role technology OAuth or other Establish original
Establish source Support task and new authorization principal and
permitted authority for each phase scope authorization Structured
Express bounded Bind permitted successor Express protected scope
authorization permitted operation operations deltas Protected
Authenticate evidence Authenticate IEV Authenticate adjudication
cryptographic and finality references identity and VAER and approval
records Transactional Maintain authority and Maintain causal Maintain
OASE, PSSA, database finality consumption acceptance and receipt
latch, scope versions, SDA Secure IPC or Isolate agent from final
Convey protected Isolate scope adjudication protected service
authority validation state and approval
Das Expires 29 April 2027 [Page 193]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Resource API Enforce actual operation Enforce successor VAER Enforce
current scope and gateway scope requirement deviation resolution
Operating-system Withhold selected local Provide in-line validation
Implement affected-act gate effects or effectuation suspension
Hardware Enforce physical Enforce receipt- Implement protected
controller effectuation dependent command scope and safety latches
Authenticated Transport protected Transport protected Transport IEV
receipts communication authority evidence reauthorization decisions
Current resource Bind actual predecessor Detect unauthorized Prevent
stale effects versioning and successor state resource change
Protected clock or Enforce current authority Enforce receipt and
Enforce approval expiry generation validator freshness and current
scope
Qualified effect Classify external Establish the required Resolve
uncertainty and observation outcome earlier real effect remaining
authority These technologies may be used in compatible combinations.
The disclosed inventive candidates depend upon their specific
protected technical interactions rather than the mere presence of the
components. PART V — TECHNICAL INTERACTIONS RELEVANT TO INVENTIVE
STEP
CW-IMP-5.1 — WHY A LIST OF KNOWN TECHNOLOGIES IS INSUFFICIENT
10.59. Source global page 237
A claim reciting a security gateway, authentication mechanism,
cryptographic signature, workflow engine, and approval interface
without defining their interaction may merely aggregate conventional
features. The stronger claim structure should explain the necessary
causal relationship among them. For CW-1, the authorization and
evidence system determines whether operation-specific finality may be
prepared, while the actual sink independently verifies the real
operation and consumes the resulting authority. For CW-2 Mode B, a
qualified earlier real effect and authorized IEV acceptance are
indispensable to the successor's actual effectuation. For CW-3,
actual operation deviation causes a protected technical suspension,
and only a valid protected resolution can create the appropriate
authority for the actual resource operation.
These relationships identify how one component constrains another.
CW-IMP-5.2 — CW-1: CANDIDATE TECHNICAL INTERDEPENDENCE The Candidate
Act identifies a bounded proposed effect. The protected evidence
system evaluates source authority and applicable conditions. The
finality controller establishes distinct scoped authority. The
designated Finality Sink obtains the actual resource operation. The
sink verifies that the actual operation corresponds to the protected
Das Expires 29 April 2027 [Page 194]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
authorization. The consumption state prevents unsupported repeated
exercise. Removing the sink-side correspondence requirement may
permit a changed operation to escape an earlier approval. Removing
protected consumption may permit replay under otherwise valid-looking
evidence. Removing actual effectuation coverage may permit bypass
through an uncontrolled resource interface. The technical
contribution should therefore be claimed as an enforced relationship
rather than
independent co-location of security tools.
CW-IMP-5.3 — CW-2: CANDIDATE TECHNICAL INTERDEPENDENCE The earlier
authorized phase produces a bounded real effect. A qualified
observation source provides evidence of that effect. The authorized
IEV validates and accepts the evidence. The accepted receipt becomes
a necessary condition of the successor's effectuation authority.
10.60. Source global page 238
The successor Finality Sink verifies the required accepted receipt
and the actual successor operation. Removing the mandatory receipt
dependency would permit B to remain independently effect- capable
where other permission remained valid. Replacing the qualified
actual-effect receipt with a scheduler-completion message would
weaken the asserted real-effect causal condition. Removing validator
identity authentication would permit unauthorized components to
impersonate the required acceptance role. Removing actual successor
verification could permit a genuine receipt to be used for the wrong
successor.
CW-IMP-5.4 — CW-3: CANDIDATE TECHNICAL INTERDEPENDENCE The OASE
establishes original task-specific authority. The PSSA represents
current cumulative scope state. The independent monitor observes the
actual or proposed operation. The SDEB expresses the specific
protected difference. The PDL withholds the affected consequence.
The ISA classifies the deviation. ASR may resolve a difference only
under existing or expressly preauthorized scope. Where new authority
is required, an appropriate principal may issue a qualified decision.
A protected SDA establishes the bounded new scope. The actual
Finality Sink verifies current authority and the precise pending
effect. Removing the protected latch may allow an effect before
adjudication. Allowing the agent's explanation to act as approval
may create unauthorized scope expansion.
Using a generic human-approval Boolean may allow a different actual
effect. Allowing approval to bypass a NOSC may defeat mandatory
resource or security conditions.
Das Expires 29 April 2027 [Page 195]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-IMP-5.5 — OBJECTIVE TECHNICAL PROBLEMS FOR SEPARATE CLAIM FAMILIES
CW-1 Problem
10.61. Source global page 239
How to maintain enforceable correspondence between previously
authorized consequential operation parameters and the actual later
resource operation despite an untrusted computational requester,
changing operation context, and possible alternate effectuation
routes. CW-2 Problem How to make a later consequential operation
technically dependent upon independently accepted evidence of a
specified earlier bounded real effect, rather than merely upon
workflow scheduling or reported activity completion. CW-3 Problem
How to prevent a suspected or confirmed expansion of autonomous task
scope from becoming effective while permitting conclusive within-
scope automated revalidation and appropriately bounded new
authorization without bypassing mandatory resource-side security
conditions. These problem formulations are illustrative.
They should be refined against the actual closest prior art
identified for each corresponding claim.
CW-IMP-5.6 — SPECIFIC HINDSIGHT AND COMBINATION ANALYSIS A technical
inventive-step response may examine: 1. What the closest prior art
actually controls. 2. What event the prior system treats as
authorization. 3. Whether the actual consequential operation is
independently reconstructed at the resource boundary. 4. Whether the
cited system maintains protected operation-specific consumption
state. 5. Whether a purported real-effect receipt is truly evidence
of the required effect. 6. Whether the accepted receipt is mandatory
for subsequent effectuation. 7. Whether the required validator has
authenticated identity and a defined observation role. 8. Whether a
detected scope deviation technically withholds the affected effect.
9. Whether automated resolution remains within existing authority.
10. Whether fresh user approval creates bounded new authorization
rather than bypassing unrelated security predicates. 11. Whether the
asserted features form a functional technical combination. 12.
Whether the prior art supplies a reason to establish that specific
relationship without relying on knowledge of the proposed invention.
CW-IMP-5.6.1 — Avoiding an Artificially Broad Distinction
Das Expires 29 April 2027 [Page 196]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
10.62. Source global page 240
The inventive-step argument should not assert that existing
technology has no revocation, no transaction authorization, no
authenticated receipts, no trusted confirmation, or no workflow
ordering. Those techniques are established. The correct comparison
concerns the precise claimed dependencies, resource-side enforcement
semantics, and supported technical effects.
CW-IMP-5.6.2 — Claim Scope An argument supporting a narrow mandatory
actual-sink implementation does not automatically establish inventive
step for every system that merely combines an AI agent with an
access-control gateway. The inventive concept should be reflected in
the mandatory elements of the claim being defended. PART VI —
PROPOSED CLAIM SUPPORT AND FALLBACK POSITIONS
CW-IMP-6.1 — CW-1 PROPOSED INDEPENDENT CLAIM KERNEL A candidate
system may comprise: A protected component configured to construct a
Candidate Act identifying a consequential operation; An enforceable
Non-Effective State preventing its actual effect; A Protected
Enforcement Domain configured to verify source authority and
protected evidence and establish separate scoped finality enablement;
And a designated Finality Sink configured to reconstruct the actual
pending resource operation, verify correspondence with the Candidate
Act and current protected authority, and consume the applicable
finality enablement before releasing the consequence.
CW-IMP-6.1.1 — Narrower Fallback Require a sink-local protected
single-use consumption transition.
CW-IMP-6.1.2 — Further Fallback Require an authenticated current
effectuation-path coverage commitment.
CW-IMP-6.1.3 — Further Fallback Require current resource-version or
operation-semantics verification at the actual sink.
CW-IMP-6.2 — CW-2 PROPOSED INDEPENDENT CLAIM KERNEL A candidate
system may comprise:
10.63. Source global page 241
A first protected consequential effectuation phase; An actual-effect
observation mechanism; An Interim Effectuation Validator having a
cryptographically verifiable identity and defined validation
authority; A protected validator-acceptance procedure producing a
VAER concerning the specified real predecessor effect; And a
successor Finality Sink configured so that the accepted VAER is a
necessary effectuation- enabling condition for a specified later
Das Expires 29 April 2027 [Page 197]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
consequential operation.
CW-IMP-6.2.1 — Narrower Fallback Require the VAER to identify the
permitted successor Candidate Act and designated successor sink.
CW-IMP-6.2.2 — Further Fallback Require sink-local single-use or
bounded receipt-dependent consumption.
CW-IMP-6.2.3 — Further Fallback Require independent reconstruction of
the actual successor operation.
CW-IMP-6.2.4 — Further Fallback Require a protected receipt-dependent
key-release, state-transition, or hardware-enable mechanism.
CW-IMP-6.2.5 — Mode A Alternative A separate claim family may
emphasize authenticated in-line IEV validation of the actual prepared
operation before the protected sink releases it.
CW-IMP-6.2.6 — Mode C Alternative A narrower combined claim may
require both accepted predecessor real-effect receipt and current in-
line validation of the successor.
CW-IMP-6.3 — CW-3 PROPOSED INDEPENDENT CLAIM KERNEL A candidate
system may comprise: A protected original task-authority envelope; A
protected accumulator representing relevant current scope and
cumulative effect state; An independent monitor configured to
identify a deviation between the actual pending operation and current
task authority; A protected deviation latch preventing the affected
consequence;
10.64. Source global page 242
An independent adjudicator configured to distinguish existing-scope
validity from scope expansion or mandatory denial; A reauthorization
controller configured to establish new bounded authority where
appropriate; And a Finality Sink configured to verify the actual
pending effect against the resulting current scope and mandatory
security predicates before release.
CW-IMP-6.3.1 — Narrower Fallback Require an authenticated SDEB
identifying the precise actual-effect scope delta.
CW-IMP-6.3.2 — Further Fallback Require automated revalidation to
establish existing or expressly preauthorized authority without
granting arbitrary new scope.
CW-IMP-6.3.3 — Further Fallback Require a protected TAPR and PRD
bound to the actual operation.
Das Expires 29 April 2027 [Page 198]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-IMP-6.3.4 — Further Fallback Require a versioned SDA and protected
scope chain.
CW-IMP-6.3.5 — Further Fallback Require explicit enforcement of NOSCs
notwithstanding valid human approval.
CW-IMP-6.4 — COMBINED INDEPENDENT CLAIM KERNEL A selected combined
implementation may require: A task-specific original authorized
scope; Operation-specific Candidate Acts; Protected source-authority
and actual-operation validation; A protected deviation latch for a
detected scope mismatch; Independent resolution or bounded new scope
authorization where required; An authenticated IEV-accepted actual-
effect receipt as a mandatory dependency for a specified successor
phase; And independent Finality-Sink verification of the actual
pending successor operation, including current authority, relevant
scope, mandatory causal receipt, and protected consumption state.
The combined arrangement may be especially relevant where a
consequential autonomous task includes both scope evolution and
ordered real effects.
10.65. Source global page 243
Its technical effect must be supported by an implementation in which
those relationships are all actually enforced. PART VII — NON-
LIMITING IMPLEMENTATION AND INDUSTRIAL DISCLOSURE
CW-IMP-7.1 — REPLACEABLE TECHNOLOGY SUBSTRATES The selected
implementations may use any technically suitable mechanisms providing
the specified properties. An OAuth-compatible authorization server
may be replaced by another protected authorization service. A
transaction database may be replaced by another suitable protected
state controller. A digital-signature mechanism may be replaced by
another authenticated evidence mechanism where the selected
validator-identity requirements remain satisfied. A remote IEV may
be replaced by a suitably protected integrated validator. A gateway
may be replaced by an actual destination-side resource controller. A
software latch may be replaced by a protected hardware command gate.
A graphical approval interface may be replaced by another qualified
trusted approval mechanism.
A JSON representation may be replaced by a suitable deterministic
binary representation. A workflow scheduler may be omitted from a
single-effect CW-1 implementation. A receipt-gated earlier real
effect may be omitted where CW-2 is not selected. A human
reauthorization interface may be omitted where CW-3 is not selected
or no scope expansion requires it. The choice of implementation
substrate does not remove an expressly mandatory technical condition
of the selected claimed workflow.
Das Expires 29 April 2027 [Page 199]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-IMP-7.2 — CROSS-WORKFLOW COMBINATION CLAUSE The technical features
of CW-1, CW-2, and CW-3 may be combined in any mutually compatible
configuration supported by the corresponding authority, evidence, and
resource-control requirements. CW-1 may operate independently as a
protected execution-finality system. CW-2 Mode A may be added to
provide authenticated in-line validation. CW-2 Mode B may be added
where receipt-constituted prior real-effect causality is required.
CW-2 Mode C may be selected where both receipt-gated predecessor
completion and current successor validation are required.
10.66. Source global page 244
CW-3 may be added to detect and govern scope deviation. CW-3 may
automatically resolve an operation already within valid original
authority. CW-3 may require an authenticated principal to authorize
eligible new scope. CW-3 may refuse a mandatory security violation
regardless of discretionary approval. A valid scope-delta
authorization does not replace an expressly required CW-2 actual-
effect receipt. An accepted prior-effect receipt does not
independently expand CW-3's originating task scope. Neither
condition replaces CW-1's applicable independent actual-operation
Finality-Sink verification. A single protected component may
implement multiple logical functions where the selected trust
requirements remain satisfied. A distributed system may place the
PED, IEV, scope adjudicator, approval service, and Finality Sink
in separate administrative or computational domains. The physical
placement of components is not universally limiting unless required
by the selected implementation.
CW-IMP-7.3 — INDUSTRIAL IMPLEMENTATION CLASSES The disclosed
workflows may be implemented in: Enterprise autonomous-agent
infrastructure; Cloud API authorization and execution; Application-
level agent gateways; Operating-system resource control; Protected
credential brokers; Database transaction controllers; Financial
payment systems; Electronic commerce; Distributed accounting systems;
Protected information release; Multi-agent orchestration; Software
deployment infrastructure; Network management;
10.67. Source global page 245
Telecommunications; Hardware accelerator control; Industrial
automation; Robotics; Autonomous transportation; Edge computing;
Remote devices; And future distributed autonomous critical systems.
The relevant industrial effect is technical control of consequential
operations under current protected authority, with optional real-
effect causal ordering and independent scope-deviation governance.
Das Expires 29 April 2027 [Page 200]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-IMP-7.4 — OPTIONAL PERFORMANCE AND ASSURANCE CONSIDERATIONS A
PHOSITA may assess: Authorization-validation latency; Finality-Sink
verification overhead; Protected-state transaction cost; Receipt-
verification latency; IEV identity-verification cost; Asynchronous
callback handling; Protected latch activation latency; Time required
for automated scope resolution; Human confirmation delay where
required; Resource-budget contention; Crash recovery; Distributed
revocation freshness; And actual effectuation-path coverage. An
implementation may optimize these metrics without omitting the
mandatory predicates supporting its claimed protection.
10.68. Source global page 246
A validation deadline does not automatically convert an inconclusive
mandatory condition into authority. A hardware-backed implementation
does not automatically provide correct effect semantics. An
authenticated remote receipt does not automatically prove a physical
effect outside the issuer's observation capability. A software
gateway cannot claim complete system-wide enforcement if the relevant
consequence remains reachable through an uncontrolled alternate path.
A remote acknowledgement gap is not proof that the actual external
operation failed.
CW-IMP-7.5 — NON-LIMITING PHOSITA AND EXPERIMENT CLAUSE The
algorithms, data structures, state machines, implementation
procedures, proposed comparative tests, reference prototypes, and
technical combinations disclosed herein are illustrative and non-
limiting. They are intended to assist a person having ordinary skill
in the art in understanding how the technical functions of CW-1, CW-
2, and CW-3 may be implemented using presently available computing
components. The invention is not limited to a particular programming
language, operating system, cryptographic protocol, database engine,
processor, commercial service, or hardware manufacturer. Existing
technical mechanisms may be substituted where the necessary protected
behavior remains technically equivalent under the selected trust
model.
Das Expires 29 April 2027 [Page 201]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
The proposed tests are demonstrations of intended technical behavior
and are not represented as already performed. A simulation
establishes the properties of that simulation under its actual
assumptions. A protected software prototype does not automatically
demonstrate resistance to compromise of its privileged operating
system. A hardware demonstration does not automatically establish
complete control of unrelated remote effectuation interfaces. The
disclosed embodiments may be combined or cross-referenced without
treating all optional mechanisms as mandatory. The claimed technical
relationship should be defined by the actual authority dependencies
and effectuation-boundary controls that the implementation enforces.
PART VIII — CONSOLIDATED TECHNICAL CONTRIBUTION
CW-IMP-8.1 — CW-1
10.69. Source global page 247
The proposed distinguishing technical relationship is that a
computationally proposed consequential operation is held non-
effective until protected operation-specific authority is
established, and the actual Finality Sink independently reconstructs
and verifies the real pending effect against that authority and
current protected state before consequential release. The use of a
conventional authorization server, gateway, cryptographic credential,
or database is not itself the claimed technical distinction.
CW-IMP-8.2 — CW-2 The proposed distinguishing technical relationship,
particularly in Mode B, is that a bounded earlier real effect
produces qualified evidence independently accepted by a
cryptographically identifiable authorized IEV, and that accepted
receipt becomes an indispensable enabling factor for the specified
next consequential phase, enforced by the successor Finality Sink.
The use of digital signatures, workflow ordering, receipts, or
hardware registers individually does not establish that relationship.
CW-IMP-8.3 — CW-3 The proposed distinguishing technical relationship
is that an independently detected departure from an authenticated
original task-specific scope activates a protected effectuation
latch, is resolved through independent technical adjudication or
appropriately authorized bounded scope expansion, and cannot reach
actual consequential effectuation without current Finality-Sink
verification of the resulting authority and all mandatory technical
conditions. The use of anomaly detection, risk scoring, human
approval, or ordinary policy rules individually does not establish
that relationship.
Das Expires 29 April 2027 [Page 202]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
CW-IMP-8.4 — COMBINED TECHNICAL CHARACTERIZATION The combined
architecture permits an autonomous system to conduct substantial
computation and legitimate task execution without granting
unrestricted authority over consequential resources. CW-1
establishes the protected transition from proposed computation to
actual-effect authorization. CW-2 establishes the specified causal
relationship between accepted earlier real-effect evidence and later
consequential authority. CW-3 governs deviations from the original
permitted scope without treating automated explanations or ordinary
human approval as substitutes for mandatory protected security
conditions. In selected combined implementations, the source
authorization, actual pending effect, required predecessor evidence,
protected scope state, and sink-local consumption state become
interdependent conditions of consequential release. The proposed
common inventive direction is therefore not the aggregation of
existing authentication, workflow, cryptographic, policy, and
approval components, but the constitution and mandatory effectuation-
boundary enforcement of precisely scoped consequential authority
through technical dependencies that prevent computation, apparent
completion, or discretionary approval from independently creating
authority to produce an unauthorized real effect.
10.70. Source global page 248
END OF SUPPLEMENTARY TECHNICAL DISCLOSURE CW-IMP-1. EMBODIMENT 1
PROTECTED CROSS-AGENT EFFECT-CONFLICT ARBITRATION WITH ATOMIC
EFFECT RESERVATIONS, CROSS-DOMAIN OPERATION CORRESPONDENCE, SINK-
BOUND FENCING, AND INDEPENDENT CONSEQUENCE-STATE RECONCILIATION
1.0 — TITLE AND GENERAL CHARACTERIZATION Systems and Methods for
Protected Cross-Agent Effect-Conflict Arbitration Using Independently
Verified Operation Footprints, Atomic Effect Reservations, Sink-Bound
Execution Fencing, and Consequence-Aware State Reconciliation Across
Heterogeneous Autonomous Computing Domains
1.0.1 — Nature of the Embodiment The present embodiment discloses
systems, methods, apparatus, protected execution components,
cryptographic authorization structures, state-transition mechanisms,
and computer-executable procedures for governing interactions among
multiple independently operating computational entities whose
proposed actions may individually possess valid execution authority
but may produce mutually incompatible, inconsistent, duplicative, or
otherwise impermissible combined consequences. The computational
entities may comprise autonomous artificial-intelligence agents, on-
Das Expires 29 April 2027 [Page 203]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
device assistants, application agents, operating-system services,
cloud-hosted agents, robotic controllers, enterprise automation
components, delegated tools, distributed workflow participants, or
other
effect-capable computing processes. In one non-limiting
implementation, a Protected Cross-Agent Effect-Conflict Arbitration
mechanism, hereinafter also referred to as PCECA, determines whether
multiple Candidate Acts may become consequentially effective under a
protected set of shared-resource, dependency, authority, and effect-
interference constraints. The mechanism operates independently of
the subjective reasoning, planning, or approval assertions produced
by the participating agents. The present embodiment is based on the
recognition that separately valid authorizations do not necessarily
compose into a valid joint execution. More particularly, two or more
Candidate Acts may each satisfy individual identity, scope, purpose,
destination, and authorization predicates while nevertheless
producing an impermissible combined
state when executed concurrently or in a particular order. The
proposed architecture introduces a protected effect-interference
evaluation and reservation mechanism that binds an operation's
concurrency authorization to the actual consequential operation
presented at an applicable Finality Sink.
11. Implementation With Existing Technology: PHOSITA-Oriented Reference
Design
This section is newly authored implementation guidance informed by
CW-1, CW-2 and CW-3, not a claim that an interoperable reference
implementation has been built, tested, or shipped. The source
specification supplies architecture and non-limiting alternatives;
concrete technology mappings below are representative engineering
choices that must be evaluated against each target platform.
A technically competent implementer can construct an initial software
reference system using an unprivileged proposal process, a separate
policy and evidence service, an authenticated durable data store, a
controlled credential broker or egress proxy, and a final effect-
capable resource interface. A design may use ordinary operating-
system process separation and a database for early feasibility work;
stronger threat assumptions require stronger isolation and control of
all effect-capable paths.
Implementation preconditions are: (1) an identifiable principal and
bounded source grant; (2) a complete inventory of consequential
effect paths in the test system; (3) independent access by the
validator to necessary operation facts; (4) authenticated, integrity-
Das Expires 29 April 2027 [Page 204]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
protected evidence; (5) a verifier capable of observing or
reconstructing the actual pending operation, not solely an agent-
supplied summary; and (6) durable, authoritative consumption state at
or controlling the effective boundary.
An API gateway that only logs or approves requests is not necessarily
a Finality Sink. An intermediary cannot guarantee denial if an
alternative route permits the same effect without equivalent
enforcement. Likewise, network dispatch acceptance does not
establish remote completion, and a trusted timestamp does not repair
incorrect underlying observations.
11.1. Suggested Initial Software Components
Proposal client: produces a Candidate Act from a planned operation
while retaining no final authority to release its effect. Represent
material fields including logical operation identifier, actor, source
grant, action verb, recipient/target, resource version, content
commitment where appropriate, policy version and deadline.
Protected source-authority service: independently resolves source
grants, delegated limits, expiration and revocation using a
controlled store; do not infer current authority solely from the AI
agent's assertion or an authentication token.
Validation controller: obtains a qualified operation descriptor and
protected observations, compares independent sources where the chosen
profile demands it, commits evidence and rejection reasons, and
issues a bounded enablement referencing the evidence without
exporting reusable unrestricted authority.
Finality Sink / effect broker: holds the pending effect or gates the
last effective transition; reconstructs actual fields from the
controlled request/resource interface; compares source, evidence,
enablement, target/version and sink-local state; atomically records
consumption where the substrate allows; then releases exactly the
qualified effect.
Durable protected journal: records monotonic state transitions,
authority generations, replay identifiers, qualified effect outcomes
and pending/unknown states. Crash recovery must not recreate
already-consumed authority. The database transaction and the
external effect are not automatically one atomic unit.
Observation and receipt service for CW-2: separates attempted/sent/
accepted operations from independently supported completed effects,
and binds accepted predecessor receipts to specified successor
dependencies.
Das Expires 29 April 2027 [Page 205]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Scope-deviation service for CW-3: compares observed requested effects
to the current authorization envelope; latches a material deviation;
obtains bounded reauthorization from a competent source without
treating a simple UI click as overriding sink-local verification.
11.2. Available Technology Integration Profiles
HTTP and API profile: TLS-authenticated services; structured request
descriptions; a reverse proxy or broker that controls all covered
outgoing requests; server-maintained conditional resource versions
such as HTTP ETags and If-Match where supported. RFC 9110
conditional request evaluation can assist with version checks but is
not itself comprehensive finality enforcement.
Credential profile: protected secret storage in an operating-system
key store, KMS, HSM or managed secret service; narrowly scoped
credentials; applicable OAuth authorization evidence; sender-
constrained tokens where supported. The broker must still validate
the exact destination, body and method before credential exercise.
Durable state profile: a transactional database with unique
constraints on logical operation identifiers, compare-and-swap or
serializable transactions on consumption state, append-only
authenticated audit evidence where appropriate, and crash recovery of
uncertain outcomes.
Host/container profile: Linux namespaces, seccomp, LSM mediation,
privileged host worker or a tightly controlled proxy may constrain a
test environment. None of these alone proves complete coverage of
all network, IPC, filesystem, browser, hardware and alternate effect
paths.
Platform interoperability profile: on Apple iOS/iPadOS and Android,
use only actually available supported APIs, application permissions,
attestation/key facilities and service endpoints. A normal third-
party app generally cannot claim universal control of OS-level
effectuation interfaces. Where a target resource offers no
enforceable finality hook, state the limit and use a receiving
service under authorized control.
Hardware profile: a TEE, TPM-like component, HSM, protected
controller or accelerator command gate may protect evidence or actual
commands; qualified evidence of the effect and sink-local durable
replay control remain separate engineering obligations.
Das Expires 29 April 2027 [Page 206]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
12. Reference Interfaces, State Machine, and Non-Normative Algorithms
The following structured records and pseudocode are proposed
explanatory reference constructs, not byte-level interoperable wire
formats taken verbatim from the 3,567-page disclosure. Any later
standards-track protocol needs canonical encoding, schema versioning,
field definitions, error semantics, algorithm agility and
interoperability review.
Conceptual CandidateAct fields: act_id, principal_id, actor_id,
grant_ref, scope_id, target_id, operation_type,
material_parameters_commitment, resource_version, delegation_path,
expiry, and nonce. A security profile must specify which fields are
mandatory and which names are privacy-sensitive.
Conceptual EvidenceRecord fields: act_id, observation_source,
qualified_descriptor_digest, grant_generation, policy_generation,
validation_time, validity_interval, validation_outcome,
evidence_issuer, evidence_signature_or_mac, and evidence_version.
Conceptual ScopedEnablement fields: act_id, sink_id, evidence_digest,
permitted_effect, target_identity, authority_generation,
consumption_key, expiry, and issuer_authenticator. Merely copying
this record is not sufficient to authorize effectuation if the
selected design requires sink-local non-bearer state.
Conceptual SinkState fields: sink_id, consumption_key, state,
revocation_fence, observed_target_version, and monotonic_generation.
Nominal lifecycle states are PREPARED, VALIDATED, RESERVED, CONSUMED,
COMMITTED, REFUSED and INDETERMINATE, but transitions depend on the
substrate and actual-effect semantics.
receive candidate; store state = NON_EFFECTIVE
source = trusted_resolve_grant(candidate.grant_ref)
if source invalid/revoked/out_of_scope: REFUSE
observed = qualified_observe_operation(candidate)
if observed materially differs: HOLD and invoke CW-3 if eligible
evidence = commit_protected_validation(candidate, source, observed)
enablement = authorize_once(candidate, evidence, designated_sink)
actual = sink.observe_pending_effect()
if actual != qualified_operation(evidence, enablement): REFUSE
if stale(source, policy, resource, revocation): REFUSE
if replayed_or_consumed(sink_local_state): REFUSE
atomically reserve/consume enablement subject to effect semantics
release only this effect; record qualified outcome or INDETERMINATE
Figure 7: Illustrative CW-1 Verification Algorithm
Das Expires 29 April 2027 [Page 207]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
12.1. Consumption, Retries, and Crash Semantics
The ordering of finality consumption and an irreversible remote
operation requires an explicit fault model. Consuming before sending
can prevent unauthorized replay but can leave an unresolved state
after a crash; consuming after sending can permit duplication.
Exactly-once external effects require additional cooperation from the
receiving resource or another demonstrated protocol, not a local
journal alone.
After an uncertain dispatch result, preserve INDETERMINATE and
reconcile through qualified receiver evidence before creating fresh
retry authority. Idempotency keys may help where the receiving
system enforces their semantics; do not assume every HTTP API or
device supports them.
Canonicalization is security-critical: parameter order, Unicode
normalization, URL redirects, target aliases, mutable resource
versions, JSON/CBOR parsing ambiguities, and content encoding must be
defined consistently at validation and sink boundaries. Refuse or
revalidate materially ambiguous operations.
CW-2 must treat predecessor proof as an accepted actual-effect
receipt, not a queued task, local success log, or timeout assumption.
The successor independently retains its own source-authority and
sink-local finality obligations.
CW-3 must preserve the original envelope; a new bounded grant or
approved scope delta is neither a general-purpose permission
escalation nor permission to bypass final verification.
13. Threat Models, Adversary Capabilities, and Security Claims
This section supplies an explicit analysis framework for CW-1 through
CW-3. The source discusses several of these attacks in its workflow
chapters; the tabulated-style classification below is a proposed
editorial synthesis. Security guarantees are conditional on the
designated effect paths being covered and the trust assumptions
actually holding.
Assets: original principal authority, true target and operation
parameters, privacy-protected data, evidence integrity, protected
consumption/revocation state, credential secrecy, and effectuation
controls. Trust boundaries: untrusted agent/runtime; policy/evidence
service; credential or dispatch broker; actual Finality Sink;
external receiving authority; and protected state storage.
Das Expires 29 April 2027 [Page 208]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Adversary capabilities may include modifying prompts or tool outputs,
controlling a lower-trust agent, replaying stale valid messages,
calling alternative tools, changing the resource between validation
and commit, causing crashes or network partitions, and controlling a
delegated service. The baseline model does not assume the attacker
controls all protected-domain keys and the actual final enforcement
hardware simultaneously; such stronger assumptions need separate
treatment.
13.1. T1: Prompt Injection and Agent-Controlled Description
Attack: an external document convinces an agent to switch recipient,
amount, command or disclosure target after user approval.
Required check: source permission does not follow a new material
effect automatically; sink reconstructs actual pending fields and
compares protected evidence.
Residual risk: the observer and sink may share a parsing bug, or the
system may lack access to the real recipient.
13.2. T2: Replay, Revocation and Time-of-Check/Time-of-Use
Attack: attacker copies enablement or replays an earlier approved
request after its grant is revoked or the resource changes.
Required check: sink-local generation, monotonic consumption and
current authority/resource-state predicates; stale or already-
consumed operations fail closed.
Residual risk: remote unreachable sinks cannot promise immediate
cross-domain revocation without leases/fences or cooperating
enforcement.
13.3. T3: Effect-Path Bypass and Credential Confusion
Attack: approved gateway is bypassed via direct sockets, IPC, a
browser, cached token, service account or hardware command queue.
Required check: enumerate and constrain each equivalent effect path;
protect credential exercise at the controlled boundary.
Residual risk: on closed platforms, third-party software may be
unable to mediate every OS-level effect.
Das Expires 29 April 2027 [Page 209]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
13.4. T4: Forged, Missing, or Misclassified Outcome Evidence
Attack: an attacker substitutes a success log or queued
acknowledgement for actual predecessor completion under CW-2.
Required check: receipt issuer, observed effect, applicable causal
dependency and independent acceptance criteria.
Residual risk: a remote domain may not expose adequate observation or
nonrepudiable outcome evidence.
13.5. T5: Deviation-Laundering and Approval Confusion
Attack: an agent changes scope and treats a generic approval dialogue
as unlimited authority under CW-3.
Required check: separate material-deviation latch, authenticated
bounded scope delta and fresh sink verification.
Residual risk: malicious or confused competent approvers can still
authorize harmful but formally permitted operations.
13.6. T6: Availability, Resource Exhaustion and Privileged Compromise
Attack: force verifier overload, partitions or process crashes to
trigger fail-open fallback; compromise validation or key management.
Required check: bounded verification, rate limits, stable fail-closed
states, protected recovery and auditable key rotation.
Residual risk: fail-closed control can deny service; full trusted-
domain compromise defeats guarantees dependent on that domain.
13.7. Threat-to-Control Review Checklist
For each claimed protection, document: attacker starting privileges;
what observations are trustworthy and independent; actual effect
paths; identity and field canonicalization; replay and freshness
conditions; state mutation atomicity; loss-of-connectivity behavior;
fail-closed availability tradeoffs; authorization escalation; and
which residual threats remain.
Do not claim prevention of all prompt injection, all credential
theft, all sandbox escapes, or all cross-platform effects. The
architecture addresses unauthorized covered consequential effects
under enforceable assumptions; it does not make untrusted model
output inherently true.
Das Expires 29 April 2027 [Page 210]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
14. Reference Test Plan and Falsifiable Acceptance Criteria
The following are PROPOSED tests and expected assertions, not
experimental results. This XML contains no independently executed
test logs, performance measurements, test-run artifacts or completed
implementation evidence. Publication must not report these scenarios
as having passed until a concrete test harness runs them and its
output is retained.
Reference fixture: two isolated actors (proposal agent and authority
service), a protected evidence store, controlled mock effect receiver
with a durable logical-operation journal, sink-local replay state,
configurable policy and revocation generations, and an observable
test event log. Use deterministic clocks and injection points for
crash, tamper, delay and concurrency.
Capture per case: initial policy/resource versions; Candidate Act and
trusted observation (with confidential fields redacted); evidence
digest and issuer; enablement scope; sink reconstruction; decision;
journal transitions; effect count and effect parameters; expected
refusal reason; and test-run version.
14.1. CW1-01 — Valid bounded operation
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Valid bounded operation.
Expected acceptance criterion: Exactly one qualified effect; consumed
once. Record actual effect count, reconstructed descriptor,
protected journal transitions and explicit refusal/hold reasons.
Mark PASS only when observed output matches this expectation; mark
NOT RUN until executed.
14.2. CW1-02 — Agent changes recipient after evidence creation
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Agent changes recipient after evidence creation.
Expected acceptance criterion: Zero effects; actual-field mismatch.
Record actual effect count, reconstructed descriptor, protected
journal transitions and explicit refusal/hold reasons. Mark PASS
only when observed output matches this expectation; mark NOT RUN
until executed.
Das Expires 29 April 2027 [Page 211]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
14.3. CW1-03 — Agent changes request body after authorization
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Agent changes request body after authorization.
Expected acceptance criterion: Zero effects; material-parameter
mismatch. Record actual effect count, reconstructed descriptor,
protected journal transitions and explicit refusal/hold reasons.
Mark PASS only when observed output matches this expectation; mark
NOT RUN until executed.
14.4. CW1-04 — Expired or revoked source grant
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Expired or revoked source grant.
Expected acceptance criterion: Zero effects; current-authority
rejection. Record actual effect count, reconstructed descriptor,
protected journal transitions and explicit refusal/hold reasons.
Mark PASS only when observed output matches this expectation; mark
NOT RUN until executed.
14.5. CW1-05 — Replay same enablement concurrently
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Replay same enablement concurrently.
Expected acceptance criterion: At most one permitted effect under
receiver/sink assumptions. Record actual effect count, reconstructed
descriptor, protected journal transitions and explicit refusal/hold
reasons. Mark PASS only when observed output matches this
expectation; mark NOT RUN until executed.
14.6. CW1-06 — Sink receives altered target alias or redirect
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Sink receives altered target alias or redirect.
Expected acceptance criterion: Zero effects until target
requalification. Record actual effect count, reconstructed
descriptor, protected journal transitions and explicit refusal/hold
reasons. Mark PASS only when observed output matches this
expectation; mark NOT RUN until executed.
Das Expires 29 April 2027 [Page 212]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
14.7. CW1-07 — Validator-to-sink evidence substitution
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Validator-to-sink evidence substitution.
Expected acceptance criterion: Zero effects; authentication/binding
failure. Record actual effect count, reconstructed descriptor,
protected journal transitions and explicit refusal/hold reasons.
Mark PASS only when observed output matches this expectation; mark
NOT RUN until executed.
14.8. CW1-08 — Resource version changes before commit
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Resource version changes before commit.
Expected acceptance criterion: Zero effects or explicit revalidation;
no silent stale commit. Record actual effect count, reconstructed
descriptor, protected journal transitions and explicit refusal/hold
reasons. Mark PASS only when observed output matches this
expectation; mark NOT RUN until executed.
14.9. CW1-09 — Crash after consumption, before remote acknowledgement
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Crash after consumption, before remote acknowledgement.
Expected acceptance criterion: No automatic authority resurrection;
indeterminate-state reconciliation. Record actual effect count,
reconstructed descriptor, protected journal transitions and explicit
refusal/hold reasons. Mark PASS only when observed output matches
this expectation; mark NOT RUN until executed.
14.10. CW1-10 — Attempt alternate unmediated effect path
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Attempt alternate unmediated effect path.
Expected acceptance criterion: Blocked or documented coverage
failure; do not claim complete enforcement. Record actual effect
count, reconstructed descriptor, protected journal transitions and
explicit refusal/hold reasons. Mark PASS only when observed output
matches this expectation; mark NOT RUN until executed.
Das Expires 29 April 2027 [Page 213]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
14.11. CW2-01 — Accepted authenticated predecessor-effect receipt
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Accepted authenticated predecessor-effect receipt.
Expected acceptance criterion: Successor eligible only if all
independent checks also pass. Record actual effect count,
reconstructed descriptor, protected journal transitions and explicit
refusal/hold reasons. Mark PASS only when observed output matches
this expectation; mark NOT RUN until executed.
14.12. CW2-02 — Queued or dispatched predecessor with no qualified
effect
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Queued or dispatched predecessor with no qualified effect.
Expected acceptance criterion: Successor withheld. Record actual
effect count, reconstructed descriptor, protected journal transitions
and explicit refusal/hold reasons. Mark PASS only when observed
output matches this expectation; mark NOT RUN until executed.
14.13. CW2-03 — Forged predecessor receipt
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Forged predecessor receipt.
Expected acceptance criterion: Successor withheld; issuer/effect
check fails. Record actual effect count, reconstructed descriptor,
protected journal transitions and explicit refusal/hold reasons.
Mark PASS only when observed output matches this expectation; mark
NOT RUN until executed.
14.14. CW2-04 — Predecessor receipt bound to another task or effect
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Predecessor receipt bound to another task or effect.
Expected acceptance criterion: Successor withheld; causal binding
mismatch. Record actual effect count, reconstructed descriptor,
protected journal transitions and explicit refusal/hold reasons.
Mark PASS only when observed output matches this expectation; mark
NOT RUN until executed.
Das Expires 29 April 2027 [Page 214]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
14.15. CW3-01 — Material effect outside original scope
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Material effect outside original scope.
Expected acceptance criterion: Candidate Act stays non-effective;
deviation is latched. Record actual effect count, reconstructed
descriptor, protected journal transitions and explicit refusal/hold
reasons. Mark PASS only when observed output matches this
expectation; mark NOT RUN until executed.
14.16. CW3-02 — Competent bounded reauthorization
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Competent bounded reauthorization.
Expected acceptance criterion: Only newly bounded effect eligible for
fresh sink verification. Record actual effect count, reconstructed
descriptor, protected journal transitions and explicit refusal/hold
reasons. Mark PASS only when observed output matches this
expectation; mark NOT RUN until executed.
14.17. CW3-03 — Unqualified or stale approval
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Unqualified or stale approval.
Expected acceptance criterion: No effect; approval does not override
finality. Record actual effect count, reconstructed descriptor,
protected journal transitions and explicit refusal/hold reasons.
Mark PASS only when observed output matches this expectation; mark
NOT RUN until executed.
14.18. SEC-01 — Validator slow or unavailable
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Validator slow or unavailable.
Expected acceptance criterion: No fail-open effect; logged controlled
denial or hold. Record actual effect count, reconstructed
descriptor, protected journal transitions and explicit refusal/hold
reasons. Mark PASS only when observed output matches this
expectation; mark NOT RUN until executed.
Das Expires 29 April 2027 [Page 215]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
14.19. SEC-02 — Parallel agents use same single-use reservation
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Parallel agents use same single-use reservation.
Expected acceptance criterion: At most one effective use under
specified atomicity assumptions. Record actual effect count,
reconstructed descriptor, protected journal transitions and explicit
refusal/hold reasons. Mark PASS only when observed output matches
this expectation; mark NOT RUN until executed.
14.20. INT-01 — Different JSON/CBOR implementations canonicalize
differently
Setup: begin from the reference fixture with a clean protected
journal and an operation-specific source grant. Inject condition:
Different JSON/CBOR implementations canonicalize differently.
Expected acceptance criterion: Mismatch detected or operation
withheld until canonical profile agreed. Record actual effect count,
reconstructed descriptor, protected journal transitions and explicit
refusal/hold reasons. Mark PASS only when observed output matches
this expectation; mark NOT RUN until executed.
14.21. Suggested Test Harness and Reporting Procedure
Implement the effect receiver as a deliberately simple stateful test
service with a monotonically incremented effect counter and a log of
exact committed descriptors. Separate request-accepted events from
completed effects. Assert denial tests have no completed-effect
counter increase.
Run each negative test at least once with the validator supplied a
correct Candidate Act while the actual sink request is tampered, to
detect systems that compare only two upstream agent-controlled
values. Also test mutations introduced after authorization but
before dispatch.
For concurrency and crash tests, inject failpoints before
reservation, after reservation, after dispatch, and before recording
remote outcome. Capture whether the receiving system supports
idempotent logical-operation semantics. Do not claim exactly-once
behavior if receiver cooperation is absent.
Das Expires 29 April 2027 [Page 216]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Publish versioned test schemas, system configuration, scripts, seeds
where applicable, run logs, failure cases, and known limitations when
available; measurements of latency and resource use should include
hardware, software version, sample size, and methodology.
15. Detailed Industry and Product Alignment With Security Problem Space
Names below identify public product environments and potential
engineering integration targets, not claims that a vendor implements
this invention or has endorsed or derived from it. Exact features of
current products must be verified against official product
documentation before citing them as factual product behaviors. Where
access to an operating-system or device effectuation path is
unavailable to third parties, the enforceable profile is limited to
resources under implementer control.
15.1. Apple iOS, iPadOS, macOS; Siri, App Intents, and Cross-
Application AI Tools
Security problem: user-initiated automation may traverse voice
assistance, application intents, extensions, cloud service
integrations and privileged resource controllers. Authenticating an
app or granting a broad permission does not establish that every
later target, exported file or destination matches the authorizing
user's intended consequence.
Applicable design: construct an explicit Candidate Act for effect-
capable operations; resolve current grant and actual destination at a
service controlled by the implementer; require sink-side confirmation
for export, credential use or persistent mutation. Supported app
interfaces, broker endpoints and protected key facilities may be
used; unrestricted kernel hooks or interception of all iOS apps must
not be assumed.
Engineering review items: source-principal continuity across apps;
entitlements; background execution; account change; resource
aliasing; user consent and failure UX; device-key security; and
whether the receiving app can actually withhold a covered effect.
15.2. Voice and System Assistants: Apple Siri, Google Gemini, Samsung
Bixby, Microsoft Copilot, and Amazon Alexa
Security problem: system-level assistants turn a spoken or typed
request into actions inside third-party applications through platform
action frameworks such as App Intents and Shortcuts on Apple
platforms and intents and app actions on Android. The assistant, the
platform action framework, and the receiving app each hold part of
the authority, and none of them alone proves that the final
Das Expires 29 April 2027 [Page 217]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
recipient, file, amount, or device command matches what the user
asked for. Injected content in a message, web page, or document read
by the assistant can steer the resulting action.
Applicable design: treat the assistant-generated action as a
Candidate Act; bind the user request, the invoking assistant, the
target app, and the material parameters into protected evidence; and
require the receiving app or its backend, acting as the Finality
Sink, to reconstruct the actual pending operation before it takes
effect. Third-party implementers can apply this only at interfaces
they control, such as their own app action handlers and server APIs;
private assistant or operating-system internals are not assumed to be
available.
Engineering review items: how the action framework conveys parameters
and confirmation state; whether a user confirmation dialog is bound
to the exact final parameters; handling of background and lock-screen
invocation; cross-device handoff of assistant sessions; and fail-
closed behavior and user experience when verification is unavailable.
15.3. Google Android and Cross-OS Mobile Interoperability
Security problem: Android component invocation, permissions, intent
routing, service credentials and remote handoff have semantics that
differ from iOS. Translation of an intent or delegated token can
change recipient identity or action meaning.
Applicable design: a canonical protected effect descriptor
independent of platform-native permission encodings; bound app/user/
delegation evidence; independent resource-side effect check.
Hardware-backed key operation and Android application sandboxing may
contribute protection but are not by themselves complete sink
verification.
Engineering review items: app identity across installs and updates,
URI or content-provider grants, package/permission state, deep links
and redirects, device migration, user profiles and alternate egress
routes.
15.4. Microsoft Windows, Enterprise Copilots, Azure and Cloud
Automation
Security problem: enterprise agents may span desktop applications,
corporate APIs, infrastructure changes, CI/CD systems and
credentialed service accounts. A prompt-injection-induced command
can be inside an authenticated execution container yet outside the
originating user's bounded task authority.
Das Expires 29 April 2027 [Page 218]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Applicable design: separate agent proposal from policy/evidence
service and brokered privileged execution; use domain credentials and
conditional updates as inputs; reconstruct actual command and
authoritative resource before effect. Endpoint or enterprise
gateways must inventory bypass routes.
Engineering review items: least-privilege service identity,
conditional resource versions, human approval identity, tenant
boundaries, audit replay and the point where a system configuration
actually commits.
15.5. OpenAI, Anthropic, Google Gemini and Meta Agent Tooling
Security problem: agents may select tools, browse, write files, send
network requests or delegate to host connectors after reading
untrusted content. Sandboxing, tool approvals and credentials can
each limit risk, but none automatically guarantees exact final-effect
correspondence.
Applicable design: treat model/tool output as a Candidate Act
proposal; force each covered consequential operation through a
distinct protected approval/evidence process and sink; validate
actual target/content at dispatch. Multi-agent successors must not
inherit unlimited source authority.
Engineering review items: prompt-injection resilience, tool
discovery, delegated task scope, human approval binding, credential-
exercise location and independent observation of outgoing calls.
15.6. NVIDIA, Arm, Qualcomm, Huawei and Hardware-Backed Security
Security problem: accelerator jobs, device interfaces, kernel
services and communications hardware may create persistent or
physical consequences outside an application sandbox. Attested
software is not proof that the queued device command is the intended
authorized command.
Applicable design: enforce a final operation gate in a privileged
controller, DPU, secure service or device interface where technically
available; bind command content and resource state to protected
authority evidence and single-use consumption.
Engineering review items: driver bypass, firmware update, hardware
queue semantics, attestation freshness, DMA or egress paths, secure
clocks, nonvolatile replay state and failure behavior under power
loss.
Das Expires 29 April 2027 [Page 219]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
15.7. Banking, Payments, Healthcare, Industrial, Telecommunications and
Robotics
Security problem: autonomous systems may issue transfers, release
information, change subscriber/network policy, modify a medical
record, or actuate devices. Retry and cancellation after uncertain
outcomes may duplicate irreversible effects; remote acceptance is not
proof of completion.
Applicable design: operation-specific authorized effect envelopes,
current target and amount checks, separate protected result receipts
for dependent stages, independently authorized recovery Candidate
Acts and conservative treatment of unknown outcomes.
Engineering review items: transaction atomicity limits, compliance
and safety obligations, remote resource cooperation, signed evidence
privacy, revocation delays, deadline constraints and availability
risk of fail-closed enforcement.
16. Detailed IETF Working-Group, RFC, and Protocol Alignment
Working-group names here are technical discussion alignments, not
assertions of charter adoption, working-group approval, or IETF
consensus. Working-group status and live drafts must be
independently rechecked at publication. Where RFCs already solve
part of the problem, this document treats them as reusable components
rather than implying they are deficient.
16.1. OAuth: Delegated Authorization, Rich Authorization Requests, and
Sender Constraint
RFC 6749 defines a widely deployed OAuth 2.0 authorization framework;
RFC 9396 specifies Rich Authorization Requests so authorization
requests can carry structured details; RFC 9449 describes DPoP proof
of possession. An implementation can translate qualified source
permission or token-bound requests into inputs for protected effect
qualification. These standards do not, by themselves, certify that
an independent sink has reconstructed the material fields of every
downstream actual resource effect.
Integration proposal: preserve RAR authorization-detail semantics,
audience/resource scope, token freshness and sender constraint as
distinct fields; bind the resulting source evidence to the chosen
Candidate Act and re-evaluate actual resource mutation at the
effectuation boundary. Review consent, revocation and downscoping
behavior for distributed delegation.
Das Expires 29 April 2027 [Page 220]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
16.2. WIMSE: Multi-System Workload Identity and Security Boundaries
Workload identity protocols can supply principal/workload
authentication to a multi-service agent workflow. An authenticated
workload remains capable of proposing an effect different from the
originally authorized task. This project adds separate act-specific
verification, protected evidence and actual sink enforcement while
relying on appropriate workload identity assurance.
Integration proposal: define which authenticated workload attributes
can be used as source evidence, which administrative domain vouches
for them, and how identity rotation or delegation changes invalidate
pending effect authority.
16.3. RATS: Attestation Evidence, Endorsements, and Verification
Results
RFC 9334 defines an architecture for remote attestation roles and
claims. A verifier result can inform confidence in a protected
validator, broker or hardware environment, but a healthy platform
state does not prove that a particular payment, disclosure or command
matches its initiating authorization.
Integration proposal: record attestation freshness and applicability
for the chosen enforcement component while keeping operation-specific
evidence and sink-side actual-effect comparisons separate.
16.4. COSE and CBOR: Authenticated Evidence Containers and Encoding
RFC 9052 defines COSE structures relevant to signing and
authenticating CBOR-encoded evidence. A chosen profile may use COSE-
authenticated evidence, protected descriptors and receipts. It must
also specify canonical representation, semantic field mapping, key
identifiers, algorithm selection and replay domains, rather than
assuming that cryptographic validity ensures operation-level
authority.
Integration proposal: define separately versioned Candidate Act,
evidence receipt and enablement profiles with explicit security-
critical fields and issuer/audience bindings.
Das Expires 29 April 2027 [Page 221]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
16.5. ACE: Authorization for Constrained Devices and Networks
RFC 9200 describes an OAuth-based authorization framework for
constrained environments. That can be relevant to IoT, device and
edge Finality Sinks where bandwidth, energy or secure storage are
limited. Source authorization, token scope and access-to-resource
conditions remain distinct from final verification of an actual
hardware actuation.
Integration proposal: use bounded-size descriptors, replay-resistant
consumption, protected local authorization generations and explicitly
defined offline leases when central authorization services are
unavailable.
16.6. SCITT: Evidence Transparency and Verifiable Statements
SCITT-related work may inform authenticated statement formats,
auditability and transparency for evidence provenance. An inclusion
proof or transparent log provides useful accountability, but a log
entry is not itself proof that a remote resource changed state or
that a pending effect must be released.
Integration proposal: bind evidence statements to source authority,
issuer and operation descriptor, and specify the difference between
evidence publication, receipt validation and actual effectuation.
16.7. HTTP: Conditional Requests, Resource Identity and Response
Semantics
RFC 9110 defines HTTP semantics including conditional request
behavior. ETag and If-Match can constrain stale updates where
resource servers implement them correctly. Neither an HTTP success
code nor a queued acknowledgement necessarily proves an irreversible
or asynchronously completed business effect.
Integration proposal: verify actual method, target, recipient,
resource version, request-body commitment, redirects and current
policy at a controlled gateway or receiving service; use qualified
outcome verification for asynchronous operations.
16.8. SEC-DISPATCH and Security Area Review
The proposed cross-cutting mechanisms span authorization, evidence,
attestation, effectuation and distributed revocation. Security Area
dispatch or review may help identify appropriate venues for specific
interoperable elements. This document is an independent technical
disclosure, not a chartered WG deliverable, and no working group is
claimed to have accepted these proposals.
Das Expires 29 April 2027 [Page 222]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
Possible discussion units include operation-bound evidence
vocabulary, sink-side verification semantics, threat model, receipt-
dependent continuation, and security considerations for untrusted
agent tool calls.
17. Industry and Product Alignment: Security Problem Mapping
All product and brand names are illustrative comparison and
discoverability terms. Their inclusion does not establish
endorsement, collaboration, technical equivalence, derivation,
conformity, or infringement. The source itself describes vendor-
neutral implementations. Apple, Siri, iOS, iPadOS, macOS, Android,
Gemini, Bixby, Copilot, Alexa, and other names used in this document
are trademarks of their respective owners.
17.1. Apple iOS, iPadOS, macOS, and Third-Party AI Tools
Application sandboxes, App Intents, privileged services, secure key
use and cross-application task execution illustrate situations where
a granted capability does not itself prove authority for the exact
exported file, recipient, resource or command. An implementation
requires an actual protected enforcement path available under
platform restrictions; this document does not assume third-party
access to private interfaces.
17.2. Android and Android-Compatible Operating Systems
Android application permissions, interprocess intents, credential-
bearing integrations and hardware-backed services present different
representations of identities, entitlements and actual resource
operations. The foundational model proposes operation-specific
authority checking and independent effectuation validation across
platform changes.
17.3. OpenAI, Anthropic, Google, Meta, and AI Agent Tooling
Agent frameworks, browser automation, coding assistants, multi-agent
orchestration, policy gateways and sandboxed execution increase the
importance of distinguishing a generated tool request from an
authorized effect. This is an applicability discussion, not a
factual assertion that any named product implements the full
architecture.
Das Expires 29 April 2027 [Page 223]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
17.4. Microsoft Enterprise and Cloud Workloads
Enterprise agent governance, operating-system enforcement, privileged
connectors, cloud identity and policy-controlled API requests involve
delegated execution, target substitution, authority freshness and
final-resource verification.
17.5. NVIDIA, Qualcomm, Huawei, Arm, and Device Hardware
Accelerators, network processing, privileged device controllers,
protected key operations and heterogeneous trusted execution
illustrate alternative physical finality boundaries. Hardware
attestation or sandboxing alone must not be equated with a complete
act-specific Finality Sink.
17.6. Banking, Telecommunications, Robotics, and Industrial Systems
Payments, data export, infrastructure reconfiguration and physical
actuation require explicit threat and rollback assumptions. In
particular, dispatch, remote acceptance and completed real-world
consequence must not be collapsed into one semantic state.
18. IETF Working-Group Relevance and Existing Protocol Relationships
18.1. OAuth Working Group
OAuth authorization and related work address delegated access and
proof of possession. A permission or token result can contribute
authenticated source evidence, but the proposed finality relationship
checks the actual pending consequence at a controlled effectuation
boundary. Relevant existing RFCs include [RFC6749], [RFC9396] (RAR),
[RFC9449] (DPoP), and HTTP conditional request semantics in [RFC9110]
when applicable. These do not automatically define the complete
architecture described here.
18.2. WIMSE — Workload Identity in Multi System Environments
Workload identity and inter-workload credential handling may provide
useful authenticated identity and delegation context when agents
invoke separately controlled services. Proposed finality checks may
consume such context without treating workload identity alone as
effect-specific authority.
Das Expires 29 April 2027 [Page 224]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
18.3. RATS — Remote ATtestation ProcedureS
Remote attestation evidence (see [RFC9334]) and appraisal can help
authenticate a protected execution environment or enforcement
component. Attestation of a platform or software measurement is
distinguishable from independent verification of the actual pending
resource operation.
18.4. COSE — CBOR Object Signing and Encryption
Authenticated protected evidence, signed operation descriptors or
finality-bound attestations may be represented using interoperable
COSE [RFC9052] or CBOR structures where applicable. No universal
wire object is mandated by this foundational document.
18.5. ACE — Authentication and Authorization for Constrained
Environments
Constrained-resource authorization [RFC9200] and device security are
relevant to edge, embedded and industrial effectuation sinks where
time, bandwidth and protected storage are limited. Resource-specific
finality consumption and offline authority freshness introduce
additional implementation constraints.
18.6. SCITT — Supply Chain Integrity, Transparency, and Trust
Transparent statements and verifiable records may assist provenance
and auditing of validated operations and effect evidence; a
transparency log alone does not itself block an unauthorized real-
time effect.
18.7. Security Dispatch and Review
SEC-DISPATCH and broader security-area discussion may help identify
appropriate technical audiences for proposals spanning multiple
authentication, authorization and device-security topics. Mention of
a working group is not a request for endorsement or evidence of
charter inclusion.
19. Relevance to the EU Artificial Intelligence Act
Regulation (EU) 2024/1689 [EU-AI-ACT] sets obligations for providers
and deployers of certain AI systems and general-purpose AI models.
Whether an obligation applies to a given deployment depends first on
whether the system meets the definition of an AI system in Article 3
and then on its classification, for example as high-risk under
Article 6 and Annex III. A purely cryptographic or rule-based
enforcement component that performs no inference may itself fall
Das Expires 29 April 2027 [Page 225]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
outside that definition while still operating inside a system that is
in scope. This section is a non-normative technical mapping. It is
not legal advice and makes no claim of conformity, certification, or
presumption of conformity.
Risk management (Article 9): the protected-execution workflows,
threat model, and falsifiable test plan in this series give a
documented and testable control for the risk that an AI agent or
assistant produces an unauthorized consequential effect, including
through reasonably foreseeable misuse such as prompt injection.
Record-keeping and traceability (Article 12): protected validation
evidence, sink-local decisions, consumption state, and qualified
actual-effect receipts yield operation-level records of what was
proposed, what was authorized, what was withheld, and what actually
took effect. Such records can support automatic logging and post-
incident traceability, subject to data-minimization requirements.
Human oversight (Article 14): the Non-Effective State and the scope-
deviation re-authorization latch provide defined points at which a
consequential action can be withheld, interrupted, or escalated to a
competent natural person. The Act does not require human approval of
every individual decision, and this architecture does not assume it;
oversight can be exercised through bounded source authority and
explicit scope-delta approvals.
Accuracy, robustness, and cybersecurity (Article 15): fail-closed
withholding, single-use consumption, anti-replay state, and
independent reconstruction of the actual pending operation at the
Finality Sink contribute to resilience against attempts by
unauthorized third parties to alter a system's use or outputs by
exploiting vulnerabilities, and they bound the consequences of
erroneous model output.
Deployer obligations (Article 26) and obligations for general-purpose
AI models with systemic risk (Article 55), including an adequate
level of cybersecurity protection, may also be relevant where
deployers integrate third-party agents into mobile or enterprise
workflows. Harmonised standards under Article 40 and the application
dates of individual obligations have been subject to change and must
be checked at the time of use. Related EU instruments, such as the
Cyber Resilience Act, the NIS2 Directive, the General Data Protection
Regulation, and the Digital Markets Act, may interact with
deployments on mobile platforms but are outside the scope of this
document.
Das Expires 29 April 2027 [Page 226]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
20. Security and Privacy Considerations
The principal adversarial cases include injected or hallucinated
commands, forged receipts, stale or swapped authorization, use of old
device ownership epochs, revocation lag, repeated credentials,
concurrent agents, direct hardware/network bypass, time-of-check/
time-of-use changes, corrupted logs, validator substitution,
cryptographic key compromise and denial of protected verification. A
conforming security claim must identify the protected trust boundary,
observational independence, completeness of effect-capable paths and
local consumption durability. The source-derived CW chapters above
discuss these threats and distinct failure treatments in detail.
Privacy risks include direct protected-data export and composition
across individually permitted operations. Evidence records and
searchable disclosure are not a license to publish secret keys,
private personal data or sensitive authorization material. Evidence
minimization and qualified access control must follow actual system
security objectives.
21. IANA Considerations
This informational document requests no IANA action.
22. Informative References
[DAS-PCT] Das, S., "Published international application WO
2026/150382 (PCT/IB2026/055615)", 2026,
<https://patentscope.wipo.int/search/en/WO2026150382>.
[EU-AI-ACT]
European Parliament and Council of the European Union,
"Regulation (EU) 2024/1689 of the European Parliament and
of the Council laying down harmonised rules on artificial
intelligence (Artificial Intelligence Act)", 13 June 2024,
<https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC8179] Bradner, S. and J. Contreras, "Intellectual Property
Rights in IETF Technology", RFC 8179, BCP 79,
DOI 10.17487/RFC8179, May 2017,
<https://www.rfc-editor.org/info/rfc8179>.
Das Expires 29 April 2027 [Page 227]
Internet-Draft Execution-Finality Part 1: Foundations October 2026
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", RFC 9052, DOI 10.17487/RFC9052,
August 2022, <https://www.rfc-editor.org/info/rfc9052>.
[RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP
Semantics", RFC 9110, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/info/rfc9200>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/info/rfc9396>.
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/info/rfc9449>.
[ZENODO-FULL]
Das, S., "iOS and Android Interoperability for Secure
Third Party AI Tools - Cross-Platform Execution Finality,
Hardware Security, and Interoperability (3,567-Page
Specification)", DOI 10.5281/zenodo.23657985, October
2026, <https://zenodo.org/records/23657985>.
Author's Address
Sangam Kumar Das
Independent Researcher
Balasore
Odisha
India
Email: info@sangamdas.com
Das Expires 29 April 2027 [Page 228]