Secure AI Execution-Finality for iOS, Android, and Cross-Platform AI Agents, Part 8: Distributed Effect Verification, Protected Recovery, and Multi-Resource Finality
draft-das-distributed-effect-recovery-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sangam Das | ||
| Last updated | 2026-10-26 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Github - DAS Execution-Finality: Runnable Reference Model and 400 Executed Tests
iOS and Android Interoperability for Secure Third Party AI Tools - Cross-Platform Execution Finality, Hardware Security, and Interoperability (3,567-Page Specification |
||
| 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-distributed-effect-recovery-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 8: Distributed Effect Verification, Protected Recovery, and
Multi-Resource Finality
draft-das-distributed-effect-recovery-00
Abstract
When an AI agent's request times out, nobody knows whether the money
moved. Agents such as Apple Siri acting through App Intents, Google
Gemini on Android, enterprise copilots, and autonomous workflows on
iOS, iPadOS, macOS, Android, Windows, Linux, cloud APIs, banking and
instant-payment systems, robotic controllers, and telecommunications
networks increasingly act across resources that they do not control.
An API acknowledgment, a queued request, an expired timeout, an
apparently failed payment, or a successful local transaction may not
prove whether the real external effect occurred. Agents that guess
then retry into duplicate transfers, compensate for effects that
never happened, report rollbacks that did not occur, leave multi-
resource operations half committed, or repeat irreversible actions.
This document, Part 8 of a twelve-part series, specifies how agents
establish what actually happened and recover safely. It describes
qualified remote-effect evidence; independent witnesses with
provenance and measurement-competence checks; crash-consistent
effect-intent journals; containment of indeterminate outcomes so that
neither successors nor retries run until reconciliation; recovery and
compensation as separately authorized Candidate Acts that cannot
inherit or exceed the original authority; resource-specific Finality
Sinks; dependency-aware multi-resource commit controls that report
partial commits truthfully; and protected irreversible-effect
frontiers that require fresh hazard state before an action that
cannot be undone. Atomicity across unrelated providers is not
presumed. Reference algorithms, twelve threat models, and thirty
reproducible tests, including an Android and iOS cooperating-client
case, are included. Part 1 of the series defines the shared
terminology and common workflows.
The document relates these mechanisms to HTTP semantics for
idempotent methods, retries, and conditional updates; OAuth 2.0
authorization, Rich Authorization Requests, Resource Indicators,
Token Exchange, and Demonstrating Proof of Possession (DPoP);
Workload Identity in Multi-System Environments (WIMSE); Remote
Das Expires 29 April 2027 [Page 1]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
ATtestation procedureS (RATS) for observers and validators; CBOR
Object Signing and Encryption (COSE) for signed evidence; Supply
Chain Integrity, Transparency, and Trust (SCITT) receipts; and
Authentication and Authorization for Constrained Environments (ACE).
Their assurances are kept distinct from proof of a specific actual
consequence, and no working-group adoption or IETF consensus is
claimed.
Industry alignment covers Apple iOS, iPadOS, and macOS with Siri,
Shortcuts, and App Intents; Google Android with Gemini, intents,
Binder, and Keystore; Samsung Bixby, Microsoft Copilot, and Amazon
Alexa; Google Cloud, Microsoft Azure, and Kubernetes; agent platforms
from OpenAI, Anthropic, and Meta; NVIDIA, Qualcomm, Arm, and Huawei
hardware; banks, card payments, and merchant APIs; instant payment
schemes such as UPI, Pix, FedNow, and SEPA Instant; agentic commerce;
securities trading and settlement; ERP and supply-chain systems;
multi-leg travel bookings; healthcare prescriptions and records;
smart homes using Matter; automotive over-the-air updates and remote
commands; energy dispatch; telecom provisioning, including eSIM
profiles; government and tax filings; cloud data deletion and
backups; email and messaging; robotics; and satellites and
intermittently connected edge systems. For each, the document states
the technical effect: an uncertain outcome blocks duplicates and
successors until a qualified receipt resolves it, and recovery runs
only under its own fresh authority. Product names are illustrative
and imply no endorsement or implementation by any vendor. For the EU
Artificial Intelligence Act (Regulation (EU) 2024/1689), truthful
outcome records and controlled recovery can help providers and
deployers address robustness, record-keeping, human-oversight, and
risk-management 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.
Das Expires 29 April 2027 [Page 2]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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: Distributed Resource Effects, Uncertain Outcomes
and Series Scope . . . . . . . . . . . . . . . . . . . . 9
1.1. Twelve-Part Series Directory: Scope and Prospective
Datatracker Identifiers . . . . . . . . . . . . . . . . . 10
1.1.1. Part 1 of 12 — Foundational Protected Consequence
Authority, Shared Definitions, CW-1, CW-2 and CW-3 . 10
1.1.2. Part 2 of 12 — Secure iOS, Android and Cross-Platform
AI-Tool Interoperability . . . . . . . . . . . . . . 10
1.1.3. Part 3 of 12 — Protected Authorization, Validation
Evidence and Scoped Finality Capabilities . . . . . . 11
1.1.4. Part 4 of 12 — Finality Sink Reconstruction, Protected
Consumption and Anti-Bypass Security . . . . . . . . 11
1.1.5. Part 5 of 12 — Multi-Agent Authority, Delegation,
Conflicts and Quorum Enforcement . . . . . . . . . . 11
1.1.6. Part 6 of 12 — Authenticated Real-Effect Receipts and
Causal Continuation . . . . . . . . . . . . . . . . . 11
1.1.7. Part 7 of 12 — AI Tool Security, Resource Identity and
Execution-Time Semantic Integrity . . . . . . . . . . 12
1.1.8. Part 8 of 12 — Distributed Effect Verification, Crash
Recovery, Irreversibility and Multi-Resource
Transactions . . . . . . . . . . . . . . . . . . . . 12
1.1.9. Part 9 of 12 — Credential Custody, Protected Disclosure
and API Security . . . . . . . . . . . . . . . . . . 12
1.1.10. Part 10 of 12 — Cross-Device Migration, Revocation and
Offline Fencing . . . . . . . . . . . . . . . . . . . 12
1.1.11. Part 11 of 12 — Kernel, Sandbox and Hardware
Enforcement . . . . . . . . . . . . . . . . . . . . . 12
1.1.12. Part 12 of 12 — Cloud, Telecom, Resource Governance and
Critical Infrastructure . . . . . . . . . . . . . . . 13
2. Public Source, Patent-Pending Context, Formal IETF IPR and
Forthcoming GitHub Implementation . . . . . . . . . . . . 13
3. Keywords: Searchable Security Problems, Products, Protocols and
Technical Mechanisms . . . . . . . . . . . . . . . . . . 14
4. Technical Model, Terminology, State Semantics and Trust
Assumptions . . . . . . . . . . . . . . . . . . . . . . . 14
Das Expires 29 April 2027 [Page 3]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
4.1. Actual consequential effect . . . . . . . . . . . . . . . 14
4.2. Candidate Act (CA) . . . . . . . . . . . . . . . . . . . 14
4.3. Non-Effective State (NES) . . . . . . . . . . . . . . . . 14
4.4. Protected Enforcement Domain (PED) . . . . . . . . . . . 14
4.5. Finality Sink (FS) . . . . . . . . . . . . . . . . . . . 15
4.6. Protected Effect Receipt (PER) . . . . . . . . . . . . . 15
4.7. Interim Effectuation Validator (IEV) . . . . . . . . . . 15
4.8. Validator-Accepted Effect Receipt (VAER) . . . . . . . . 15
4.9. Causal Continuation Condition (CCC) . . . . . . . . . . . 15
4.10. Qualified Remote-Outcome Evidence . . . . . . . . . . . . 15
4.11. Indeterminate Outcome . . . . . . . . . . . . . . . . . . 15
4.12. Protected Effect-Intent Journal . . . . . . . . . . . . . 15
4.13. Recovery Candidate Act . . . . . . . . . . . . . . . . . 16
4.14. Compensation . . . . . . . . . . . . . . . . . . . . . . 16
4.15. Transaction Intent Envelope . . . . . . . . . . . . . . . 16
4.16. Constituent Finality Sink . . . . . . . . . . . . . . . . 16
4.17. Effect Dependency Graph . . . . . . . . . . . . . . . . . 16
4.18. Irreversibility Frontier . . . . . . . . . . . . . . . . 16
4.19. Qualified Witness Independence . . . . . . . . . . . . . 16
4.20. Scoped Non-Bearer Finality Enablement . . . . . . . . . . 16
4.21. Bounded Idempotency Policy . . . . . . . . . . . . . . . 17
4.22. Protected Outcome Reconciliation . . . . . . . . . . . . 17
4.23. Supported Failure Guarantee . . . . . . . . . . . . . . . 17
4.24. Authority, Evidence and Distributed-Effect Safety
Invariants . . . . . . . . . . . . . . . . . . . . . . . 17
4.24.1. Invariant 1 . . . . . . . . . . . . . . . . . . . . 17
4.24.2. Invariant 2 . . . . . . . . . . . . . . . . . . . . 17
4.24.3. Invariant 3 . . . . . . . . . . . . . . . . . . . . 17
4.24.4. Invariant 4 . . . . . . . . . . . . . . . . . . . . 17
4.24.5. Invariant 5 . . . . . . . . . . . . . . . . . . . . 17
4.24.6. Invariant 6 . . . . . . . . . . . . . . . . . . . . 18
4.24.7. Invariant 7 . . . . . . . . . . . . . . . . . . . . 18
4.24.8. Invariant 8 . . . . . . . . . . . . . . . . . . . . 18
4.24.9. Invariant 9 . . . . . . . . . . . . . . . . . . . . 18
4.24.10. Invariant 10 . . . . . . . . . . . . . . . . . . . . 18
4.24.11. Invariant 11 . . . . . . . . . . . . . . . . . . . . 18
4.24.12. Invariant 12 . . . . . . . . . . . . . . . . . . . . 18
4.24.13. Invariant 13 . . . . . . . . . . . . . . . . . . . . 18
4.24.14. Invariant 14 . . . . . . . . . . . . . . . . . . . . 19
4.24.15. Invariant 15 . . . . . . . . . . . . . . . . . . . . 19
5. Source-Derived Technical Disclosures With Original Global Page
Anchors . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Selected CW-2 — Validated Predecessor Real-Effect Receipts
and Continuation . . . . . . . . . . . . . . . . . . . . 19
5.1.1. Protected Component Architecture . . . . . . . . . . 19
5.1.2. Actual-Effect and Failure Decision Flowchart . . . . 20
5.1.3. Original Technical Disclosure — Page-Indexed
Sections . . . . . . . . . . . . . . . . . . . . . . 20
Das Expires 29 April 2027 [Page 4]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.2. Embodiment 4 — Cross-Domain Consequential Effect Evidence
and Remote Outcome Qualification . . . . . . . . . . . . 42
5.2.1. Protected Component Architecture . . . . . . . . . . 42
5.2.2. Actual-Effect and Failure Decision Flowchart . . . . 42
5.2.3. Original Technical Disclosure — Page-Indexed
Sections . . . . . . . . . . . . . . . . . . . . . . 43
5.3. Embodiment 12 — Protected Recovery, Compensating Effects
and Non-Replayable Recovery Authority . . . . . . . . . . 119
5.3.1. Protected Component Architecture . . . . . . . . . . 119
5.3.2. Actual-Effect and Failure Decision Flowchart . . . . 120
5.3.3. Original Technical Disclosure — Page-Indexed
Sections . . . . . . . . . . . . . . . . . . . . . . 120
5.4. Embodiment 16 — Crash-Consistent Effect-Intent Journals and
Indeterminate Outcome Reconciliation . . . . . . . . . . 202
5.4.1. Protected Component Architecture . . . . . . . . . . 202
5.4.2. Actual-Effect and Failure Decision Flowchart . . . . 203
5.4.3. Original Technical Disclosure — Page-Indexed
Sections . . . . . . . . . . . . . . . . . . . . . . 203
5.5. Embodiment 36 — Multi-Resource Transaction Finality,
Partial Commit and Separate Compensation . . . . . . . . 289
5.5.1. Protected Component Architecture . . . . . . . . . . 289
5.5.2. Actual-Effect and Failure Decision Flowchart . . . . 290
5.5.3. Original Technical Disclosure — Page-Indexed
Sections . . . . . . . . . . . . . . . . . . . . . . 290
5.6. Embodiment 37 — Irreversible-Effect Frontier and
Hazard-State Finality . . . . . . . . . . . . . . . . . . 385
5.6.1. Protected Component Architecture . . . . . . . . . . 385
5.6.2. Actual-Effect and Failure Decision Flowchart . . . . 385
5.6.3. Original Technical Disclosure — Page-Indexed
Sections . . . . . . . . . . . . . . . . . . . . . . 386
5.7. Embodiment 38 — Independent Evidence Witnesses, Measurement
Competence and Cross-Domain Proof . . . . . . . . . . . . 481
5.7.1. Protected Component Architecture . . . . . . . . . . 481
5.7.2. Actual-Effect and Failure Decision Flowchart . . . . 481
5.7.3. Original Technical Disclosure — Page-Indexed
Sections . . . . . . . . . . . . . . . . . . . . . . 482
6. PHOSITA Implementation: Existing Technologies, Protected
Components and Cross-Resource Deployment . . . . . . . . 581
6.1. Minimal cooperating multi-resource testbed . . . . . . . 581
6.2. Canonical Candidate Act and transaction envelope . . . . 582
6.3. Protected source grant capture . . . . . . . . . . . . . 582
6.4. Remote owner and actual operation identity . . . . . . . 582
6.5. Material payload binding and canonicalization . . . . . . 582
6.6. Receipt acquisition and factual outcome qualification . . 582
6.7. IEV deployment and separation . . . . . . . . . . . . . . 582
6.8. Crash-consistent journal . . . . . . . . . . . . . . . . 583
6.9. Effect release transaction ordering . . . . . . . . . . . 583
6.10. Idempotency-key provider qualification . . . . . . . . . 583
Das Expires 29 April 2027 [Page 5]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
6.11. Read-after-write reconciliation . . . . . . . . . . . . . 583
6.12. Distributed orchestration with explicit commit modes . . 583
6.13. Independent constituent sinks . . . . . . . . . . . . . . 583
6.14. Partial-commit containment . . . . . . . . . . . . . . . 584
6.15. Compensation authorization controller . . . . . . . . . . 584
6.16. Recovery generation and bounded budget . . . . . . . . . 584
6.17. Witness provenance and independence . . . . . . . . . . . 584
6.18. Hardware and irreversible consequence frontiers . . . . . 584
6.19. iOS and Android cooperating deployment . . . . . . . . . 584
6.20. Cloud, financial and telecom resource adapters . . . . . 585
6.21. Failure injection and logs . . . . . . . . . . . . . . . 585
6.22. Noncooperating receiver limitation . . . . . . . . . . . 585
6.23. Alternative trusted substrates . . . . . . . . . . . . . 585
7. Reference Data Models, Protected State Transitions and
Illustrative Algorithms . . . . . . . . . . . . . . . . . 585
7.1. Candidate Act and Finality Request Record . . . . . . . . 585
7.2. Actual Remote-Effect Receipt and Observer Provenance . . 586
7.3. Protected Effect-Intent Journal . . . . . . . . . . . . . 586
7.4. Remote Operation Outcome Reconciliation . . . . . . . . . 587
7.5. Scoped Finality Consumption at Receiving Resource . . . . 587
7.6. Qualified Compensating Candidate Act . . . . . . . . . . 587
7.7. Multi-Resource Intent Decomposition . . . . . . . . . . . 588
7.8. Partial Commit Containment . . . . . . . . . . . . . . . 588
7.9. Irreversibility Frontier Gate . . . . . . . . . . . . . . 588
7.10. Observer Dependency and Correlation Test . . . . . . . . 589
7.11. Time-Out and Retry Protocol . . . . . . . . . . . . . . . 589
7.12. Protected Causal Continuation Evaluation . . . . . . . . 590
8. Explicit Threat Models, Attacker Capabilities, Trust Boundaries
and Residual Risk . . . . . . . . . . . . . . . . . . . . 590
8.1. Threat 1 — Prompt-injected multi-service agent . . . . . 590
8.2. Threat 2 — Duplicate payment after timeout . . . . . . . 590
8.3. Threat 3 — Forged remote success receipt . . . . . . . . 591
8.4. Threat 4 — Correlated evidence masquerading as
independent . . . . . . . . . . . . . . . . . . . . . . 591
8.5. Threat 5 — Crash/snapshot rollback . . . . . . . . . . . 591
8.6. Threat 6 — Multi-resource partial-commit manipulation . . 591
8.7. Threat 7 — Recovery scope escalation . . . . . . . . . . 592
8.8. Threat 8 — Cross-domain destination substitution . . . . 592
8.9. Threat 9 — Irreversible act with stale hazard state . . . 592
8.10. Threat 10 — Resource exhaustion and evidence flooding . . 592
8.11. Threat 11 — Compromised protected gate . . . . . . . . . 593
8.12. Threat 12 — Queue accepted but actual work deferred . . . 593
9. Technical Validation: Proposed Reproducible Test Cases and
Expected Actual-Effect Results . . . . . . . . . . . . . 593
9.1. DE01 — Valid cross-domain effect . . . . . . . . . . . . 593
9.2. DE02 — Remote API accepted but work queued . . . . . . . 594
9.3. DE03 — False signed receipt . . . . . . . . . . . . . . . 594
9.4. DE04 — Receipt replay from earlier operation . . . . . . 594
Das Expires 29 April 2027 [Page 6]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
9.5. DE05 — Receipt mismatch to destination . . . . . . . . . 595
9.6. DE06 — Correlated observers . . . . . . . . . . . . . . . 595
9.7. DE07 — Qualified independent witnesses . . . . . . . . . 595
9.8. DE08 — Lost acknowledgement after effect . . . . . . . . 595
9.9. DE09 — Proven non-effectuation . . . . . . . . . . . . . 596
9.10. DE10 — Crash before protected consumption . . . . . . . . 596
9.11. DE11 — Crash after consumption before dispatch . . . . . 596
9.12. DE12 — Crash after external commit . . . . . . . . . . . 597
9.13. DE13 — Snapshot rollback . . . . . . . . . . . . . . . . 597
9.14. DE14 — Two concurrent effect attempts . . . . . . . . . . 597
9.15. DE15 — Multi-resource all commit . . . . . . . . . . . . 598
9.16. DE16 — A commits B fails . . . . . . . . . . . . . . . . 598
9.17. DE17 — Coordinator false rollback . . . . . . . . . . . . 598
9.18. DE18 — Authorized compensation . . . . . . . . . . . . . 599
9.19. DE19 — Unauthorized compensation . . . . . . . . . . . . 599
9.20. DE20 — Recovery generation replay . . . . . . . . . . . . 599
9.21. DE21 — Irreversible-effect stale hazard . . . . . . . . . 599
9.22. DE22 — Wrong irreversible target . . . . . . . . . . . . 600
9.23. DE23 — Fresh authorized irreversible command . . . . . . 600
9.24. DE24 — Time-of-check/time-of-effect drift . . . . . . . . 600
9.25. DE25 — Observer software generation change . . . . . . . 601
9.26. DE26 — Receiver without finality API . . . . . . . . . . 601
9.27. DE27 — Verification exhaustion . . . . . . . . . . . . . 601
9.28. DE28 — Android and iOS cooperating clients . . . . . . . 602
9.29. DE29 — HTTP idempotency misunderstanding . . . . . . . . 602
9.30. DE30 — Revoked recovery authority . . . . . . . . . . . . 602
10. Detailed Industry and Product Alignment: Cross-Platform AI,
Cloud, Banking, Telecom and Autonomous Systems . . . . . 603
10.1. Apple iOS, iPadOS, Siri, Shortcuts and App Intents . . . 603
10.2. Apple macOS automation and enterprise apps . . . . . . . 603
10.3. Google Android, Intents, Binder and Keystore . . . . . . 603
10.4. Google Gemini, Cloud Run, Kubernetes and GCP resource
APIs . . . . . . . . . . . . . . . . . . . . . . . . . 604
10.5. Microsoft Azure, Windows and enterprise AI agents . . . 604
10.6. OpenAI Agents SDK, Responses API, Codex and computer
use . . . . . . . . . . . . . . . . . . . . . . . . . . 604
10.7. Anthropic Claude Code, Managed Agents and developer
automation . . . . . . . . . . . . . . . . . . . . . . 604
10.8. Meta agent architectures and policy-mediated egress . . 604
10.9. NVIDIA OpenShell, Sentry, BlueField and accelerator
environments . . . . . . . . . . . . . . . . . . . . . 605
10.10. Qualcomm Snapdragon and Arm-based trusted hardware . . . 605
10.11. Huawei and heterogeneous operating-system/device
ecosystems . . . . . . . . . . . . . . . . . . . . . . 605
10.12. Banks, card payments, fund transfers and merchant
APIs . . . . . . . . . . . . . . . . . . . . . . . . . 605
10.13. Cloud infrastructure and database deployments . . . . . 606
10.14. Financial audit, insurance and compliance workflows . . 606
Das Expires 29 April 2027 [Page 7]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
10.15. Telecommunications 5G/6G core, edge and network
management . . . . . . . . . . . . . . . . . . . . . . 606
10.16. Robotics, autonomous vehicles and industrial control . . 606
10.17. Healthcare administration and regulated records . . . . 606
10.18. Satellites, remote edge and intermittent connectivity . 607
10.19. Voice and System Assistants: Apple Siri, Google Gemini,
Samsung Bixby, Microsoft Copilot and Amazon Alexa . . . 607
10.20. Instant Payment Schemes: UPI, Pix, FedNow and SEPA
Instant . . . . . . . . . . . . . . . . . . . . . . . . 607
10.21. Agentic Commerce, Checkout and Digital Wallets . . . . . 608
10.22. Securities Trading and Settlement . . . . . . . . . . . 608
10.23. ERP, Warehouse and Supply-Chain Systems . . . . . . . . 609
10.24. Multi-Leg Travel Bookings . . . . . . . . . . . . . . . 609
10.25. Healthcare Prescriptions and Records . . . . . . . . . . 609
10.26. Smart Home and Matter Devices . . . . . . . . . . . . . 610
10.27. Automotive Over-the-Air Updates and Remote Commands . . 610
10.28. Energy Dispatch and Utility Operations . . . . . . . . . 610
10.29. Telecommunications Provisioning, Number Porting and eSIM
Profiles . . . . . . . . . . . . . . . . . . . . . . . 611
10.30. Government, Tax and Regulatory Filings . . . . . . . . . 611
10.31. Cloud Data Deletion, Backups and Retention . . . . . . . 612
10.32. Email, Messaging and Notifications . . . . . . . . . . . 612
10.33. Summary of Technical Effects Across Industries . . . . . 612
11. Detailed IETF Working-Group, RFC and Protocol Interoperability
Relevance . . . . . . . . . . . . . . . . . . . . . . . . 613
11.1. OAuth WG: structured authorization and constrained
credentials . . . . . . . . . . . . . . . . . . . . . . 613
11.2. WIMSE WG: runtime workload identity and multi-hop service
chains . . . . . . . . . . . . . . . . . . . . . . . . . 614
11.3. RATS WG: attested observer and validator state . . . . . 614
11.4. COSE/CBOR: interoperable signed evidence encodings . . . 615
11.5. SCITT: transparency, receipts and accountable
statements . . . . . . . . . . . . . . . . . . . . . . . 615
11.6. HTTP and HTTPBIS: request semantics, conditional updates
and retries . . . . . . . . . . . . . . . . . . . . . . 615
11.7. ACE WG: authorization in constrained networked
devices . . . . . . . . . . . . . . . . . . . . . . . . 616
11.8. SEC-DISPATCH and Security Area technical review . . . . 616
11.9. IPR obligations and status of individual
Internet-Drafts . . . . . . . . . . . . . . . . . . . . 616
12. Relevance to the EU Artificial Intelligence Act . . . . . . . 617
13. Security, Privacy, Effect Correctness and Claim-Scope
Limitations . . . . . . . . . . . . . . . . . . . . . . . 618
13.1. Request success and effect truth . . . . . . . . . . . . 618
13.2. Source, capability and recipient integrity . . . . . . . 618
13.3. Remote effect observability limits . . . . . . . . . . . 618
13.4. Crash, state rollback and replay . . . . . . . . . . . . 618
13.5. Transactional semantics . . . . . . . . . . . . . . . . 619
Das Expires 29 April 2027 [Page 8]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
13.6. Safety and irreversible operations . . . . . . . . . . . 619
13.7. Privacy of receipts and journals . . . . . . . . . . . . 619
13.8. Qualified witness competence . . . . . . . . . . . . . . 619
13.9. Verification exhaustion . . . . . . . . . . . . . . . . 619
13.10. Source-disclosure chronology . . . . . . . . . . . . . . 619
13.11. Platform capability constraints . . . . . . . . . . . . 619
13.12. Prior-art and patent statements . . . . . . . . . . . . 620
14. Patent-Examiner and Industry Discovery Index With Global
Source-Page and Figure Anchors . . . . . . . . . . . . . 620
15. Foundational and Other Companion Internet-Draft
Cross-References . . . . . . . . . . . . . . . . . . . . 621
16. Informative References . . . . . . . . . . . . . . . . . . . 622
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 626
1. Introduction: Distributed Resource Effects, Uncertain Outcomes and
Series Scope
An autonomous agent can be authenticated, approved for a task and
operating through an access-controlled API, yet its status display
may disagree with the consequential state at the remote resource. An
HTTP timeout is not proof of non-effectuation. A queue
acknowledgment is not evidence of a bank transfer, document
publication, cloud mutation or device actuation. A rollback in one
database cannot undo messages already delivered or physical actions
already completed in another administrative domain.
This Part 8 addresses a distributed security and reliability problem:
under a bounded original source grant, which actual effects have
occurred, what independently qualified evidence supports them, which
effects may still be performed, and what recovery or compensation
requires fresh authority? A receipt or signature can authenticate a
statement without proving its causal relation to the actual pending
resource state. A coordinator can schedule transactions without
becoming competent to override resource-local authority.
The central source-derived mechanisms come from Embodiment 4
(independent cross-domain outcome evidence), Embodiment 12
(separately authorized recovery), Embodiment 16 (crash-consistent
journals and indeterminate outcomes), Embodiment 36 (multi-resource
transactions and partial-commit containment), Embodiment 37
(irreversible-effect frontiers), and Embodiment 38 (observer
qualification and evidence independence). Selected CW-2 passages
provide predecessor-effect receipt terminology. Each mechanism has
different authority and evidence conditions; this document does not
silently equate them.
Das Expires 29 April 2027 [Page 9]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The target readers include patent examiners, iOS and Android
platform-security engineers, third-party AI agent developers, cloud
resource API designers, financial/payment infrastructure engineers,
telecommunications network controllers and safety-relevant system
implementers. Descriptions of named commercial ecosystems indicate
relevant engineering problems and possible cooperating integration
points, not company endorsement, actual product adoption, independent
patent validity or infringement.
The technical source consists of the public 3,567-page publication
and the independently identified international application cited
below. Page-indexed text extracted from the submitted PDF, diagrams
newly composed for this Internet-Draft, proposed reference algorithms
and test specifications have different documentary histories; a newly
written diagram or algorithm cannot retroactively establish the
content of an earlier filed application.
1.1. Twelve-Part Series Directory: Scope and Prospective Datatracker
Identifiers
The following names are cross-reference targets for a planned twelve-
part individual-submission family. A proposed Datatracker URL is not
proof of a published Internet-Draft or an established IETF standard.
Part 1 is the common vocabulary and trust-model reference; other
parts retain distinct mechanisms.
1.1.1. Part 1 of 12 — Foundational Protected Consequence Authority,
Shared Definitions, CW-1, CW-2 and CW-3
Proposed document identifier: draft-das-interoperable-consequence-
authority; prospective address: https://datatracker.ietf.org/doc/
draft-das-interoperable-consequence-authority/ .
This foundational part defines CA, NES, PED, protected evidence,
scoped finality, FS, CW-1/CW-2/CW-3.
1.1.2. Part 2 of 12 — Secure iOS, Android and Cross-Platform AI-Tool
Interoperability
Proposed document identifier: draft-das-cross-platform-ai-
interoperability; prospective address:
https://datatracker.ietf.org/doc/draft-das-cross-platform-ai-
interoperability/ .
This companion gives the principal technical disclosure of its named
subject; mechanisms are referenced where relevant, not presumed
necessary for every Part 8 deployment.
Das Expires 29 April 2027 [Page 10]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
1.1.3. Part 3 of 12 — Protected Authorization, Validation Evidence and
Scoped Finality Capabilities
Proposed document identifier: draft-das-protected-authority-evidence;
prospective address: https://datatracker.ietf.org/doc/draft-das-
protected-authority-evidence/ .
This companion gives the principal technical disclosure of its named
subject; mechanisms are referenced where relevant, not presumed
necessary for every Part 8 deployment.
1.1.4. Part 4 of 12 — Finality Sink Reconstruction, Protected
Consumption and Anti-Bypass Security
Proposed document identifier: draft-das-finality-sink-enforcement;
prospective address: https://datatracker.ietf.org/doc/draft-das-
finality-sink-enforcement/ .
This companion gives the principal technical disclosure of its named
subject; mechanisms are referenced where relevant, not presumed
necessary for every Part 8 deployment.
1.1.5. Part 5 of 12 — Multi-Agent Authority, Delegation, Conflicts and
Quorum Enforcement
Proposed document identifier: draft-das-multi-agent-authority-
control; prospective address: https://datatracker.ietf.org/doc/draft-
das-multi-agent-authority-control/ .
This companion gives the principal technical disclosure of its named
subject; mechanisms are referenced where relevant, not presumed
necessary for every Part 8 deployment.
1.1.6. Part 6 of 12 — Authenticated Real-Effect Receipts and Causal
Continuation
Proposed document identifier: draft-das-causal-effect-receipts;
prospective address: https://datatracker.ietf.org/doc/draft-das-
causal-effect-receipts/ .
This companion gives the principal technical disclosure of its named
subject; mechanisms are referenced where relevant, not presumed
necessary for every Part 8 deployment.
Das Expires 29 April 2027 [Page 11]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
1.1.7. Part 7 of 12 — AI Tool Security, Resource Identity and
Execution-Time Semantic Integrity
Proposed document identifier: draft-das-agent-tool-integrity;
prospective address: https://datatracker.ietf.org/doc/draft-das-
agent-tool-integrity/ .
This companion gives the principal technical disclosure of its named
subject; mechanisms are referenced where relevant, not presumed
necessary for every Part 8 deployment.
1.1.8. Part 8 of 12 — Distributed Effect Verification, Crash Recovery,
Irreversibility and Multi-Resource Transactions
Proposed document identifier: draft-das-distributed-effect-recovery;
prospective address: https://datatracker.ietf.org/doc/draft-das-
distributed-effect-recovery/ .
Part 8 focuses on actual remote effect evidence, independently
authorized recovery and multi-resource effects.
1.1.9. Part 9 of 12 — Credential Custody, Protected Disclosure and API
Security
Proposed document identifier: draft-das-agent-credential-privacy;
prospective address: https://datatracker.ietf.org/doc/draft-das-
agent-credential-privacy/ .
This companion gives the principal technical disclosure of its named
subject; mechanisms are referenced where relevant, not presumed
necessary for every Part 8 deployment.
1.1.10. Part 10 of 12 — Cross-Device Migration, Revocation and Offline
Fencing
Proposed document identifier: draft-das-cross-device-authority-
revocation; prospective address: https://datatracker.ietf.org/doc/
draft-das-cross-device-authority-revocation/ .
This companion gives the principal technical disclosure of its named
subject; mechanisms are referenced where relevant, not presumed
necessary for every Part 8 deployment.
1.1.11. Part 11 of 12 — Kernel, Sandbox and Hardware Enforcement
Proposed document identifier: draft-das-hardware-execution-finality;
prospective address: https://datatracker.ietf.org/doc/draft-das-
hardware-execution-finality/ .
Das Expires 29 April 2027 [Page 12]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
This companion gives the principal technical disclosure of its named
subject; mechanisms are referenced where relevant, not presumed
necessary for every Part 8 deployment.
1.1.12. Part 12 of 12 — Cloud, Telecom, Resource Governance and
Critical Infrastructure
Proposed document identifier: draft-das-autonomous-infrastructure-
finality; prospective address: https://datatracker.ietf.org/doc/
draft-das-autonomous-infrastructure-finality/ .
This companion gives the principal technical disclosure of its named
subject; mechanisms are referenced where relevant, not presumed
necessary for every Part 8 deployment.
2. Public Source, Patent-Pending Context, Formal IETF IPR and
Forthcoming GitHub Implementation
The principal cited 8,598-page international technical disclosure is
PCT/IB2026/055615, filed 4 June 2026 and identified with publication
WO 2026/150382 [PCT-055615]. Earlier PCT/IB2025/058316 is a separate
patent application, not the June 2026 8,598-page principal
disclosure. The scope, filing support and exact priority of
particular features must be established by authentic as-filed
documents; nothing here represents a grant, validity conclusion or
legal finding.
The 3,567-page source publication is entitled "iOS and Android
Interoperability for Secure Third Party AI Tools - Cross-Platform
Execution Finality, Hardware Security, and Interoperability
(3,567-Page Specification)", available at [ZENODO]
(https://zenodo.org/records/23657985, DOI 10.5281/zenodo.23657985).
The original publication and its page images remain authoritative
where text extraction is imperfect.
Detailed application and claim mappings, Indian filings, priority
relationships and any required IETF IPR declarations will be
submitted or updated through the applicable separate BCP 79 process.
This document statement is not itself a completed IETF IPR submission
and makes no licensing representation absent an explicit filed
declaration. A GitHub reference implementation and reproducible test
harness are planned to be linked in a future revision; no repository
or successful laboratory result is claimed to exist here.
Das Expires 29 April 2027 [Page 13]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
3. Keywords: Searchable Security Problems, Products, Protocols and
Technical Mechanisms
distributed AI agents; cross-domain resource effects; remote-effect
verification; uncertain API outcome; HTTP timeout; non-idempotent
request replay; duplicate payment prevention; financial transaction
security; Apple iOS; iPadOS; macOS; Android; mobile AI automation;
bank API; payment processing; cloud infrastructure; distributed
systems; agentic workflows; saga compensation; partial commit;
transaction idempotency; crash consistency; write-ahead log;
execution-finality journal; finality sink; actual-operation
reconstruction; candidate act; non-effective state; protected source
authority; receipt-gated workflow; independent effectuation
validator; protected evidence provenance; witness independence; RATS
attestation; signed effect receipt; WIMSE; OAuth; COSE; CBOR; SCITT;
bounded recovery; irreversibility; robotic actuation; irreversible
cloud commands; telecom control plane; secure retries; cross-domain
authorization; sink-local consumption; recovery candidate act;
transaction dependency graph; PHOSITA implementation; reproducible
security tests; public technical disclosure; prior-art search.
4. Technical Model, Terminology, State Semantics and Trust Assumptions
4.1. Actual consequential effect
A persistent, external, information-release, financial or physical
consequence at a receiving resource. Attempt, dispatch, acceptance
and confirmed completion may be distinct states.
4.2. Candidate Act (CA)
A proposed consequential operation represented with sufficiently
specific originating authority, target, operation, parameters,
recipient and effect context.
4.3. Non-Effective State (NES)
Protected inability to cause the governed effect before the required
source authority and current finality conditions pass.
4.4. Protected Enforcement Domain (PED)
A protected authority-validation environment separate from the
untrusted agent under the documented compromise model.
Das Expires 29 April 2027 [Page 14]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
4.5. Finality Sink (FS)
A designated actual-effect boundary reconstructing the pending
operation, checking its current qualified authority and protected
local state, and withholding or causing the allowed consequence.
4.6. Protected Effect Receipt (PER)
Qualified record of an earlier real effect, distinguishable from mere
submitted request or accepted work item.
4.7. Interim Effectuation Validator (IEV)
Independently qualified checker of a predecessor result or protected
effect predicate, with identity and provenance required where the
selected causal mechanism mandates it.
4.8. Validator-Accepted Effect Receipt (VAER)
A predecessor receipt accepted under the required IEV predicate for a
selected future phase; not universal bearer authority.
4.9. Causal Continuation Condition (CCC)
Protected prerequisite for later effectuation that may depend on
accepted predecessor real-effect evidence and current successor
authority.
4.10. Qualified Remote-Outcome Evidence
Authenticated, current and semantically appropriate evidence
supporting the effect that actually occurred at another administered
resource, under stated observer and trust limitations.
4.11. Indeterminate Outcome
A state in which an effect attempt cannot be classified as both
safely not performed and confirmed successfully performed, e.g.,
dispatch succeeded but response was lost.
4.12. Protected Effect-Intent Journal
Durably protected relationship between proposed effect, authority
validation, sink-side consumption and known or unresolved actual
outcome.
Das Expires 29 April 2027 [Page 15]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
4.13. Recovery Candidate Act
A separate consequential proposal for retry, continuation, reversal,
mitigation or compensation, requiring competent source authorization
and sink finality appropriate to its own effect.
4.14. Compensation
A new potentially consequential act intended to mitigate earlier
effects. It need not reverse historical financial, physical or
disclosed effects.
4.15. Transaction Intent Envelope
Qualified overarching task statement identifying constituent source-
authorized effects, resource targets, dependencies, applicable
budgets and partial-commit policy.
4.16. Constituent Finality Sink
One of multiple independently controlled resource effectuation
interfaces, each responsible for its own actual act and source/
resource predicates.
4.17. Effect Dependency Graph
Protected representation of which accepted predecessor actual effects
or resource states are mandatory for a successor operation.
4.18. Irreversibility Frontier
Operation-specific boundary after which an effect cannot safely be
assumed reversible by local rollback or later compensation.
4.19. Qualified Witness Independence
Documented separation of observation channels and causal
dependencies; multiple signatures over one manipulated data source
are not automatically multiple independent observations.
4.20. Scoped Non-Bearer Finality Enablement
Act-bound authority that is not independently usable as a
transferable reusable credential; resource-side verification and
consumption are required.
Das Expires 29 April 2027 [Page 16]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
4.21. Bounded Idempotency Policy
Explicit resource-specific treatment of repeated logical operation
identifiers or proven non-effectuation, not a blanket assumption that
a POST or physical command can safely be retried.
4.22. Protected Outcome Reconciliation
Independent determination of previously observed, consumed and still
uncertain effects before retry, compensation or successor activation.
4.23. Supported Failure Guarantee
The precise safety result under stated assumptions about trust, sink
coverage, network partitions, protected state and participating
remote services; no universal exactly-once assertion.
4.24. Authority, Evidence and Distributed-Effect Safety Invariants
4.24.1. Invariant 1
A valid agent identity, API token or command permission does not
establish final authority for a materially different real external
operation.
4.24.2. Invariant 2
Request queued, request accepted, server processed, external resource
mutated and downstream effect confirmed are separately represented
events unless their equality is proven under the chosen protocol.
4.24.3. Invariant 3
An HTTP timeout or lost acknowledgment never by itself proves non-
execution of a non-idempotent effect.
4.24.4. Invariant 4
A previous stage receipt cannot automatically establish new original
source authority for an unauthorized successor.
4.24.5. Invariant 5
An actual resource-side Finality Sink verifies present material
operation fields, authority, evidence and local consumption state
before releasing a governed effect.
Das Expires 29 April 2027 [Page 17]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
4.24.6. Invariant 6
A local coordinator commit is not asserted to create atomicity across
resource systems that provide no shared atomic commit.
4.24.7. Invariant 7
A compensation is a distinct consequential operation with independent
authorization; it does not retroactively remove every historical
effect.
4.24.8. Invariant 8
Crash and rollback recovery cannot restore already-consumed single-
use authority merely because the requesting agent lost its local
cache.
4.24.9. Invariant 9
Materially changed resource identity, recipient, amount or payload
requires new matching qualification at the actual receiving sink.
4.24.10. Invariant 10
An irreversible command requires its own qualified current safety and
resource conditions where those are mandatory; a signed instruction
alone is insufficient.
4.24.11. Invariant 11
Witness signature authenticity and attestation of selected observer
properties do not automatically establish factual competence,
independent observations or actual-effect truth.
4.24.12. Invariant 12
When a remote service does not expose sufficient finality evidence or
enforceable resource-side guards, the achievable claim is explicitly
limited; no universal fail-proof cross-domain guarantee is asserted.
4.24.13. Invariant 13
Independent protected consumption is atomic within its authoritative
scope; exactly-once external effects are claimed only under stronger
and independently demonstrated resource-side conditions.
Das Expires 29 April 2027 [Page 18]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
4.24.14. Invariant 14
Unsupported verification, stale evidence, authority mismatch and
required but unavailable sinks result in withholding or separately
authorized resolution, not silent permission.
4.24.15. Invariant 15
Source-extracted historical material and new editorial diagrams or
proposed tests must retain distinct publication chronology and
provenance.
5. Source-Derived Technical Disclosures With Original Global Page
Anchors
The following page-indexed text is extracted from the seven uploaded
PDFs and retains the source patent-disclosure framing. Text
extraction can normalize hyphenation, spacing and formulas; compare
critical terms with the authoritative source PDF. Each diagram is a
new editorial interpretation and not represented as a figure from the
historical patent filing. Page boundaries may share content with
adjoining embodiments.
5.1. Selected CW-2 — Validated Predecessor Real-Effect Receipts and
Continuation
Original technical source: TECHNICAL SPECIFICATION -1-554.pdf, global
pages 63–79 inclusive. Principal source treatment within Part 8.
Related mechanisms may also be referenced by Parts 3, 4 and 6.
5.1.1. Protected Component Architecture
[Predecessor CA / approved bounded effect]
|
[Protected actual predecessor FS]
|
[Real-effect observation and receipt]
|
[Qualified IEV identity and acceptance]
|
[CCC prerequisite for successor]
|
[Successor CA + independent FS]
|
[Actual dependent consequence or HOLD]
Figure 1: Selected CW-2 — Validated Predecessor Real-Effect
Receipts and Continuation — architecture
Das Expires 29 April 2027 [Page 19]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.1.2. Actual-Effect and Failure Decision Flowchart
[Earlier real effect attempted]
|
<Actual qualified result proven?> -- NO --> [HOLD]
| YES
<IEV competence/receipt accepted?> -- NO --> [HOLD]
| YES
<Successor source scope current?> -- NO --> [REFUSE]
| YES
[Successor FS reconstructs actual operation]
|
<Bound finality and consumption valid?> -- NO --> [REFUSE]
| YES
[Consume and effectuate successor]
Figure 2: Selected CW-2 — Validated Predecessor Real-Effect
Receipts and Continuation — effectuation decisions
5.1.3. Original Technical Disclosure — Page-Indexed Sections
5.1.3.1. Original 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.
Das Expires 29 April 2027 [Page 20]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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,
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
5.1.3.2. Original 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.
Das Expires 29 April 2027 [Page 21]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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 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.
Das Expires 29 April 2027 [Page 22]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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.
5.1.3.3. Original 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 |
Das Expires 29 April 2027 [Page 23]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.1.3.4. Original 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.
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.
Das Expires 29 April 2027 [Page 24]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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
5.1.3.5. Original 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
Workflow CW-1.
The principal execution-finality protection of CW-1 may operate
independently without employing an IEV for every operation.
Das Expires 29 April 2027 [Page 25]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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
5.1.3.6. Original 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.
Das Expires 29 April 2027 [Page 26]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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 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.
Das Expires 29 April 2027 [Page 27]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The controlled effectuation interface must require the receipt-
dependent condition irrespective of which covered upstream software
path requests the effect.
5.1.3.7. Original 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.
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
Das Expires 29 April 2027 [Page 28]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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
5.1.3.8. Original 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.
Das Expires 29 April 2027 [Page 29]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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
5.1.3.9. Original Source — Global Page 71
AUTHORIZED IEV[0] | v ACCEPTED RECEIPT[0] | v 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
Das Expires 29 April 2027 [Page 30]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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.
5.1.3.10. Original 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.
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
Das Expires 29 April 2027 [Page 31]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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 32]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.1.3.11. Original 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
Das Expires 29 April 2027 [Page 33]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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.
5.1.3.12. Original 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.
Das Expires 29 April 2027 [Page 34]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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
5.1.3.13. Original 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
Das Expires 29 April 2027 [Page 35]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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 36]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.1.3.14. Original 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.
Das Expires 29 April 2027 [Page 37]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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.
5.1.3.15. Original 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.
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.
Das Expires 29 April 2027 [Page 38]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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.
5.1.3.16. Original 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.
Das Expires 29 April 2027 [Page 39]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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,
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
5.1.3.17. Original 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
Das Expires 29 April 2027 [Page 40]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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, predecessor_phase_ids, candidate_act_digest,
operation_class, actual_operation_binding, resource_scope,
destination_scope, designated_finality_sink,
Das Expires 29 April 2027 [Page 41]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.2. Embodiment 4 — Cross-Domain Consequential Effect Evidence and
Remote Outcome Qualification
Original technical source: TECHNICAL SPECIFICATION -1-554.pdf, global
pages 492–554 inclusive. Principal source treatment within Part 8.
Related mechanisms may also be referenced by Parts 3, 4 and 6.
5.2.1. Protected Component Architecture
[Source task + Candidate Act held NES]
|
[Origin PED / approved operation]
|
[Remote independently controlled resource]
|
[Recipient-side observation or witnesses]
|
[Evidence authenticity / meaning / identity]
|
[Outcome verifier and protected commitment]
|
[Successor condition, when applicable]
|
[Receiving successor Finality Sink]
Figure 3: Embodiment 4 — Cross-Domain Consequential Effect
Evidence and Remote Outcome Qualification — architecture
5.2.2. Actual-Effect and Failure Decision Flowchart
[Remote request dispatched]
|
<Actual remote effect established?> -- NO --> [UNCERTAIN/HOLD]
| YES
<Evidence source trustworthy and current?> -- NO --> [HOLD]
| YES
<Operation/recipient/result correspondence?> -- NO --> [REFUSE]
| YES
<Successor independently authorized?> -- NO --> [REFUSE]
| YES
[Reconstruct successor actual effect at FS]
|
<Current finality valid?> -- NO --> [REFUSE]
| YES
[Controlled successor effect]
Das Expires 29 April 2027 [Page 42]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Figure 4: Embodiment 4 — Cross-Domain Consequential Effect
Evidence and Remote Outcome Qualification — effectuation
decisions
5.2.3. Original Technical Disclosure — Page-Indexed Sections
5.2.3.1. Original Source — Global Page 492
The embodiment may be implemented through operating-system mediation,
protected application services, trusted execution environments,
secure controllers, remote protected services, or suitably
authenticated distributed arrangements.
An optional IEV may perform additional last-mile correspondence
verification.
An optional scope-deviation mechanism may request new user authority
for a changed target.
The proposed architecture remains applicable to single-act execution-
finality control without requiring every operation to use phased
continuation or human approval.
The central proposed technical contribution is the protected,
enforceable correspondence between an authenticated user-reference
context, a verified semantically resolved entity, and the actual
operation reconstructed at the consequential effectuation boundary,
including authorized temporal and cross-application transformations.
The inventive step of any claimed technical combination remains
subject to examination against existing graphical interface
grounding, entity-resolution, action-verification, concurrency-
control, and protected execution technologies.
END OF EMBODIMENT 3.
EMBODIMENT 4
PROTECTED CROSS-DOMAIN ACTUAL-CONSEQUENCE WITNESSING WITH OPERATION-
BOUND REMOTE STATE EVIDENCE, INDEPENDENT OBSERVATION, CROSS-COMMITTED
EFFECT PROOFS, AND SINK-ENFORCED OUTCOME-DEPENDENT AUTHORITY
4.0 — COMPLETE TECHNICAL TITLE
Das Expires 29 April 2027 [Page 43]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Systems and Methods for Protected Cross-Domain Actual-Consequence
Witnessing Using Authenticated Operation-to-Remote-State
Correspondence, Independently Qualified Effect Observers, Cross-
Committed Consequence Evidence, Protected Outcome Reconciliation, and
Scoped Continuation Authority Across Heterogeneous Autonomous
Computing Domains
4.0.1 — General Characterization
The present embodiment discloses systems, methods, apparatus,
protected computing components, authenticated communication
protocols, cryptographic evidence structures, independent observation
mechanisms, protected state transitions, and non-limiting reference
implementations for determining whether an operation authorized and
initiated in one computing domain has actually produced a specified
consequential state change in another computing domain.
The architecture may be applied to artificial-intelligence agents,
autonomous computing systems, operating-system services, application
frameworks, distributed workflows, financial systems, remote storage
services, communication platforms, cloud infrastructure, enterprise
applications, telecommunications systems, robotic controllers,
industrial computing systems, and other computational entities
capable of initiating consequential operations across trust or
administrative boundaries.
5.2.3.2. Original Source — Global Page 493
In one non-limiting implementation, an autonomous agent operating
within a first computing domain requests authorization to perform an
operation whose intended consequence is located within a second
computing domain.
The first domain may independently validate the requested operation
and authorize its transmission or dispatch through a designated
Finality Sink.
However, successful dispatch from the first domain does not
necessarily establish that the intended consequence occurred within
the second domain.
The remote operation may be received, rejected, queued, accepted,
partially executed, committed, subsequently reversed, or completed
without the originating domain receiving a corresponding
acknowledgement.
Das Expires 29 April 2027 [Page 44]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The present embodiment addresses the technical distinction between
authorization of a remote operation and independently supportable
evidence concerning its actual remote consequence.
The architecture introduces a Cross-Domain Actual-Consequence
Witnessing mechanism, hereinafter also referred to as CDACW,
configured to bind a protected originating Candidate Act to
authenticated evidence concerning a specified remote effect.
The CDACW mechanism may obtain evidence from a remote protected
enforcement component, an independently controlled observer, an
authenticated state-transition record, a verifiable storage-state
proof, a qualified sensor, a cooperating remote authority, or another
technically suitable source.
The system evaluates the extent to which the observation evidence
establishes the specifically required remote outcome.
Where sufficient evidence exists, the system may commit a protected
remote-outcome record.
Where evidence is incomplete, inconsistent, stale, or insufficiently
trustworthy, the system represents the corresponding uncertainty
rather than falsely asserting verified completion.
Where a subsequent consequential operation depends upon the remote
result, the result may be supplied to an Interim Effectuation
Validator or other protected continuation component.
The successor operation remains subject to independently scoped
authorization and Finality Sink verification.
4.0.2 — Central Technical Principle
The controlling principle of the present embodiment is:
Authorization to initiate a remote consequential operation,
successful transmission of its request, and receipt of an
acknowledgement from the remote service are not necessarily
equivalent to independently verified occurrence of the intended
remote consequence.
In a protected implementation, the claimed remote outcome must be
supported by evidence obtained through an observation mechanism
capable of establishing the particular asserted consequence.
Das Expires 29 April 2027 [Page 45]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Where the relevant consequence cannot be independently verified, the
system may classify it as unverified or unknown and withhold
operations whose authorization requires verified completion.
5.2.3.3. Original Source — Global Page 494
4.0.3 — Nature of the Proposed Technical Contribution
The proposed technical contribution does not rest merely upon
generating a digital signature, storing an audit record, obtaining a
server acknowledgement, using a transparency ledger, or verifying the
integrity of a remote computing environment.
Such techniques may provide supporting mechanisms.
The potentially distinguishing arrangement concerns the enforceable
binding among:
1. A protected originating Candidate Act;
2. The actual outbound operation presented at the originating
Finality Sink;
3. A remote operation identity or effect-specific transaction
reference;
4. A defined remote consequence predicate;
5. A qualified observation source capable of supporting that
predicate;
6. Authenticated evidence of the relevant remote state or effect;
7. A protected correspondence decision between the authorized
operation and observed consequence;
8. An authenticated remote-outcome commitment;
9. A separately enforced decision governing any dependent subsequent
consequence.
Where the remote system supports authenticated before-state and
after-state evidence, the architecture may additionally verify a
specified state transition.
Where independent evidence is unavailable, the architecture does not
assume that a signed remote success statement proves the underlying
consequence.
Das Expires 29 April 2027 [Page 46]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The specific technical arrangements are described below.
4.1 — TECHNICAL FIELD
The embodiment relates to autonomous execution security, distributed
system verification, cryptographic evidence, remote transaction
monitoring, trusted execution environments, protected hardware
controllers, verifiable data structures, effectuation-boundary
enforcement, inter-domain operation tracking, distributed state
consistency, authenticated observation, and consequence-dependent
execution authority.
More particularly, the embodiment concerns the establishment of
trustworthy correspondence between an operation authorized within a
first protected computing domain and an actual consequence occurring
within a different computing domain.
The disclosure is applicable where the originating computing system
cannot safely infer completion solely from local dispatch, transport
acknowledgement, remote acceptance, or the requesting agent's own
conclusion.
5.2.3.4. Original Source — Global Page 495
The architecture may be implemented through local and remote
protected components, authenticated service interfaces, independently
operated verification services, secure controller observations,
hardware-backed evidence, cryptographic state proofs, or suitable
combinations thereof.
No particular cloud provider, payment network, operating system,
cryptographic primitive, trusted processor manufacturer, distributed
ledger, or AI model is essential to the disclosed architecture.
4.2 — SPECIFIC TECHNICAL PROBLEMS
4.2.1 — Local Authorization Versus Remote Consequence
An autonomous agent may be authorized to submit a remote operation.
The originating Finality Sink may independently verify the actual
request, destination, resource, and scoped authority.
Following successful verification, the request may be transmitted.
However, the originating sink does not necessarily control the remote
system's subsequent internal behavior.
Das Expires 29 April 2027 [Page 47]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The remote system may accept the request without immediately
performing the requested operation.
It may also return an error after performing part of the operation.
Therefore, authorization and successful dispatch do not establish
actual remote completion.
4.2.2 — Remote Acknowledgement Ambiguity
A remote response may indicate:
• Request received;
• Request authenticated;
• Request accepted for processing;
• Operation queued;
• Operation execution started;
• Local transaction committed;
• Remote replication pending;
• External settlement pending;
• Physical actuation initiated;
• Requested business process completed.
These assertions represent different technical events.
5.2.3.5. Original Source — Global Page 496
An acknowledgement identifying one event does not necessarily
establish another.
For example, an HTTP success response may indicate acceptance of a
request but may not establish that an external payment settled or
that a physical device reached the intended position.
The present embodiment requires explicit identification of the
consequence that the evidence is intended to establish.
4.2.3 — Remote Service Self-Reporting
Das Expires 29 April 2027 [Page 48]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The originating domain may receive a signed statement from the remote
service declaring success.
The signature may authenticate the identity of the statement issuer
and protect the statement against modification.
However, a correctly signed false statement remains false.
The remote service may be compromised, defective, misconfigured, or
unable to observe the specific claimed consequence.
The architecture therefore distinguishes authenticated reporting from
independently supportable remote outcome evidence.
4.2.4 — Remote Effect-Identity Substitution
A remote service may return a valid record concerning a different
operation.
For example, an agent may request storage of Object A and receive a
receipt describing Object B.
The record may be authentic but unrelated to the authorized Candidate
Act.
Accordingly, the system must verify correspondence among the
authorized operation, remote effect identity, actual destination, and
observed state.
4.2.5 — Remote State-Version Changes
A remote resource may change after the request is transmitted.
A later observation may reveal a state different from the expected
state.
The difference may result from the authorized operation, a concurrent
independent operation, a rollback, replication delay, or another
cause.
Observation of a changed remote state does not necessarily prove that
the originating operation caused the change.
A sufficiently strong implementation must therefore establish the
required causal or operation-specific relationship.
4.2.6 — Multi-Stage External Effects
Das Expires 29 April 2027 [Page 49]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A remote operation may involve several technical stages.
5.2.3.6. Original Source — Global Page 497
For example, a document may be uploaded, stored, indexed, replicated,
made visible to a recipient, and eventually read.
Each stage may be independently consequential.
A receipt establishing storage does not necessarily establish
recipient access.
A payment authorization does not necessarily establish settlement.
An actuator-command acknowledgement does not necessarily establish
actual physical movement.
The architecture must preserve distinctions among these effect
stages.
4.2.7 — Partial and Irreversible Remote Effects
A remote service may complete only part of a requested operation.
Some effects may be irreversible.
Examples include transmission of private information, external
financial settlement, publication of content, or physical actuation.
A local rollback cannot necessarily eliminate those consequences.
The architecture must support evidence-qualified partial-outcome
classification and separately governed recovery.
4.2.8 — Remote Administrative Independence
The originating agent and remote service may operate under different
administrators, security policies, hardware platforms, or legal
entities.
The originating domain may not have unrestricted access to the remote
service's internal database, transaction logs, or protected
controller state.
The system must therefore define which verification mechanisms are
available and what conclusion each can support.
Das Expires 29 April 2027 [Page 50]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A nonparticipating remote service cannot be assumed to provide
independent verifiability merely because the originating system
requests it.
4.2.9 — Technical Objective
The principal objective is to establish an implementable arrangement
in which a defined remote consequence can be verified using evidence
that is:
• Authenticated to an acceptable source;
• Bound to the correct originating operation;
• Bound to the relevant remote resource or effect;
• Fresh for the required verification purpose;
5.2.3.7. Original Source — Global Page 498
• Supported by the source's actual observation capabilities;
• Evaluated under appropriate state-consistency rules;
• Resistant to replay or substitution;
• Incorporated into protected consequence-state management;
• Enforceable as a predicate for any dependent subsequent operation.
4.3 — RELATIONSHIP TO COMMON WORKFLOWS
The present embodiment may incorporate Common Master Workflow CW-1.
The originating Candidate Act may be held in a Non-Effective State
while the PED validates its authority.
The originating Finality Sink independently verifies the actual
pending external operation before permitting dispatch.
The embodiment may incorporate CW-2 where a successor operation
depends upon verified remote outcome evidence.
In such an implementation, the remote-outcome evidence may be
represented as or incorporated into a Protected Effect Receipt.
An IEV may independently evaluate that evidence before permitting
continuation.
Das Expires 29 April 2027 [Page 51]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The embodiment may incorporate CW-3 where an unexpected remote
operation, changed destination, different resource, or anomalous
consequence indicates a possible departure from originally authorized
task scope.
The individual mechanisms remain distinguishable.
CW-1 governs the authority to perform an operation.
CW-2 optionally governs independent phase validation and
continuation.
CW-3 optionally governs scope-deviation detection and
reauthorization.
Embodiment 4 governs the evidentiary and enforceable relationship
between an authorized operation and the actual consequence claimed to
have occurred in another computing domain.
The CDACW mechanism may operate independently of CW-2 where only
consequence verification or protected outcome reporting is required.
4.4 — ADDITIONAL TECHNICAL DEFINITIONS
4.4.1 — Originating Execution Domain (OED)
5.2.3.8. Original Source — Global Page 499
The Originating Execution Domain is the computing domain in which a
Candidate Act is proposed, authorized, or released toward a remote
destination.
The OED may contain an agent, PED, Finality Sink, and protected
operation-state manager.
4.4.2 — Remote Effect Domain (RED)
A Remote Effect Domain is the computing or physical domain in which
the consequence under examination is expected to occur.
The RED may comprise a remote application, cloud service, database,
payment processor, storage platform, device controller, or other
effect-capable system.
4.4.3 — Cross-Domain Effect Intent Descriptor (CDEID)
Das Expires 29 April 2027 [Page 52]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A Cross-Domain Effect Intent Descriptor is a machine-verifiable
representation of the specific remote consequence required by the
originating operation.
The CDEID distinguishes the intended remote effect from the mere
transmission of a request.
4.4.4 — Remote Effect Identity (REI-4)
A Remote Effect Identity is an authenticated identifier or protected
reference associated with a specific remote operation or effectuation
attempt.
The designation REI-4 distinguishes this term from the Resolved
Entity Identity defined in Embodiment 3.
4.4.5 — Remote Consequence Predicate (RCP)
A Remote Consequence Predicate is a technical condition defining the
remote state or event whose occurrence must be established.
An RCP may include a resource state, version, quantity, recipient,
operation type, persistence condition, or physical observation
requirement.
4.4.6 — Qualified Effect Witness (QEW)
A Qualified Effect Witness is an observation component whose
identity, technical observation capabilities, and applicable trust
properties have been established for a defined class of consequences.
A QEW may be independent of the requesting agent without necessarily
being independent of the remote service administrator.
Its exact independence properties must be identified.
4.4.7 — Witness Capability Declaration (WCD)
A Witness Capability Declaration specifies which consequences and
evidentiary properties a particular witness can support.
5.2.3.9. Original Source — Global Page 500
The WCD may include observation scope, supported resources, trusted
measurement interface, authentication key, observation time
semantics, and known limitations.
4.4.8 — Remote Effect Observation Record (REOR)
Das Expires 29 April 2027 [Page 53]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A Remote Effect Observation Record is an authenticated record
describing a remote event or resource state observed by a QEW.
The record may contain actual operation identity, relevant state,
outcome classification, observation sequence, and evidence reference.
4.4.9 — Causal State-Delta Attestation (CSDA)
A Causal State-Delta Attestation is a record or protected evidence
construction establishing a defined relationship between a particular
operation and a corresponding remote state transition.
Depending upon the implementation, the record may include
authenticated before-state and after-state commitments, transaction
identity, protected execution ordering, and a remote controller
commitment.
The term does not imply causality where the available evidence
establishes only correlation.
4.4.10 — Cross-Domain Effect Binding Record (CDEBR)
A Cross-Domain Effect Binding Record is an authenticated commitment
linking the originating Candidate Act, actual dispatched operation,
remote effect identity, consequence predicate, and relevant witness
evidence.
4.4.11 — Witness Independence Profile (WIP)
A Witness Independence Profile identifies the administrative,
computational, hardware, measurement, and evidentiary independence of
one or more witnesses.
A WIP may identify shared trust roots or correlated failure modes.
4.4.12 — Remote Outcome Assurance Class (ROAC)
A Remote Outcome Assurance Class identifies the extent of the remote
consequence supported by verified evidence.
Different classes may correspond to dispatch, receipt, acceptance,
state commitment, independently observed state, or stronger outcome
claims.
4.4.13 — Protected Remote Outcome Commitment (PROC)
A Protected Remote Outcome Commitment is a protected representation
of the verified remote outcome and its supporting evidence.
Das Expires 29 April 2027 [Page 54]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A PROC may be used by CW-2 as an input to continuation validation.
4.4.14 — Remote Outcome Reconciliation Fence (RORF)
5.2.3.10. Original Source — Global Page 501
A Remote Outcome Reconciliation Fence is protected state that
prevents specified unsafe retry, continuation, duplicate
effectuation, or conflict-reservation release while the remote result
remains unresolved.
4.4.15 — Remote Witness Equivocation
Remote Witness Equivocation occurs when a witness presents materially
incompatible authenticated accounts of the same relevant remote event
or state without an authorized explanation.
4.4.16 — Consequence Finality Condition (CFC)
A Consequence Finality Condition specifies when a particular remote
outcome is sufficiently stable or completed for the intended reliance
purpose.
A CFC may require a committed database version, completed settlement,
a confirmed delivery event, an authenticated physical-state
observation, or another expressly defined condition.
4.4.17 — Evidence-Qualified Outcome (EQO)
An Evidence-Qualified Outcome is an outcome classification
accompanied by an indication of what the evidence technically
supports.
An EQO may establish a limited fact without establishing all
downstream consequences of the operation.
4.5 — TRUST MODEL AND IMPLEMENTATION ASSUMPTIONS
4.5.1 — Trust Separation
The OED and RED may be independently administered.
The originating agent is not presumed to control or fully observe the
remote consequence.
A remote service's self-reported result is not automatically treated
as independently verified.
Das Expires 29 April 2027 [Page 55]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
4.5.2 — Independent Witnessing Versus Authenticated Self-Reporting
The embodiment distinguishes several possible arrangements.
In a first arrangement, the remote application provides its own
signed acknowledgement.
In a second arrangement, a protected controller within the remote
service produces authenticated state-transition evidence.
In a third arrangement, a separately controlled observer examines
relevant remote state.
In a fourth arrangement, multiple witnesses independently observe
different evidence channels.
These arrangements may provide different levels of assurance.
The architecture does not incorrectly characterize every
authenticated remote message as independent witnessing.
5.2.3.11. Original Source — Global Page 502
4.5.3 — Remote Controller Trust
A protected remote transaction controller may establish an operation-
specific state transition within the controller's enforcement domain.
However, this conclusion depends upon whether the protected component
actually controls the relevant state mutation and whether its
evidence-generation path is trustworthy.
A software service that can freely forge arbitrary database state
cannot establish independent state truth solely by signing its own
report.
4.5.4 — Remote Attestation Limitations
Remote attestation may provide evidence about the configuration or
execution environment of a remote component.
Such evidence can help establish trust in the component's observation
or enforcement capabilities.
However, attestation of code identity or platform state does not
automatically prove that a specific external operation produced its
intended consequence.
Das Expires 29 April 2027 [Page 56]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The corresponding consequence must be measured or established through
an appropriate additional mechanism.
4.5.5 — Independent Observer Limitations
A separately administered observer may provide useful independent
evidence.
However, the observer must be technically capable of observing the
required event or state.
For example, a monitoring service that sees a network request cannot
necessarily verify remote database commitment.
Independence of administration does not compensate for lack of
observation capability.
4.5.6 — Physical Consequence Limitations
A protected actuator controller may report command acceptance.
A physical sensor may report a measured position.
Neither result alone necessarily establishes every intended real-
world outcome.
Where physical consequences matter, the embodiment identifies the
specific physical property being measured and the assurance limits of
the sensing arrangement.
4.5.7 — Unavailable Remote Verification
Where a remote service does not cooperate and no independently
trustworthy observation source exists, the system may be unable to
establish the claimed remote consequence.
The implementation may record the operation as unverified, unknown,
or supported only by a limited remote assertion.
5.2.3.12. Original Source — Global Page 503
It shall not characterize such an operation as independently verified
merely because it obtained an ordinary success response.
4.5.8 — Scope of Security Guarantee
Das Expires 29 April 2027 [Page 57]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The disclosed security guarantee applies to the effects and
observations actually controlled or verified by the implemented trust
boundaries.
No generic remote protocol can guarantee the truth of arbitrary
external-world claims without an observation or enforcement basis
capable of supporting those claims.
4.6 — DETAILED SYSTEM ARCHITECTURE
4.6.1 — Originating Candidate Act Controller
An originating Candidate Act Controller receives or constructs an
operation intended to affect an external resource.
The controller identifies the relevant remote consequence and forms a
CDEID.
The controller may operate within the Candidate Act Construction
Component described in CW-1.
4.6.2 — Originating Protected Enforcement Domain
The originating PED validates the individual authority to perform the
external operation.
It may maintain protected operation identifiers, authorization
commitments, expected remote outcomes, retry constraints, and
revocation state.
The PED may generate scoped non-bearer finality authority for the
outbound operation.
4.6.3 — Originating Finality Sink
The originating Finality Sink independently verifies the actual
outbound operation.
The sink may comprise a protected network gateway, service-operation
dispatcher, credential-release controller, transaction gateway,
storage-export interface, or equivalent consequential boundary.
It may bind the actual dispatched operation to an authenticated
attempt identifier.
4.6.4 — Remote Operation Correlation Component
Das Expires 29 April 2027 [Page 58]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A Remote Operation Correlation Component associates the originating
operation with the remote effect identity.
The component may employ an authenticated operation identifier,
request nonce, idempotency reference, destination transaction
identifier, or another technically suitable correlation mechanism.
The identifier must not be accepted as proof of actual remote
completion by itself.
4.6.5 — Remote Effectuation Controller
5.2.3.13. Original Source — Global Page 504
Where the remote system participates, a Remote Effectuation
Controller governs the specified remote state transition.
The controller may validate the requested operation and commit the
resulting state under authenticated transactional or protected
controller semantics.
The component may produce an operation-bound completion record.
4.6.6 — Witness Evidence Collection Component
A Witness Evidence Collection Component obtains REORs from one or
more designated witnesses.
It may request observations after dispatch or receive authenticated
event notifications.
The component verifies message authenticity and correlation
identifiers before submitting evidence for appraisal.
4.6.7 — Witness Qualification Registry
A Witness Qualification Registry maintains WCDs and applicable WIPs.
The registry identifies:
• Witness identity;
• Supported observations;
• Observation source;
• Trusted measurement or state interface;
Das Expires 29 April 2027 [Page 59]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
• Protected key or authentication mechanism;
• Relevant administrative control;
• Supported consequence predicates;
• Limitations;
• Validity period;
• Revocation state.
The registry may be local, protected, distributed, or supplied
through authenticated reference values.
4.6.8 — Cross-Domain Consequence Verifier
A Cross-Domain Consequence Verifier, or CDCV, evaluates the collected
evidence against the CDEID and required RCP.
The CDCV determines what outcome is actually supported.
It does not automatically promote a weaker witness claim into a
stronger finality conclusion.
4.6.9 — Protected Remote Outcome Registry
5.2.3.14. Original Source — Global Page 505
A Protected Remote Outcome Registry maintains relevant remote outcome
state.
It may include:
• Original Candidate Act identifier;
• Actual outbound request commitment;
• Remote effect identity;
• Witness evidence commitments;
• Current outcome assurance class;
• Outstanding reconciliation requirements;
• Protected attempt state;
Das Expires 29 April 2027 [Page 60]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
• Consumed retry or continuation references;
• Applicable successor-operation dependencies.
4.6.10 — Remote Outcome Reconciliation Controller
A Remote Outcome Reconciliation Controller obtains additional
evidence when the reported outcome is incomplete or contradictory.
It may update the protected outcome classification or preserve the
RORF.
4.6.11 — Optional Interim Effectuation Validator
Where a subsequent consequential act depends upon the remote outcome,
the IEV may evaluate the PROC under CW-2.
The IEV independently determines whether the specific continuation
predicate has been satisfied.
The resulting continuation authority remains scoped to the successor
operation.
4.6.12 — Optional Scope-Deviation Monitor
Where the actual remote operation or outcome indicates unexpected
destination, resource, effect type, or scope expansion, CW-3 may be
invoked.
The suspected deviation does not by itself confer authority for
corrective or additional actions.
4.7 — CROSS-DOMAIN EFFECT INTENT DESCRIPTOR
4.7.1 — Purpose
A CDEID represents the remote consequence that the originating system
intends to establish.
It distinguishes the requested external state from the mere
communication sent to request that state.
5.2.3.15. Original Source — Global Page 506
4.7.2 — Representative Data Structure
Das Expires 29 April 2027 [Page 61]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
CROSS_DOMAIN_EFFECT_INTENT_DESCRIPTOR = { protocol_version,
originating_candidate_act_id, originating_domain_id,
requesting_principal_commitment,
actual_outbound_operation_commitment, designated_remote_domain_id,
remote_resource_identity, remote_effect_class,
expected_operation_semantics, expected_preconditions,
required_remote_postconditions, acceptable_partial_outcomes,
required_outcome_assurance_class, remote_operation_correlation_nonce,
applicable_remote_state_version, intended_finality_condition,
witness_policy_reference, authority_epoch, revocation_epoch,
designated_originating_sink_id, protected_authentication } The
structure is illustrative.
The implementation may include additional effect-specific fields.
4.7.3 — Defined Consequence Predicate
The CDEID may require verification of an exact resource state.
For example:
"The designated remote object is stored under Object ID O-45 with
content digest H-X and committed version V12."
Another predicate may require:
"The remote payment transaction is recorded as settled by the
designated authoritative settlement system."
Another may require:
"The remote actuator position is within a defined measured tolerance
interval."
Each predicate must be evaluated according to evidence capable of
supporting that specific claim.
4.7.4 — Avoiding Vague Success Predicates
A predicate expressed merely as "task successful" may be too vague to
support meaningful independent verification.
5.2.3.16. Original Source — Global Page 507
The implementation may convert the objective into measurable
technical conditions.
Das Expires 29 April 2027 [Page 62]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Where the intended business or human-level objective cannot be
directly verified, the system may establish narrower technical facts
and preserve the distinction.
4.7.5 — Authorized Result Variants
A CDEID may identify multiple acceptable outcomes.
For example, a remote storage operation may validly produce a new
resource version or identify an existing identical object under an
expressly defined deduplication rule.
The system verifies that the reported outcome falls within the
permitted alternatives.
The alternatives are established as part of the protected
authorization rather than added by an untrusted agent after the fact.
4.8 — OUTCOME ASSURANCE CLASSIFICATION
The embodiment may employ evidence-qualified outcome classes.
These classes are not necessarily arranged as a universally strict
linear hierarchy because some observations establish different types
of facts.
Class O0 — Local Authorization Verified
The originating operation passed applicable protected authorization.
This does not establish that the remote request was transmitted.
Class O1 — Local Dispatch Verified
A protected originating component establishes that the specified
outbound request was dispatched.
This does not establish receipt by the remote service.
Class O2 — Remote Receipt Verified
An authenticated remote component establishes receipt of the
specified request.
This does not necessarily establish acceptance or execution.
Class O3 — Remote Acceptance Verified
Das Expires 29 April 2027 [Page 63]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An appropriate remote component establishes acceptance of the
operation for processing.
This does not necessarily establish the requested persistent state
change.
Class O4 — Remote Commit Report Authenticated
A remote component authenticates a report identifying a committed
state transition.
5.2.3.17. Original Source — Global Page 508
The conclusion depends upon the trustworthiness and actual
capabilities of the reporting component.
Class O5 — Remote State Observed
A qualified observer verifies that a specified remote state or
condition is present.
This does not necessarily establish that the originating operation
caused the state.
Class O6 — Operation-Bound Remote Transition Verified
Sufficient authenticated evidence establishes that the particular
originating operation produced or participated in the specified
remote state transition under the supported causal model.
Class O7 — Required Consequence Finality Verified
The evidence establishes the applicable CFC, such as a particular
durable commit, authoritative settlement state, or defined physical
observation.
This does not imply permanent irreversibility unless the underlying
system actually provides that property.
Class OU — Outcome Unknown
Evidence is insufficient to establish the required outcome.
Class OP — Partial Outcome Verified
Evidence supports only a defined subset of the required consequence.
Class OM — Mismatch Verified
Das Expires 29 April 2027 [Page 64]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Evidence establishes a material difference between the expected and
actual remote consequence.
The classes are illustrative.
An implementation may use effect-specific assurance profiles rather
than these exact labels.
The verifier must evaluate whether the evidence supports the
particular result required by the relying operation.
4.9 — QUALIFIED EFFECT WITNESSING
4.9.1 — Witness Capability Requirements
A QEW must have an identifiable observation path to the relevant
consequence.
The WCD identifies the properties that the witness can verify.
For example, a database controller may observe committed state.
A network controller may observe dispatch.
5.2.3.18. Original Source — Global Page 509
A message recipient service may observe delivery into a recipient-
owned mailbox.
A separate measurement device may observe a physical parameter.
4.9.2 — Witness Authentication
The witness may authenticate observations through digital signatures,
message-authentication codes, authenticated channels, hardware-
protected records, or equivalent methods.
Authentication protects the integrity and source of the record.
It does not independently establish that the witness is honest or
correctly implemented.
4.9.3 — Witness State Binding
Where the witness reports a resource state, the record may identify:
• Resource identity;
Das Expires 29 April 2027 [Page 65]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
• Resource version;
• Relevant state commitment;
• Observation time or sequence;
• Observation authority;
• Remote service identity;
• Applicable operation identifier.
The verifier checks the relevant bindings.
4.9.4 — Witness Freshness
An earlier observation cannot automatically establish the current
state of a mutable remote resource.
The witness evidence may be bound to a trusted sequence, remote state
version, transaction index, challenge nonce, or other freshness
mechanism.
The applicable freshness predicate depends upon the consequence being
verified.
4.9.5 — Witness Revocation
A witness whose authentication keys are compromised or whose
measurement capability is no longer trustworthy may be revoked.
The verifier checks the applicable witness validity state before
relying upon new evidence.
Earlier evidence may require reassessment where the applicable
security policy identifies compromise affecting its validity.
4.9.6 — Witness Independence
5.2.3.19. Original Source — Global Page 510
A witness may be independent of the requesting agent but controlled
by the same administrator as the remote service.
Another witness may be independently administered but obtain its
information from the remote service's self-reported API.
These arrangements have different independence properties.
Das Expires 29 April 2027 [Page 66]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The system records those properties explicitly where the distinction
matters.
4.9.7 — Non-Circular Verification
The verifier avoids treating multiple records derived from the same
unverified assertion as independent confirmation.
For example, two monitoring services that merely copy a remote
server's signed success response do not create two independent
measurements of actual state.
A quorum based on those two reports does not establish independence
merely because two signatures are present.
4.10 — REMOTE EFFECT OBSERVATION RECORD
4.10.1 — Representative Structure
REMOTE_EFFECT_OBSERVATION_RECORD = { record_version, witness_id,
witness_capability_profile_id, remote_effect_domain_id,
remote_resource_id, originating_operation_commitment,
remote_effect_identity, remote_execution_attempt_id,
observed_effect_class, observed_before_state_commitment,
observed_after_state_commitment, observed_state_version,
observation_sequence, observation_time_or_interval,
causal_linkage_evidence_reference, supported_assurance_class,
uncertainty_or_partial_effect_flags, protected_authentication }
4.10.2 — Before-State Evidence
A remote observer may record the relevant resource state before
effectuation.
The before-state evidence may comprise a version number, content
commitment, authenticated database root, controller state, or
equivalent representation.
5.2.3.20. Original Source — Global Page 511
4.10.3 — After-State Evidence
Following an operation, the observer may obtain corresponding after-
state evidence.
A changed state may support an inference that an effect occurred.
However, a before/after difference alone does not necessarily prove
that the specific originating operation caused the change.
Das Expires 29 April 2027 [Page 67]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
4.10.4 — Operation Correlation
Where causality matters, the record may contain authenticated linkage
between the operation identifier and the resulting state transition.
Such linkage may be generated by a controller that atomically records
the applied operation and state mutation within the same protected
transaction or equivalent enforced state machine.
4.10.5 — Independent State Observation
Another witness may verify the resulting remote state through a
separately controlled read or measurement interface.
The additional observation may strengthen evidence that the state
exists.
It does not automatically prove causation unless the necessary
operation-specific relationship is separately established.
4.11 — CAUSAL STATE-DELTA ATTESTATION
4.11.1 — Purpose
A CSDA provides an implementation option for establishing stronger
correspondence between an authorized operation and a remote state
mutation.
The mechanism may be used where the remote effectuation controller
participates in the verification protocol.
4.11.2 — Required Operation Identity
The originating sink generates or binds an authenticated operation
reference.
The reference is unique within the applicable replay and transaction
domain.
The reference may include a nonce, protected sequence, resource
identity, and operation commitment.
4.11.3 — Protected Before-State
The remote controller obtains the relevant pre-operation state.
The state may be represented by an authenticated resource version or
commitment.
Das Expires 29 April 2027 [Page 68]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.2.3.21. Original Source — Global Page 512
4.11.4 — Remote Operation Application
The remote controller verifies applicable remote authority and
applies the authorized operation.
Where the operation modifies a transactional resource, the controller
may commit the operation and corresponding operation-identity record
within one durable transaction.
4.11.5 — Protected After-State
The controller obtains the resulting state or committed transaction
result.
The result is associated with the specific operation identifier.
4.11.6 — Atomic Operation-to-State Binding
In one implementation, the remote transactional controller commits:
1. The originating operation reference;
2. The actual applied operation;
3. The prior resource version;
4. The resulting resource version;
5. The transaction outcome;
6. The protected commit sequence.
The record is committed within the same transaction as the governed
resource mutation, or through an equivalent mechanism providing the
required linkage.
4.11.7 — Attestation Generation
Following commitment, the controller generates an authenticated CSDA
referencing the committed transaction.
The attestation may be signed after the transaction, provided the
record is durably recoverable and cannot be substituted by an
untrusted component under the stated trust model.
4.11.8 — Concurrency Handling
Das Expires 29 April 2027 [Page 69]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Where concurrent remote operations can modify the same resource, the
CSDA uses appropriate transaction identifiers, protected sequence
ordering, and resource-version constraints.
The verifier does not attribute an arbitrary observed state
difference to the originating operation merely because it occurred
within a similar time interval.
4.11.9 — Limits of Causal Assurance
A CSDA supports a causal conclusion only to the extent that the
reporting controller correctly mediates the relevant operation and
maintains trustworthy operation-to-state linkage.
5.2.3.22. Original Source — Global Page 513
If the remote administrator can forge the transactional history, the
attestation may remain an authenticated remote assertion rather than
independently established causality.
A stronger implementation may combine the CSDA with protected
execution, independent state observation, or another appropriate
trust mechanism.
4.12 — CROSS-COMMITTED REMOTE EFFECT BINDING
4.12.1 — First Commitment: Authorized Remote Intent
The originating PED commits the Candidate Act and CDEID.
In one illustrative construction:
A = H("REMOTE-INTENT-V1" || CANONICAL(CAD) || CANONICAL(CDEID) ||
AUTHORITY_EPOCH)
The value is maintained within authenticated protected state or
signed as appropriate.
4.12.2 — Second Commitment: Actual Outbound Operation
The originating Finality Sink independently obtains the actual
outbound operation.
It commits:
B = H("REMOTE-DISPATCH-V1" || A || ACTUAL_OPERATION || DESTINATION ||
ATTEMPT_ID)
Das Expires 29 April 2027 [Page 70]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The actual operation representation is canonicalized before
commitment.
This commitment establishes the relation between the authorized
intent and actual dispatch.
It does not establish the remote outcome.
4.12.3 — Third Commitment: Remote Observed Effect
A qualified witness generates or provides authenticated evidence.
The remote evidence commitment may be:
C = H("REMOTE-EFFECT-V1" || B || REMOTE_EFFECT_ID || OBSERVATION ||
OUTCOME_CLASS || WITNESS_ID)
The evidence supports only the consequence observable by the witness.
4.12.4 — Fourth Commitment: Protected Outcome Decision
The CDCV evaluates the witness evidence against the required RCP.
If the required predicate is established, the PED or protected
outcome controller commits:
D = AUTH_PROTECT(H("REMOTE-OUTCOME-V1" || A || B || C ||
VERIFIED_PREDICATE || OUTCOME_STATE))
5.2.3.23. Original Source — Global Page 514
4.12.5 — Optional Fifth Commitment: Continuation Authority
Where a successor operation requires verified remote completion, the
optional IEV may validate D and authorize a successor-specific CAR.
The resulting finality authority may bind:
E = AUTH_PROTECT(H("REMOTE-CONTINUATION-V1" || D || SUCCESSOR_CAD ||
SINK_ID || NONCE))
4.12.6 — Technical Significance
These commitments are not merely an audit chain.
In an applicable implementation, the finality-enforcement system
verifies the required protected outcome commitment before permitting
a dependent successor act.
Das Expires 29 April 2027 [Page 71]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An unrelated signed receipt cannot be substituted for the required
remote result.
The implementation may use sealed handles, authenticated state
references, hardware-protected records, or equivalent constructions
instead of separate hash objects.
4.13 — PROTECTED REMOTE OUTCOME STATE MACHINE
4.13.1 — Candidate Authorized
The originating Candidate Act satisfies its applicable protected
authorization conditions.
No remote outcome is presumed.
4.13.2 — Dispatch Authorized
The originating Finality Sink verifies the actual outbound operation.
The request may be dispatched.
4.13.3 — Dispatch Attempted
An authenticated attempt record identifies the actual transmitted
operation and destination.
4.13.4 — Remote Receipt Observed
A qualified source establishes receipt by the remote service, where
supported.
4.13.5 — Remote Acceptance Observed
The remote service reports or proves acceptance according to the
available evidence.
4.13.6 — Remote Effect Pending
The requested remote consequence has not yet been established.
5.2.3.24. Original Source — Global Page 515
4.13.7 — Remote Effect Observed
A witness establishes an applicable remote state or event.
4.13.8 — Causal Correspondence Validated
Das Expires 29 April 2027 [Page 72]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Where required, the verifier establishes the operation-to-outcome
relationship under the applicable causal evidence rules.
4.13.9 — Consequence Predicate Satisfied
The required RCP is verified at the necessary assurance level.
4.13.10 — Outcome Commitment Finalized
The PROC is committed to protected state.
4.13.11 — Outcome Unknown
Evidence remains insufficient.
The operation is not falsely classified as completed.
4.13.12 — Partial Outcome
Only a defined subset of the expected consequence is supported.
4.13.13 — Outcome Mismatch
The verified remote effect differs materially from the authorized
target or expected result.
4.13.14 — Reconciliation Pending
The system awaits additional evidence or executes a specifically
authorized reconciliation procedure.
4.13.15 — Continuation Eligible
A successor operation may be considered only when its own required
outcome predicates are satisfied.
4.13.16 — Recovery Pending
A separately authorized recovery operation may be required.
These states may be combined or specialized.
The particular protected state transitions depend upon the required
remote-effect assurance.
4.14 — COMPLETE OPERATIONAL WORKFLOW
Step 1 — Construct Remote Candidate Act
Das Expires 29 April 2027 [Page 73]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.2.3.25. Original Source — Global Page 516
An autonomous computational entity proposes an operation affecting a
resource or system outside its originating domain.
Step 2 — Define the Required Remote Consequence
The system constructs a CDEID identifying the specific external state
or event to be established.
Step 3 — Establish Required Assurance
The system identifies the ROAC and witness requirements appropriate
to the remote consequence.
Step 4 — Perform Originating Protected Validation
The PED verifies the Candidate Act and applicable authority.
Step 5 — Hold the Outbound Operation Non-Effective
The requested external dispatch remains withheld until the applicable
finality predicates pass.
Step 6 — Independently Verify Actual Dispatch
The originating Finality Sink reconstructs the actual request,
destination, resource, and parameters.
Step 7 — Commit Outbound Attempt Identity
The system records an authenticated operation and attempt reference.
Step 8 — Dispatch the Authorized Operation
The originating sink permits the specific authorized outbound effect.
Step 9 — Obtain Remote Correlation Evidence
Where supported, the remote service identifies the corresponding
remote operation or transaction.
Step 10 — Obtain Qualified Witness Evidence
The Witness Evidence Collection Component obtains authenticated
observations.
Step 11 — Verify Witness Capability
Das Expires 29 April 2027 [Page 74]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The verifier determines what the witness is technically capable of
establishing.
Step 12 — Verify Operation Binding
The system verifies the association between originating operation,
remote effect identity, and observation evidence.
Step 13 — Evaluate Actual Remote Outcome
The CDCV determines whether the required RCP is satisfied.
Step 14 — Classify the Evidence-Qualified Outcome
5.2.3.26. Original Source — Global Page 517
The system records verified completion, partial effect, mismatch,
insufficient evidence, or another supported outcome.
Step 15 — Commit Protected Remote Outcome
The appropriate PROC or unresolved-effect state is committed.
Step 16 — Evaluate Dependent Continuation
Where required, an IEV or other protected continuation validator
examines the remote outcome.
Step 17 — Permit, Withhold, or Recover
The system permits only properly authorized successor operations,
maintains unresolved fences, or initiates separately governed
recovery procedures.
4.15 — REFERENCE PSEUDOCODE: REMOTE CONSEQUENCE INTENT
FUNCTION CONSTRUCT_REMOTE_EFFECT_INTENT( candidate_act,
remote_destination, required_consequence, protected_policy ):
REQUIRE PED.VERIFY_CANDIDATE_ACT( candidate_act )
REQUIRE PED.VERIFY_REMOTE_DESTINATION( remote_destination )
predicate = CANONICALIZE_REMOTE_PREDICATE( required_consequence )
IF predicate IS NOT MACHINE_VERIFIABLE: RETURN REQUIRE_REFINEMENT
Das Expires 29 April 2027 [Page 75]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
witness_requirements = RESOLVE_REQUIRED_WITNESS_ASSURANCE( predicate,
protected_policy )
cdeid = { candidate_act_digest: HASH(candidate_act),
remote_destination:
5.2.3.27. Original Source — Global Page 518
remote_destination.identifier,
required_effect: predicate,
required_assurance: witness_requirements,
remote_operation_nonce: PED.NEW_NONCE(),
authority_epoch: PED.CURRENT_AUTHORITY_EPOCH() }
committed = PED.COMMIT_REMOTE_INTENT( cdeid )
IF committed != SUCCESS: RETURN DENY
RETURN committed The procedure establishes the intended remote
consequence.
It does not establish that the consequence occurred.
4.16 — REFERENCE PSEUDOCODE: OUTBOUND OPERATION BINDING
FUNCTION AUTHORIZE_AND_DISPATCH_REMOTE_ACT( candidate_act,
remote_intent, originating_sink ):
actual_operation = originating_sink.RECONSTRUCT_PENDING_OPERATION()
IF actual_operation IS NULL: RETURN DENY
REQUIRE originating_sink.VERIFY_SCOPED_AUTHORITY( candidate_act,
actual_operation )
REQUIRE VERIFY_REMOTE_INTENT_CORRESPONDENCE( remote_intent,
actual_operation )
5.2.3.28. Original Source — Global Page 519
attempt_id = PED.ALLOCATE_PROTECTED_ATTEMPT_ID()
Das Expires 29 April 2027 [Page 76]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
dispatch_record = PED.ATOMIC_PREPARE_DISPATCH({ candidate_digest:
HASH(candidate_act),
remote_intent_digest: HASH(remote_intent),
actual_operation_digest: HASH(actual_operation),
attempt_identifier: attempt_id,
destination: actual_operation.destination })
IF dispatch_record != COMMITTED: RETURN DENY
attempt = originating_sink.DISPATCH( actual_operation,
dispatch_record )
PED.RECORD_DISPATCH_ATTEMPT( attempt_id, attempt )
RETURN { attempt_id, dispatch_state: CLASSIFY_LOCAL_DISPATCH(attempt)
} The procedure distinguishes local dispatch from remote effect
completion.
4.17 — REFERENCE PSEUDOCODE: WITNESS QUALIFICATION
FUNCTION QUALIFY_REMOTE_WITNESS( witness_record,
required_remote_predicate ):
witness_profile = WITNESS_REGISTRY.LOOKUP( witness_record.witness_id
)
5.2.3.29. Original Source — Global Page 520
IF witness_profile IS NULL: RETURN UNQUALIFIED
IF NOT VERIFY_WITNESS_AUTHENTICATION( witness_record, witness_profile
): RETURN UNQUALIFIED
IF NOT VERIFY_WITNESS_CURRENT_STATUS( witness_profile ): RETURN
UNQUALIFIED
IF NOT OBSERVATION_CAPABILITY_SUPPORTS( witness_profile,
required_remote_predicate ): RETURN INSUFFICIENT_OBSERVATION
IF NOT VERIFY_OBSERVATION_FRESHNESS( witness_record,
required_remote_predicate ): RETURN STALE_EVIDENCE
Das Expires 29 April 2027 [Page 77]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
RETURN { qualified: TRUE, supported_claims:
witness_profile.supported_claims, independence_profile:
witness_profile.independence, assurance: witness_profile.assurance }
A successful witness-qualification result does not independently
establish that the witness's particular observation is correct.
The observation must still be appraised.
4.18 — REFERENCE PSEUDOCODE: REMOTE OUTCOME VERIFICATION
FUNCTION VERIFY_ACTUAL_REMOTE_CONSEQUENCE( remote_intent,
originating_dispatch_record, witness_records[] ):
REQUIRE VERIFY_PROTECTED_REMOTE_INTENT( remote_intent )
5.2.3.30. Original Source — Global Page 521
REQUIRE VERIFY_DISPATCH_BINDING( originating_dispatch_record,
remote_intent )
accepted_evidence = []
FOR record IN witness_records:
qualification = QUALIFY_REMOTE_WITNESS( record,
remote_intent.required_effect )
IF qualification.qualified != TRUE: CONTINUE
IF NOT VERIFY_REMOTE_OPERATION_CORRELATION( record,
originating_dispatch_record ): CONTINUE
accepted_evidence.APPEND({ observation: record, qualification:
qualification })
IF accepted_evidence IS EMPTY: RETURN OUTCOME_UNKNOWN
assessed = EVALUATE_REMOTE_PREDICATE( remote_intent.required_effect,
accepted_evidence )
IF assessed.evidence_conflict == TRUE: RETURN REQUIRE_RECONCILIATION
IF assessed.supports_required_outcome != TRUE: RETURN
CLASSIFY_LIMITED_OUTCOME( assessed )
committed = PED.COMMIT_VERIFIED_REMOTE_OUTCOME({
remote_intent_digest: HASH(remote_intent),
Das Expires 29 April 2027 [Page 78]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
dispatch_digest: HASH(originating_dispatch_record),
5.2.3.31. Original Source — Global Page 522
witness_evidence_commitment: HASH_CANONICAL(accepted_evidence),
verified_predicate: remote_intent.required_effect,
verified_outcome: assessed.outcome,
assurance_class: assessed.assurance_class,
protected_sequence: PED.NEXT_MONOTONIC_SEQUENCE() })
IF committed != SUCCESS: RETURN OUTCOME_COMMIT_FAILURE
RETURN committed This procedure illustrates evidence-qualified
consequence verification.
It does not automatically assume that a remote signature, server
acknowledgement, or log inclusion establishes the required outcome.
4.19 — REFERENCE PSEUDOCODE: CAUSAL STATE-DELTA VERIFICATION
FUNCTION VERIFY_CAUSAL_STATE_DELTA( remote_operation_reference,
before_state_record, after_state_record, protected_transaction_record
):
REQUIRE VERIFY_REMOTE_CONTROLLER_IDENTITY(
protected_transaction_record )
REQUIRE VERIFY_TRANSACTION_RECORD_AUTHENTICITY(
protected_transaction_record )
REQUIRE MATCHES_OPERATION_REFERENCE( protected_transaction_record,
remote_operation_reference )
REQUIRE VERIFY_BEFORE_STATE_BINDING( before_state_record,
protected_transaction_record )
5.2.3.32. Original Source — Global Page 523
REQUIRE VERIFY_AFTER_STATE_BINDING( after_state_record,
protected_transaction_record )
REQUIRE VERIFY_COMMIT_SEQUENCE( protected_transaction_record )
Das Expires 29 April 2027 [Page 79]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
IF NOT CONTROLLER_PROVIDES_OPERATION_STATE_LINKAGE: RETURN
STATE_CHANGE_OBSERVED_ONLY
IF NOT TRUST_ASSUMPTIONS_SATISFIED: RETURN
AUTHENTICATED_REMOTE_ASSERTION_ONLY
RETURN { result: OPERATION_BOUND_TRANSITION_VERIFIED,
before_state: before_state_record.commitment,
after_state: after_state_record.commitment,
operation: remote_operation_reference,
transaction: protected_transaction_record.identifier } The procedure
explicitly separates evidence of state difference from evidence of an
operation-specific state transition.
4.20 — REFERENCE PSEUDOCODE: OUTCOME-DEPENDENT CONTINUATION
FUNCTION AUTHORIZE_AFTER_REMOTE_OUTCOME( remote_outcome_commitment,
proposed_successor_act, successor_sink ):
REQUIRE PED.VERIFY_REMOTE_OUTCOME_COMMITMENT(
remote_outcome_commitment )
required_predicate = RESOLVE_SUCCESSOR_DEPENDENCY(
proposed_successor_act )
5.2.3.33. Original Source — Global Page 524
IF NOT REMOTE_OUTCOME_SUPPORTS( remote_outcome_commitment,
required_predicate ): RETURN WITHHOLD_SUCCESSOR
iev_result = IEV.VALIDATE_CONTINUATION({ predecessor_effect:
remote_outcome_commitment,
successor_candidate: proposed_successor_act,
current_protected_state: PED.LOAD_CURRENT_STATE() })
IF iev_result != PASS: RETURN WITHHOLD_SUCCESSOR
successor_authority = PED.PREPARE_SCOPED_CONTINUATION(
proposed_successor_act, remote_outcome_commitment, iev_result )
IF successor_authority IS INVALID: RETURN WITHHOLD_SUCCESSOR
Das Expires 29 April 2027 [Page 80]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
actual_successor = successor_sink.RECONSTRUCT_PENDING_OPERATION()
REQUIRE successor_sink.VERIFY_SCOPED_AUTHORITY( successor_authority,
actual_successor )
REQUIRE successor_sink.VERIFY_REMOTE_OUTCOME_BINDING(
remote_outcome_commitment, successor_authority )
REQUIRE successor_sink.VERIFY_CURRENT_STATE()
consumption = successor_sink.ATOMIC_CONSUME( successor_authority,
actual_successor )
5.2.3.34. Original Source — Global Page 525
IF consumption != SUCCESS: RETURN DENY
RETURN successor_sink.EFFECTUATE( actual_successor, consumption ) The
IEV is optional unless the particular successor operation requires
independent inter-phase validation.
Another protected continuation mechanism may implement the same
required technical predicates under an appropriate trust model.
4.21 — BASIC UNDERSTANDABLE EXAMPLE: SENDING A DOCUMENT TO A REMOTE
SERVICE
4.21.1 — Original User Task
A user instructs an AI assistant:
"Upload my expense report to the company portal and, after it has
been saved successfully, send the confirmation message to my
manager."
The task includes two separate consequences.
The first consequence is storage of the report in the remote company
portal.
The second consequence is transmission of a confirmation message.
The second consequence depends upon the first.
4.21.2 — Initial Candidate Act
The assistant constructs Candidate Act CA-401.
Das Expires 29 April 2027 [Page 81]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The act requests upload of a selected report to the designated remote
portal.
The originating PED validates the applicable user authorization.
The originating Finality Sink verifies the actual selected report and
destination.
4.21.3 — Local Dispatch
The originating sink permits the authorized upload.
A protected record identifies the actual transmitted object,
destination, and operation attempt.
The local dispatch event does not by itself establish that the portal
saved the report.
4.21.4 — Remote Acceptance
The portal responds:
5.2.3.35. Original Source — Global Page 526
"Upload received."
This establishes, at most, a remote acceptance claim according to the
trustworthiness of the response source.
It does not necessarily establish durable storage of the report.
4.21.5 — Protected Remote Storage Observation
In a cooperating implementation, a remote protected storage
controller commits the report object under Object ID O-401.
The controller records the committed version, report content
commitment, and transaction reference.
A qualified witness obtains authenticated evidence of the committed
object.
4.21.6 — Cross-Domain Correspondence
The verifier checks that:
1. The original authorized report matches the protected outbound
object commitment;
Das Expires 29 April 2027 [Page 82]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
2. The remote object corresponds to the same authorized report under
the permitted transformation rules;
3. The remote destination matches the authorized portal;
4. The remote storage evidence refers to the correct operation;
5. The required storage-commit predicate is satisfied.
4.21.7 — Verified Remote Outcome
The CDCV commits a PROC representing the verified remote storage
result.
The result identifies the supported assurance level.
If only remote acceptance is established, the system does not falsely
mark durable storage as verified.
4.21.8 — Confirmation Message Continuation
The assistant proposes Candidate Act CA-402 to send the confirmation
message.
The optional IEV verifies the protected remote storage outcome.
If the required result is confirmed, a new scoped authority may be
generated for CA-402.
The message Finality Sink verifies the actual message and destination
before transmission.
4.21.9 — Failure Scenario
Suppose the portal responds "Upload received" but subsequently
rejects the file during processing.
5.2.3.36. Original Source — Global Page 527
The witness evidence does not establish the required stored-object
predicate.
The confirmation message remains withheld.
The agent may instead notify the user of the failed or unresolved
upload under a separately permitted notification operation.
4.21.10 — Technical Effect
Das Expires 29 April 2027 [Page 83]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
This example demonstrates how a system can prevent an autonomous
agent from sending a false completion message merely because the
remote service acknowledged receipt of the upload request.
The mechanism depends upon evidence of the defined remote storage
consequence rather than the agent's prediction or ordinary response
text.
4.22 — WORKED EXAMPLE B: FINANCIAL TRANSACTION AND ACCOUNTING UPDATE
4.22.1 — Scenario
An autonomous financial agent submits an authorized payment
instruction through a remote payment system.
A subsequent accounting entry requires confirmation of the relevant
payment state.
4.22.2 — Protected Payment Authorization
The originating Candidate Act identifies:
• Permitted payment amount;
• Currency;
• Source account;
• Recipient;
• Payment instruction reference;
• Designated remote service.
The originating Finality Sink verifies the actual outbound
instruction.
4.22.3 — Remote Acceptance
The remote payment system accepts the instruction.
The acceptance event may establish only that the instruction entered
processing.
4.22.4 — Required Consequence Predicate
The accounting continuation may require a specified authoritative
settlement state.
Das Expires 29 April 2027 [Page 84]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.2.3.37. Original Source — Global Page 528
The RCP identifies that state.
The system does not substitute a weaker "request accepted" predicate.
4.22.5 — Qualified Observation
Where the payment infrastructure supports an authenticated
transaction-status interface, a witness obtains evidence concerning
the authoritative payment state.
The witness qualification rules determine whether that evidence can
establish the required settlement condition.
4.22.6 — Unknown Outcome
If the transaction result remains uncertain, the system preserves an
unresolved state.
The agent does not automatically repeat the payment instruction.
4.22.7 — Continuation
After the required remote state is verified, the accounting update
may receive separately scoped authorization.
The accounting Finality Sink verifies the actual pending update.
4.22.8 — Technical Effect
The system distinguishes payment submission, remote acceptance, and
the specific downstream payment state required for accounting
continuation.
The architecture does not assume that financial settlement is always
instantaneous, irreversible, or externally observable.
4.23 — WORKED EXAMPLE C: REMOTE DATABASE MODIFICATION
4.23.1 — Scenario
An agent requests a change to a record in a remote database.
The operation changes a resource from Version 21 to Version 22.
4.23.2 — Originating Authorization
Das Expires 29 April 2027 [Page 85]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The originating Candidate Act identifies the record, permitted
modification, expected current version, and remote service.
The originating Finality Sink verifies the actual request.
4.23.3 — Remote Transactional Controller
A cooperating remote controller applies the modification through a
transactional interface.
5.2.3.38. Original Source — Global Page 529
Within the transaction, it records:
• Operation identifier;
• Previous record version;
• Applied mutation;
• New record version;
• Commit sequence.
The operation-to-commit evidence is committed according to the remote
system's transactional semantics.
4.23.4 — Witness Observation
A qualified observer obtains the authenticated transaction record.
Where required, a separate read confirms that the resource currently
presents Version 22.
4.23.5 — Causal Correspondence
The CDCV determines whether the transaction record establishes that
the authorized operation was the operation applied to the resource.
A mere observation that Version 22 exists is insufficient if another
concurrent operation could have produced that version and the
required causal linkage is absent.
4.23.6 — Result
The system commits an appropriately qualified remote-outcome record.
Das Expires 29 April 2027 [Page 86]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A dependent operation may proceed only if the required state and
authority remain valid.
4.23.7 — Technical Effect
The example illustrates stronger verification through operation-bound
transactional evidence rather than arbitrary before-and-after
observations.
4.24 — WORKED EXAMPLE D: REMOTE MESSAGE DELIVERY
4.24.1 — Scenario
An AI assistant is instructed to send a message to a designated
recipient and perform another action after the message reaches the
recipient's mailbox.
4.24.2 — Local Dispatch
The originating message gateway verifies the authorized recipient and
content.
It dispatches the message.
5.2.3.39. Original Source — Global Page 530
A local dispatch receipt is generated.
4.24.3 — Remote Message Acceptance
The remote messaging service acknowledges receipt.
This may establish that the service accepted the message for
processing.
It does not necessarily establish placement in the recipient's
mailbox.
4.24.4 — Recipient Mailbox Observation
Where the destination service supports it, an authenticated mailbox-
delivery record identifies the message and recipient mailbox.
The witness verifies the corresponding mailbox state.
4.24.5 — Continuation Predicate
Das Expires 29 April 2027 [Page 87]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
If the successor operation requires mailbox delivery, the verified
mailbox evidence may satisfy the predicate.
If the successor requires proof that the human recipient read and
understood the message, mailbox delivery is insufficient.
4.24.6 — Technical Effect
The architecture preserves distinctions among message dispatch,
service acceptance, mailbox delivery, and human comprehension.
It does not claim that a delivery receipt establishes subjective
human awareness.
4.25 — WORKED EXAMPLE E: REMOTE PHYSICAL ACTUATION
4.25.1 — Scenario
An autonomous controller sends a command to a remote industrial
device.
The intended consequence is movement of an actuator to a defined
position within an allowed tolerance.
4.25.2 — Originating Authorization
The originating PED validates the command.
The originating sink verifies the actual device, target position, and
permitted operating parameters.
4.25.3 — Remote Controller Acknowledgement
The remote controller acknowledges command receipt.
This does not necessarily establish that the actuator physically
moved.
5.2.3.40. Original Source — Global Page 531
4.25.4 — Physical-State Witness
A protected or appropriately trusted sensor measures the resulting
actuator position.
The witness produces an authenticated observation record.
Das Expires 29 April 2027 [Page 88]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The record includes the relevant measurement, time or sequence,
sensor identity, and observation assurance.
4.25.5 — Independent Validation
The CDCV determines whether the observed physical position satisfies
the required predicate.
Where the sensor cannot establish that the specific command caused
the movement, the system records only the supported physical-state
conclusion.
4.25.6 — Successor Operation
A subsequent actuator command may depend upon the measured position.
Where required, CW-2 provides independent continuation validation.
4.25.7 — Technical Effect
The example distinguishes remotely acknowledged command acceptance
from independently observed physical-state achievement.
The accuracy and assurance of the conclusion depend upon the sensor
and its actual measurement capabilities.
4.26 — WORKED EXAMPLE F: NONPARTICIPATING REMOTE SERVICE
4.26.1 — Scenario
An autonomous agent submits a permitted operation to an external
service that does not provide protected effect receipts or verifiable
state-transition evidence.
4.26.2 — Available Evidence
The originating system may observe successful local dispatch and an
ordinary remote success response.
The external service may not expose a trustworthy state query or
independent observation interface.
4.26.3 — Evidence Classification
The CDCV records the available facts according to their supported
assurance.
Das Expires 29 April 2027 [Page 89]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
It does not classify the intended external effect as independently
verified merely because the service returned success.
4.26.4 — Continuation Policy
5.2.3.41. Original Source — Global Page 532
If a successor operation requires independently verified remote
completion, that operation remains withheld.
If the user authorized a different continuation rule that
legitimately depends only upon dispatch or remote acceptance, the
system may apply that narrower rule.
4.26.5 — Technical Effect
The embodiment permits graceful degradation of evidence assurance
without making false claims of independent verification.
It does not assume remote service cooperation where none exists.
4.27 — MULTI-WITNESS CORROBORATION
4.27.1 — Purpose
Some remote consequences may require evidence from multiple
observers.
For example, a remote transactional controller may provide an
authenticated commit record while another observer verifies the
resulting resource state.
4.27.2 — Witness Selection
The system selects witnesses according to the required outcome
predicate and available observation capabilities.
A witness is not chosen solely because it can produce a digital
signature.
4.27.3 — Independence Analysis
The WIP may identify:
• Administrative owner;
• Execution environment;
Das Expires 29 April 2027 [Page 90]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
• Measurement interface;
• Data source;
• Authentication root;
• Shared failure modes;
• Possible common control of witnesses.
4.27.4 — Correlated Witnesses
Several observers relying on the same unverified report may provide
redundant signatures without independent outcome evidence.
The system does not treat the number of signatures as a substitute
for evidence independence.
5.2.3.42. Original Source — Global Page 533
4.27.5 — Threshold Evidence
In one implementation, a protected policy requires a threshold of
witnesses satisfying specified independence and observation criteria.
The threshold may be expressed over distinct administrative or
technical failure domains.
The policy must define its adversary assumptions.
4.27.6 — Conflicting Evidence
Where qualified witnesses report incompatible outcomes, the CDCV may
withhold the required verified-completion decision and initiate
reconciliation.
4.27.7 — No Universal Quorum Guarantee
A witness quorum cannot establish truth if all participating
witnesses share a common compromised data source or lack the ability
to observe the required consequence.
The strength of the quorum depends upon the actual witness
construction and failure model.
4.28 — REMOTE STATE CONSISTENCY AND TEMPORAL VALIDITY
4.28.1 — Consistency Model
Das Expires 29 April 2027 [Page 91]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A remote service may use strong consistency, eventual consistency,
asynchronous replication, transactional snapshots, or another state
model.
The verifier identifies the relevant model when it affects the
required outcome predicate.
4.28.2 — Stale Replica Observation
A witness may query a stale replica.
The resulting record may not reflect the most recent committed state.
Where necessary, the verifier requires an authoritative version,
quorum read, protected transaction index, or other suitable freshness
condition.
4.28.3 — Concurrent Mutations
Two remote operations may modify the same resource.
The verifier distinguishes:
• State created by the originating operation;
• State created by another operation;
• State subsequently overwritten;
• State that remains valid only at a historical version.
5.2.3.43. Original Source — Global Page 534
4.28.4 — Historical Versus Current Outcome
A witness may prove that a state existed at an earlier time.
That proof does not necessarily establish that the state still
exists.
The required consequence predicate specifies whether historical
occurrence or current state is necessary.
4.28.5 — Remote Finality Conditions
A remote service may support a stable commit point.
Another service may permit later reversal or reorganization.
Das Expires 29 April 2027 [Page 92]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The CDCV records the supported finality condition rather than
assuming universal irreversibility.
4.28.6 — Time-of-Verification to Time-of-Continuation
A remote state may change after verification but before a successor
effect.
Where the successor requires the state to remain current, the IEV or
successor Finality Sink revalidates the corresponding predicate at
the applicable boundary.
4.29 — PRIVACY-PRESERVING WITNESSING
4.29.1 — Minimal Evidence Disclosure
The witness need not reveal complete private resource contents if the
required consequence can be verified using a narrower authenticated
representation.
For example, a storage witness may provide a content commitment,
object identity, and version rather than the complete stored
document.
4.29.2 — Commitment Equality
Where two protected domains compare commitments, they use a
compatible canonicalization and commitment construction.
Different random salts or encoding rules cannot automatically be
compared for equality.
4.29.3 — Selective Outcome Evidence
A witness may release only the fields necessary to establish the
relevant RCP.
For example, an external verifier may need to know that a transaction
reached a particular state without receiving unrelated financial
details.
4.29.4 — Privacy-Preserving Proof Systems
An implementation may employ suitable cryptographic proofs to
establish a defined predicate over committed remote data.
Das Expires 29 April 2027 [Page 93]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.2.3.44. Original Source — Global Page 535
However, a cryptographic proof of a predicate over supplied data does
not establish that the supplied data accurately represents the
external world unless that relationship is independently trustworthy.
4.29.5 — Evidence Retention
Sensitive witness evidence may be retained within protected storage.
The system may preserve commitments and minimal metadata while
restricting access to complete observations.
4.29.6 — Cross-Domain Policy
The witness protocol may honor applicable data-minimization and
authority constraints.
Remote verification does not automatically authorize unrestricted
export of the remote service's private data.
4.30 — FAILURE AND RECOVERY BEHAVIOR
4.30.1 — Failure Before Outbound Dispatch
The Candidate Act remains non-effective if required originating
authorization fails.
No remote consequence is presumed.
4.30.2 — Failure After Outbound Dispatch
The system preserves the authenticated attempt reference.
A missing acknowledgement does not establish absence of effect.
4.30.3 — Failure During Remote Processing
The remote service may have applied part or all of the requested
operation.
The system obtains suitable outcome evidence where available.
4.30.4 — Missing Witness Response
Where a required witness is unavailable, the required remote outcome
remains unverified.
Das Expires 29 April 2027 [Page 94]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The system may defer outcome-dependent continuation.
4.30.5 — Witness Authentication Failure
Evidence from an unauthenticated or revoked witness is not accepted
for a predicate requiring that witness assurance.
4.30.6 — Incompatible Witness Reports
The system preserves uncertainty and invokes a protected
reconciliation procedure.
5.2.3.45. Original Source — Global Page 536
4.30.7 — Partial Remote Effect
The verifier records the supported partial outcome.
It does not treat partial completion as full completion unless
expressly permitted by the original consequence predicate.
4.30.8 — Verified Wrong Effect
Where the actual remote effect differs materially from the authorized
operation, the system may activate CW-3 scope-deviation handling and
preserve the mismatch evidence.
Further effects are separately governed.
4.30.9 — Remote State Rollback
An earlier verified state may be reverted.
Where the continuation predicate requires continuing validity, the
system reevaluates the required remote state.
4.30.10 — Remote Log Equivocation
A remote service or witness may provide incompatible authenticated
views of operation history.
The system may compare authenticated state roots, witness records, or
transparency evidence.
Detected equivocation results in protected uncertainty, rejection, or
another defined response.
4.30.11 — Duplicate Request Attempt
Das Expires 29 April 2027 [Page 95]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A retry is bound to the applicable idempotency, protected attempt,
and authorization rules.
The original operation's authority is not automatically restored.
4.30.12 — Recovery Operation
A corrective external operation is represented as a separate
Candidate Act where it produces a new consequential effect.
Its effectuation remains subject to applicable finality authorization
and verification.
4.31 — ADVERSARIAL THREAT MODEL
4.31.1 — Forged Remote Success Response
An attacker fabricates a success response.
The verifier checks authentication and required effect evidence
rather than accepting unverified response text.
4.31.2 — Authenticated False Remote Assertion
5.2.3.46. Original Source — Global Page 537
A compromised remote service signs an incorrect statement.
The system does not equate signature validity with independent truth.
4.31.3 — Wrong-Operation Receipt Substitution
An attacker presents a genuine receipt for a different operation.
Operation-identity binding prevents unauthorized substitution.
4.31.4 — Replay of Old Effect Evidence
An old remote receipt is replayed for a new Candidate Act.
The verifier checks freshness, operation identity, protected
sequence, and required state.
4.31.5 — Remote Resource Substitution
The remote service acts upon a resource different from the authorized
target.
Das Expires 29 April 2027 [Page 96]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Where observation coverage exists, the verifier detects mismatch
between expected and actual effect identity.
4.31.6 — Causality Spoofing
An attacker presents an observed state change caused by another
operation as evidence that the authorized operation succeeded.
The verifier requires the specified causal linkage where causality is
essential.
4.31.7 — Concurrent Remote Mutation
Another actor changes the resource while the authorized operation is
pending.
The verifier uses authenticated transaction or version evidence to
distinguish the relevant state transitions.
4.31.8 — Stale Replica Attack
A witness returns outdated but authentic state.
The verifier checks applicable freshness and consistency properties.
4.31.9 — Witness Collusion
Several witnesses coordinate false reports.
The assurance depends upon the actual threshold, independence, and
trust model.
A numerical quorum alone does not eliminate collusion risk.
4.31.10 — Witness Evidence Laundering
5.2.3.47. Original Source — Global Page 538
Several observers repeat one unverified remote statement.
The system does not treat copied assertions as independent
measurements.
4.31.11 — Compromised Witness Key
An attacker obtains an observation-signing key.
Das Expires 29 April 2027 [Page 97]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Applicable witness revocation and authentication-state checks are
used.
4.31.12 — Remote Log Rollback
A remote system presents an earlier log state as current.
Protected version, sequence, or independently anchored state evidence
may detect rollback where implemented.
4.31.13 — Equivocating Remote History
The remote service presents different authenticated histories to
different observers.
Independent consistency checks or appropriately configured
transparency mechanisms may detect incompatible histories where
supporting evidence is available.
4.31.14 — False Transparency-Based Assurance
An attacker records a false success statement in an append-only log.
The log may prove inclusion of the statement but not truth of the
reported external effect.
The CDCV retains the required outcome-evidence distinction.
4.31.15 — Remote Attestation Misuse
A valid code-measurement attestation is presented as proof of a
particular external transaction.
The verifier requires effect-specific evidence rather than accepting
platform-state attestation alone.
4.31.16 — Receipt Downgrade
A remote acceptance receipt is treated as a final outcome receipt.
The required ROAC prevents unauthorized elevation of assurance.
4.31.17 — Observation Timing Manipulation
A remote actor provides an observation from a time when the resource
temporarily satisfied the required condition.
The verifier evaluates the temporal and finality predicates.
Das Expires 29 April 2027 [Page 98]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
4.31.18 — Idempotency-Key Reuse
5.2.3.48. Original Source — Global Page 539
An attacker uses a valid idempotency reference for a different
operation.
The system verifies its binding to the original operation and
applicable resource scope.
4.31.19 — Outcome-Based Authority Escalation
An agent attempts to use a valid remote receipt to authorize an
unrelated successor operation.
The protected continuation mechanism checks the actual successor
scope.
4.31.20 — Remote Service Nonparticipation
The remote service supplies no independently useful evidence.
The system records the supported limited assurance rather than
inventing remote completion.
4.31.21 — Physical Sensor Spoofing
An attacker manipulates a physical sensor used as a witness.
The system's assurance depends upon the implemented sensor
authentication, calibration, measurement integrity, and relevant
redundancy.
4.31.22 — Incorrect Object Alias
The remote effect is reported under an identifier that does not
correspond to the authorized resource.
Authenticated entity mapping is required where applicable.
4.31.23 — Network Partition
The originating and remote domains become disconnected.
The system preserves the relevant attempt and uncertainty state
without assuming that the remote effect failed.
4.31.24 — Outcome Witness Denial-of-Service
Das Expires 29 April 2027 [Page 99]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An attacker prevents timely witness responses.
Where verified completion is mandatory for continuation, the affected
successor operation remains withheld.
4.31.25 — Malicious Recovery Attempt
An agent proposes a broad compensating action after an uncertain
remote outcome.
The proposed recovery requires separate authorization and Finality
Sink verification.
4.32 — EXPERIMENTAL REFERENCE IMPLEMENTATION
4.32.1 — Prototype Objective
5.2.3.49. Original Source — Global Page 540
A representative reference prototype may demonstrate that a protected
originating operation can be bound to independently qualified remote
state evidence and that a dependent successor operation remains
withheld until the required remote predicate is verified.
4.32.2 — Prototype Components
The prototype may comprise:
1. A simulated autonomous agent;
2. An originating Candidate Act constructor;
3. A protected or experimentally simulated PED;
4. An originating Finality Sink;
5. A remote transactional service;
6. A remote resource database;
7. A remote operation-correlation interface;
8. A transactional operation-effect record;
9. An independently controlled observation service;
10. A witness qualification registry;
Das Expires 29 April 2027 [Page 100]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
11. A CDCV;
12. A protected remote-outcome store;
13. An optional IEV;
14. A successor-operation gateway;
15. A fault-injection harness.
4.32.3 — Remote Transactional State
The remote service may maintain a resource record containing:
• Resource identifier;
• Resource version;
• Resource value or content commitment;
• Last applied operation identifier;
• Commit sequence;
• Transaction status.
4.32.4 — Transactionally Bound Operation Record
5.2.3.50. Original Source — Global Page 541
A cooperating remote controller may update the resource and insert
the operation-effect record within one database transaction.
The database guarantees of this operation are limited to the tested
transactional domain.
The prototype does not assume atomicity with unrelated external
physical effects.
4.32.5 — Witness Interface
A witness may obtain an authenticated transaction record and
independently query the committed resource state.
The witness signs or otherwise authenticates its observation.
4.32.6 — Protected Outcome Verification
Das Expires 29 April 2027 [Page 101]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The CDCV checks operation identity, required state transition,
freshness, and witness qualification.
A verified outcome is committed to protected state.
4.32.7 — Successor Enforcement
A successor gateway refuses a dependent operation until the
applicable protected remote-outcome predicate is satisfied.
4.32.8 — Prototype Limitations
A software-only prototype can demonstrate the operation-binding,
receipt, witness, and continuation logic under a defined software
trust model.
It cannot establish resistance to a malicious remote database
administrator without additional protected enforcement or
independently trustworthy observation.
4.33 — NON-LIMITING FEASIBILITY EXPERIMENTS
The following experiments are proposed. They are not statements of
experiments already performed.
Experiment 1 — Local Dispatch Without Remote Commit
Authorize and dispatch a remote operation.
Cause the remote service to accept but not commit it.
Verify that the system does not classify the required state change as
completed.
Experiment 2 — Remote Commit with Lost Acknowledgement
Cause the remote service to commit the operation but suppress the
acknowledgement.
Verify that subsequent qualified observation can establish the
outcome without automatically duplicating the original operation.
5.2.3.51. Original Source — Global Page 542
Experiment 3 — Signed False Success Statement
Provide an authenticated remote success report while withholding the
required state change.
Das Expires 29 April 2027 [Page 102]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Verify that the system does not accept the statement as independent
proof when the required witness predicate is not satisfied.
Experiment 4 — Wrong-Operation Receipt
Submit a valid receipt from another transaction.
Verify rejection based upon operation and effect identity.
Experiment 5 — Stale Observation
Provide an authentic old state record.
Verify that the applicable freshness predicate rejects it for a
current-state requirement.
Experiment 6 — Concurrent Remote Modification
Cause an unrelated operation to modify the same resource during the
test.
Verify that the system does not falsely attribute the unrelated state
change to the originating Candidate Act.
Experiment 7 — Transactionally Bound State Delta
Commit an operation identifier, pre-state reference, and resulting
state within one transactional resource system.
Verify that the CDCV can validate the supported operation-to-state
relationship.
Experiment 8 — State Observation Without Causal Evidence
Provide authentic before-and-after state observations without an
operation-specific transaction record.
Verify that the outcome is classified as state observed rather than
proven caused by the originating operation.
Experiment 9 — Remote Receipt Replay
Replay an earlier witness receipt under a new Candidate Act.
Verify that operation and freshness binding prevent unauthorized
acceptance.
Experiment 10 — Multiple Correlated Witnesses
Das Expires 29 April 2027 [Page 103]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Provide several signatures derived from one unverified success
assertion.
Verify that the witness policy does not classify them as independent
confirmation when independence is required.
5.2.3.52. Original Source — Global Page 543
Experiment 11 — Conflicting Witnesses
Provide two authenticated incompatible observations.
Verify that the system enters reconciliation or uncertainty state
rather than arbitrarily selecting success.
Experiment 12 — Nonparticipating Remote Service
Use a remote endpoint that supplies only ordinary acknowledgements.
Verify that the system reports the actual available assurance without
asserting independently verified completion.
Experiment 13 — Partial Remote Effect
Cause the remote operation to modify only part of the intended
resource set.
Verify that the outcome classifier identifies the supported partial
effect.
Experiment 14 — Wrong Remote Resource
Have the remote service commit a different resource from the one
authorized.
Verify mismatch detection where the relevant observation coverage is
implemented.
Experiment 15 — Remote State Rollback
Verify an initial committed state, then revert the remote resource.
Verify that a successor requiring current state does not rely blindly
upon stale historical evidence.
Experiment 16 — Remote Log Equivocation
Present incompatible authenticated transaction histories.
Das Expires 29 April 2027 [Page 104]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Verify that the implemented consistency checks identify the conflict
where the relevant evidence is available.
Experiment 17 — Privacy-Minimized Observation
Verify an operation outcome using commitments and state identifiers
without releasing complete private resource content.
Measure whether the required predicate remains verifiable.
Experiment 18 — Outcome-Dependent Continuation
Attempt to execute a successor Candidate Act before required remote
verification.
Verify that the successor Finality Sink refuses effectuation.
Experiment 19 — Valid Outcome and Continuation
5.2.3.53. Original Source — Global Page 544
Complete the remote operation, produce qualified evidence, and
authorize the specified successor operation.
Verify that the successor remains bounded by its separate finality
authority.
Experiment 20 — Receipt-Based Authority Escalation
Attempt to use a valid remote outcome receipt to authorize an
unrelated operation.
Verify rejection.
Experiment 21 — Network Partition Recovery
Interrupt communication after the remote effect occurs but before the
originating domain receives confirmation.
Verify preservation and reconciliation of protected uncertain-attempt
state.
Experiment 22 — Witness Revocation
Revoke a witness or invalidate its authentication state.
Verify that later evidence from the invalid source does not satisfy a
predicate requiring a valid witness.
Das Expires 29 April 2027 [Page 105]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Experiment 23 — Physical Actuator Outcome
Transmit an authorized actuator command and provide independent
position observations.
Verify distinction between command acknowledgement and measured
physical outcome.
Experiment 24 — Combined CW-1, CW-2, and CW-3
Perform a remote operation using protected originating finality
control.
Verify the remote outcome.
Introduce a changed destination or scope during the successor phase.
Verify that independent outcome validation does not bypass the
required scope-deviation and finality authorization checks.
4.34 — MEASURABLE TECHNICAL PROPERTIES
The embodiment may be evaluated according to:
• False remote-completion acceptance rate;
• Wrong-operation receipt acceptance rate;
• Remote effect-substitution detection rate;
• Outcome-assurance classification accuracy;
5.2.3.54. Original Source — Global Page 545
• Causal attribution accuracy;
• State-version consistency verification;
• Stale evidence acceptance rate;
• Receipt replay acceptance rate;
• Witness authentication failure detection;
• Witness-collusion tolerance under a specified threat model;
• Conflicting-witness detection rate;
Das Expires 29 April 2027 [Page 106]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
• Partial-outcome classification accuracy;
• Unknown-outcome handling correctness;
• Duplicate remote-effect rate;
• Protected continuation correctness;
• Crash recovery consistency;
• Additional remote verification latency;
• Remote witness message overhead;
• Protected evidence storage cost;
• Resource consumption;
• Recovery completion behavior;
• Privacy disclosure associated with witness evidence.
Measurements should distinguish evidence integrity from evidence
truthfulness.
A cryptographically valid record is not necessarily evidence of an
accurately observed external consequence.
4.35 — IMPLEMENTATION VARIANTS
Variant 4.A — Remote Protected Storage Witness
A protected remote storage controller produces authenticated evidence
of a committed resource state.
Variant 4.B — Transactional Operation-State Witness
A remote transactional controller commits operation identity and
state mutation within one durable transaction.
Variant 4.C — Independent Remote State Reader
5.2.3.55. Original Source — Global Page 546
A separately controlled observer verifies a specified remote state
through an authenticated interface.
Variant 4.D — Multi-Witness Corroboration
Das Expires 29 April 2027 [Page 107]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Multiple qualified observers contribute evidence under an expressly
defined independence and fault model.
Variant 4.E — Hardware-Attested Remote Controller
Remote attestation supports appraisal of the remote observation or
enforcement environment.
Effect-specific evidence remains required.
Variant 4.F — Local Dispatch-Only Evidence
The system records only the verified local transmission event where
stronger remote evidence is unavailable.
Variant 4.G — Remote Acceptance-Only Evidence
The system authenticates remote acceptance but does not incorrectly
classify it as completed effectuation.
Variant 4.H — Protected Causal State-Delta Attestation
The system verifies an operation-bound remote state transition.
Variant 4.I — Remote Resource-Version Proof
The system validates a remote resource version against authenticated
state evidence.
Variant 4.J — Remote Transparency Support
An authenticated transparency service supports consistency or
inclusion verification.
Log inclusion is not treated as independent proof that an underlying
real-world statement is true.
Variant 4.K — Privacy-Preserving Outcome Proof
The witness provides minimum necessary evidence concerning a
protected remote predicate.
Variant 4.L — Remote Physical-State Witness
An appropriate sensor or controller measures a specified physical
outcome.
Variant 4.M — Financial Transaction-State Witness
Das Expires 29 April 2027 [Page 108]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An authenticated financial transaction interface provides evidence
concerning a defined payment state.
Variant 4.N — Messaging Delivery Witness
An authenticated destination-side component supports a defined
delivery-state predicate.
5.2.3.56. Original Source — Global Page 547
Variant 4.O — Cloud Resource-State Witness
A protected cloud control-plane or resource controller provides
authenticated evidence of a specified state change.
Variant 4.P — Cross-Device Effect Witness
A second device verifies a consequence performed by the first device
under applicable protected evidence rules.
Variant 4.Q — No Separate IEV
The protected remote-outcome record is used for reporting or another
authorized purpose without phase-continuation validation.
Variant 4.R — IEV-Governed Continuation
A verified remote outcome becomes a mandatory predicate for a
specifically authorized successor operation.
Variant 4.S — Unknown-Outcome Fence
An unresolved remote operation prevents unsafe retries or dependent
effects.
Variant 4.T — Partial-Effect Recovery
A verified incomplete remote operation triggers a separately governed
corrective Candidate Act.
Variant 4.U — Distributed Witness Qualification
Witness capability profiles are authenticated across multiple
domains.
Variant 4.V — Hardware-Protected Evidence Registry
Das Expires 29 April 2027 [Page 109]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Remote evidence commitments are maintained within a protected
processor or secure storage environment.
Variant 4.W — Asynchronous Remote Verification
Remote outcome evidence is obtained after originating dispatch
without blocking unrelated authorized operations.
Variant 4.X — Threshold Remote Evidence
A specified set of qualified observers must satisfy the applicable
outcome predicate.
Variant 4.Y — State-Dependent Revalidation
A historical remote outcome is revalidated where the successor
requires the corresponding state to remain current.
Variant 4.Z — Software Reference Prototype
5.2.3.57. Original Source — Global Page 548
The mechanism is implemented through cooperating software services
and controlled effectuation gateways under a defined trust model.
The variants are non-limiting and may be combined where technically
appropriate.
4.36 — DISTINCTION FROM CONVENTIONAL SYSTEMS
4.36.1 — Conventional API Acknowledgements
A conventional remote API may return an acknowledgement indicating
that a request was received or accepted.
The present embodiment distinguishes acknowledgement from verified
occurrence of a specified consequential state change.
The additional enforcement may depend upon the exact remote outcome
predicate rather than a generic success flag.
4.36.2 — Conventional Digital Signatures
A digital signature may authenticate the source and integrity of a
statement.
The present embodiment does not claim signatures themselves as
inventive.
Das Expires 29 April 2027 [Page 110]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
It further evaluates whether the authenticated statement is supported
by the source's actual observation capability and operation-specific
evidence.
4.36.3 — Conventional Remote Attestation
Remote attestation may establish evidence concerning remote component
state or configuration.
The embodiment does not presume that an attested execution
environment proves completion of every operation performed by that
environment.
It requires the appropriate effect-specific state or event evidence.
4.36.4 — Conventional Audit Receipts
An audit receipt may prove that an event record was generated,
stored, or authenticated.
The present embodiment distinguishes such proof from independent
verification of the external consequence represented by the record.
4.36.5 — Conventional Transparency Logs
An append-only transparency system may provide evidence that a signed
statement was registered and that a history is consistent.
The system does not thereby establish the truth of the underlying
signed statement.
CDACW may use transparency as a supporting consistency mechanism
while separately evaluating effect truth and witness capability.
5.2.3.58. Original Source — Global Page 549
4.36.6 — Conventional Database Transactions
A database transaction may provide atomicity and consistency within
its controlled transactional domain.
The present embodiment may use such transactions to establish
operation-to-state linkage.
The potential additional contribution concerns binding that evidence
to an originating autonomous-agent authorization and enforcing
outcome-dependent authority across trust boundaries.
Das Expires 29 April 2027 [Page 111]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
4.36.7 — Conventional Two-Phase Commit
Two-phase commit may coordinate transactional participants.
The present embodiment does not presume all external services or
real-world effects can participate in an atomic distributed
transaction.
It supports independently observed effects, uncertain outcomes, and
separately authorized continuation.
4.36.8 — Conventional Distributed Sagas
A distributed saga may coordinate multi-step operations and
compensating actions.
The present embodiment adds specifically protected outcome-assurance
predicates and effectuation-boundary enforcement where the claimed
implementation requires them.
The mere use of a saga or compensation step is not characterized as
new.
4.36.9 — Conventional Monitoring Dashboards
A monitoring service may display remote success indicators.
Such indicators may be useful but do not necessarily control whether
a successor consequential operation is permitted.
The present embodiment may make the qualified outcome commitment a
mandatory input to scoped successor finality authority.
4.36.10 — Conventional Agent Self-Reflection
An AI agent may conclude from a tool response that the remote task
succeeded.
The present embodiment separates agent reasoning from the required
protected evidence of actual remote consequences.
4.37 — PROPOSED INVENTIVE-STEP FOCUS
The present embodiment should not rely upon the broad proposition
that remote systems may provide signed receipts or that an
application should verify a remote operation before continuing.
Das Expires 29 April 2027 [Page 112]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Such principles are established in distributed computing and
security.
5.2.3.59. Original Source — Global Page 550
The potentially more specific inventive concept lies in a protected
arrangement comprising:
First, an originating Candidate Act whose requested remote
consequence is represented through a machine-verifiable effect
predicate.
Second, an independently verified outbound operation bound to
protected finality authority.
Third, a remote operation identity or correlation mechanism bound to
the actual outbound act.
Fourth, evidence from a qualified source capable of establishing the
required remote outcome.
Fifth, a protected verification procedure that distinguishes
observation of state from operation-specific causation and from
stronger finality assertions.
Sixth, a protected remote-outcome commitment binding the original
act, remote evidence, and verified consequence predicate.
Seventh, enforcement of that protected outcome commitment as an
applicable condition for a separately authorized successor operation.
Eighth, preservation of uncertain-effect state where the required
remote consequence cannot be established.
A narrower claim may specifically require the CSDA procedure,
authenticated operation-to-state linkage, and Finality Sink
enforcement of a successor authority bound to the verified remote
transition.
Another implementation may focus upon multi-witness qualification
where the witness capability and independence constraints materially
affect the permitted finality decision.
However, the mere addition of multiple signatures, witnesses, hashes,
or protected records does not automatically establish inventive step.
4.37.1 — Candidate Objective Technical Problem
Das Expires 29 April 2027 [Page 113]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An illustrative objective technical problem is:
How to prevent an autonomous computing system from authorizing a
dependent consequential operation on the basis of an unverified or
incorrectly correlated remote success indication, where the actual
remote effect occurs outside the originating enforcement domain and
may be delayed, partial, concurrent, reversible, or uncertain.
4.37.2 — Candidate Technical Solution
A potential technical solution is a protected cross-domain effect-
evidence protocol that binds the originating operation to a defined
remote consequence predicate, obtains appropriately qualified
operation-specific outcome evidence, commits the supported result to
protected state, and makes successful verification of that result an
enforceable prerequisite for the particular dependent operation.
4.37.3 — Technical Effect
5.2.3.60. Original Source — Global Page 551
Where correctly implemented, the arrangement may prevent a successor
Finality Sink from releasing an operation merely because the
originating agent received an ordinary success response or an
authenticated but insufficient remote receipt.
4.37.4 — Inventive-Step Qualification
Novelty and inventive step depend upon the actual claim limitations
and the relevant prior art concerning remote attestation,
transactional receipts, verifiable state transitions, distributed
authorization, protected execution gateways, and consequence-
dependent workflows.
The proposed combination should be examined against the closest
disclosures rather than assumed patentable merely because it
introduces new terminology.
4.38 — SUPPORT FOR POTENTIAL CLAIMED SUBJECT MATTER
The present embodiment provides technical support for considering
claims directed to:
Aspect 1: Construction of a protected remote consequence predicate
associated with an originating Candidate Act.
Aspect 2: Binding of the actual outbound operation to the protected
remote intent.
Das Expires 29 April 2027 [Page 114]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Aspect 3: Generation of a protected remote effectuation attempt
identifier.
Aspect 4: Authenticated correlation between originating and remote
operation identities.
Aspect 5: Qualification of an observation source according to the
specific remote consequence it can establish.
Aspect 6: Independent remote state witnessing.
Aspect 7: Representation of witness independence and common failure
dependencies.
Aspect 8: Protected before-state and after-state commitments.
Aspect 9: Operation-specific causal state-transition attestation.
Aspect 10: Verification of a remote transaction identifier against a
protected originating operation.
Aspect 11: Verification of authenticated remote resource versions.
Aspect 12: Separation of dispatch, receipt, acceptance, commit,
observed state, and required finality assurance.
Aspect 13: Prevention of remote outcome assurance elevation
unsupported by evidence.
Aspect 14: Authenticated cross-commitment of originating operation,
remote observation, and verified consequence.
Aspect 15: Protected handling of remote outcome uncertainty.
Aspect 16: Preservation of a reconciliation fence during unresolved
external effects.
5.2.3.61. Original Source — Global Page 552
Aspect 17: Prevention of unsafe duplicate retries.
Aspect 18: Detection of mismatched remote resources or operations.
Aspect 19: Detection of conflicting qualified witness evidence.
Aspect 20: Verification of remote state consistency across time or
replicas.
Das Expires 29 April 2027 [Page 115]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Aspect 21: Privacy-minimized remote effect evidence.
Aspect 22: Optional integration with remote attestation.
Aspect 23: Optional integration with verifiable transparency records.
Aspect 24: Protected outcome-dependent successor authorization.
Aspect 25: Independent successor Finality Sink verification against
remote outcome evidence.
Aspect 26: Scoped non-bearer continuation authority derived from or
bound to verified remote consequence predicates.
Aspect 27: Separately authorized recovery following remote partial or
incorrect effects.
Aspect 28: Cross-device authenticated remote outcome witnessing.
Aspect 29: Physical-state witnessing for remotely initiated actuator
operations.
Aspect 30: Distributed protected outcome-state management.
Aspect 31: Multi-witness evidence evaluation under a defined
independent fault model.
Aspect 32: Remote witness revocation and evidence freshness
verification.
Aspect 33: Distinction between a verified historical state and a
currently required remote state.
Aspect 34: Operation-bound transactional evidence combined with
independent remote state observation.
Aspect 35: Fail-closed outcome-dependent continuation where required
remote effect evidence is unavailable.
The aspects may support different independent or dependent claim
structures where appropriately disclosed and distinguished over prior
art.
4.39 — RELATIONSHIP TO EMBODIMENTS 1, 2, AND 3
Embodiment 1 concerns protected conflict arbitration among
independently authorized consequential operations.
Das Expires 29 April 2027 [Page 116]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Embodiment 2 concerns independently validated pre-effect operation
correspondence, protected phase outcomes, and scoped continuation.
Embodiment 3 concerns the relationship between a user-referenced
object, resolved computational entity, and actual effectuation
target.
5.2.3.62. Original Source — Global Page 553
Embodiment 4 concerns the evidence-supported relationship between an
authorized originating operation and the actual consequence claimed
to have occurred within another domain.
These mechanisms address different technical predicates.
An operation may be correctly authorized and conflict-free while the
remote service fails to perform the requested effect.
An operation may select the correct user-referenced resource while
the remote destination stores a different object.
A remote outcome receipt may be authentic while the operation to
which it relates is different from the authorized Candidate Act.
Accordingly, a combined implementation may require:
1. Correct user-referenced object correspondence under Embodiment 3;
2. Protected cross-operation compatibility under Embodiment 1;
3. Properly scoped originating effectuation authority under CW-1;
4. Verified remote consequence under Embodiment 4;
5. Independently validated continuation under Embodiment 2;
6. Optional scope-deviation resolution under CW-3.
No particular combination is universally mandatory unless required by
the corresponding claim.
4.40 — INDUSTRIAL APPLICABILITY
The present architecture may be applied to systems in which
autonomous computational entities cause remote consequences that must
be verified before further consequential actions occur.
Illustrative fields include:
Das Expires 29 April 2027 [Page 117]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Autonomous cloud management;
Enterprise AI agent orchestration;
Remote document storage and collaboration;
Financial transaction processing;
Messaging and communication systems;
Distributed workflow automation;
Remote software deployment;
Database administration;
Robotic and industrial control;
5.2.3.63. Original Source — Global Page 554
Telecommunications infrastructure;
Cross-device autonomous operation;
Remote identity and credential management;
Cloud resource provisioning;
Digital commerce;
Protected data export;
Safety-sensitive remotely actuated systems.
The technical value depends upon the specific remote effects,
evidence sources, protected trust assumptions, and enforcement
boundaries available in the implementation.
4.41 — FINAL NON-LIMITING TECHNICAL SUMMARY
The present embodiment discloses a protected cross-domain actual-
consequence witnessing architecture in which an operation authorized
in an originating computing domain is bound to a defined
consequential result expected within a remote computing domain.
The originating Candidate Act is represented by a protected remote
effect intent.
Das Expires 29 April 2027 [Page 118]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The originating Finality Sink independently verifies the actual
outbound operation and associates it with a protected attempt
reference.
The remote operation may be observed through a cooperating protected
controller, qualified witness, authenticated transaction record,
independently verifiable state interface, physical observation
mechanism, or another suitable evidence source.
The system evaluates the source's actual observation capabilities and
the relationship between the originating operation and observed
remote state.
Where the necessary evidence exists, the system establishes an
authenticated consequence record supporting the specific remote
outcome predicate.
Where causality is required, the implementation may use protected
operation-to-state linkage, including a transactionally bound state-
delta record.
Where evidence supports only remote receipt, acceptance, or
historical state observation, the system does not automatically
characterize the broader intended consequence as verified.
Where the actual remote result is partial, mismatched, uncertain, or
unsupported, the system preserves the corresponding protected outcome
state.
A successor operation whose authorization depends upon the remote
result may be governed through an Interim Effectuation Validator or
another protected continuation procedure.
The resulting successor finality authority is bound to the required
outcome evidence and to the specifically permitted subsequent
operation.
5.3. Embodiment 12 — Protected Recovery, Compensating Effects and Non-
Replayable Recovery Authority
Original technical source: TECHNICAL SPECIFICATION -1063-1541.pdf,
global pages 1063–1139 inclusive. Principal source treatment within
Part 8. Related mechanisms may also be referenced by Parts 3, 4 and
6.
5.3.1. Protected Component Architecture
Das Expires 29 April 2027 [Page 119]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
[Original operation + protected journal]
|
[Actual outcome collection / uncertain flag]
|
[Qualified failure-state classification]
|
[Bounded recovery envelope]
|
[Recovery CA / NES / current source grant]
|
[Non-replayable recovery generation]
|
[Recovery FS independently reconstructs]
|
[Permitted corrective effect or refuse]
Figure 5: Embodiment 12 — Protected Recovery, Compensating
Effects and Non- Replayable Recovery Authority — architecture
5.3.2. Actual-Effect and Failure Decision Flowchart
[Error / timeout / partial completion]
|
<Original effect status known?> -- NO --> [INDETERMINATE]
| YES / after reconciliation
[Qualify permitted recovery class]
|
<Competent new recovery authority?> -- NO --> [WITHHOLD]
| YES
[Create separately scoped Recovery CA]
|
<FS actual corrective act and state valid?> -- NO --> [REFUSE]
| YES
[Consume recovery generation, perform effect]
Figure 6: Embodiment 12 — Protected Recovery, Compensating
Effects and Non- Replayable Recovery Authority — effectuation
decisions
5.3.3. Original Technical Disclosure — Page-Indexed Sections
Das Expires 29 April 2027 [Page 120]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.3.3.1. Original Source — Global Page 1063
The principal candidate inventive technical concept of Embodiment 11
is a protected concurrent-effect finality architecture in which
authenticated resource-version and semantic conflict dependencies are
bound to operation-specific protected reservations, and a non-
bypassable Finality Sink independently reconstructs the actual
pending consequential operation and refuses effectuation unless its
current resource versions, conflict predicates, scoped non-bearer
authority, and protected reservation-consumption state satisfy the
required conditions.
Novelty, inventive step, unity, and appropriate claim breadth remain
subject to examination of relevant prior art and the enabling
disclosure actually filed.
END OF EMBODIMENT 11 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 12
PROTECTED AUTONOMOUS RECOVERY, COMPENSATING EFFECTS, AND NON-
REPLAYABLE POST-FAILURE AUTHORITY WITH EVIDENCE-QUALIFIED EFFECT
RECONSTRUCTION, RECOVERY-SPECIFIC CANDIDATE ACTS, AND INDEPENDENT
FINALITY-SINK ENFORCEMENT
12.0 — COMPLETE TECHNICAL TITLE
Systems and Methods for Protected Recovery of Autonomous
Consequential Operations Using Authenticated Actual-Effect Evidence,
Independently Verified Failure-State Classification, Recovery-
Specific Candidate Acts, Bounded Compensation and Continuation
Authority, Non-Replayable Recovery Generations, Protected Outcome
Reconciliation, and Independent Finality-Sink Verification of Actual
Corrective Operations
12.0.1 — General Technical Description
The present Embodiment 12 discloses systems, methods, apparatus,
protected computing components, authenticated recovery protocols,
machine-verifiable failure-state representations, cryptographic and
non-cryptographic authority mechanisms, protected recovery-state
transitions, hardware and software effectuation controllers, and non-
limiting implementations for governing recovery actions performed by
autonomous computational systems following interrupted, failed,
uncertain, partially completed, or otherwise abnormal consequential
operations.
Das Expires 29 April 2027 [Page 121]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The computational entities may comprise artificial-intelligence
agents, autonomous assistants, workflow orchestration systems,
distributed application services, cloud workloads, database clients,
network controllers, transaction processors, operating-system
components, embedded devices, industrial controllers, hardware
accelerators, robotic systems, or other computational entities
capable of initiating external effects.
A consequential operation may fail before effectuation, fail after
partially producing an effect, complete successfully without
delivering an acknowledgement, or produce an external state different
from the expected state.
5.3.3.2. Original Source — Global Page 1064
An autonomous recovery agent may attempt to retry the operation,
reverse an earlier change, modify a related resource, issue a refund,
cancel an instruction, restore a configuration, send a notification,
or perform another corrective action.
Such recovery operations may themselves produce consequential
external effects.
An original authorization to perform a task does not automatically
confer unrestricted authority to perform every action that an
autonomous recovery algorithm considers useful.
Similarly, a local exception, timeout, failed acknowledgement, or
software error does not establish that the corresponding real-world
operation never occurred.
The present embodiment therefore separates:
The original consequential operation;
The evidence concerning its actual effect;
The determination of whether recovery is required;
The authority to select a particular recovery procedure;
The authority to prepare a corrective Candidate Act;
The authority to perform the actual corrective effect;
And the evidence necessary to authorize any dependent successor
phase.
Das Expires 29 April 2027 [Page 122]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
In a principal implementation, the system places the original
operation into a protected recovery state when its outcome cannot be
safely treated as ordinary success or confirmed non-effectuation.
An authenticated recovery controller collects qualified evidence
concerning the effectuation attempt and any actual consequential
result.
An authorized verifier classifies the supported outcome and
establishes a bounded recovery envelope.
A recovery planner may propose one or more corrective actions within
that envelope.
Each consequential corrective action is represented as a distinct
Recovery Candidate Act and remains non-effective pending its own
valid finality authorization.
Before the corrective effect is released, a Recovery Finality Sink
independently reconstructs the actual pending operation and verifies
its relationship to the qualified earlier outcome, current protected
authority, recovery scope, target resource, generation, and sink-
local consumption state.
The recovery action becomes effective only when the applicable
protected conditions pass.
5.3.3.3. Original Source — Global Page 1065
12.0.2 — Fundamental Technical Principle
An abnormal computational outcome does not create new authority to
act.
A timeout is not proof of non-execution.
A failed acknowledgement is not proof of failure.
A recovery instruction is not automatically valid because it
describes a beneficial corrective intention.
A compensation is a new consequential effect and is not necessarily a
reversal of the original physical, financial, informational, or
computational consequence.
A recovered or restarted agent does not automatically reacquire
previously consumed authority.
Das Expires 29 April 2027 [Page 123]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The protected system therefore requires recovery to be supported by
qualified evidence and separately enforceable authority.
12.0.3 — Principal Proposed Inventive Concept
The principal proposed technical combination comprises:
An authenticated original Candidate Act;
A protected original-effect attempt and consumption record;
Qualified evidence concerning the effect that actually occurred,
failed to occur, or remains uncertain;
A protected recovery-state classification;
An authenticated recovery authority envelope;
One or more recovery-specific Candidate Acts;
Protected recovery-generation and replay state;
A mandatory relation between the proposed recovery and the supported
original outcome;
A scoped non-bearer recovery enablement;
And independent reconstruction and verification of the actual
corrective operation at a Recovery Finality Sink.
The protected system does not treat a recovery planner's stated
intention as sufficient authority.
5.3.3.4. Original Source — Global Page 1066
The actual corrective consequence must remain within the bounded
recovery authority and satisfy current protected state.
12.0.4 — Distinction from Conventional Compensation
Conventional distributed workflows may invoke compensating
transactions when earlier steps fail.
The present embodiment may employ such transactions.
However, the proposed additional technical relationship is that a
compensating effect is not automatically authorized merely because an
earlier transaction was attempted.
Das Expires 29 April 2027 [Page 124]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The system may require independently qualified evidence establishing
the relevant prior-effect state, a permitted corrective effect scope,
current target-state verification, and sink-local protected
consumption of the recovery authority.
The system may additionally distinguish a genuinely reversible effect
from a separate mitigating effect.
12.0.5 — Multiple Recovery Classes
The embodiment may support protected retry, forward completion,
compensation, containment, restoration, abandonment, human-authorized
remediation, or other technically defined recovery classes.
Each class may have different effect predicates and authority
requirements.
A particular implementation need not support every class.
12.0.6 — Relationship to Common Workflows
The embodiment may incorporate Candidate Acts, Non-Effective State,
Protected Enforcement Domains, protected validation evidence, scoped
non-bearer finality enablement, and independent Finality Sink
verification from Common Master Workflow CW-1.
Where a later consequential recovery phase must depend upon a
qualified earlier real effect, the receipt-constituted causal
authority mechanism of CW-2 may apply.
Where an actual recovery operation exceeds the original authorized
scope, protected reauthorization under CW-3 may apply.
The protected recovery procedure does not automatically require every
operation to use CW-2.
However, where a selected CW-2 causal dependency is mandatory, a
generic recovery log or administrative approval cannot replace the
accepted actual-effect receipt.
12.0.7 — Relationship to Earlier Embodiments
5.3.3.5. Original Source — Global Page 1067
Embodiment 1 may govern conflicts between a recovery operation and
other concurrent Candidate Acts.
Das Expires 29 April 2027 [Page 125]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Embodiment 2 may govern causally dependent successor operations
requiring accepted prior real-effect receipts.
Embodiment 3 may verify that the actual recovery target corresponds
to the authorized object.
Embodiment 4 may provide qualified external-effect observation or
independently supported outcome evidence.
Embodiment 5 may constrain computational and resource expenditure
during recovery.
Embodiment 6 may ensure that current tool semantics remain consistent
with the permitted corrective operation.
Embodiment 7 may preserve and attenuate recovery authority during
delegation.
Embodiment 8 may prevent a recovery process from disclosing
additional protected information without valid privacy authority.
Embodiment 9 may prevent an earlier device owner from using stale
authority after workload migration.
Embodiment 10 may require current model or algorithmic-generation
validity.
Embodiment 11 may govern version-bound reservations and safe
reconciliation of concurrent effects.
Miscellaneous Embodiment M-1 may provide additional effectuation-path
coverage and protected-state integration.
The present embodiment is specifically directed to what an autonomous
system may validly do after an earlier consequential operation has
failed, partially completed, or become uncertain.
Previously completed embodiments remain unchanged.
12.1 — TECHNICAL FIELD
The present embodiment relates to autonomous computing security,
protected recovery orchestration, distributed workflow recovery,
consequential-effect verification, transaction compensation, fault-
tolerant execution, authenticated authorization, protected retry
control, idempotency, crash recovery, physical-effect safety, and
independent execution-finality enforcement.
Das Expires 29 April 2027 [Page 126]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.3.3.6. Original Source — Global Page 1068
The disclosed mechanisms may be implemented in current and future
computing systems having one or more effect-capable boundaries.
The relevant consequences may include database mutations, file
changes, transaction submissions, payment operations, network
configuration changes, information disclosures, device commands,
physical actuation, credential activation, or other controlled
external effects.
12.2 — SPECIFIC TECHNICAL PROBLEMS
12.2.1 — Failure Without Proof of Non-Effectuation
An application may report failure even though the corresponding
external operation completed.
12.2.2 — Lost Acknowledgement
A remote recipient may process a command and lose the response before
the sender receives it.
12.2.3 — Partial Completion
Several intended effects may have different completion states.
12.2.4 — Duplicate Retry
A restarted agent may repeat an operation that already became
effective.
12.2.5 — Compensation of an Unperformed Effect
A recovery agent may attempt to reverse an operation that never
occurred.
12.2.6 — Double Compensation
Two recovery workers may independently perform the same corrective
effect.
12.2.7 — Compensation Beyond Authorized Scope
A corrective procedure may modify resources or amounts exceeding the
original authority.
12.2.8 — Compensation Against the Wrong Target
Das Expires 29 April 2027 [Page 127]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A resource may have changed ownership, identifier, or version after
the original operation.
12.2.9 — Irreversible Consequence
Some effects cannot be undone by any subsequent computational
command.
5.3.3.7. Original Source — Global Page 1069
12.2.10 — Competing Recovery Paths
Several recovery strategies may be individually plausible but
mutually incompatible.
12.2.11 — Stale Recovery Context
A recovery agent may act upon an outdated observation of the current
external state.
12.2.12 — Recovery Policy Manipulation
A compromised agent may choose an unauthorized recovery mode.
12.2.13 — Retry Storm
Repeated automated recovery attempts may overload external services
or exhaust resources.
12.2.14 — Recovery Credential Abuse
An agent may attempt to use privileged recovery credentials for an
unrelated action.
12.2.15 — Snapshot Rollback
A restarted execution environment may restore previously consumed
recovery authority.
12.2.16 — Remote Recovery Without Trustworthy Evidence
A destination service may receive a corrective instruction without
evidence supporting the earlier effect.
12.2.17 — Cross-Domain Recovery
Multiple independently administered systems may need to reconcile a
partially completed operation.
Das Expires 29 April 2027 [Page 128]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
12.2.18 — Recovery After Model or Tool Replacement
A changed computational implementation may select a different
correction procedure.
12.2.19 — Recovery Conflicting With Later Legitimate Changes
The affected resource may have been validly modified by another
operation after the original effect.
12.2.20 — Technical Objective
A candidate objective technical problem is:
How to prevent unauthorized, duplicated, incorrectly targeted, or
causally unsupported corrective effects by autonomous systems after
an earlier consequential operation has failed, partially completed,
or become uncertain, using qualified actual-effect evidence,
5.3.3.8. Original Source — Global Page 1070
bounded recovery-specific authority, protected non-replayable state,
and independent Finality-Sink verification of the actual proposed
recovery operation.
12.3 — ESTABLISHED RECOVERY TECHNIQUES AND LIMITATIONS
12.3.1 — Conventional Retry
A system may repeat a request following an error.
Retry is established technology.
Its safety depends upon the operation's semantics and actual prior
outcome.
12.3.2 — Conventional Idempotency
A destination may recognize an operation identifier and suppress
repeated application of the same effect.
Such mechanisms are established.
Their guarantees depend upon the destination's implementation,
identifier retention, and parameter-binding behavior.
12.3.3 — Conventional Compensation
Das Expires 29 April 2027 [Page 129]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A workflow may execute a corrective transaction after another
transaction fails.
Compensating transactions are established.
A compensation does not automatically reverse an irreversible
external consequence.
12.3.4 — Conventional Saga Orchestration
A coordinator may execute a sequence of local transactions and invoke
compensations following partial failure.
Such orchestration is established.
The proposed embodiment does not claim original invention of that
pattern.
12.3.5 — Conventional Write-Ahead Logging
A system may record intended or committed mutations in a durable log.
Such logging is established.
A logged intention is not automatically evidence of an externally
completed consequential effect.
5.3.3.9. Original Source — Global Page 1071
12.3.6 — Conventional Checkpoint Recovery
A computational environment may resume from a stored checkpoint.
A checkpoint does not automatically restore the current validity of
external operation-specific authority.
12.3.7 — Conventional Dead-Letter Queues
Failed messages may be placed into a separate queue for later
processing.
Such queues are established.
They do not independently determine whether the original external
effect occurred or whether a later corrective command is authorized.
12.3.8 — Conventional Human Approval
Das Expires 29 April 2027 [Page 130]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A human may approve a proposed corrective action.
Such approval may be a valid source of authority where properly
authenticated and scoped.
It does not independently establish that the actual effect matches
the approved operation.
12.3.9 — Conventional Audit Logs
An audit log may preserve application events and reported outcomes.
The system must distinguish such records from qualified observation
of actual real-world effects.
12.3.10 — Candidate Technical Distinction
The proposed technical distinction concerns converting qualified
recovery evidence and bounded corrective authority into mandatory,
operation-specific finality conditions rather than treating the
recovery planner's decision as sufficient for effectuation.
12.4 — PRINCIPAL SYSTEM ARCHITECTURE
A representative implementation comprises:
An Original Candidate Act Registry;
A Protected Effect Attempt Controller;
A Qualified Outcome Evidence Collector;
An Authorized Effect-State Verifier;
5.3.3.10. Original Source — Global Page 1072
A Protected Recovery State Controller;
A Recovery Eligibility and Scope Verifier;
A Recovery Candidate Act Constructor;
A Protected Recovery Reservation Controller;
A Recovery-Specific Non-Bearer Authority Service;
A Recovery Finality Sink;
Das Expires 29 April 2027 [Page 131]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
And a Protected Recovery Outcome Reconciliation Controller.
Optional components may include an Interim Effectuation Validator, a
remote-effect observer, an idempotency verifier, a resource-version
controller, a protected credential broker, a hardware safety
interlock, a multi-domain compensation coordinator, and a persistent
evidence store.
The components may operate within one protected system or across
several independently authenticated domains.
The trust model must identify which components may be compromised and
which components must remain protected for the claimed guarantee.
12.5 — BROAD TECHNICAL DEFINITIONS
12.5.1 — Original Consequential Candidate Act
An Original Consequential Candidate Act, or OCCA, means the original
authorized proposed operation whose actual effect or failure state
gives rise to a recovery decision.
12.5.2 — Recovery Candidate Act
A Recovery Candidate Act, or RCA-12, means a separately represented
proposed consequential operation intended to retry, complete,
compensate, contain, restore, mitigate, or otherwise address an
earlier operation.
12.5.3 — Protected Original-Effect Record
A Protected Original-Effect Record, or POER, means authenticated
information associating the original Candidate Act with applicable
dispatch, consumption, and supported effectuation state.
12.5.4 — Qualified Actual-Effect Evidence
5.3.3.11. Original Source — Global Page 1073
Qualified Actual-Effect Evidence, or QAEE, means evidence whose
source, scope, authenticity, freshness, and observation properties
are sufficient for a specified conclusion concerning an earlier
consequential effect.
12.5.5 — Protected Recovery Classification
Protected Recovery Classification, or PRC-12, means an authenticated
determination of the supported actual-effect and recovery state.
Das Expires 29 April 2027 [Page 132]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
12.5.6 — Protected Recovery Envelope
A Protected Recovery Envelope, or PRE-12, means machine-verifiable
authority specifying permitted recovery classes, resource scopes,
effect bounds, recipients, conditions, and relevant recovery limits.
12.5.7 — Recovery Evidence Commitment
A Recovery Evidence Commitment, or REC-12, means an authenticated
representation binding selected qualified earlier-effect evidence to
a proposed recovery.
12.5.8 — Recovery Authority Epoch
A Recovery Authority Epoch, or RAE-12, means a protected generation
governing the validity of recovery-specific authority.
12.5.9 — Recovery Attempt Identifier
A Recovery Attempt Identifier, or RAID-12, means an authenticated
reference identifying a particular recovery attempt and its
corresponding protected consumption state.
12.5.10 — Non-Replayable Recovery Authority
Non-Replayable Recovery Authority means scoped protected enablement
whose exercise is limited by operation identity, applicable recovery
state, designated sink, generation, and consumption conditions.
12.5.11 — Recovery Finality Sink
A Recovery Finality Sink, or RFS, means an effect-capable boundary
configured to withhold a proposed corrective operation until the
required recovery evidence, scope, current-state, and finality
conditions pass.
12.5.12 — Protected Recovery Reservation
A Protected Recovery Reservation, or PRR-12, means authenticated
state provisionally allocating authority or resources for a
particular recovery effect.
12.5.13 — Recovery Consumption State
Das Expires 29 April 2027 [Page 133]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.3.3.12. Original Source — Global Page 1074
Recovery Consumption State means protected information identifying
whether specified recovery authority has been exercised, cancelled,
expired, or otherwise resolved.
12.5.14 — Effect Outcome Classification
Effect Outcome Classification means a technically defined
determination concerning the status of an earlier attempted effect.
12.5.15 — Confirmed Non-Effectuation
Confirmed Non-Effectuation means a conclusion supported by qualified
evidence that a specified effect did not occur within the relevant
boundary and observation scope.
12.5.16 — Confirmed Partial Effect
Confirmed Partial Effect means qualified evidence establishing that
only a specified portion or subset of the intended effect occurred.
12.5.17 — Confirmed Completed Effect
Confirmed Completed Effect means qualified evidence establishing that
a defined real effect occurred.
12.5.18 — Unresolved Effect Outcome
Unresolved Effect Outcome means a condition in which the available
evidence cannot safely establish completion or non-completion of the
relevant effect.
12.5.19 — Recovery Retry Fence
A Recovery Retry Fence means a protected condition preventing another
effect attempt while required earlier-outcome or duplicate-
suppression conditions remain unsatisfied.
12.5.20 — Bounded Compensation Authority
Bounded Compensation Authority means permission to perform a
specified corrective effect subject to protected amount, resource,
operation, and causality restrictions.
12.5.21 — Compensation Correspondence
Das Expires 29 April 2027 [Page 134]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Compensation Correspondence means a machine-verifiable relationship
between the supported original effect and the corrective effect
proposed to address it.
12.5.22 — Residual Effect
A Residual Effect means a real-world or computational consequence
that remains after a compensating or mitigating operation.
12.5.23 — Irreversibility Classification
5.3.3.13. Original Source — Global Page 1075
Irreversibility Classification means a protected determination
concerning whether an original effect can be technically reversed,
partially corrected, or only mitigated.
12.5.24 — Protected Recovery Graph
A Protected Recovery Graph, or PRG-12, means a machine-verifiable
representation of original effects, dependencies, corrective
operations, and protected recovery-state relationships.
12.5.25 — Recovery Branch Exclusivity
Recovery Branch Exclusivity means a protected condition preventing
incompatible recovery strategies from simultaneously obtaining
effective authority for the same relevant failure state.
12.5.26 — Recovery Successor Authority
Recovery Successor Authority means scoped authority to perform an
additional consequential recovery phase after satisfaction of the
required earlier-phase conditions.
12.5.27 — Protected Recovery Stop Condition
A Protected Recovery Stop Condition means a machine-verifiable
condition preventing additional recovery effects after a defined
successful, exhausted, revoked, or unsafe state.
12.5.28 — Protected Recovery Budget
A Protected Recovery Budget means bounded allowance for recovery
attempts, resources, time, financial exposure, or other applicable
technical quantities.
12.5.29 — Recovery State Rollback Protection
Das Expires 29 April 2027 [Page 135]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Recovery State Rollback Protection means a mechanism preventing
restoration of previously consumed or revoked recovery authority
through stale snapshots or state copies.
12.5.30 — Recovery-Effect Continuity Commitment
A Recovery-Effect Continuity Commitment means a protected relation
binding the original effect, its supported actual outcome, and the
permitted corrective operation.
12.6 — CLASSIFICATION OF ORIGINAL EFFECT OUTCOMES
A protected verifier may classify an earlier operation according to
its supported effectuation state.
12.6.1 — Not Dispatched
5.3.3.14. Original Source — Global Page 1076
Qualified evidence establishes that the operation never crossed the
relevant consequential dispatch boundary.
12.6.2 — Dispatched but Unresolved
A protected dispatcher initiated the operation, but sufficient
evidence concerning the resulting real effect is unavailable.
12.6.3 — Confirmed Rejected
The receiving controlled resource provides qualified evidence that
the operation was rejected before the specified effect occurred.
12.6.4 — Confirmed Completed
A qualified observation establishes the specified completed
consequence.
12.6.5 — Confirmed Partial
Only defined components of the intended effect are established as
completed.
12.6.6 — Completed With Divergent Result
An effect occurred but produced a result different from the expected
outcome.
12.6.7 — Irreversible Effect Completed
Das Expires 29 April 2027 [Page 136]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A consequential event occurred that cannot be undone through an exact
inverse operation.
12.6.8 — Evidence Conflict
Different qualified sources provide inconsistent information
concerning the actual outcome.
12.6.9 — Evidence Insufficient
Available information cannot support the required completion or non-
effectuation conclusion.
12.6.10 — Classification Limitation
The system does not infer confirmed failure merely from elapsed time,
a connection error, a missing acknowledgement, or an agent-generated
explanation.
12.7 — ORIGINAL-EFFECT EVIDENCE
The system may obtain relevant evidence from a controlled execution
sink, transaction controller, protected resource state, authenticated
remote service, qualified external observer, or another source having
sufficient technical visibility.
5.3.3.15. Original Source — Global Page 1077
A representative original-effect evidence record may comprise:
QUALIFIED_ACTUAL_EFFECT_EVIDENCE = { evidence_version,
original_candidate_act, actual_operation_commitment,
original_effectuation_sink, operation_attempt_identifier,
source_controller_identity, observation_source_identity,
observation_scope, supported_effect_status,
supported_resource_identity, actual_effect_parameters,
current_or_observed_resource_version, effectuation_generation,
observation_epoch, known_partial_effects, unresolved_effects,
evidence_assurance_profile, protected_authentication }
An evidence record must not claim a stronger conclusion than its
observation supports.
For example, a protected outbound gateway may establish that a
message was transmitted from the local interface.
That evidence does not necessarily establish that the remote
recipient read the message.
Das Expires 29 April 2027 [Page 137]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A protected storage controller may establish that a particular
durable mutation committed.
Such evidence may support a stronger conclusion concerning that
resource state.
The assurance must be tied to the actual observed effect.
12.8 — INDEPENDENT OUTCOME VERIFICATION
12.8.1 — Separation From Recovery Planner
The component deciding how to recover need not be trusted to
establish what previously happened.
12.8.2 — Authenticated Observer
A qualified observer may possess an enrolled cryptographic identity
and authorized observation role.
5.3.3.16. Original Source — Global Page 1078
12.8.3 — Resource-Side Evidence
The affected resource may provide authoritative evidence of its
current state or completed operation.
12.8.4 — External Effect Validation
An independent verifier may reconcile protected source and
destination evidence.
12.8.5 — Conflicting Evidence
The verifier may classify the outcome as unresolved rather than
selecting an unsupported convenient result.
12.8.6 — Negative Evidence
A valid negative-effect conclusion may require proof that the command
never crossed the effectuation boundary, was definitively rejected,
or could not have occurred under the established protected state.
12.8.7 — Timeout Limitation
A timeout does not constitute negative effect evidence.
12.8.8 — Causal Receipt Integration
Das Expires 29 April 2027 [Page 138]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Where CW-2 applies, a qualified accepted actual-effect receipt may be
a mandatory constituent of authority for the dependent successor
phase.
12.8.9 — Evidence Freshness
Recovery may require current resource-state information in addition
to historical effect evidence.
12.8.10 — Technical Effect
Independent verification prevents a compromised or mistaken recovery
planner from converting an unsupported failure assertion into
effective corrective authority through the governed sink.
12.9 — PROTECTED RECOVERY ENVELOPE
A PRE-12 may define what recovery operations are potentially
permissible under specified effect outcomes.
A representative structure is:
PROTECTED_RECOVERY_ENVELOPE = {
5.3.3.17. Original Source — Global Page 1079
envelope_identifier, original_candidate_act,
original_authority_reference, supported_effect_classifications,
permitted_recovery_modes, authorized_target_resources,
permitted_corrective_effects, compensation_quantity_bounds,
cumulative_recovery_budget, allowed_retry_count,
relevant_resource_versions, required_outcome_evidence,
required_validator_roles, required_finality_sinks,
maximum_recovery_depth, branch_exclusivity_policy,
current_authority_epoch, revocation_reference,
protected_envelope_authentication }
The recovery envelope does not automatically activate every listed
recovery mode.
The selected operation must satisfy its individual evidence, state,
and effectuation conditions.
A recovery envelope may permit one retry but prohibit compensation.
Another may permit refund or cancellation but not modification of
unrelated resources.
Das Expires 29 April 2027 [Page 139]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Another may require independently authenticated human authorization
before a consequential correction.
12.10 — RECOVERY MODES
12.10.1 — Observation-Only Recovery
The system collects additional evidence without producing another
consequential effect.
12.10.2 — Verified Retry
The system repeats a defined operation only when retry safety is
technically established.
12.10.3 — Forward Completion
The system performs a remaining authorized step after confirming the
earlier required effect.
12.10.4 — Exact State Restoration
5.3.3.18. Original Source — Global Page 1080
The system restores a protected state where the effect is genuinely
reversible and current state permits restoration.
12.10.5 — Compensating Effect
A new consequential operation addresses an earlier completed effect
without necessarily erasing its historical occurrence.
12.10.6 — Mitigating Effect
A protective action limits damage or future consequences when
reversal is unavailable.
12.10.7 — Containment
The system restricts credentials, future effects, resources, or
communication paths.
12.10.8 — Protected Abandonment
The system terminates further attempts while preserving qualified
state and applicable outstanding obligations.
12.10.9 — Human-Authorized Remediation
Das Expires 29 April 2027 [Page 140]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A properly authenticated principal authorizes a corrective operation
outside an earlier automatic recovery scope.
12.10.10 — Hybrid Recovery
Several modes may be combined according to a protected dependency and
authority structure.
12.11 — RECOVERY CANDIDATE ACT
Each proposed consequential recovery operation is represented
separately from the original Candidate Act.
A representative Recovery Candidate Act may comprise:
RECOVERY_CANDIDATE_ACT = { recovery_candidate_identifier,
original_candidate_act_reference, original_attempt_reference,
qualified_effect_evidence_reference, supported_effect_classification,
recovery_mode, proposed_actual_corrective_operation,
affected_resource_references, current_resource_state,
5.3.3.19. Original Source — Global Page 1081
requested_compensation_or_retry_scope,
original_authority_constraints, recovery_envelope_reference,
recovery_generation, recovery_branch_identifier,
designated_finality_sink, protected_candidate_authentication }
The Recovery Candidate Act may be generated by a model, deterministic
controller, recovery planner, or other computation.
Its creation does not itself activate the proposed effect.
The protected system independently verifies the correctness of the
required authority relationship.
12.12 — RECOVERY AUTHORITY IS NOT INHERITED AUTOMATICALLY
The original Candidate Act may authorize one external operation.
The recovery system may need to perform a different operation.
For example, original authority to send a payment does not
automatically confer authority to debit another account, transfer a
larger amount, or reveal additional protected financial information
during investigation.
Das Expires 29 April 2027 [Page 141]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Similarly, authority to publish a document does not automatically
permit unrestricted publication of additional explanations or
corrections.
A recovery controller therefore distinguishes:
The original authorized objective;
The original permitted effect envelope;
The actual supported effect;
The proposed recovery effect;
And the current authority permitting that specific recovery.
Where the proposed corrective operation exceeds the valid recovery
envelope, renewed authority is required.
The system does not treat the agent's claim of necessity as
sufficient permission.
5.3.3.20. Original Source — Global Page 1082
12.13 — PROTECTED RECOVERY GENERATIONS
A principal implementation associates the recovery operation with a
protected generation or equivalent authoritative state.
The generation may advance when a recovery branch is selected, an
attempt is consumed, authority is revoked, a compensation completes,
or a new authorized recovery procedure begins.
12.13.1 — Original Generation
The system identifies the generation of the original consequential
operation.
12.13.2 — Recovery Generation
A separately identifiable recovery generation governs corrective
authority.
12.13.3 — Attempt Count
The controller tracks applicable attempted or consumed recovery
operations.
Das Expires 29 April 2027 [Page 142]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
12.13.4 — Stale Generation
An earlier recovery authorization cannot automatically be replayed
after the protected generation changes.
12.13.5 — Snapshot Protection
Current authority is maintained outside untrusted copyable workload
state or verified against an authoritative protected source.
12.13.6 — Multi-Agent Recovery
Several agents share the applicable protected recovery-generation
state.
12.13.7 — Branch Exclusivity
Conflicting recovery branches cannot simultaneously exercise
authority where exclusivity is required.
12.13.8 — Recovery Exhaustion
The system may close recovery authority after a defined limit or
terminal state.
12.14 — RECOVERY BRANCH EXCLUSIVITY
An autonomous planner may identify multiple possible recovery
strategies.
5.3.3.21. Original Source — Global Page 1083
For example, it may propose retrying a transfer, refunding a prior
transfer, or placing the transaction under review.
These strategies may not be mutually compatible.
The protected controller may establish a branch-selection record
identifying the currently permitted mode.
A representative branch state may comprise:
PROTECTED_RECOVERY_BRANCH = { original_effect_reference,
current_effect_classification, selected_recovery_mode,
current_recovery_generation, authorized_candidate_scope,
incompatible_branch_set, active_recovery_reservations,
current_resource_versions, branch_consumption_state,
protected_branch_authentication }
Das Expires 29 April 2027 [Page 143]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Where the selected branch requires exclusivity, the protected
controller prevents incompatible branches from both receiving
effective authority.
A later change of strategy may require cancellation, reconciliation,
and issuance of new protected authority.
A stale branch cannot be activated merely by restoring an earlier
recovery-plan file.
12.15 — RETRY SAFETY
12.15.1 — Known Non-Effectuation
A retry may be permitted where qualified evidence establishes that
the original operation did not occur and current authorization
remains valid.
12.15.2 — Destination Idempotency
A retry may be permitted where the destination implements a
sufficiently reliable idempotency or duplicate-suppression mechanism
for the specified operation.
12.15.3 — Parameter Binding
The repeated request must correspond to the original permitted
operation.
12.15.4 — Unresolved Outcome
5.3.3.22. Original Source — Global Page 1084
If prior effectuation is uncertain, an unrestricted new attempt is
not presumed safe.
12.15.5 — Same Operation Identifier
A retry may use a stable protected operation identifier when the
destination's semantics support such reuse.
12.15.6 — Changed Operation Parameters
A materially changed request may require another Candidate Act and
authorization.
12.15.7 — Retention Limits
Das Expires 29 April 2027 [Page 144]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The destination's duplicate-suppression state may expire.
The recovery system must not assume indefinite idempotency.
12.15.8 — Retry Budget
The controller may limit the number of permitted attempts.
12.15.9 — Sink Verification
The actual resource sink checks current retry authorization, effect
scope, and applicable protected consumption state.
12.15.10 — No Universal Exactly-Once Claim
Exactly-once real-world effectuation cannot be inferred solely from
retrying with the same request identifier.
12.16 — COMPENSATION AS A NEW CONSEQUENCE
A compensating operation may address an earlier effect by creating
another effect.
It may restore an earlier database value, release reserved inventory,
issue a refund, cancel a pending action, publish a correction,
restore a configuration, or initiate another authorized response.
The compensation must be evaluated according to its actual technical
effect.
12.16.1 — Original Effect Binding
The proposed compensation references the original effect it is
intended to address.
12.16.2 — Supported Completion
The system verifies whether the relevant original effect occurred.
5.3.3.23. Original Source — Global Page 1085
12.16.3 — Current State
The controller obtains the current resource state before proposing
correction.
12.16.4 — Corrective Scope
Das Expires 29 April 2027 [Page 145]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The proposed compensation must remain within the applicable recovery
authority.
12.16.5 — Target Identity
The actual resource affected by compensation is verified.
12.16.6 — Amount and Quantity
The compensation cannot exceed permitted bounds merely because the
earlier workflow failed.
12.16.7 — Separate Finality
The correction requires its own effectuation authorization.
12.16.8 — Consumption
The compensation authority is appropriately consumed.
12.16.9 — Residual State
Any remaining effect or obligation is recorded.
12.16.10 — Compensation Limitation
The successful execution of a compensating operation does not
necessarily mean that the original consequence never occurred.
12.17 — IRREVERSIBLE AND PARTIALLY REVERSIBLE EFFECTS
Some consequences cannot be restored to their earlier state.
12.17.1 — Information Disclosure
Once an external recipient obtains information, a subsequent deletion
request cannot guarantee that all copies or knowledge have been
eliminated.
12.17.2 — Physical Actuation
A physical movement may produce material consequences that cannot be
undone by returning an actuator to its earlier position.
5.3.3.24. Original Source — Global Page 1086
12.17.3 — Network Transmission
Das Expires 29 April 2027 [Page 146]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A transmitted packet cannot necessarily be recalled after delivery.
12.17.4 — Published Data
Removing a publication does not guarantee that prior recipients or
caches no longer possess it.
12.17.5 — Financial Transfer
A refund may be a new transaction rather than a literal erasure of
the original transfer.
12.17.6 — Credential Disclosure
Rotating a credential may prevent future use but does not reverse
earlier disclosure.
12.17.7 — Industrial Operation
Restoring a controller setting may not restore prior physical process
conditions.
12.17.8 — Protected Classification
The recovery verifier identifies which relevant corrective outcomes
can actually be guaranteed.
12.17.9 — Mitigation
The protected envelope may authorize containment or mitigation where
exact reversal is unavailable.
12.17.10 — No False Restoration Claim
A protected recovery record must not equate an approximate corrective
action with complete reversal unless the actual supported technical
result justifies that conclusion.
12.18 — FORWARD RECOVERY
Forward recovery seeks to complete an authorized objective after a
partially completed workflow.
For example, a controlled service may have successfully reserved a
resource while a dependent activation failed.
The recovery planner may propose resuming the remaining phase.
Das Expires 29 April 2027 [Page 147]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The system first verifies the relevant earlier completed effect.
5.3.3.25. Original Source — Global Page 1087
Where a selected causal continuation protocol requires an accepted
prior-effect receipt, the receipt becomes a necessary condition for
successor authority.
The protected controller verifies current resource state and original
task scope.
It then constructs an operation-specific successor Candidate Act.
The actual Finality Sink reconstructs and verifies the pending
successor effect.
A generic workflow status marked successful does not replace the
required effect and authority predicates.
12.19 — BACKWARD RECOVERY
Backward recovery seeks to address earlier completed effects after a
later phase fails.
A protected recovery graph may identify prior effects and available
compensating actions.
The system determines which original effects actually occurred.
It distinguishes reversible state mutations from non-reversible
consequences.
Each consequential compensation is separately authorized and
verified.
Where a compensation depends upon an earlier compensation having
completed, the applicable causal authority may require qualified
prior real-effect evidence.
The order of compensations may be significant.
A nominal reverse ordering is not automatically safe if resource
state, third-party effects, or dependencies have changed.
The recovery planner must operate under explicit protected
consistency and authority rules.
12.20 — EFFECT DEPENDENCY GRAPH
Das Expires 29 April 2027 [Page 148]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A workflow may be represented as a graph containing original effects,
observations, recovery Candidates, and completion conditions.
A representative logical structure may comprise:
ORIGINAL_CANDIDATE | v ORIGINAL_EFFECT_ATTEMPT |
5.3.3.26. Original Source — Global Page 1088
v QUALIFIED_OUTCOME_EVIDENCE | v PROTECTED_RECOVERY_CLASSIFICATION |
v BOUNDED_RECOVERY_AUTHORITY | v RECOVERY_CANDIDATE_ACT | v
PROTECTED_RECOVERY_VALIDATION | v RECOVERY_FINALITY_SINK | v
ACTUAL_CORRECTIVE_EFFECT | v QUALIFIED_RECOVERY_OUTCOME
The graph may include alternative, parallel, or dependent recovery
branches.
Graph structure alone does not authorize an effect.
The required protected evidence and authority predicates must be
satisfied at the corresponding real-effect boundary.
12.21 — CURRENT-STATE RECONSTRUCTION
A historical effect may have altered a resource.
Another legitimate operation may subsequently modify that resource
again.
A recovery planner must not blindly restore the state that existed
before the original operation if doing so would overwrite independent
valid changes.
The protected system may evaluate:
The original target identity;
The original effect and its supported result;
The current resource version;
5.3.3.27. Original Source — Global Page 1089
Intervening relevant modifications;
The permitted corrective operation;
And applicable shared-resource invariants.
Das Expires 29 April 2027 [Page 149]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A protected recovery may use a version-bound conditional mutation.
Where the current state no longer supports the originally planned
compensation, the system may require recalculation, restriction, or
renewed authority.
This mechanism may incorporate Embodiment 11's protected concurrency
and reservation controls.
12.22 — RECOVERY-SPECIFIC NON-BEARER AUTHORITY
A representative recovery capability may comprise:
NON_BEARER_RECOVERY_AUTHORITY = { authority_version,
original_candidate_act, original_attempt_reference,
qualified_effect_evidence, supported_effect_classification,
recovery_candidate_act, permitted_recovery_mode,
actual_corrective_effect_scope, target_resource_commitment,
current_resource_version, recovery_envelope_commitment,
selected_recovery_branch, recovery_generation,
designated_recovery_finality_sink, retry_or_compensation_limit,
authority_expiration_conditions, protected_revocation_reference,
recovery_consumption_reference,
cryptographic_or_protected_authentication }
The authority may be implemented through a signed capability,
protected controller state, key-release condition, or another
suitable non-bearer mechanism.
Copying an authority object does not permit arbitrary additional
recovery effects.
The actual Finality Sink verifies current state and consumption.
5.3.3.28. Original Source — Global Page 1090
12.23 — RECOVERY FINALITY SINK
The Recovery Finality Sink is the controlled boundary through which
the actual corrective consequence may become effective.
It may comprise:
A database commit interface;
A file-system mutation controller;
A payment or refund gateway;
Das Expires 29 April 2027 [Page 150]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A credential broker;
A network configuration interface;
A communication service;
A protected storage controller;
An actuator command interface;
A hardware device controller;
Or another effect-capable resource boundary.
The sink independently obtains or reconstructs the actual pending
recovery operation.
It verifies the original-effect evidence and corresponding authority
requirements.
It checks that the proposed correction falls within the recovery
envelope.
It verifies the actual target and current relevant resource state.
It checks current recovery generation, revocation, reservations, and
consumption.
Only after mandatory predicates pass may the governed corrective
effect be released.
A recovery planner's signed instruction does not independently
replace sink verification.
12.24 — PROTECTED CREDENTIAL CONTROL DURING RECOVERY
A recovery operation may require privileged credentials.
For example, an authorized corrective transaction may require access
to a financial system or infrastructure-management service.
5.3.3.29. Original Source — Global Page 1091
The protected system may keep reusable privileged credentials outside
ordinary agent memory.
A credential broker may receive a recovery-specific Candidate Act and
verify its current authority.
Das Expires 29 April 2027 [Page 151]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The broker may refuse credential activation when the recovery attempt
lacks qualified effect evidence, exceeds the permitted scope, or
presents stale generation state.
Where the protected effect requires credential release, the
credential-access primitive itself may be treated as a consequential
Candidate Act.
The agent does not automatically receive unrestricted administrative
credentials merely because the original workflow failed.
12.25 — RECOVERY WORK AND RESOURCE BUDGETS
Recovery processes may consume computational resources, external API
calls, payment fees, device operations, or limited physical
resources.
A protected recovery budget may restrict these costs.
The budget may specify:
Permitted recovery attempts;
Maximum financial exposure;
Permitted time window;
Maximum computational work;
Maximum external requests;
Maximum resource allocations;
Or another defined quantitative condition.
The protected system may atomically reserve applicable recovery
allowance.
A failed recovery attempt may consume part of the allowance according
to its real effect and resource usage.
A model cannot automatically reset the budget by creating another
recovery agent or restarting its session.
5.3.3.30. Original Source — Global Page 1092
12.26 — PROTECTED RECOVERY STATE MACHINE
Das Expires 29 April 2027 [Page 152]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A non-limiting recovery state machine may comprise:
ORIGINAL_EFFECT_PENDING: The original operation remains prepared but
has not been definitively classified.
ORIGINAL_ATTEMPT_RECORDED: A protected record of an attempted
consequential operation exists.
OUTCOME_EVIDENCE_PENDING: Required qualified outcome evidence has not
yet been obtained.
CONFIRMED_NON_EFFECT: Suitable evidence establishes absence of the
specified effect.
CONFIRMED_PARTIAL_EFFECT: A defined subset of the intended effects
occurred.
CONFIRMED_COMPLETED_EFFECT: The specified earlier consequence
occurred.
OUTCOME_UNCERTAIN: The actual effectuation outcome remains
unresolved.
EVIDENCE_CONFLICT: Available qualified observations are inconsistent.
RECOVERY_ELIGIBILITY_PENDING: Applicable recovery authority is being
evaluated.
RECOVERY_MODE_SELECTED: A bounded recovery mode has been established.
RECOVERY_CANDIDATE_PREPARED: A proposed corrective operation exists.
RECOVERY_NON_EFFECTIVE: The corrective operation remains withheld.
RECOVERY_RESERVATION_PENDING: Required resources or authority are
being reserved.
RECOVERY_AUTHORITY_PREPARED: Valid scoped recovery enablement exists.
RECOVERY_FINALITY_PENDING: The actual operation awaits sink
verification.
RECOVERY_EFFECT_ATTEMPTED: The corrective operation has been
initiated.
RECOVERY_EFFECT_CONFIRMED: Qualified evidence establishes the
specified corrective result.
Das Expires 29 April 2027 [Page 153]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
RECOVERY_EFFECT_UNCERTAIN: The corrective effect outcome cannot be
safely determined.
RECOVERY_AUTHORITY_CONSUMED: The applicable corrective authority has
been consumed.
5.3.3.31. Original Source — Global Page 1093
RECOVERY_RECONCILIATION_PENDING: Further evidence or bounded
corrective action is required.
RECOVERY_EXHAUSTED: Applicable automatic recovery authority has
reached its defined limit.
RECOVERY_TERMINATED: The protected recovery process has ended
according to its valid terminal conditions.
Historical completed effects are not erased by movement between
recovery states.
12.27 — PRINCIPAL END-TO-END WORKFLOW
Step 1 — Identify Original Candidate Act.
The system retrieves the original protected operation and applicable
authority.
Step 2 — Determine Effectuation Attempt State.
The protected controller identifies whether the original operation
was dispatched or otherwise presented for actual effectuation.
Step 3 — Establish Recovery Hold.
Potentially unsafe retries or corrective operations remain non-
effective.
Step 4 — Collect Outcome Evidence.
The system obtains evidence from relevant authorized sinks,
observers, and protected state.
Step 5 — Authenticate Evidence.
The verifier checks the source, integrity, role, freshness, and
supported observation scope.
Step 6 — Classify Original Outcome.
Das Expires 29 April 2027 [Page 154]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The protected system determines the supported effectuation state.
Step 7 — Preserve Uncertainty.
Where evidence is insufficient, the controller does not invent a
definitive success or failure.
Step 8 — Load Recovery Authority Envelope.
The applicable permitted recovery modes and effect limits are
established.
Step 9 — Verify Recovery Eligibility.
5.3.3.32. Original Source — Global Page 1094
The selected recovery mode must be supported by the original outcome
and current authority.
Step 10 — Select Recovery Branch.
The protected controller prevents conflicting recovery strategies
where required.
Step 11 — Reconstruct Current Resource State.
Relevant target identities, versions, and external conditions are
obtained.
Step 12 — Construct Recovery Candidate Act.
The recovery planner proposes the corrective operation.
Step 13 — Verify Correspondence.
The proposed operation is evaluated against the supported original
effect and recovery envelope.
Step 14 — Verify Scope.
The correction must remain within applicable current authority.
Step 15 — Reserve Recovery State.
A protected reservation or generation transition establishes
conditional eligibility.
Step 16 — Prepare Scoped Non-Bearer Authority.
Das Expires 29 April 2027 [Page 155]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The controller establishes recovery-specific enablement.
Step 17 — Present Corrective Operation.
The recovery requester submits its proposed actual effect.
Step 18 — Reconstruct Actual Effect.
The Recovery Finality Sink independently identifies the operation
presented at its boundary.
Step 19 — Verify Qualified Earlier-Effect Evidence.
The sink verifies the required relationship with the original
supported outcome.
Step 20 — Verify Current Resource and Authority.
The sink checks current target, state, scope, revocation, and
consumption.
Step 21 — Verify Recovery Generation.
The sink rejects stale or incompatible recovery attempts.
5.3.3.33. Original Source — Global Page 1095
Step 22 — Consume Recovery Authority.
The applicable protected authority is atomically or otherwise safely
committed.
Step 23 — Permit Corrective Consequence.
The controlled recovery effect becomes effective.
Step 24 — Record Effectuation Attempt.
The system commits qualified evidence of the recovery attempt.
Step 25 — Validate Actual Corrective Result.
Where required, an authorized observer verifies the actual outcome.
Step 26 — Update Recovery Graph.
The protected state reflects the completed, partial, or uncertain
result.
Das Expires 29 April 2027 [Page 156]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Step 27 — Evaluate Residual Effects.
Remaining obligations, constraints, or irreversible effects are
identified.
Step 28 — Authorize Successor Phase if Applicable.
A further consequential phase requires its own valid authority and
any mandatory accepted prior-effect receipt.
Step 29 — Enforce Stop Condition.
The process ends or remains contained when further automatic recovery
is not authorized.
12.28 — REFERENCE PSEUDOCODE: ORIGINAL OUTCOME CLASSIFICATION
FUNCTION CLASSIFY_ORIGINAL_EFFECT( original_candidate,
protected_outcome_verifier ): REQUIRE VERIFY_ORIGINAL_CANDIDATE_ACT(
original_candidate ) attempts = LOAD_PROTECTED_EFFECT_ATTEMPTS(
original_candidate )
5.3.3.34. Original Source — Global Page 1096
evidence = COLLECT_QUALIFIED_OUTCOME_EVIDENCE( original_candidate,
attempts ) REQUIRE VERIFY_EVIDENCE_SOURCE_IDENTITIES( evidence )
REQUIRE VERIFY_OBSERVATION_SCOPES( evidence ) REQUIRE
VERIFY_EVIDENCE_INTEGRITY( evidence ) IF
QUALIFIED_PROOF_OF_NON_EFFECT(evidence): classification =
CONFIRMED_NON_EFFECT ELSE IF
QUALIFIED_PROOF_OF_COMPLETE_EFFECT(evidence): classification =
CONFIRMED_COMPLETED_EFFECT ELSE IF
QUALIFIED_PROOF_OF_PARTIAL_EFFECT(evidence): classification =
CONFIRMED_PARTIAL_EFFECT ELSE IF
QUALIFIED_EVIDENCE_CONFLICTS(evidence): classification =
EVIDENCE_CONFLICT ELSE: classification = OUTCOME_UNCERTAIN RETURN
protected_outcome_verifier .AUTHENTICATE_CLASSIFICATION({
original_candidate: HASH(original_candidate), qualified_evidence:
HASH(evidence), classification: classification, recovery_epoch:
CURRENT_RECOVERY_EPOCH() })
A timeout alone cannot satisfy the confirmed-non-effect predicate.
5.3.3.35. Original Source — Global Page 1097
12.29 — REFERENCE PSEUDOCODE: RECOVERY ELIGIBILITY
Das Expires 29 April 2027 [Page 157]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
FUNCTION VERIFY_RECOVERY_ELIGIBILITY( original_candidate,
effect_classification, proposed_recovery_mode, recovery_envelope ):
REQUIRE VERIFY_ORIGINAL_AUTHORITY( original_candidate ) REQUIRE
VERIFY_EFFECT_CLASSIFICATION( effect_classification ) REQUIRE
VERIFY_RECOVERY_ENVELOPE( recovery_envelope ) REQUIRE
RECOVERY_MODE_PERMITTED( proposed_recovery_mode, recovery_envelope )
IF proposed_recovery_mode == RETRY: REQUIRE VERIFIED_RETRY_SAFETY(
effect_classification, recovery_envelope ) IF proposed_recovery_mode
== COMPENSATE: REQUIRE COMPENSATION_CAUSALLY_SUPPORTED(
effect_classification, recovery_envelope ) IF proposed_recovery_mode
== FORWARD_COMPLETE: REQUIRE REQUIRED_PRIOR_EFFECTS_ESTABLISHED(
effect_classification ) IF proposed_recovery_mode == CONTAIN: REQUIRE
VERIFY_CONTAINMENT_SCOPE( recovery_envelope )
5.3.3.36. Original Source — Global Page 1098
REQUIRE CURRENT_RECOVERY_AUTHORITY_VALID() REQUIRE
RECOVERY_BUDGET_AVAILABLE() RETURN ELIGIBLE_FOR_CANDIDATE_PREPARATION
Eligibility does not itself release a consequential operation.
12.30 — REFERENCE PSEUDOCODE: RECOVERY CANDIDATE PREPARATION
FUNCTION PREPARE_RECOVERY_CANDIDATE( original_candidate,
qualified_outcome, recovery_plan, protected_recovery_controller ):
REQUIRE VERIFY_QUALIFIED_OUTCOME( qualified_outcome ) REQUIRE
VERIFY_PLAN_IS_WITHIN_RECOVERY_ENVELOPE( recovery_plan,
original_candidate ) actual_targets =
RESOLVE_CURRENT_RESOURCE_IDENTITIES( recovery_plan ) current_state =
OBSERVE_RELEVANT_CURRENT_RESOURCE_STATE( actual_targets ) REQUIRE
VERIFY_RECOVERY_TARGET_CORRESPONDENCE( original_candidate,
qualified_outcome, actual_targets ) REQUIRE
VERIFY_CURRENT_STATE_COMPATIBILITY( recovery_plan, current_state )
candidate = CONSTRUCT_DISTINCT_RECOVERY_CANDIDATE({ original:
original_candidate,
5.3.3.37. Original Source — Global Page 1099
qualified_outcome: qualified_outcome, recovery_plan: recovery_plan,
current_targets: actual_targets, current_state: current_state,
recovery_generation: NEXT_PROTECTED_RECOVERY_GENERATION() }) RETURN
protected_recovery_controller
.COMMIT_NON_EFFECTIVE_RECOVERY_CANDIDATE( candidate )
12.31 — REFERENCE PSEUDOCODE: RECOVERY RESERVATION
Das Expires 29 April 2027 [Page 158]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
FUNCTION RESERVE_RECOVERY_EFFECT( recovery_candidate,
protected_recovery_controller ): REQUIRE VERIFY_RECOVERY_CANDIDATE(
recovery_candidate ) REQUIRE VERIFY_CURRENT_RECOVERY_ENVELOPE(
recovery_candidate ) REQUIRE VERIFY_RECOVERY_BRANCH_ELIGIBILITY(
recovery_candidate ) REQUIRE VERIFY_RECOVERY_BUDGET(
recovery_candidate ) REQUIRE VERIFY_CURRENT_RESOURCE_CONDITIONS(
recovery_candidate ) reservation = protected_recovery_controller
5.3.3.38. Original Source — Global Page 1100
.ATOMIC_COMPARE_AND_RESERVE({ original_effect:
recovery_candidate.original_reference, recovery_candidate:
HASH(recovery_candidate), expected_recovery_generation:
CURRENT_RECOVERY_GENERATION(), selected_recovery_branch:
recovery_candidate.branch, permitted_corrective_scope:
recovery_candidate.effect_scope, budget_charge:
recovery_candidate.required_allowance, designated_sink:
recovery_candidate.finality_sink }) IF reservation != COMMITTED:
RETURN HOLD_OR_RECONCILE RETURN reservation
The protected controller must ensure that incompatible recovery
branches cannot simultaneously consume the same exclusive authority.
12.32 — REFERENCE PSEUDOCODE: RECOVERY FINALITY
FUNCTION EFFECTUATE_RECOVERY( recovery_candidate, recovery_authority,
recovery_finality_sink ): actual_operation = recovery_finality_sink
.RECONSTRUCT_ACTUAL_PENDING_OPERATION() IF actual_operation IS NULL:
RETURN DENY REQUIRE recovery_finality_sink
.VERIFY_ORIGINAL_EFFECT_REFERENCE( recovery_candidate )
5.3.3.39. Original Source — Global Page 1101
REQUIRE recovery_finality_sink
.VERIFY_REQUIRED_QUALIFIED_EFFECT_EVIDENCE( recovery_candidate )
REQUIRE recovery_finality_sink .VERIFY_RECOVERY_MODE_AND_SCOPE(
actual_operation, recovery_candidate ) REQUIRE recovery_finality_sink
.VERIFY_ACTUAL_TARGET_RESOURCE( actual_operation ) REQUIRE
recovery_finality_sink .VERIFY_CURRENT_RESOURCE_STATE() REQUIRE
recovery_finality_sink .VERIFY_CURRENT_RECOVERY_GENERATION(
recovery_authority ) REQUIRE recovery_finality_sink
.VERIFY_RECOVERY_BRANCH_AND_RESERVATION( recovery_authority ) REQUIRE
recovery_finality_sink .VERIFY_AUTHORITY_AND_REVOCATION() REQUIRE
recovery_finality_sink .VERIFY_NON_BEARER_AUTHORITY(
recovery_authority, actual_operation ) REQUIRE recovery_finality_sink
.VERIFY_RECOVERY_CONSUMPTION_STATE() consumption =
recovery_finality_sink .ATOMIC_CONSUME_RECOVERY_AUTHORITY(
recovery_authority, actual_operation ) IF consumption != SUCCESS:
Das Expires 29 April 2027 [Page 159]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
RETURN DENY
5.3.3.40. Original Source — Global Page 1102
attempt = recovery_finality_sink .EFFECTUATE_CORRECTIVE_OPERATION(
actual_operation ) COMMIT_PROTECTED_RECOVERY_ATTEMPT( attempt,
consumption ) RETURN attempt
The local attempt result must not be misrepresented as proof of
complete remote success.
12.33 — REFERENCE PSEUDOCODE: UNCERTAIN OUTCOME RETRY
FUNCTION AUTHORIZE_RECOVERY_RETRY( original_attempt,
protected_retry_controller ): outcome =
LOAD_CURRENT_QUALIFIED_OUTCOME( original_attempt ) IF outcome ==
CONFIRMED_COMPLETED_EFFECT: RETURN DENY_DUPLICATE_EFFECT IF outcome
== CONFIRMED_NON_EFFECT: RETURN EVALUATE_NEW_RETRY_AUTHORITY() IF
outcome == OUTCOME_UNCERTAIN: destination_guarantee =
VERIFY_DESTINATION_DUPLICATE_SUPPRESSION( original_attempt ) IF
destination_guarantee != SUFFICIENT:
ESTABLISH_RETRY_FENCE(original_attempt) RETURN
REQUIRE_OUTCOME_RECONCILIATION REQUIRE
VERIFY_EXACT_OPERATION_IDENTITY( original_attempt ) REQUIRE
VERIFY_PARAMETER_BINDING( original_attempt )
5.3.3.41. Original Source — Global Page 1103
REQUIRE VERIFY_DESTINATION_RETENTION_CONDITIONS() RETURN
PREPARE_BOUNDED_IDEMPOTENT_RETRY() RETURN
APPLY_PROTECTED_RECOVERY_POLICY()
The result depends upon the actual destination's duplicate-
suppression properties.
12.34 — REFERENCE PSEUDOCODE: COMPENSATION
Das Expires 29 April 2027 [Page 160]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
FUNCTION AUTHORIZE_COMPENSATING_EFFECT( original_effect,
proposed_compensation, protected_compensation_controller ):
qualified_result = VERIFY_ACTUAL_ORIGINAL_EFFECT( original_effect )
REQUIRE qualified_result .SUPPORTS_REQUESTED_COMPENSATION() REQUIRE
VERIFY_COMPENSATION_AUTHORITY( proposed_compensation ) REQUIRE
VERIFY_COMPENSATION_CORRESPONDENCE( qualified_result,
proposed_compensation ) current_state =
OBSERVE_CURRENT_COMPENSATION_TARGET( proposed_compensation ) REQUIRE
VERIFY_CURRENT_STATE_COMPATIBILITY( current_state,
proposed_compensation ) REQUIRE VERIFY_COMPENSATION_LIMITS(
proposed_compensation ) REQUIRE
VERIFY_COMPENSATION_NOT_ALREADY_CONSUMED( original_effect
5.3.3.42. Original Source — Global Page 1104
) RETURN protected_compensation_controller
.PREPARE_NON_EFFECTIVE_COMPENSATION( proposed_compensation,
qualified_result, current_state )
The prepared compensation is subsequently subject to actual Finality-
Sink authorization.
12.35 — REFERENCE PSEUDOCODE: RECOVERY TERMINATION
FUNCTION EVALUATE_RECOVERY_TERMINATION( recovery_workflow,
protected_recovery_controller ): effects =
LOAD_QUALIFIED_RECOVERY_EFFECTS( recovery_workflow ) unresolved =
IDENTIFY_UNRESOLVED_RECOVERY_EFFECTS( effects ) IF unresolved NOT
EMPTY: RETURN KEEP_RELEVANT_RETRY_FENCES residuals =
CLASSIFY_RESIDUAL_CONSEQUENCES( recovery_workflow, effects ) REQUIRE
VERIFY_CURRENT_RECOVERY_STOP_POLICY( recovery_workflow ) IF
REQUIRED_OBJECTIVE_SATISFIED( effects, residuals ): RETURN
protected_recovery_controller
.ATOMIC_TERMINATE_AND_REVOKE_UNUSED_AUTHORITY( recovery_workflow ) IF
AUTOMATIC_RECOVERY_BUDGET_EXHAUSTED():
5.3.3.43. Original Source — Global Page 1105
RETURN ESCALATE_UNRESOLVED_RECOVERY_STATE RETURN
REQUIRE_SEPARATELY_AUTHORIZED_NEXT_PHASE
Termination does not imply that all earlier real-world effects have
been erased.
12.36 — WORKED EXAMPLE A: REMOTE PAYMENT ACKNOWLEDGEMENT LOST
An autonomous financial assistant is authorized to initiate one
bounded payment.
Das Expires 29 April 2027 [Page 161]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The payment request is transmitted to the designated transaction
service.
The communication connection fails before the assistant receives the
response.
The assistant cannot determine whether the payment occurred.
A conventional recovery procedure might immediately resend the
payment.
Under the present embodiment, the protected controller classifies the
earlier outcome as unresolved.
It maintains the original operation identity and establishes a retry
fence.
A qualified transaction-status check or other supported mechanism
attempts to determine the actual payment state.
If the payment is confirmed completed, another payment is not
automatically authorized.
If non-effectuation is confirmed, a bounded new attempt may be
considered.
If the destination supports a sufficient operation-bound idempotency
mechanism, a carefully constrained retry may be authorized according
to its actual guarantee.
The payment Finality Sink verifies the current retry-specific
authority and actual transaction parameters.
Expected demonstrable result: A missing acknowledgement alone does
not permit a second independent payment.
12.37 — WORKED EXAMPLE B: INVENTORY RESERVED, PAYMENT FAILED
An autonomous purchasing workflow reserves a specified quantity of
goods.
The protected resource controller confirms the inventory reservation.
5.3.3.44. Original Source — Global Page 1106
The subsequent payment phase fails before completing a payment.
Das Expires 29 April 2027 [Page 162]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The recovery planner proposes releasing the earlier inventory
reservation.
The system obtains qualified evidence that the inventory reservation
actually occurred.
It verifies that the proposed release corresponds to the same
reservation and current resource state.
A bounded compensation Candidate Act is created.
The inventory Finality Sink checks the protected compensation
authority and current reservation generation.
The release is performed only once.
If another authorized workflow has legitimately transformed the
reservation state, the recovery controller reevaluates the corrective
effect rather than blindly applying a stale inverse update.
Expected demonstrable result: The compensation is tied to an actually
established reservation and cannot be repeated or redirected without
valid authority.
12.38 — WORKED EXAMPLE C: PAYMENT COMPLETED, SHIPPING FAILED
An autonomous commerce workflow successfully executes a payment.
A later delivery or shipping instruction fails.
The recovery controller receives qualified evidence that the payment
occurred.
The system may permit either a bounded refund or a separately
authorized forward-completion procedure, depending upon current
authority and recovery policy.
The two recovery branches may be mutually incompatible.
The protected controller records the selected branch and prevents
simultaneous unauthorized execution of both.
If refund is selected, a new refund Candidate Act is created.
The refund sink verifies the actual recipient, original payment
reference, amount, and recovery consumption state.
A refund does not mean that the original payment never occurred.
Das Expires 29 April 2027 [Page 163]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Expected demonstrable result: Recovery cannot use the original
payment authorization to issue unlimited refunds or duplicate
corrective payments.
5.3.3.45. Original Source — Global Page 1107
12.39 — WORKED EXAMPLE D: IRREVERSIBLE INFORMATION DISCLOSURE
An autonomous assistant transmits a protected document to an external
recipient.
The system subsequently determines that the disclosure was not
authorized.
The original information release has already occurred.
The recovery controller may propose revoking future access, rotating
exposed credentials, requesting deletion, or sending a bounded
notification.
However, the controller does not classify such actions as complete
reversal of the earlier disclosure.
Each consequential corrective operation requires appropriate current
authority.
The actual credential-revocation or communication sink verifies the
corresponding Recovery Candidate Act.
The system records residual information-exposure risk.
Expected demonstrable result: Recovery does not falsely treat an
irreversible information disclosure as technically undone.
12.40 — WORKED EXAMPLE E: FILE OVERWRITE FOLLOWED BY INTERVENING
CHANGES
An autonomous coding agent overwrites a protected configuration file.
The original modification completes.
Another authorized administrator subsequently makes a legitimate
change to the same file.
An error detector later recommends restoring the file to its earlier
version.
Das Expires 29 April 2027 [Page 164]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Blind restoration would remove the administrator's intervening valid
modification.
The recovery controller obtains qualified evidence of the original
write and the current file version.
It constructs a proposed corrective mutation that preserves
applicable intervening changes where technically feasible.
If safe correction cannot be established, the system withholds
automatic restoration and requires appropriate authority.
5.3.3.46. Original Source — Global Page 1108
The file-system Finality Sink verifies current resource identity,
content, version, and protected recovery scope.
Expected demonstrable result: A recovery operation cannot overwrite
later legitimate state merely by relying on an earlier snapshot.
12.41 — WORKED EXAMPLE F: PHYSICAL ACTUATOR PARTIALLY COMPLETED
An autonomous robotic controller issues an authorized movement
command.
The actuator begins moving.
A controller fault occurs before the intended endpoint is reached.
The system does not assume that the actuator remains at its initial
position.
Qualified sensors or device-controller evidence establish the
supported current physical state.
A protected recovery controller determines whether movement
completion, safe stopping, repositioning, or another bounded
operation is permitted.
The selected corrective command becomes a distinct Recovery Candidate
Act.
The actuator Finality Sink verifies the actual current physical
target, movement envelope, operating state, and recovery authority.
The system may prioritize a separately authenticated safe containment
condition where necessary.
Das Expires 29 April 2027 [Page 165]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Expected demonstrable result: The recovery command is based upon the
supported actual physical state rather than the original intended
trajectory alone.
12.42 — WORKED EXAMPLE G: AUTONOMOUS NETWORK CONFIGURATION FAILURE
An autonomous network controller applies part of a multi-device
configuration update.
Some network devices confirm the specified state changes.
Other devices become unreachable.
The recovery system reconstructs the supported device-specific
configuration state.
It distinguishes confirmed changes from unknown outcomes.
5.3.3.47. Original Source — Global Page 1109
A recovery planner proposes a permitted restoration or forward-
completion strategy.
Each device command remains associated with its own actual resource
identity and applicable authority.
A network Finality Sink checks the current configuration and
recovery-specific enablement.
The controller does not broadcast an unrestricted rollback command
based only upon the original workflow's failed status.
Expected demonstrable result: Recovery operates upon verified or
conservatively classified device state rather than a single ambiguous
workflow error.
12.43 — WORKED EXAMPLE H: COMPROMISED RECOVERY AGENT
An autonomous recovery agent receives a failure notification.
The agent proposes transferring unrelated data to an external
service, claiming the transfer is necessary for diagnosis.
The protected recovery envelope permits only specified status queries
and bounded corrective operations.
The proposed data export is outside that envelope.
Das Expires 29 April 2027 [Page 166]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The Data-Release Finality Sink verifies the actual information and
destination.
The unauthorized recovery disclosure remains non-effective.
A separate appropriate authorization would be required before such an
export could proceed.
Expected demonstrable result: The label "recovery" does not grant the
agent unrestricted information-export or execution authority.
12.44 — WORKED EXAMPLE I: SNAPSHOT RESTORES CONSUMED RECOVERY
AUTHORITY
A virtualized recovery worker prepares and executes a valid
corrective operation.
The protected recovery authority is consumed.
The worker subsequently restarts from a snapshot created before the
compensation.
Its local memory contains the earlier valid-looking authority
reference.
5.3.3.48. Original Source — Global Page 1110
The worker attempts to repeat the corrective operation.
The Recovery Finality Sink checks authoritative protected recovery-
generation and consumption state.
The old authority is rejected.
Expected demonstrable result: Restoring computational state does not
resurrect already consumed recovery authority.
12.45 — WORKED EXAMPLE J: TWO AGENTS INITIATE THE SAME COMPENSATION
Two autonomous agents independently detect the same workflow failure.
Both propose refunding the same completed transaction.
The protected recovery controller associates both requests with the
same original effect and applicable recovery branch.
A protected reservation permits only the authorized corrective
transaction under the defined exclusivity rule.
Das Expires 29 April 2027 [Page 167]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The losing request is withheld or reconciled.
The actual refund sink verifies the original payment reference and
current compensation-consumption state.
Expected demonstrable result: Multiple recovery agents cannot
independently produce duplicate compensation through the governed
protected sink.
12.46 — WORKED EXAMPLE K: CAUSAL MULTI-PHASE RECOVERY
A protected workflow requires a completed resource restoration before
a dependent service may be reactivated.
The restoration Candidate Act is authorized and effectuation occurs
through its designated sink.
An authorized Interim Effectuation Validator obtains qualified
evidence concerning the actual restoration result.
The validator possesses the required enrolled cryptographic identity.
The protected system accepts the actual-effect receipt under the
defined causal continuation protocol.
5.3.3.49. Original Source — Global Page 1111
A successor activation Candidate Act is then prepared.
The next Finality Sink requires both current activation authority and
the accepted restoration receipt as a constitutive enabling
condition.
An ordinary recovery log entry is insufficient.
Expected demonstrable result: Service activation cannot validly
proceed through the governed sink without the specified accepted
earlier real-effect evidence.
12.47 — WORKED EXAMPLE L: RECOVERY AFTER MODEL REPLACEMENT
An autonomous agent prepares a corrective operation using a specified
approved computational generation.
Before effectuation, the system replaces the recovery model or
decision algorithm.
The new implementation proposes a broader corrective operation.
Das Expires 29 April 2027 [Page 168]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The protected system verifies current computational-generation
authority under the applicable drift policy.
It independently checks the actual corrective effect against the
recovery envelope.
The Finality Sink rejects the expanded operation unless valid current
authority is established.
Expected demonstrable result: Model replacement does not permit an
agent to enlarge recovery authority established under an earlier
execution state.
12.48 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
12.48.1 — Timeout-as-Failure Attack
An attacker causes a communication timeout and induces a duplicate
effect.
The recovery classifier preserves uncertainty until qualified
evidence or sufficient idempotency conditions permit retry.
12.48.2 — Forged Failure Record
An attacker supplies a fabricated failure event.
The verifier requires authenticated evidence from an authorized
source.
12.48.3 — Forged Completion Record
5.3.3.50. Original Source — Global Page 1112
An attacker falsely claims that an effect completed to trigger
unauthorized compensation.
The protected system verifies qualified actual-effect evidence.
12.48.4 — Wrong Observation Scope
A local dispatch record is presented as proof of remote delivery.
The verifier checks what the evidence source actually observed.
12.48.5 — Replay of Old Outcome Evidence
An earlier valid receipt is used to authorize an unrelated recovery.
Das Expires 29 April 2027 [Page 169]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The authority remains bound to the original effect and current
recovery state.
12.48.6 — Compensation Without Original Effect
An agent attempts a refund or reversal without sufficient evidence of
the original effect.
The recovery Finality Sink rejects unsupported compensation.
12.48.7 — Double Compensation
Several recovery attempts use the same original-effect reference.
Protected branch, reservation, and consumption state prevent
unauthorized duplication.
12.48.8 — Wrong Compensation Target
A corrective operation points to a different resource or recipient.
The sink verifies actual target correspondence.
12.48.9 — Excessive Compensation Amount
The recovery agent proposes a correction exceeding the permitted
amount or quantity.
The protected envelope and Finality Sink enforce bounded scope.
12.48.10 — Recovery Branch Race
Two incompatible recovery strategies are activated simultaneously.
Protected branch exclusivity prevents conflicting grants.
12.48.11 — Retry After Completed Effect
An agent retries a command already known to have executed.
5.3.3.51. Original Source — Global Page 1113
The protected retry state rejects the unsupported duplicate.
12.48.12 — Retry Under Unknown Outcome
A remote response is lost.
Das Expires 29 April 2027 [Page 170]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The system does not equate communication uncertainty with proof of
non-execution.
12.48.13 — Idempotency-Key Substitution
An attacker reuses an operation identifier with different parameters.
The receiving controller verifies parameter and authority binding.
12.48.14 — Expired Duplicate-Suppression State
A retry occurs after the destination's idempotency record has
expired.
The protected controller requires current evidence of retry safety.
12.48.15 — Snapshot Rollback
A recovery agent restores earlier local state.
The Finality Sink verifies current protected recovery generations and
consumption.
12.48.16 — Recovery Epoch Forgery
An attacker invents a newer-looking recovery generation.
The controller requires authenticated authoritative state.
12.48.17 — Stale Recovery Branch
A previously permitted recovery strategy is exercised after the
controller selected another branch.
Current branch-state verification rejects the stale attempt.
12.48.18 — Privileged Credential Misuse
An agent requests unrestricted credentials for an allegedly necessary
correction.
The protected broker enforces recovery-specific scope.
12.48.19 — Recovery Data Exfiltration
A recovery planner attempts unauthorized disclosure of protected
diagnostic or user information.
Das Expires 29 April 2027 [Page 171]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.3.3.52. Original Source — Global Page 1114
The actual data-release boundary enforces the separate applicable
disclosure authority.
12.48.20 — Malicious Compensating Operation
A proposed correction introduces a harmful unrelated mutation.
The Finality Sink verifies the actual operation against the bounded
recovery envelope.
12.48.21 — Resource Version Drift
A resource changes after the compensation plan was prepared.
Current version and resource-state validation reject unsafe stale
correction.
12.48.22 — Resource Alias Substitution
The intended original target resolves to another resource.
Protected actual-target reconstruction detects the mismatch.
12.48.23 — Tool Semantic Change
A recovery tool acquires additional side effects through a software
update.
Current operation semantics must remain within the recovery
authority.
12.48.24 — Model Drift During Recovery
The recovery algorithm changes after approval.
Current generation-bound authority may be required before actual
correction.
12.48.25 — Partial-Effect Misclassification
A workflow with some completed effects is treated as wholly failed.
Qualified outcome classification identifies the supported partial
state.
12.48.26 — Physical-Effect Reversal Assumption
Das Expires 29 April 2027 [Page 172]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An agent assumes that reversing a device command restores the earlier
physical state.
The system evaluates actual physical conditions and irreversible
consequences.
12.48.27 — Information-Disclosure Reversal Assumption
A recovery agent treats deletion of an original message as proof that
recipients no longer possess the information.
The system preserves residual disclosure state.
5.3.3.53. Original Source — Global Page 1115
12.48.28 — Fake Recovery Validator Identity
An attacker impersonates an authorized recovery verifier.
The sink requires valid identity and role authentication.
12.48.29 — Genuine but Unauthorized Verifier
A correctly signed record originates from an entity lacking authority
for the relevant recovery decision.
The protected verifier checks the authorized role.
12.48.30 — Recovery State Rollback
A stale recovery database restores previously permitted authority.
Protected generation and consumption constraints reject unauthorized
reactivation.
12.48.31 — Recovery Budget Reset
An agent restarts or delegates recovery to avoid retry limits.
The relevant budget remains associated with the protected original
effect and authority domain.
12.48.32 — Distributed Recovery Split Brain
Two controllers believe they are authorized to compensate the same
effect.
Das Expires 29 April 2027 [Page 173]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A protected authoritative branch or reservation relationship
constrains conflicting effectuation.
12.48.33 — Evidence Suppression
An attacker conceals evidence of completed effectuation to induce
retry.
The assurance depends upon required independent evidence sources and
conservative handling of missing information.
12.48.34 — Inconsistent External Observers
Two qualified sources report incompatible outcomes.
The system classifies the evidence conflict instead of manufacturing
a convenient success state.
12.48.35 — Unbounded Recovery Recursion
A failed recovery triggers another recovery indefinitely.
5.3.3.54. Original Source — Global Page 1116
Protected recovery depth, budgets, and stop conditions bound
automatic execution.
12.48.36 — Recovery Verification Exhaustion
An attacker submits complex or malformed evidence.
Protected verification resources are bounded, and mandatory failure
does not become permission.
12.48.37 — Recovery Through Alternate Effectuation Path
An agent invokes another API or device interface.
Relevant consequential interfaces must enforce the required authority
for the claimed coverage.
12.48.38 — Compromised Recovery Planner
The planner fabricates a beneficial recovery rationale.
Protected evidence and Finality-Sink checks remain independent of its
assertion.
Das Expires 29 April 2027 [Page 174]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
12.48.39 — Compromised Finality Sink
The controlled resource interface is compromised.
A stronger guarantee requires an appropriately protected downstream
enforcement boundary.
12.48.40 — Unauthorized Corrective Escalation
An agent claims that emergency remediation requires broader actions.
Any emergency mode must be independently authenticated, technically
bounded, and subject to its defined safety conditions.
12.49 — CRASH CONSISTENCY AND RECOVERY OF RECOVERY
12.49.1 — Crash Before Original Effect
The system establishes whether the original effect crossed the
relevant consequential boundary.
12.49.2 — Crash After Original Dispatch
The corresponding external outcome may remain uncertain.
12.49.3 — Crash During Evidence Collection
5.3.3.55. Original Source — Global Page 1117
Incomplete evidence does not establish a favorable recovery outcome.
12.49.4 — Crash After Recovery Classification
Protected state preserves the authenticated classification and its
evidence references.
12.49.5 — Crash During Recovery Reservation
Authoritative state determines whether the reservation committed.
12.49.6 — Crash Before Recovery Effectuation
Current protected authority determines whether the operation may be
safely resumed.
12.49.7 — Crash During Recovery Effectuation
The actual corrective effect may be partial or uncertain.
Das Expires 29 April 2027 [Page 175]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
12.49.8 — Crash After Recovery Effectuation
The completed correction remains a real effect.
12.49.9 — Restart From Old Snapshot
Current protected generations prevent reuse of stale authority.
12.49.10 — Reconciliation
The controller reconstructs the supported current state before
permitting additional consequential recovery.
12.50 — NON-LIMITING PROPOSED FEASIBILITY EXPERIMENTS
The following experiments are proposed and are not represented as
completed results.
Experiment 1 — Confirmed Non-Effect: Verify safe retry eligibility
after qualified non-effectuation evidence.
Experiment 2 — Lost Acknowledgement: Simulate successful remote
execution with a missing response.
Experiment 3 — Unknown Outcome: Confirm that an unresolved operation
does not automatically authorize retry.
Experiment 4 — Completed Effect: Verify rejection of a duplicate
effect after confirmed completion.
5.3.3.56. Original Source — Global Page 1118
Experiment 5 — Partial Completion: Test recovery classification when
only part of a multi-effect workflow completed.
Experiment 6 — Forged Failure Evidence: Submit an unauthenticated
failure record.
Experiment 7 — Forged Completion Evidence: Submit a false record
claiming an effect occurred.
Experiment 8 — Wrong Verifier Role: Test rejection of a genuine
signature from an unauthorized verifier.
Experiment 9 — Unsupported Negative Evidence: Attempt to classify a
timeout as proof that no effect occurred.
Das Expires 29 April 2027 [Page 176]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Experiment 10 — Destination Idempotency: Test a bounded retry using
destination-supported operation identity.
Experiment 11 — Parameter Mutation: Reuse an idempotency reference
for a different amount or target.
Experiment 12 — Idempotency Expiry: Attempt retry after destination
duplicate-suppression state expires.
Experiment 13 — Valid Compensation: Compensate a qualified completed
reversible effect.
Experiment 14 — Unsupported Compensation: Attempt a correction
without evidence that the original effect occurred.
Experiment 15 — Double Compensation: Run two recovery agents
proposing the same correction.
Experiment 16 — Recovery Branch Race: Attempt simultaneous
incompatible retry and refund strategies.
Experiment 17 — Stale Recovery Generation: Present previously valid
recovery authority after state advancement.
Experiment 18 — Recovery Authority Replay: Reuse consumed recovery
enablement.
Experiment 19 — Snapshot Rollback: Restore an earlier recovery worker
snapshot.
Experiment 20 — Resource Substitution: Change the actual compensation
target after approval.
Experiment 21 — Current-State Conflict: Modify the resource after
compensation planning.
Experiment 22 — Recovery Scope Expansion: Propose a corrective effect
exceeding the protected recovery envelope.
5.3.3.57. Original Source — Global Page 1119
Experiment 23 — Credential Misuse: Request broader privileged
credentials during recovery.
Experiment 24 — Recovery Data Export: Attempt unauthorized
diagnostic-data transmission.
Das Expires 29 April 2027 [Page 177]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Experiment 25 — Irreversible Disclosure: Verify that mitigation does
not falsely clear the original disclosure record.
Experiment 26 — Partial Physical Motion: Base recovery upon qualified
actual device position.
Experiment 27 — Network Configuration Recovery: Restore selected
verified configuration changes.
Experiment 28 — Multi-Domain Partial Commit: Simulate one successful
external effect and another failed effect.
Experiment 29 — Causal Receipt Integration: Require accepted earlier
real-effect evidence before dependent recovery continuation.
Experiment 30 — Current Resource Version: Reject a stale corrective
mutation after intervening authorized changes.
Experiment 31 — Recovery Budget: Exhaust bounded retry or
compensation allowances.
Experiment 32 — Recovery Depth: Prevent unbounded recursive
compensations.
Experiment 33 — Model Replacement: Change the recovery planner or
execution model after authorization.
Experiment 34 — Tool Semantics Change: Introduce a new side effect
into a recovery API.
Experiment 35 — Device Migration: Test current recovery authority
following exclusive workload transfer.
Experiment 36 — Alternate API: Attempt correction through another
covered effectuation path.
Experiment 37 — Crash Before Compensation: Recover the protected
reservation without assuming effectuation.
Experiment 38 — Crash After Compensation: Prevent repeated
effectuation after restart.
Experiment 39 — Conflicting Observer Evidence: Verify conservative
recovery-state handling.
Experiment 40 — Evidence Work Exhaustion: Submit malformed or
excessive recovery evidence.
Das Expires 29 April 2027 [Page 178]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.3.3.58. Original Source — Global Page 1120
Experiment 41 — Human-Authorized Expansion: Obtain properly scoped
new authorization for an otherwise impermissible corrective effect.
Experiment 42 — Stop Condition: Terminate automatic recovery when
objectives or limits are reached.
Experiment 43 — One-Component Prototype: Integrate evidence
verification, authority, and finality within one protected
controller.
Experiment 44 — Distributed Prototype: Place original effectuation,
recovery authority, and corrective sink in separate authenticated
domains.
Experiment 45 — No Blockchain: Demonstrate non-replayable recovery
and evidence-qualified finality without a public distributed ledger.
Each experiment should define the threat assumptions, protected
state, actual consequence, expected result, and objective observation
criteria.
12.51 — PRESENT-DAY PHOSITA REFERENCE IMPLEMENTATION
12.51.1 — Minimum Prototype Architecture
A reference implementation may use:
Two independently operating service processes;
A protected original-operation registry;
A simulated external-effect service;
A qualified outcome verifier;
A protected recovery controller;
And a controlled corrective-operation Finality Sink.
12.51.2 — Original Operation
The originating agent submits one bounded Candidate Act to the
controlled service.
12.51.3 — Controlled Failure Injection
Das Expires 29 April 2027 [Page 179]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The prototype may deliberately interrupt the network response before
the originating agent receives acknowledgement.
12.51.4 — Qualified Outcome State
5.3.3.59. Original Source — Global Page 1121
The controlled service retains protected evidence identifying whether
the operation committed.
12.51.5 — Recovery Classification
The authorized verifier reconstructs the supported outcome.
12.51.6 — Recovery Envelope
The prototype defines permitted retries, compensations, and current
target constraints.
12.51.7 — Recovery Candidate
The recovery planner proposes a distinct corrective operation.
12.51.8 — Finality Gate
The corrective resource gateway verifies current authority and
original-effect correspondence.
12.51.9 — Protected Consumption
An authoritative state store prevents repeated unauthorized exercise
of the corrective authority.
12.51.10 — Adversarial Tests
The prototype may introduce duplicated messages, stale state, forged
receipts, wrong targets, and model-generated scope expansion.
12.51.11 — Present-Day Components
The implementation may use transactional databases, authenticated
service identities, cryptographic signatures, controlled APIs,
protected resource versions, and available isolation mechanisms.
12.51.12 — Hardware Extension
Das Expires 29 April 2027 [Page 180]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A stronger implementation may place the finality control within a
protected device, storage controller, credential service, or
independently enforced hardware boundary.
12.51.13 — Experimental Limitation
A successful software prototype establishes feasibility under its
stated trust model.
It does not independently establish universal safety against
compromise of every privileged component.
5.3.3.60. Original Source — Global Page 1122
12.52 — PERFORMANCE, AVAILABILITY, AND RECOVERY ENGINEERING
12.52.1 — Qualified Evidence Caching
Recent authenticated effect evidence may be reused where its
identity, scope, and freshness remain valid.
12.52.2 — Recovery Fast Path
Where the earlier effect is definitively known and recovery is
narrowly authorized, compact protected verification may permit
efficient execution.
12.52.3 — Uncertain Outcome Slow Path
Ambiguous external outcomes may require additional observation or
manual escalation.
12.52.4 — Resource-Bounded Verification
Expensive reconciliation or evidence validation may be limited by
protected work budgets.
12.52.5 — Retry Backoff
The system may apply controlled delay or rate limits without treating
delay as proof of non-execution.
12.52.6 — Recovery Admission Control
Excessive simultaneous recoveries may be restricted to protect
availability.
12.52.7 — Durable State
Das Expires 29 April 2027 [Page 181]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Authoritative consumption and recovery-generation state may require
persistent protected storage.
12.52.8 — Distributed Coordination
Multiple recovery controllers may require suitable shared state or
bounded authority partitioning.
12.52.9 — Partial-Service Availability
The system may permit observation-only investigation while
consequential recovery remains withheld.
12.52.10 — Human Escalation
A bounded protected workflow may request new authority where
automatic recovery cannot safely proceed.
12.52.11 — External-System Limitations
5.3.3.61. Original Source — Global Page 1123
A third-party system lacking duplicate suppression or qualified
outcome observation may limit the achievable recovery guarantee.
12.52.12 — Assurance Statement
An implementation should distinguish properties it directly enforces
from outcomes dependent upon remote systems, physical processes, or
unobservable effects.
12.53 — OPTIONAL ADVANCED FUTURE-ORIENTED CONCEPTS
12.53.1 — Multi-Provider Autonomous Recovery
Independent autonomous-agent providers may cooperate in a recovery
workflow while retaining source-derived bounded recovery authority.
12.53.2 — Long-Running Agent Recovery
A task may operate across sessions, model replacements, and
infrastructure changes while preserving its authoritative recovery
state.
12.53.3 — Confidential Computing Recovery
Das Expires 29 April 2027 [Page 182]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A protected computation environment may create authenticated effect
evidence while corrective external operations remain separately
governed.
12.53.4 — Cross-Cloud Compensation
A recovery protocol may coordinate qualified partial effects across
several cloud environments.
12.53.5 — Protected Agent Swarm Recovery
Multiple agents may investigate or plan recovery while only
authorized mutually compatible recovery branches become effective.
12.53.6 — Hardware Command Recovery
An effect-capable device may provide protected evidence concerning
command acceptance, dispatch, and actual completion.
12.53.7 — Robotic Physical-State Recovery
A robotic controller may combine qualified sensor observations with
bounded safe corrective authority.
12.53.8 — Autonomous Vehicle Recovery
5.3.3.62. Original Source — Global Page 1124
A controller may apply independently authorized contingency commands
under current physical-state and safety constraints.
12.53.9 — Industrial Control Recovery
Protected equipment may distinguish restoration of command state from
restoration of physical process state.
12.53.10 — Telecommunications Recovery
Autonomous network controllers may reconcile partially applied
configuration changes across several devices.
12.53.11 — Satellite and Remote Systems
Intermittently connected devices may retain protected recovery state
and bounded offline authority until reconciliation becomes possible.
12.53.12 — Neural Accelerator Recovery
Das Expires 29 April 2027 [Page 183]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An accelerator may require protected command-state evidence before
replaying a partially completed computational effect.
12.53.13 — Distributed Resource Escrow
Protected recovery allowances may be partitioned into nonoverlapping
budgets for separate domains.
12.53.14 — Privacy-Preserving Recovery Proofs
A verifier may establish selected recovery eligibility predicates
without disclosing all protected transaction contents.
12.53.15 — Cryptographic Algorithm Migration
Recovery evidence authentication may migrate among suitable
cryptographic primitives.
12.53.16 — Continuous Model Updates
Recovery authority may remain tied to current model or algorithm
generations.
12.53.17 — Persistent Autonomous Memory
Recovered agents may access previous task context without reviving
consumed consequential authority.
12.53.18 — Future Device-to-Device Effects
Peer-connected hardware systems may require protected recovery
authorization for direct resource commands.
5.3.3.63. Original Source — Global Page 1125
12.53.19 — Dynamic Recovery Policy Evolution
A policy update may alter future recovery eligibility while
preserving the actual history of earlier effects.
12.53.20 — Unified Protected Recovery-Finality Infrastructure
A shared protected service may provide actual-effect classification,
bounded recovery authority, non-replayable state, and effectuation-
time verification across heterogeneous autonomous systems.
These future-oriented variations are technical proposals, not
statements of completed implementations.
Das Expires 29 April 2027 [Page 184]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
12.54 — OPTIONAL ADVANCED TECHNICAL COMBINATIONS
12.54.1 — Qualified Outcome Plus Recovery Finality
A corrective operation becomes effective only when the Finality Sink
verifies the required qualified earlier-effect evidence.
12.54.2 — Non-Effectuation Evidence Plus Retry
A bounded retry is authorized only upon sufficient proof of non-
effectuation or another verified retry-safe condition.
12.54.3 — Actual Effect Plus Compensation
A compensating operation is bound to the supported original effect
and its current resource state.
12.54.4 — Recovery Branch Plus Non-Bearer Authority
Incompatible recovery modes are restricted through protected branch
selection and operation-specific consumption.
12.54.5 — Recovery Epoch Plus Snapshot Protection
Restored computational state cannot recreate previously consumed
corrective authority.
12.54.6 — Causal Receipt Plus Successor Recovery
A dependent corrective phase requires the accepted actual-effect
receipt of an earlier completed phase.
12.54.7 — Resource Version Plus Compensation
5.3.3.64. Original Source — Global Page 1126
A corrective mutation is conditioned upon current authoritative
resource state rather than a stale pre-failure snapshot.
12.54.8 — Device Ownership Plus Recovery
A corrective hardware command requires current exclusive device
authority as well as recovery-specific authorization.
12.54.9 — Model Drift Plus Recovery Revalidation
A changed recovery algorithm triggers current verification before
protected corrective effectuation.
Das Expires 29 April 2027 [Page 185]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
12.54.10 — Privacy Continuity Plus Recovery
Diagnostic or corrective information releases remain subject to
applicable cumulative privacy constraints.
12.54.11 — Bounded Work Plus Recovery Authority
The recovery system enforces a protected budget over external
attempts and computational resources.
12.54.12 — Multiple Outcome Witnesses Plus Recovery Scope
Qualified observations from distinct authorized sources may be
combined to support a particular bounded recovery decision.
12.55 — PROPOSED INVENTIVE-STEP ANALYSIS
12.55.1 — Established Prior Art
Compensating transactions, distributed sagas, retry policies,
idempotency mechanisms, transaction logs, checkpoint recovery, and
distributed workflow orchestration are established technical areas.
The embodiment does not claim those mechanisms individually.
12.55.2 — Candidate Objective Technical Problem
A candidate objective technical problem is:
How to prevent an autonomous recovery process from producing
unauthorized, duplicated, or causally unsupported external corrective
effects after an earlier operation has completed, partially
completed, failed, or become uncertain, while preserving current
resource and authority constraints at the actual corrective
effectuation boundary.
5.3.3.65. Original Source — Global Page 1127
12.55.3 — Candidate Technical Solution
The proposed combination comprises:
Authenticated original-operation state;
Qualified actual-effect evidence;
Protected outcome classification;
Das Expires 29 April 2027 [Page 186]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A bounded recovery envelope;
A separate recovery-specific Candidate Act;
Protected recovery branch and generation state;
Operation-specific non-bearer corrective authority;
And independent actual-operation verification at the Recovery
Finality Sink.
12.55.4 — Technical Interaction
The original Candidate Act identifies the initially authorized
consequence.
Qualified effect evidence establishes the supported real outcome.
The recovery verifier determines which corrective modes are eligible.
The recovery envelope limits permissible new effects.
The recovery Candidate Act represents the specific proposed
correction.
Protected recovery-generation state prevents stale or repeated
exercise.
The Finality Sink verifies the actual pending operation and relevant
earlier-effect evidence.
The sink consumes the authority and controls the corrective effect.
Each relationship addresses a separate failure mode that can arise
when an autonomous system attempts to recover from an earlier
consequential operation.
12.55.5 — Not Merely a Saga
A saga may organize forward and compensating transactions.
The proposed stronger relationship requires recovery-specific
consequential authority to be verified against the supported actual
original effect and current protected state at the corrective
resource boundary.
12.55.6 — Not Merely Idempotency
Das Expires 29 April 2027 [Page 187]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.3.3.66. Original Source — Global Page 1128
Idempotency may suppress repeated execution of identical operations
under specified destination guarantees.
It does not independently establish permission for a new compensating
or mitigating operation.
12.55.7 — Not Merely Error Handling
A software exception may initiate recovery planning.
It does not automatically establish the actual external outcome or
valid corrective scope.
12.55.8 — Not Merely a Signed Log
A signed record may authenticate a report.
It does not establish a stronger real-effect conclusion than the
reporting source supports.
12.55.9 — Not Merely Human Approval
A human may validly authorize a bounded recovery.
The actual effectuation boundary still verifies the requested
operation against the current protected authority.
12.55.10 — Candidate Narrow Inventive Kernel
A potentially significant technical combination is:
A protected autonomous recovery system in which a prior consequential
operation is classified using qualified actual-effect evidence, a
recovery-specific Candidate Act is bound to the supported effect
state and a protected bounded recovery envelope, and a Recovery
Finality Sink independently reconstructs the actual proposed
corrective effect and refuses effectuation unless the required
earlier-effect correspondence, current authority, resource state,
non-replayable recovery generation, and sink-local consumption
conditions are satisfied.
12.55.11 — Additional Narrow Kernel: Unknown Outcome
Das Expires 29 April 2027 [Page 188]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An additional candidate may require a protected retry fence
preventing a new non-idempotent effect when the original effect
remains uncertain, except under verified destination-specific
duplicate-suppression conditions or qualified non-effectuation
evidence.
12.55.12 — Additional Narrow Kernel: Compensation
Another candidate may require a compensation to be separately
authorized by evidence of an actual completed original effect,
current target-state validation, and non-replayable compensation-
specific finality authority.
12.55.13 — Additional Narrow Kernel: Causal Recovery
5.3.3.67. Original Source — Global Page 1129
Another candidate may require an accepted authenticated earlier
actual-effect receipt as a necessary enabling condition for a
successor corrective operation.
12.55.14 — Additional Narrow Kernel: Irreversible Effects
Another candidate may distinguish reversible and irreversible
consequences and condition permitted recovery on an explicitly
authorized mitigation effect rather than a fictitious restoration of
original state.
12.55.15 — Hindsight Considerations
An inventive-step analysis should determine whether the closest
relevant prior art already teaches or makes obvious the proposed
relationship among qualified actual-effect evidence, recovery-
specific authorization, protected replay state, and independent sink-
side corrective-effect enforcement.
Merely adding an ordinary authorization check to an existing saga may
be obvious in some circumstances.
A stronger technical distinction should therefore identify the
specific mandatory causal and state dependencies preventing a
demonstrable unauthorized recovery effect.
12.55.16 — Patentability Qualification
Terminology such as protected recovery, receipt, compensation
authority, or Finality Sink does not independently establish novelty.
Das Expires 29 April 2027 [Page 189]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The patentability of a selected combination depends upon its precise
claim limitations, relevant prior art, technical contribution, and
enabling disclosure.
12.56 — INDUSTRIAL APPLICABILITY
12.56.1 — Enterprise Autonomous Agents
Enterprise agents may recover from failed tool operations without
automatically obtaining unrestricted corrective authority.
12.56.2 — Cloud Infrastructure
Cloud workloads may reconcile partially completed resource changes
under protected recovery state.
12.56.3 — Distributed Microservices
Several services may execute bounded corrective transactions
supported by qualified effect evidence.
12.56.4 — Financial Transactions
5.3.3.68. Original Source — Global Page 1130
Payment and account systems may distinguish uncertain outcomes from
confirmed failure before authorizing retry or refund.
12.56.5 — Electronic Commerce
Ordering, inventory, payment, and delivery workflows may require
protected compensation and branch-exclusivity controls.
12.56.6 — Database Systems
Database recovery may be associated with current authority and actual
mutation state.
12.56.7 — File and Document Platforms
Autonomous document-editing agents may perform version-safe
restoration without overwriting later legitimate changes.
12.56.8 — Autonomous Coding
Coding agents may repair failed deployments under protected effect,
scope, and credential constraints.
Das Expires 29 April 2027 [Page 190]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
12.56.9 — Storage Infrastructure
Storage services may distinguish committed, partially committed, and
unresolved operations.
12.56.10 — Telecommunications
Network controllers may reconcile partially applied configuration
changes across independent devices.
12.56.11 — Industrial Automation
Protected industrial controllers may authorize safe corrective
operations according to actual physical and operational state.
12.56.12 — Robotics
Robotic recovery may use qualified sensor evidence and bounded
actuation authority.
12.56.13 — Autonomous Vehicles
Protected controller recovery may distinguish completed physical
actions from pending or failed computational commands.
12.56.14 — Medical and Laboratory Devices
Controlled equipment may perform bounded recovery operations under
appropriate current device state and independently established
authority.
5.3.3.69. Original Source — Global Page 1131
12.56.15 — Confidential Computing
Recovery may preserve protected evidence and independent external
effectuation authority across confidential execution boundaries.
12.56.16 — Hardware Accelerators
Accelerator workloads may reconcile command completion and resource
state following faults.
12.56.17 — Edge Computing
Distributed edge devices may maintain bounded recovery authority
under intermittent communication.
Das Expires 29 April 2027 [Page 191]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
12.56.18 — Satellite and Remote Equipment
Remote controllers may avoid unsupported repeated effects where
acknowledgements are delayed or unavailable.
12.56.19 — Information Security
Containment, credential rotation, and corrective communications may
remain subject to operation-specific recovery authorization.
12.56.20 — Future Autonomous Infrastructure
The architecture may govern corrective effects across evolving multi-
agent, multimodal, heterogeneous hardware, and distributed autonomous
computing systems.
The industrial utility resides in separating recovery computation
from authority to produce an actual corrective consequence.
12.57 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
12.57.1 — Candidate Independent System Claim
A candidate system may comprise:
A protected original-operation record controller;
An outcome-evidence verifier configured to classify the supported
actual result of an earlier consequential operation;
A recovery-authority controller configured to establish a bounded
recovery envelope;
A Recovery Candidate Act constructor configured to represent a
proposed corrective effect separately from the original operation;
5.3.3.70. Original Source — Global Page 1132
A protected recovery-generation and consumption controller;
And a Recovery Finality Sink configured to reconstruct the actual
pending corrective operation, verify the required earlier-effect
evidence and current recovery authority, and withhold the corrective
consequence unless the mandatory predicates are satisfied.
12.57.2 — Candidate Independent Method Claim
A corresponding method may comprise:
Das Expires 29 April 2027 [Page 192]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Obtaining authenticated information concerning an original Candidate
Act;
Collecting qualified actual-effect evidence;
Classifying the supported original outcome;
Establishing bounded recovery eligibility;
Constructing a distinct Recovery Candidate Act;
Preparing recovery-specific non-bearer finality enablement;
Independently reconstructing the actual corrective operation at its
Finality Sink;
Verifying earlier-effect correspondence, current resource state,
recovery generation, and authorized scope;
And permitting the corrective effect only upon successful protected
authorization and consumption.
12.57.3 — Candidate Independent Non-Replayable Recovery Claim
Another candidate may concern preventing duplicate corrective effects
through protected branch selection, monotonic recovery-generation
state, operation-specific authority, and independent sink-side
consumption.
12.57.4 — Candidate Independent Evidence-Qualified Compensation Claim
Another candidate may require qualified proof of a specified earlier
completed effect and separately authorized compensation whose actual
scope and target are independently verified.
12.57.5 — Candidate Independent Uncertain-Outcome Recovery Claim
Another candidate may concern mandatory withholding of unsafe retries
when original effectuation is uncertain, subject to defined qualified
non-effectuation or duplicate-suppression conditions.
12.57.6 — Candidate Hardware Recovery Claim
5.3.3.71. Original Source — Global Page 1133
A protected device apparatus may verify original command outcome
evidence, current physical or device state, and scoped corrective
authority before accepting a consequential recovery command.
Das Expires 29 April 2027 [Page 193]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
These candidate architectures may overlap.
Final claim selection should preserve technical unity and distinguish
truly separate claim categories from repeated statements of the same
inventive kernel.
12.58 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
Dependent aspect 1: The original operation is represented by an
authenticated Candidate Act.
Dependent aspect 2: The original effectuation attempt is maintained
in protected state.
Dependent aspect 3: Outcome evidence is obtained from the original
Finality Sink.
Dependent aspect 4: Outcome evidence is obtained from an
independently authenticated observer.
Dependent aspect 5: The outcome verifier possesses an enrolled
cryptographic identity.
Dependent aspect 6: A verifier's authorized role is checked
separately from its cryptographic identity.
Dependent aspect 7: The original effect is classified as confirmed
completed.
Dependent aspect 8: The original effect is classified as confirmed
non-effective.
Dependent aspect 9: The original effect is classified as partially
completed.
Dependent aspect 10: An uncertain earlier outcome establishes a
protected retry fence.
Dependent aspect 11: A timeout alone cannot establish confirmed non-
effectuation.
Dependent aspect 12: A corrective operation is represented by a
distinct Recovery Candidate Act.
Dependent aspect 13: Recovery authority is bound to the original
Candidate Act.
Das Expires 29 April 2027 [Page 194]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Dependent aspect 14: Recovery authority is bound to qualified
original-effect evidence.
Dependent aspect 15: Recovery authority is limited by a protected
recovery envelope.
Dependent aspect 16: Recovery modes are separately defined and
authenticated.
5.3.3.72. Original Source — Global Page 1134
Dependent aspect 17: A protected branch prevents incompatible
recovery strategies from concurrently effecting the same original
operation.
Dependent aspect 18: Recovery authority includes a protected
generation.
Dependent aspect 19: A stale recovery generation is rejected.
Dependent aspect 20: Recovery consumption state survives workload
restart or snapshot restoration.
Dependent aspect 21: A recovery attempt is limited by a protected
retry count.
Dependent aspect 22: A recovery attempt is limited by a quantitative
resource or effect budget.
Dependent aspect 23: A verified destination idempotency mechanism
permits a bounded retry under its stated guarantees.
Dependent aspect 24: A retry identifier is bound to the original
operation parameters.
Dependent aspect 25: The system verifies current destination
duplicate-suppression retention conditions.
Dependent aspect 26: A compensation is permitted only where the
required original-effect evidence supports it.
Dependent aspect 27: A compensation is bound to a specified original
target or effect.
Dependent aspect 28: Compensation amount or quantity is bounded by
current authority.
Das Expires 29 April 2027 [Page 195]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Dependent aspect 29: Compensation is separately consumed through
protected state.
Dependent aspect 30: A completed compensation cannot be repeated
under stale authority.
Dependent aspect 31: Current resource versions are checked before
corrective mutation.
Dependent aspect 32: Intervening legitimate resource modifications
are included in recovery validation.
Dependent aspect 33: An irreversible original effect is represented
as residual protected state.
Dependent aspect 34: A mitigation is distinguished from exact
reversal.
Dependent aspect 35: A containment operation is governed by
separately bounded authority.
Dependent aspect 36: A privileged recovery credential is exercised
only through an operation-specific protected broker.
5.3.3.73. Original Source — Global Page 1135
Dependent aspect 37: The Recovery Finality Sink reconstructs the
actual corrective operation.
Dependent aspect 38: The Finality Sink verifies actual recovery
target identity.
Dependent aspect 39: The sink verifies current recovery branch and
generation state.
Dependent aspect 40: The sink verifies current recovery revocation
and consumption state.
Dependent aspect 41: Recovery authority is non-bearer and designated-
sink bound.
Dependent aspect 42: Corrective resource mutation and authority
consumption occur atomically where supported.
Dependent aspect 43: A successor recovery phase requires accepted
earlier actual-effect evidence where CW-2 applies.
Das Expires 29 April 2027 [Page 196]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Dependent aspect 44: A changed recovery operation exceeding the
original authorized envelope requires new authority.
Dependent aspect 45: Cross-provider recovery preserves source-derived
recovery restrictions.
Dependent aspect 46: Cross-device recovery verifies current
effectuation ownership.
Dependent aspect 47: Recovery following model or runtime change
requires appropriate current execution-state validation.
Dependent aspect 48: A recovery information disclosure remains
subject to applicable protected cumulative privacy constraints.
Dependent aspect 49: A multi-effect recovery graph represents
completed, pending, and unresolved external consequences.
Dependent aspect 50: A protected stop condition prevents further
unauthorized recursive recovery.
Dependent aspect 51: Recovery-verification resource consumption is
bounded.
Dependent aspect 52: Hardware recovery uses qualified current device
or physical-state evidence.
Dependent aspect 53: Newly introduced recovery effectuation paths
require appropriate enforcement-coverage validation.
Dependent aspect 54: The recovery verifier and Finality Sink may
reside within one protected component.
Dependent aspect 55: The recovery verifier and Finality Sink may
reside in separately authenticated domains.
5.3.3.74. Original Source — Global Page 1136
Dependent aspect 56: The architecture maintains authenticated
recovery state without requiring blockchain technology.
These technical aspects are non-limiting candidate dependent-claim
features and do not establish individual patentability by their
enumeration.
12.59 — NON-LIMITING TECHNICAL EFFECTS
12.59.1 — Prevention of Unsupported Corrective Actions
Das Expires 29 April 2027 [Page 197]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The architecture may prevent a recovery agent from causing an
external correction not supported by the required earlier-effect
evidence and current authority.
12.59.2 — Duplicate Recovery Restriction
Protected generation and consumption state may prevent repeated
unauthorized compensation.
12.59.3 — Uncertain-Outcome Safety
The system may avoid unsafe automatic retries where an earlier
operation's real effect remains unknown.
12.59.4 — Scope Preservation
Recovery does not automatically enlarge the original consequential
authority.
12.59.5 — Current Target Verification
Corrective operations may be bound to actual current resource
identity and version state.
12.59.6 — Separation of Compensation and Reversal
The architecture may preserve technically accurate records of real
original and corrective effects.
12.59.7 — Bounded Autonomous Operation
Recovery attempts and resource consumption may remain within
authenticated technical limits.
12.59.8 — Cross-Domain Causal Continuity
Where applicable, authenticated accepted real-effect receipts may
control dependent recovery phases.
12.59.9 — Replay Resistance
5.3.3.75. Original Source — Global Page 1137
Current protected recovery state may prevent stale snapshot or
duplicated authority exercise.
12.59.10 — Implementation Limits
Das Expires 29 April 2027 [Page 198]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The guarantees depend upon the actual protected evidence, resource-
state observation, recovery-authority enforcement, and coverage of
relevant consequential interfaces.
No mechanism can retrospectively eliminate all irreversible external
effects merely by performing compensation.
12.60 — UNIVERSAL NON-LIMITING COMBINATION AND PHOSITA IMPLEMENTATION
CLAUSE
The mechanisms disclosed in Embodiment 12 may be implemented
individually or in technically compatible combinations with the
protected authorization, evidence, finality, conflict-control,
resource-accounting, privacy, migration, and execution-integrity
mechanisms of other embodiments.
A particular implementation may govern only protected retries.
Another may govern only compensating resource mutations.
Another may govern physical-device recovery.
Another may govern recovery of distributed autonomous workflows.
Another may govern information-disclosure mitigation.
Another may combine several recovery classes.
Unless expressly required by a selected claim, no individual recovery
mode, record representation, validator arrangement, cryptographic
primitive, hardware substrate, transaction mechanism, or deployment
topology is universally essential.
The pseudocode, algorithms, state machines, data structures,
experiments, diagrams, and worked examples are illustrative and non-
limiting.
Their purpose is to assist a person having ordinary skill in the art
in understanding and implementing the disclosed technical
arrangements.
Where different embodiments describe compatible source authority,
protected evidence, finality enablement, independent verification, or
recovery mechanisms, such mechanisms may be combined under
appropriate technical conditions.
A cross-reference to another embodiment does not automatically make
every feature of that embodiment mandatory.
Das Expires 29 April 2027 [Page 199]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.3.3.76. Original Source — Global Page 1138
Technical compatibility, enabling disclosure, and actual claim
language determine which combinations are supported.
A generic historical receipt does not replace a mandatory CW-2
accepted actual-effect receipt.
A signed record does not automatically establish that a real external
effect occurred.
A recovery Candidate Act does not automatically acquire authority
from the original task.
A successful compensation does not automatically erase the original
historical consequence.
Future-oriented implementations are non-limiting technical proposals
rather than statements that they have already been built or tested.
No proposed experiment is represented as completed unless
independently executed and documented.
12.61 — FINAL TECHNICAL SUMMARY AND INVENTIVE-STEP CHARACTERIZATION
The present Embodiment 12 discloses a protected autonomous recovery
architecture governing the consequential operations that may be
proposed after an earlier operation fails, partially completes,
succeeds without acknowledgement, or becomes uncertain.
The architecture distinguishes a computational failure indication
from evidence concerning the actual real-world effect.
A protected controller may obtain authenticated and qualified outcome
evidence from relevant effectuation sinks, resource controllers, or
authorized observers.
The supported original outcome is classified without treating a
timeout, missing acknowledgement, or untrusted assertion as proof of
non-effectuation.
A protected recovery envelope defines the corrective operation
classes and bounds that may be authorized.
A recovery planner may propose retries, compensations, forward
completion, containment, restoration, or other permitted actions.
Das Expires 29 April 2027 [Page 200]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Each consequential corrective action is represented as a distinct
Recovery Candidate Act.
The recovery Candidate Act remains non-effective until the
appropriate protected conditions pass.
The proposed correction is bound to the actual supported earlier
effect, relevant original authority, current resource state, selected
recovery branch, and protected recovery generation.
5.3.3.77. Original Source — Global Page 1139
A scoped non-bearer recovery authority may be established and
consumed under protected state.
An independent Recovery Finality Sink obtains or reconstructs the
actual corrective operation presented for effectuation.
It verifies the required qualified original-effect evidence,
authorized recovery class, actual target, current resource state,
applicable scope, recovery-generation validity, revocation, and sink-
local consumption conditions.
Only when the required predicates pass may the corrective consequence
occur through the governed protected interface.
Where an earlier effect is irreversible, the system distinguishes
mitigation from literal reversal.
Where a prior effect remains uncertain, the system may maintain a
retry fence until sufficient evidence or a supported duplicate-
suppression condition permits further action.
Where several recovery agents act concurrently, protected branch and
consumption state may prevent duplicate or incompatible corrective
operations.
Where a successor phase requires an earlier real-effect receipt under
CW-2, the accepted receipt remains a constitutive necessary authority
input rather than a merely informational log entry.
The architecture may be implemented in software, protected hardware,
firmware, transactional services, independently administered resource
controllers, or compatible combinations.
Das Expires 29 April 2027 [Page 201]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
It may govern present-day autonomous agents, distributed
applications, financial systems, databases, industrial equipment,
robotics, communication infrastructure, and emerging heterogeneous
computing environments.
The embodiment does not claim that retry, idempotency, saga
orchestration, compensation, or checkpoint recovery are individually
new.
Its proposed technical contribution lies in making the relationship
among qualified actual-effect evidence, bounded corrective authority,
current recovery state, and independent effectuation control
technically mandatory.
The principal candidate inventive concept of Embodiment 12 is a
protected autonomous recovery-finality system in which a previous
consequential operation is evaluated using qualified actual-effect
evidence, a distinct corrective Candidate Act receives bounded and
non-replayable recovery-specific authority, and an independently
enforcing Recovery Finality Sink refuses the actual corrective
consequence unless the earlier-effect correspondence, present
resource state, permitted recovery scope, current recovery
generation, and protected consumption conditions satisfy the
applicable mandatory predicates.
5.4. Embodiment 16 — Crash-Consistent Effect-Intent Journals and
Indeterminate Outcome Reconciliation
Original technical source: TECHNICAL SPECIFICATION -1063-1541.pdf,
global pages 1385–1465 inclusive. Principal source treatment within
Part 8. Related mechanisms may also be referenced by Parts 3, 4 and
6.
5.4.1. Protected Component Architecture
Das Expires 29 April 2027 [Page 202]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
[CA / permitted effect / source scope]
|
[Protected effect-intent journal]
|
[Durable pre-effect decision/consumption]
|
[Receiving actual Finality Sink]
|
[External effect (may be remote)]
|
[Outcome observed / lost ACK / crash]
|
[Durable reconcile / consumed / uncertain]
|
[No unverified reuse of authority]
Figure 7: Embodiment 16 — Crash-Consistent Effect-Intent Journals and
Indeterminate Outcome Reconciliation — architecture
5.4.2. Actual-Effect and Failure Decision Flowchart
[Journal effect-intent before release]
|
<Atomic protected consume valid?> -- NO --> [DENY]
| YES
[Actual effect attempt at receiver]
|
<Verified outcome available?> -- YES --> [COMMIT RESULT]
| NO
[Mark INDETERMINATE, preserve state]
|
<Resource proves non-effectuation?> -- YES --> [QUALIFIED RETRY]
| NO
[No automatic duplicate; reconcile/recover]
Figure 8: Embodiment 16 — Crash-Consistent Effect-Intent Journals and
Indeterminate Outcome Reconciliation — effectuation decisions
5.4.3. Original Technical Disclosure — Page-Indexed Sections
5.4.3.1. Original Source — Global Page 1385
CRASH-CONSISTENT EXECUTION-FINALITY JOURNALING, EXACTLY-ONCE
AUTHORIZATION, AND INDETERMINATE EXTERNAL-OUTCOME RECONCILIATION WITH
DURABLE EFFECT-INTENT COMMITMENTS, MONOTONIC AUTHORITY CONSUMPTION,
RECEIVER-SIDE DUPLICATE FENCING, AND INDEPENDENT ACTUAL-EFFECT
VERIFICATION
Das Expires 29 April 2027 [Page 203]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
16.0 — COMPLETE TECHNICAL TITLE
Systems and Methods for Crash-Consistent Autonomous Consequential
Execution Using Authenticated Write-Ahead Finality Journals, Durable
Operation-Specific Authority Consumption, Protected Dispatch-Intent
Commitments, Monotonic Recovery Generations, Receiver-Bound Duplicate
Suppression, Qualified External-Effect Outcome Evidence,
Indeterminate-Result Fencing, and Independent Finality-Sink
Verification of Actual Pending Operations
16.0.1 — General Technical Description
The present Embodiment 16 discloses systems, methods, apparatus,
protected computing components, authenticated journaling protocols,
machine-verifiable operation-state representations, cryptographic and
non-cryptographic enforcement mechanisms, protected transaction-state
transitions, durable authority-consumption procedures, and non-
limiting implementations for governing consequential operations
across process crashes, system restarts, network interruptions,
storage recovery, workload migration, partial execution, duplicate
submissions, and uncertain external outcomes.
The computational entities may include artificial-intelligence
agents, autonomous assistants, distributed service processes,
transaction processors, payment controllers, cloud workloads,
database services, operating-system components, network controllers,
robotic systems, industrial equipment, embedded devices, hardware
accelerators, or other entities capable of initiating consequential
operations.
Such operations may include persistent data mutation, payment
submission, message transmission, credential activation, file export,
network configuration, storage commit, protected information
disclosure, physical actuation, device-command execution, or another
externally effective operation.
An operation may be validly authorized before an interruption occurs.
However, the interruption may occur at any point between validation,
protected authority consumption, dispatch preparation, actual
effectuation, destination processing, acknowledgement, and final
outcome recording.
The requesting entity may subsequently restart with incomplete or
stale information.
A software exception, timeout, or missing acknowledgement does not
necessarily establish that the underlying effect failed.
Das Expires 29 April 2027 [Page 204]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An authenticated journal entry recording an intended operation does
not necessarily establish that the operation occurred.
5.4.3.2. Original Source — Global Page 1386
A protected record establishing consumption of authority does not
necessarily establish that a remote recipient processed the
corresponding request.
A valid receiver acknowledgement may establish only the properties
supported by the receiving system's authenticated observation or
transaction state.
The present embodiment therefore establishes a protected distinction
among:
Authorization eligibility;
Durable operation preparation;
Protected finality consumption;
Durable dispatch intent;
Actual release or dispatch;
Receiver-side acceptance;
Qualified effect completion;
And unresolved or indeterminate outcomes.
In a principal implementation, a protected Finality Sink reconstructs
the actual pending consequential operation and validates current
operation-specific authority.
Before permitting the effect, the sink establishes an authenticated
durable journal state that binds the operation, its validation
evidence, its protected authority-generation state, and its
applicable effectuation boundary.
A monotonic authority-consumption transition ensures that one
specified single-use finality enablement cannot be independently
consumed more than once.
Where the resource mutation and authority consumption share an
appropriately protected transactional domain, the system may commit
both within one atomic transition.
Das Expires 29 April 2027 [Page 205]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Where the actual effect requires a separate external destination, the
system employs a protected dispatch-intent and outcome-reconciliation
protocol.
The external operation may be associated with a stable authenticated
operation identifier and a qualified receiver-side duplicate-
suppression mechanism where available.
If the external outcome becomes uncertain, the system preserves the
relevant consumed authority and establishes a retry fence.
A new effect is not automatically authorized merely because the
sender failed to receive acknowledgement.
5.4.3.3. Original Source — Global Page 1387
The system may obtain qualified destination evidence, invoke a
supported idempotent retry procedure, or require a separately
authorized recovery Candidate Act.
16.0.2 — Fundamental Technical Principle
The right to attempt an effect once is not proof that the effect
occurred once.
The following are technically distinct properties:
An operation was authorized.
The authorization was consumed.
The operation was durably prepared for dispatch.
The operation was dispatched.
A destination accepted the operation.
The destination committed the intended mutation.
A physical consequence occurred.
An acknowledgement was received.
And the final outcome was independently established.
The system must not silently treat these states as interchangeable.
16.0.3 — Principal Proposed Inventive Concept
Das Expires 29 April 2027 [Page 206]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The principal candidate inventive combination comprises:
A specified consequential Candidate Act;
A protected actual-operation descriptor;
Authenticated validation evidence;
An operation-specific non-bearer finality enablement;
A protected durable finality journal;
An authoritative monotonic consumption generation;
A durable dispatch-intent and effect-attempt relationship;
A defined effectuation boundary;
A qualified receiver or external-observation mechanism;
5.4.3.4. Original Source — Global Page 1388
An indeterminate-outcome state;
A protected retry or recovery fence;
And independent verification before any further consequential
effectuation.
The proposed technical interaction ensures that an interruption
cannot automatically transform an earlier consumed authorization,
unresolved dispatch, or stale journal copy into fresh permission to
perform another real-world effect.
16.0.4 — Distinction Between Local and External Guarantees
The embodiment expressly separates at least three classes of
guarantee.
Local authorization uniqueness: An authoritative protected controller
allows only the specified permitted number of finality-consumption
transitions.
Local transactional effect atomicity: Where the protected resource
mutation and finality consumption belong to one atomic transaction
domain, both may be committed or rejected together.
Das Expires 29 April 2027 [Page 207]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
External outcome guarantee: Where the effect occurs in a distinct
resource, service, or physical system, the guarantee depends upon
destination-side controls and qualified observation.
Exactly-once local authority consumption does not by itself establish
exactly-once external processing.
16.0.5 — Established Techniques
Write-ahead logging, idempotency, duplicate suppression, durable
transaction journals, transactional outbox processing, replay-
resistant identifiers, and receiver-side transaction records are
established mechanisms.
The present embodiment does not claim their original invention.
Its candidate contribution concerns the protected dependency between
the actual Finality-Sink operation, evidence-qualified authority,
durable consumption, dispatch-state continuity, and indeterminate-
outcome handling.
16.0.6 — Relationship to Common Workflows
The embodiment may incorporate the Candidate Act, Non-Effective
State, Protected Enforcement Domain, independent evidence validation,
scoped non-bearer finality authority, actual-operation
reconstruction, and Finality Sink mechanisms of CW-1.
Where a dependent successor operation requires a qualified earlier
real effect, the accepted identity-authenticated actual-effect
receipt of CW-2 remains a constitutive authority input.
A durable journal entry recording a dispatch attempt does not replace
such a receipt.
5.4.3.5. Original Source — Global Page 1389
Optional CW-3 reauthorization may apply when retry, repair,
compensation, or resumed execution materially changes the permitted
operation.
16.0.7 — Relationship to Earlier Embodiments
Embodiment 1 may control conflicting effects.
Embodiment 2 may require accepted evidence of an earlier completed
effect before causal continuation.
Das Expires 29 April 2027 [Page 208]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Embodiments 3 and 4 may verify actual targets and externally observed
consequences.
Embodiment 5 may constrain resource expenditure during repeated or
delayed execution.
Embodiment 6 may verify current tool and command semantics.
Embodiment 7 may preserve operation authority across delegated
domains.
Embodiment 8 may prevent duplicate or cumulative unauthorized privacy
disclosures.
Embodiment 9 may establish current hardware ownership.
Embodiment 10 may control executable-generation validity.
Embodiment 11 may provide version-bound reservations and protected
concurrent mutations.
Embodiment 12 may govern the authority to choose and perform
corrective recovery operations.
Embodiment 13 may supply qualified collective authorization.
Embodiment 14 may establish current mandatory effectuation-path
coverage.
Embodiment 15 may establish the cross-committed evidence and non-
bearer authority whose durable consumption is governed here.
Miscellaneous Embodiment M-1 may supply optional protected state,
infrastructure, and dynamic enforcement modules.
The present embodiment develops the persistence, crash atomicity,
receiver-side coordination, and outcome-uncertainty treatment of
consequential finality, without modifying the earlier embodiments.
16.1 — TECHNICAL FIELD
The invention relates to crash-consistent autonomous execution,
protected transaction journals, secure distributed systems, durable
authority state, resource mutation protocols, authenticated external-
effect evidence, replay-resistant authorization, distributed
effectuation,
Das Expires 29 April 2027 [Page 209]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.4.3.6. Original Source — Global Page 1390
idempotency, non-bearer capabilities, hardware command control, and
execution-finality security.
More specifically, the invention concerns preventing an uncertain
earlier effectuation attempt from causing unauthorized repeated
consequential operations following failures, retries, reconnections,
and restarts.
16.2 — SPECIFIC TECHNICAL PROBLEMS
16.2.1 — Crash Before Authority Consumption
The system may fail before a finality enablement is durably consumed.
16.2.2 — Crash During Consumption
A requester may not know whether the protected consumption transition
committed.
16.2.3 — Crash After Consumption but Before Dispatch
Authority may be consumed although the consequential effect has not
been transmitted.
16.2.4 — Crash During External Dispatch
Only part of an operation may have been transmitted or accepted.
16.2.5 — Crash After Destination Processing
The destination may complete the operation while the sender remains
unaware.
16.2.6 — Lost Acknowledgement
A communication failure may conceal successful external processing.
16.2.7 — Duplicate Client Retry
An autonomous agent may submit the same operation again.
16.2.8 — Duplicate Queue Delivery
A messaging system may deliver the same committed event more than
once.
Das Expires 29 April 2027 [Page 210]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
16.2.9 — Duplicate Recovery Worker
Several restarted processes may attempt to resume the same operation.
16.2.10 — Stale Snapshot
A restored workload may contain an earlier apparently unconsumed
authorization reference.
5.4.3.7. Original Source — Global Page 1391
16.2.11 — Journal Rollback
An attacker may attempt to restore a previous journal state.
16.2.12 — Journal Reordering
A storage or software fault may present effect records in an
incorrect causal or protected sequence.
16.2.13 — Torn Journal Write
A power failure may interrupt a multi-field journal update.
16.2.14 — Delayed Storage Durability
An application may receive a write success indication before the
required durable persistence guarantee is actually satisfied.
16.2.15 — Dual-Write Failure
A protected consumption record may commit while the external dispatch
record is lost, or vice versa.
16.2.16 — Idempotency Key Collision
Different operations may share an identifier without matching
parameters.
16.2.17 — Idempotency Retention Expiry
A receiver may discard duplicate-suppression state before a later
retry.
16.2.18 — Receiver State Rollback
A destination may lose the record establishing that an operation
already took effect.
Das Expires 29 April 2027 [Page 211]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
16.2.19 — Receiver-Side Partial Mutation
A receiver may durably record an operation identifier but fail before
the corresponding resource mutation, or perform a mutation without
retaining the identifier.
16.2.20 — Partitioned Finality Controllers
Different controllers may believe the same authority remains
available.
16.2.21 — Delayed Former Leader
An old coordinator may resume and attempt execution after leadership
has transferred.
16.2.22 — Operation Parameter Substitution
5.4.3.8. Original Source — Global Page 1392
A retry may use the original operation identifier with different
actual parameters.
16.2.23 — Changed Resource State
The target may have changed since the original validation.
16.2.24 — Actual Effect Without Confirmed Receipt
An operation may physically occur without producing reliable machine-
readable completion evidence.
16.2.25 — Irreversible Effect
A completed information disclosure or physical operation may not be
safely repeated or undone.
16.2.26 — Technical Objective
A candidate objective technical problem is:
How to preserve operation-specific protected execution authority and
prevent unsupported repeat consequential effects across crashes,
retries, partitions, and uncertain remote outcomes by durably binding
actual Finality-Sink operations to monotonic consumption and
dispatch-intent state, and requiring qualified outcome reconciliation
or independently valid recovery authority before further
effectuation.
Das Expires 29 April 2027 [Page 212]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
16.3 — ESTABLISHED TECHNIQUES AND THEIR LIMITATIONS
16.3.1 — Write-Ahead Logging
A database or transactional service may durably record information
before applying a mutation.
Write-ahead logging is established.
A local log does not automatically prove that an external recipient
performed an operation.
16.3.2 — Transactional Outbox
An application may atomically commit business state and an outbound
event to one local transaction domain.
This is established.
The later relay may still deliver a message multiple times.
16.3.3 — Inbox Deduplication
5.4.3.9. Original Source — Global Page 1393
A receiver may record identifiers of previously processed messages.
Such techniques are established.
Their correctness depends upon how the duplicate record is coupled to
the actual mutation.
16.3.4 — Idempotency Keys
A client may associate repeated requests with a stable logical
operation identifier.
Idempotency keys are established.
A key alone does not guarantee that the receiver durably enforces the
intended semantics.
16.3.5 — Distributed Consensus
A replicated state machine may establish authoritative transaction or
consumption ordering.
Consensus is established.
Das Expires 29 April 2027 [Page 213]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
It does not automatically make a separate external physical
consequence atomic with the replicated decision.
16.3.6 — Two-Phase Commit
Distributed transaction systems may coordinate prepare and commit
phases across participating resources.
This is established.
Its guarantees require suitable participant support, durability, and
failure assumptions.
16.3.7 — Transactional Message Processing
Messaging infrastructure may provide defined delivery, processing, or
transaction guarantees.
The protection must identify the precise covered scope.
16.3.8 — Retry With Backoff
A client may delay repeated attempts.
Such delay does not establish that an earlier effect failed.
16.3.9 — Checkpoint and Restore
A runtime may restore computational state from a checkpoint.
The restored workload must not automatically recreate consumed
consequential authority.
5.4.3.10. Original Source — Global Page 1394
16.3.10 — Candidate Technical Distinction
The proposed technical relationship connects actual-effect
reconstruction, evidence-qualified authority consumption, durable
dispatch-state continuity, and receiver or observer outcome
reconciliation so that the recovery protocol cannot infer new
execution permission from an unresolved earlier effect.
16.4 — PRINCIPAL SYSTEM ARCHITECTURE
A representative implementation comprises:
An Authenticated Candidate Act Controller;
Das Expires 29 April 2027 [Page 214]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An Actual Operation Reconstruction Component;
An Operation-Specific Evidence Verifier;
A Protected Finality Authority Controller;
A Durable Finality Journal;
A Monotonic Authority Consumption Controller;
A Protected Dispatch-Intent Controller;
A Consequential Effectuation Sink;
An Optional Receiver-Side Operation Registry;
A Qualified Outcome Evidence Collector;
An Indeterminate Outcome Reconciliation Controller;
And a Protected Recovery Fencing Service.
Optional components may include a transaction coordinator, outbox
dispatcher, inbox controller, protected storage module, hardware
monotonic counter, replicated state machine, device command
controller, distributed lease service, clock or epoch controller, and
independent real-effect validator.
16.4.1 — Authority Controller
Determines whether the actual operation has valid current non-bearer
finality enablement.
16.4.2 — Journal
Retains durable authenticated evidence concerning authority and
dispatch state transitions.
5.4.3.11. Original Source — Global Page 1395
16.4.3 — Consumption Controller
Prevents unauthorized reuse of operation-specific finality authority.
16.4.4 — Dispatch Controller
Maintains a durable relationship between consumed authority and the
external operation attempt.
Das Expires 29 April 2027 [Page 215]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
16.4.5 — Receiver Registry
Where supported, associates received operation identifiers with
actual destination-side processing.
16.4.6 — Outcome Verifier
Determines what can be established concerning the external
consequential result.
16.4.7 — Reconciliation Controller
Preserves uncertainty and restricts further effectuation until safe
continuation conditions are established.
16.5 — BROAD TECHNICAL DEFINITIONS
16.5.1 — Journal-Governed Candidate Act
A Journal-Governed Candidate Act, or JGCA, means a consequential
Candidate Act whose effectuation is governed by protected durable
authority and dispatch state.
16.5.2 — Protected Finality Journal
A Protected Finality Journal, or PFJ-16, means authenticated durable
state representing relevant finality preparation, consumption,
dispatch, and outcome transitions.
16.5.3 — Finality Journal Entry
A Finality Journal Entry, or FJE-16, means a protected record
describing a specified operation-state transition.
16.5.4 — Protected Journal Sequence
A Protected Journal Sequence, or PJS-16, means a protected ordering
or generation relation among applicable journal records.
16.5.5 — Durable Finality Preparation
5.4.3.12. Original Source — Global Page 1396
Durable Finality Preparation means a protected persisted state
establishing that a particular operation is eligible for a defined
subsequent finality transition.
16.5.6 — Durable Authority Consumption
Das Expires 29 April 2027 [Page 216]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Durable Authority Consumption means an authoritative persistent
transition committing permitted finality use under applicable
protected state.
16.5.7 — Monotonic Consumption Generation
A Monotonic Consumption Generation, or MCG-16, means a protected
generation that prevents stale or consumed authority from being
restored through unauthorized rollback.
16.5.8 — Protected Dispatch Intent
Protected Dispatch Intent, or PDI-16, means durable authenticated
state establishing the specific operation a controlled dispatcher may
attempt.
16.5.9 — Dispatch Intent Commitment
A Dispatch Intent Commitment, or DIC-16, means a protected commitment
binding the actual operation, finality authority consumption,
intended destination, and dispatch identity.
16.5.10 — Protected Effect Attempt
A Protected Effect Attempt, or PEA-16, means a qualified recorded
attempt to release the specified consequential operation.
16.5.11 — Effect Attempt Identifier
An Effect Attempt Identifier, or EAI-16, means a protected reference
identifying a particular dispatch attempt.
16.5.12 — Logical Effect Identifier
A Logical Effect Identifier, or LEI-16, means a stable authenticated
identifier representing the intended single logical consequence
across permitted retries.
16.5.13 — Receiver-Side Effect Registry
A Receiver-Side Effect Registry, or RSER, means authoritative
receiving-resource state associating logical operation identifiers
with applicable acceptance or mutation outcomes.
16.5.14 — Receiver Duplicate Fence
Das Expires 29 April 2027 [Page 217]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A Receiver Duplicate Fence, or RDF-16, means a receiver-enforced
restriction preventing unauthorized repeated application of the same
logical operation.
16.5.15 — Receiver Commit Evidence
5.4.3.13. Original Source — Global Page 1397
Receiver Commit Evidence, or RCE-16, means authenticated evidence
concerning a receiving resource's specified actual processing or
mutation state.
16.5.16 — Protected Outcome Classification
Protected Outcome Classification, or POC-16, means an authenticated
determination concerning a specified actual effect outcome.
16.5.17 — Indeterminate Effect State
Indeterminate Effect State, or IES-16, means authoritative state
indicating that actual completion or non-effectuation cannot be
sufficiently established.
16.5.18 — Indeterminate Outcome Fence
An Indeterminate Outcome Fence, or IOF-16, means a protected
restriction preventing unsafe additional effectuation while the
earlier outcome remains unresolved.
16.5.19 — Protected Retry Eligibility
Protected Retry Eligibility means a verified condition under which
another attempt of a specified logical operation is permitted.
16.5.20 — Protected Retry Lease
A Protected Retry Lease, or PRL-16, means bounded authority to
perform a specified retry subject to protected generation,
destination, and validity constraints.
16.5.21 — Receiver Retention Commitment
A Receiver Retention Commitment, or RRC-16, means qualified
information concerning the period or condition under which the
receiver preserves the applicable duplicate-suppression state.
16.5.22 — Protected Outcome Witness
Das Expires 29 April 2027 [Page 218]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A Protected Outcome Witness, or POW-16, means an authorized observer
supplying evidence concerning a specified external effect.
16.5.23 — Qualified Non-Effectuation Evidence
Qualified Non-Effectuation Evidence means evidence sufficient under a
defined trust model to establish that the specified real effect did
not occur.
16.5.24 — Qualified Completed-Effect Evidence
Qualified Completed-Effect Evidence means evidence sufficient to
establish the specified completed consequence.
16.5.25 — Protected Effect Reconciliation
5.4.3.14. Original Source — Global Page 1398
Protected Effect Reconciliation means a verified procedure resolving
earlier dispatch and effect state without automatically authorizing a
new consequence.
16.5.26 — Recovery Authority Fence
A Recovery Authority Fence means protected state preventing duplicate
or incompatible corrective operations.
16.5.27 — Fenced Execution Generation
A Fenced Execution Generation, or FEG-16, means a current protected
generation preventing an old coordinator, worker, or device owner
from exercising stale consequential authority.
16.5.28 — Protected Journal Checkpoint
A Protected Journal Checkpoint, or PJC-16, means an authenticated
compact state representing journal transitions necessary for
continued enforcement.
16.5.29 — Journal Rollback Protection
Journal Rollback Protection means a mechanism preventing stale or
altered journal state from recreating previously consumed authority.
16.5.30 — Effectuation Boundary Commitment
Das Expires 29 April 2027 [Page 219]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An Effectuation Boundary Commitment means an authenticated reference
to the actual interface at which the specified consequence may be
released.
16.5.31 — Atomic Resource-Finality Commit
Atomic Resource-Finality Commit means one transaction-domain
transition that commits both the permitted resource effect and its
corresponding finality consumption under the specified atomicity
guarantees.
16.5.32 — External Dispatch Uncertainty
External Dispatch Uncertainty means an unresolved condition
concerning whether an externally addressed effect crossed its
dispatch or receiving boundary.
16.5.33 — Outcome-Specific Reauthorization
Outcome-Specific Reauthorization means new consequential authority
issued only after the necessary supported earlier-outcome conditions
are established.
16.5.34 — Protected Journal Continuity
Protected Journal Continuity means preservation of authoritative
consequential-operation state across crash, restart, migration, and
recovery.
16.5.35 — Exactly-Once Authorization Consumption
5.4.3.15. Original Source — Global Page 1399
Exactly-Once Authorization Consumption means, for a specified single-
use finality enablement and authoritative protected consumption
domain, no more than one permitted consumption transition can commit.
It does not independently establish that a corresponding external
operation physically occurs exactly once.
16.6 — OPERATION IDENTITY AND ACTUAL EFFECT BINDING
A protected operation identifier may be derived from, or
authenticated with, the corresponding Candidate Act and actual-effect
descriptor.
A representative operation record may comprise:
Das Expires 29 April 2027 [Page 220]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
PROTECTED_LOGICAL_OPERATION = { logical_effect_identifier,
originating_candidate_act, protected_source_authority,
actual_operation_commitment, protected_resource_identity,
intended_destination, operation_semantics_version,
relevant_resource_version, designated_finality_sink,
finality_enablement_reference, current_authority_epoch,
current_execution_generation, protected_operation_authentication }
The logical effect identifier may remain stable across qualified
retries of the same logical operation.
An attempt identifier may differ between dispatch attempts.
The system must distinguish the logical effect from the transmission
attempt.
A copied identifier cannot independently authorize a new operation
with different actual parameters.
16.6.1 — Stable Logical Identity
Permitted retries may refer to the same original consequential
objective.
16.6.2 — Distinct Attempts
Separate attempts may have distinct identifiers while preserving the
logical operation binding.
5.4.3.16. Original Source — Global Page 1400
16.6.3 — Actual Parameters
The actual effect parameters must correspond to the protected
operation.
16.6.4 — Resource Identity
The actual target must be verified.
16.6.5 — Operation Contract
The current semantics must satisfy the applicable validated contract.
16.6.6 — Generation State
Stale workload or authority generations cannot independently produce
another effect.
Das Expires 29 April 2027 [Page 221]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
16.7 — PROTECTED DURABLE FINALITY JOURNAL
A representative journal entry may comprise:
PROTECTED_FINALITY_JOURNAL_ENTRY = { journal_format_version,
journal_domain_identifier, journal_sequence,
previous_entry_commitment, candidate_act_digest,
actual_operation_digest, logical_effect_identifier,
attempt_identifier, validation_evidence_commitment,
protected_finality_authority_reference,
authority_consumption_generation, state_transition_type,
dispatch_intent_commitment, designated_effectuation_sink,
receiver_identity_if_applicable, protected_resource_generation,
authority_epoch, journal_durability_status,
qualified_outcome_evidence_reference, protected_entry_authentication
}
The journal may be implemented using a transactional store, write-
ahead log, protected append-only state, durable key-value store,
hardware-protected storage, or an equivalent authoritative mechanism.
A cryptographic hash chain may assist integrity checking.
5.4.3.17. Original Source — Global Page 1401
A hash chain does not independently guarantee availability,
durability, completeness, or rollback resistance.
Those properties require suitable protected storage and state-
management mechanisms.
16.8 — REQUIRED JOURNAL TRANSITIONS
A principal implementation may define:
INTENT_PREPARED: The Candidate Act and actual effect descriptor have
been committed for protected validation.
VALIDATION_COMMITTED: Required current operation-specific validation
has passed.
FINALITY_READY: The applicable non-bearer enablement is eligible.
CONSUMPTION_PREPARED: The sink is preparing the protected authority
transition.
AUTHORITY_CONSUMED: The permitted finality use has been durably
consumed.
Das Expires 29 April 2027 [Page 222]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
DISPATCH_INTENT_COMMITTED: A protected record identifies the
externally addressable effect prepared for dispatch.
DISPATCH_IN_PROGRESS: The controlled effectuation interface has
initiated the corresponding operation.
DISPATCH_POSSIBLE: The operation may have crossed the dispatch
boundary, but the evidence is insufficient to determine the exact
state.
RECEIVER_ACCEPTED: Qualified evidence establishes the receiver's
specified acceptance state.
EFFECT_COMMITTED: Qualified evidence establishes the defined
completed external or resource effect.
EFFECT_REJECTED: Qualified evidence establishes rejection without the
specified consequential mutation.
EFFECT_PARTIAL: Qualified evidence establishes a partial consequence.
EFFECT_INDETERMINATE: The relevant real outcome remains unresolved.
RETRY_FENCED: Another effect attempt is prohibited pending the
defined safety conditions.
RECOVERY_AUTHORIZED: A separately verified recovery procedure has
received the required authority.
5.4.3.18. Original Source — Global Page 1402
TERMINATED: The logical operation has reached a valid protected
terminal condition.
The records must distinguish the durability of local state from
evidence about a remote result.
16.9 — DURABILITY AND STORAGE ORDERING
A protected finality protocol must identify which state is required
to be durable before the actual consequence becomes possible.
A principal remote-dispatch implementation may require:
1. A verified actual-operation descriptor. 2. Valid current
protected finality authority. 3. A durable consumption and dispatch-
intent relationship. 4. A release fence tied to the committed state.
5. Only then, controlled external dispatch.
Das Expires 29 April 2027 [Page 223]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The durability barrier must correspond to the actual storage
semantics.
A file write accepted into volatile cache does not automatically
constitute a durable commit.
An application-level acknowledgement from a storage API may be
insufficient if its documented semantics do not establish the
required persistence.
Suitable implementations may employ transactional commit, persistence
barriers, hardware-backed storage, quorum-durable replication, or
another mechanism providing the claimed durability.
16.9.1 — Journal Atomicity
Security-relevant fields may be committed within one atomic protected
record or equivalent transaction.
16.9.2 — Torn Write Detection
Incomplete records may be detected using suitable integrity and
transaction-state mechanisms.
16.9.3 — Ordering
Required state transitions must not be reordered across an
unprotected external effectuation boundary.
16.9.4 — Recovery Scan
Following restart, the controller reconstructs the latest
authoritative operation state.
16.9.5 — Missing State
5.4.3.19. Original Source — Global Page 1403
Unresolved mandatory journal state cannot be treated as proof that an
external effect did not occur.
16.10 — LOCAL ATOMIC RESOURCE-FINALITY MODE
A first principal operating mode applies where the Finality Sink and
affected resource support one protected transactional domain.
For example, a database controller may have authority to perform
both:
Das Expires 29 April 2027 [Page 224]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The target mutation; and
The associated finality-consumption update.
A representative transaction may be:
ATOMIC_TRANSACTION { VERIFY_CURRENT_SOURCE_AUTHORITY
VERIFY_ACTUAL_OPERATION VERIFY_VALID_FINALITY_ENABLEMENT
VERIFY_CURRENT_RESOURCE_VERSION VERIFY_UNCONSUMED_AUTHORITY
APPLY_AUTHORIZED_RESOURCE_MUTATION CONSUME_FINALITY_AUTHORITY
COMMIT_PROTECTED_JOURNAL_STATE }
If the transaction aborts, neither the resource mutation nor the
authoritative consumption transition is committed.
If it commits, both are durably associated under the selected
resource's transaction guarantees.
16.10.1 — Linearization Point
The operation may use the authoritative transaction commit as the
point at which local effect and consumption become effective.
16.10.2 — Duplicate Submission
A repeated request observes the existing committed logical operation
state rather than applying the mutation again.
16.10.3 — Resource Version
The transaction may verify current version or other conditional
state.
16.10.4 — Journal Record
5.4.3.20. Original Source — Global Page 1404
The committed journal state identifies the corresponding operation
and authority consumption.
16.10.5 — Limitation
The guarantee applies to the resource effects and state actually
included within the transaction boundary.
An additional external notification, network transmission, or
physical action may require a separate protocol.
Das Expires 29 April 2027 [Page 225]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
16.11 — REMOTE DISPATCH MODE
A second operating mode applies where the actual effect occurs in a
separate remote resource or administrative domain.
The local controller cannot necessarily atomically commit its
finality journal together with the remote consequence.
A protected procedure may therefore:
Establish a valid operation-specific authority;
Durably consume the relevant finality enablement;
Commit a protected dispatch-intent record;
Permit a controlled dispatcher to transmit the precisely committed
operation;
Maintain an indeterminate state if the result becomes uncertain;
And obtain qualified receiver or external-effect evidence before
permitting any further effectuation decision.
The system must not silently convert a local durable commit into a
claim of remote successful completion.
16.12 — ATOMIC CONSUMPTION–DISPATCH INTENT COUPLING
A principal remote configuration may commit both the finality
consumption and dispatch-intent reference in one authoritative
protected state transition.
ATOMIC { REQUIRE AUTHORITY_VALID REQUIRE ACTUAL_OPERATION_MATCHES
REQUIRE FINALITY_UNCONSUMED
5.4.3.21. Original Source — Global Page 1405
CONSUME_FINALITY_ENABLEMENT RECORD_EXACT_DISPATCH_INTENT
ADVANCE_PROTECTED_GENERATION }
The committed dispatch intent may authorize a designated protected
dispatcher to attempt the corresponding operation.
It does not authorize arbitrary newly generated operations.
If the process crashes immediately after the atomic transition, the
journal preserves the operation identity and consumed authority.
Das Expires 29 April 2027 [Page 226]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The dispatcher may resume only according to the selected remote-
effect protocol.
Where safe retransmission cannot be established, the operation
remains fenced until reconciliation.
16.13 — CONTROLLED OUTBOX VARIATION
A protected outbox may contain the exact operation prepared for
remote delivery.
A representative record may comprise:
PROTECTED_EFFECT_OUTBOX = { logical_effect_identifier,
attempt_identifier, actual_operation_commitment,
serialized_dispatch_payload_reference, authorized_destination,
finality_consumption_reference, source_authority_epoch,
dispatcher_generation, receiver_duplicate_policy_reference,
current_dispatch_state, protected_record_authentication }
The protected outbox entry may be committed with finality
consumption.
An authorized dispatcher later reads the durable entry.
It must not construct a materially different operation from current
agent output.
It verifies the current permitted dispatch state and destination.
Where the selected protocol permits at-least-once transmission, the
destination must have adequate duplicate-control properties for the
claimed effect guarantee.
5.4.3.22. Original Source — Global Page 1406
The outbox itself does not create exactly-once external processing.
16.14 — RECEIVER-SIDE DUPLICATE FENCING
A destination may maintain authoritative state binding the logical
effect identifier to the actual resource operation.
A representative receiver record may comprise:
RECEIVER_EFFECT_REGISTRY = { receiver_identity,
logical_effect_identifier, accepted_operation_digest,
originating_authority_reference, receiver_resource_identifier,
Das Expires 29 April 2027 [Page 227]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
receiver_transaction_identifier, receiver_resource_generation,
processing_status, committed_effect_reference,
protected_duplicate_retention_state, authenticated_receiver_state }
The receiver may reject a repeated request with the same logical
identifier and incompatible parameters.
If the same logical operation was already committed, the receiver may
return the authenticated existing result without applying another
mutation.
For strong receiver-side effect uniqueness, the duplicate registry
and protected resource mutation must be appropriately atomic or
supported by an equivalent mechanism.
If the receiver merely writes the duplicate registry before a
separate unprotected mutation, a crash could leave an operation
recorded as completed even though no effect occurred.
If the receiver applies the mutation before separately writing the
registry, a crash could permit duplicate mutation on retry.
16.15 — RECEIVER TRANSACTIONAL COMMIT
Where the receiver controls a transactional resource, it may process
an incoming logical effect as follows:
ATOMIC_RECEIVER_TRANSACTION { VERIFY_OPERATION_IDENTITY
VERIFY_CURRENT_RECEIVER_AUTHORITY
5.4.3.23. Original Source — Global Page 1407
IF LOGICAL_OPERATION_ALREADY_COMMITTED: RETURN RECORDED_RESULT
VERIFY_ACTUAL_OPERATION_PARAMETERS VERIFY_CURRENT_RESOURCE_STATE
APPLY_RESOURCE_MUTATION RECORD_LOGICAL_OPERATION_AS_COMMITTED
COMMIT_TRANSACTION }
The exact receiver semantics must be defined.
A receiver that only acknowledges message arrival cannot claim to
have committed the requested resource mutation.
Where the receiving system supports a defined idempotent operation
but not one atomic transaction, the corresponding protection may use
another qualified and documented mechanism.
16.16 — RECEIVER RETENTION AND IDENTITY LIFETIME
Das Expires 29 April 2027 [Page 228]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Duplicate suppression is meaningful only while the relevant receiver
state remains applicable.
16.16.1 — Retention Scope
The receiver identifies how long or under what conditions operation
identifiers are retained.
16.16.2 — Stable Parameter Binding
The identifier remains associated with the original operation digest.
16.16.3 — Expiration
After retention expiry, the original logical identifier may no longer
be sufficient for safe retry.
16.16.4 — Reconciliation
The sender may require qualified receiver-state queries or separately
authorized recovery.
16.16.5 — New Identifier
Generating a new logical identifier is not automatically permitted
while the earlier effect remains uncertain.
16.16.6 — Current Policy
The protected retry controller checks the receiver's actual guarantee
rather than assuming indefinite deduplication.
5.4.3.24. Original Source — Global Page 1408
16.17 — INDETERMINATE EXTERNAL OUTCOME
A consequential operation may reach an indeterminate state when the
available evidence cannot establish whether the actual effect
occurred.
A timeout is a communication condition.
A disconnected socket is a transport condition.
A missing acknowledgement is an observation condition.
None is sufficient by itself to establish that the destination did
not perform the operation.
Das Expires 29 April 2027 [Page 229]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The protected journal may therefore record:
The original authorized operation;
The consumed authority;
The dispatch intent;
The possibility of dispatch;
The last qualified receiver evidence;
And the current unresolved outcome.
The operation remains protected against unsupported independent re-
execution.
16.18 — QUALIFIED OUTCOME EVIDENCE
The system may use authenticated evidence from:
A transactional receiver;
A protected resource controller;
An independent effect observer;
A hardware command completion interface;
An appropriately qualified external validator;
Or another source with sufficient technical visibility.
A representative outcome record may comprise:
5.4.3.25. Original Source — Global Page 1409
QUALIFIED_EXTERNAL_EFFECT_OUTCOME = {
original_logical_effect_identifier, original_operation_commitment,
receiver_or_observer_identity, authorized_observation_role,
actual_resource_identity, supported_effect_status,
committed_resource_state_reference, receiver_transaction_reference,
observation_scope, observation_generation,
unresolved_effect_components, evidence_assurance_profile,
protected_evidence_authentication }
A receiver's acknowledgement of command receipt does not
automatically establish physical actuation completion.
Das Expires 29 April 2027 [Page 230]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A transactional database commit receipt may support a stronger claim
concerning the database resource state.
The actual observation and evidence qualifications determine the
supported result.
16.19 — QUALIFIED NON-EFFECTUATION
The system may classify an earlier operation as not performed only
when supported by sufficient evidence.
Possible evidence may include:
A protected dispatcher record establishing that dispatch never
crossed its controlled boundary;
A receiving transaction system conclusively reporting rejection
without mutation;
A qualified receiver state proving that the operation identifier was
never accepted within an appropriately complete observation scope;
Or another technically sufficient negative-effect condition.
A receiver query returning no record may be insufficient if the
receiving system can discard records, process operations outside that
registry, or fail to expose a complete authoritative history.
The negative conclusion must therefore be limited to the evidence
assurance actually established.
5.4.3.26. Original Source — Global Page 1410
16.20 — SAFE RETRY CLASSES
The system may distinguish several retry classes.
16.20.1 — Confirmed Non-Effectuation Retry
A new attempt may be considered after qualified evidence establishes
that the original effect did not occur.
16.20.2 — Receiver-Idempotent Retry
A repeated transmission may be permitted under a verified receiver
duplicate-suppression guarantee covering the same logical operation.
16.20.3 — Transactionally Idempotent Retry
Das Expires 29 April 2027 [Page 231]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The receiver may atomically return the result of an already committed
mutation without applying it again.
16.20.4 — Idempotent Operation Semantics
The actual operation may have semantics making repetition safe under
the defined resource conditions.
16.20.5 — Observation-Only Retry
A status query or equivalent non-effecting observation may be
repeated where permitted.
16.20.6 — Separately Authorized Recovery
A new consequential operation may be authorized following appropriate
qualified outcome classification.
16.20.7 — Unsafe Retry
If no sufficient retry-safety condition can be established, the
original effect remains fenced.
16.20.8 — Technical Limitation
A delay, exponential backoff interval, or operator impatience does
not establish a safe retry class.
16.21 — RETRY FENCE
A protected retry fence may be associated with the logical effect
identifier.
5.4.3.27. Original Source — Global Page 1411
The fence may prevent:
Submission of a new operation identifier for the same unresolved
effect;
Reactivation of consumed finality authority;
Duplicate outbox processing outside the permitted dispatch protocol;
Unrelated recovery workers issuing the same consequential effect;
And unqualified automatic operation replay.
Das Expires 29 April 2027 [Page 232]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The fence may be lifted only through a current protected transition
satisfying the selected outcome and retry conditions.
A status query may be permitted while effecting commands remain
withheld.
16.22 — MONOTONIC AUTHORITY GENERATIONS
The system may maintain a protected generation for each relevant
authority or logical effect.
A successful consumption transition advances the generation.
An untrusted agent snapshot cannot restore the earlier generation.
A recovered worker must obtain the current authoritative state.
A malicious process cannot produce valid new consequential authority
merely by editing a local journal copy or resetting a counter in its
own address space.
The assurance may be provided through protected transactional state,
hardware-supported monotonic mechanisms, an appropriately replicated
authoritative controller, or another equivalent construction.
16.23 — FENCING OLD COORDINATORS
A distributed system may elect a new dispatcher or coordinator after
failure.
However, an old coordinator may later resume.
A simple lease expiration at the coordinator is insufficient if the
old coordinator can still perform unmediated operations.
A principal implementation may require the actual receiver or
effectuation sink to verify a current fencing generation.
5.4.3.28. Original Source — Global Page 1412
16.23.1 — Current Leader Generation
The protected system maintains an authoritative coordinator
generation.
16.23.2 — Dispatch Authorization
A dispatcher receives bounded authority under that generation.
Das Expires 29 April 2027 [Page 233]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
16.23.3 — Leader Replacement
The generation advances when control changes.
16.23.4 — Stale Worker
The old worker's generation becomes invalid.
16.23.5 — Receiver Enforcement
The actual resource controller rejects commands from obsolete
generations.
16.23.6 — Limitation
A fencing counter that is not enforced at the actual consequence
boundary cannot independently prevent stale external effects.
16.24 — JOURNAL ROLLBACK PROTECTION
The journal may be protected through one or more mechanisms:
Authoritative transactional generations;
Tamper-evident record chaining;
Protected checkpoints;
Hardware-backed persistent counters;
Quorum-durable state;
Authenticated state roots;
Or another suitable mechanism.
A hash chain detects some modifications under its assumptions but
does not independently prevent an attacker from replacing the entire
chain with an older valid-looking copy.
A stronger rollback-resistant implementation must bind the accepted
journal state to an authoritative non-rollbackable reference.
5.4.3.29. Original Source — Global Page 1413
16.24.1 — Checkpoint
Das Expires 29 April 2027 [Page 234]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The system may periodically commit a protected summary of earlier
transitions.
16.24.2 — Historical Records
Earlier journal entries may be compacted if the necessary consumption
and outcome properties remain preserved.
16.24.3 — Compaction Safety
Removing historical records must not allow a consumed operation
identifier to be treated as newly valid.
16.24.4 — Restart
Current authoritative state must be reconstructed before effectuation
resumes.
16.25 — JOURNAL COMPACTION AND LONG-DURATION AUTHORITY
Long-running systems may accumulate many protected operation records.
The system may retain sufficient authenticated state to preserve:
Consumed authority identifiers;
Current logical effect identities;
Unresolved external outcomes;
Active receiver duplicate-suppression requirements;
Relevant revocation generations;
Recovery fences;
And completed effect references required for later causal
continuation.
The journal may store compact commitments or state summaries where
sufficient.
A compacted record must not eliminate information necessary for the
selected security predicate.
A receipt or state summary representing earlier effectuation must
preserve its qualified assurance scope.
Das Expires 29 April 2027 [Page 235]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.4.3.30. Original Source — Global Page 1414
16.26 — MULTI-SINK CONSEQUENCES
One logical workflow may produce several distinct external effects.
For example, an operation may update a database, transmit an
instruction, and activate a hardware command.
The system must determine whether these consequences are:
One atomic protected resource transaction;
Separate bounded Candidate Acts;
A causally ordered chain;
Or a distributed operation requiring qualified partial-outcome
handling.
A single consumed authorization for a high-level workflow does not
automatically prove that every external consequence occurred.
Each actual effect may require its own Finality-Sink state and
evidence.
Where successor authority depends upon prior real completion, the
accepted actual-effect receipt remains mandatory under the selected
causal protocol.
16.27 — PARTIAL EFFECTUATION
A protected operation may have several components.
Some may complete.
Others may fail.
The journal may represent each applicable component separately.
A representative partial outcome may comprise:
PROTECTED_PARTIAL_EFFECT_STATE = { parent_logical_effect,
child_effect_references, qualified_completed_components,
qualified_rejected_components, unresolved_components,
consumed_authority_components, current_resource_states,
recovery_authority_references, protected_state_authentication }
Das Expires 29 April 2027 [Page 236]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.4.3.31. Original Source — Global Page 1415
The system does not classify the entire operation as safely
unperformed merely because one component failed.
Any corrective or successor consequence requires appropriate current
authority.
16.28 — CRASH-RESILIENT DEVICE COMMANDS
A device command may have a more complex completion boundary than a
database mutation.
The device may acknowledge command acceptance before movement or
actuation begins.
It may acknowledge dispatch while the physical operation remains
incomplete.
It may complete the physical operation but lose connection before
reporting the result.
A protected hardware controller may therefore distinguish:
Command validated;
Command accepted;
Command queued;
Command issued;
Physical actuation started;
Physical actuation completed;
And completion uncertain.
Where supported, hardware-local protected state may prevent duplicate
command acceptance.
Where physical state can be observed, qualified sensor evidence may
support outcome reconciliation.
A protected command counter does not by itself establish that every
physical consequence completed exactly once.
16.29 — INFORMATION DISCLOSURE AS AN IRREVERSIBLE EFFECT
Das Expires 29 April 2027 [Page 237]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An information-release sink may transmit protected data to an
external recipient.
5.4.3.32. Original Source — Global Page 1416
If acknowledgement is lost, the system cannot automatically resend
the information without examining the applicable disclosure authority
and cumulative exposure conditions.
Even repeated transmission of identical information may affect a
privacy policy differently according to the recipient, timing, or
applicable model.
A protected disclosure journal may therefore bind:
The actual outgoing information;
The authorized recipient;
The applicable privacy state;
The consumed disclosure authority;
The transmission attempt;
And the relevant outcome uncertainty.
A local failure does not undo any information already received
externally.
16.30 — PROTECTED EFFECTUATION STATE MACHINE
A non-limiting state machine comprises:
CANDIDATE_PREPARED: A proposed consequential operation exists.
NON_EFFECTIVE: The effect remains withheld.
VALIDATION_PENDING: Required authority and evidence checks are
incomplete.
VALIDATION_ACCEPTED: Applicable validation predicates pass.
JOURNAL_PREPARED: A protected durable operation state is being
established.
JOURNAL_COMMITTED: The required operation record is durably
committed.
Das Expires 29 April 2027 [Page 238]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
FINALITY_ELIGIBLE: Current non-bearer finality authority is
available.
CONSUMPTION_PENDING: The protected consumption transition is being
performed.
AUTHORITY_CONSUMED: The corresponding finality use is durably
consumed.
DISPATCH_INTENT_COMMITTED: The exact externally addressed operation
is durably committed for controlled dispatch.
5.4.3.33. Original Source — Global Page 1417
DISPATCH_AUTHORIZED: The designated dispatcher may attempt the
committed operation under current protocol conditions.
DISPATCH_ATTEMPTED: The relevant effectuation interface has initiated
the request.
DISPATCH_UNCERTAIN: It is not known whether the operation crossed the
required external boundary.
RECEIVER_ACCEPTED: Qualified evidence establishes the selected
receiver acceptance state.
EFFECT_CONFIRMED: Qualified evidence establishes the actual specified
consequence.
EFFECT_REJECTED: Qualified evidence establishes the specified non-
effecting rejection.
EFFECT_PARTIAL: Qualified evidence establishes partial effectuation.
EFFECT_INDETERMINATE: The real consequence remains unresolved.
RETRY_FENCED: Additional effect attempts remain prohibited pending
safe eligibility.
RETRY_ELIGIBLE: The protected controller has established a valid
retry condition.
RECOVERY_PENDING: Separately governed recovery may be required.
TERMINATED: The operation has reached an authorized terminal state.
The state machine may be implemented through one protected resource
controller or several appropriately coordinated domains.
Das Expires 29 April 2027 [Page 239]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
16.31 — PRINCIPAL END-TO-END WORKFLOW
Step 1 — Establish Candidate Act. Identify the proposed consequential
operation.
Step 2 — Hold the Effect. Maintain Non-Effective State.
Step 3 — Verify Source Authority. Establish current permission for
the effect.
Step 4 — Verify Protected Evidence. Evaluate the required evidence,
including any cross-committed validation.
Step 5 — Reconstruct Actual Pending Operation. The Finality Sink
obtains the current real operation.
Step 6 — Bind Logical Effect Identity. Establish the precise
operation and target.
Step 7 — Establish Journal Scope. Identify the authoritative journal
and consumption domain.
5.4.3.34. Original Source — Global Page 1418
Step 8 — Verify Current Resource State. Confirm required target and
version conditions.
Step 9 — Verify Finality Enablement. Check current non-bearer
authority.
Step 10 — Verify No Prior Consumption. Establish available protected
use.
Step 11 — Prepare Durable Intent. Form the exact operation record.
Step 12 — Commit Required Journal State. Satisfy the selected
persistence barrier.
Step 13 — Consume Finality Authority. Commit the protected monotonic
transition.
Step 14 — Commit Dispatch Intent. Bind the actual external operation
to the consumed authority, atomically where the architecture
requires.
Step 15 — Verify Dispatcher Generation. Ensure current designated
effectuation ownership.
Das Expires 29 April 2027 [Page 240]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Step 16 — Release the Actual Operation. Permit only the committed
consequential effect.
Step 17 — Record Attempt State. Preserve qualified evidence
concerning dispatch.
Step 18 — Obtain Receiver Evidence. Query or receive the relevant
destination result.
Step 19 — Classify Outcome. Distinguish confirmed completion,
rejection, partial effect, and uncertainty.
Step 20 — Commit Outcome State. Authenticate the supported result.
Step 21 — Apply Retry Fence if Required. Prevent unsafe new
effectuation.
Step 22 — Reconcile Indeterminate State. Obtain further qualified
evidence where possible.
Step 23 — Evaluate Retry Eligibility. Permit another attempt only
under sufficient operation-specific conditions.
Step 24 — Govern Recovery. Require separately valid corrective
authority where applicable.
Step 25 — Enforce Terminal State. Prevent unauthorized later reuse
of the consumed finality authority.
16.32 — REFERENCE PSEUDOCODE: PROTECTED FINALITY PREPARATION
FUNCTION PREPARE_CRASH_CONSISTENT_FINALITY( candidate_act,
finality_sink,
5.4.3.35. Original Source — Global Page 1419
protected_journal ): actual_operation =
finality_sink.RECONSTRUCT_ACTUAL_PENDING_OPERATION() REQUIRE
VERIFY_CANDIDATE_ACT(candidate_act) REQUIRE
VERIFY_ACTUAL_OPERATION_CORRESPONDENCE( actual_operation,
candidate_act ) REQUIRE VERIFY_REQUIRED_VALIDATION_EVIDENCE(
candidate_act ) REQUIRE VERIFY_CURRENT_SOURCE_AUTHORITY(
candidate_act ) REQUIRE VERIFY_CURRENT_RESOURCE_STATE(
actual_operation ) REQUIRE VERIFY_CURRENT_NON_BEARER_ENABLEMENT(
candidate_act ) logical_id = DERIVE_PROTECTED_LOGICAL_EFFECT_ID(
candidate_act, actual_operation ) prepared = protected_journal
.ATOMIC_PREPARE({ logical_effect: logical_id, actual_operation:
HASH(actual_operation), candidate_act: HASH(candidate_act),
Das Expires 29 April 2027 [Page 241]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
finality_enablement: CURRENT_ENABLEMENT_REFERENCE(),
current_consumption_generation: CURRENT_MONOTONIC_GENERATION(),
5.4.3.36. Original Source — Global Page 1420
designated_sink: finality_sink.identity }) IF prepared !=
DURABLY_COMMITTED: RETURN HOLD RETURN prepared
The durable-commit test must correspond to the actual storage
guarantee.
16.33 — REFERENCE PSEUDOCODE: LOCAL ATOMIC EFFECT
FUNCTION COMMIT_LOCAL_ATOMIC_EFFECT( prepared_operation,
protected_resource_sink ): REQUIRE VERIFY_PREPARED_OPERATION(
prepared_operation ) REQUIRE VERIFY_CURRENT_AUTHORITY(
prepared_operation ) transaction = protected_resource_sink
.BEGIN_PROTECTED_TRANSACTION() REQUIRE transaction
.VERIFY_ACTUAL_RESOURCE_AND_OPERATION() REQUIRE transaction
.VERIFY_EXPECTED_RESOURCE_VERSION() REQUIRE transaction
.VERIFY_UNCONSUMED_FINALITY_GENERATION() transaction
.APPLY_AUTHORIZED_RESOURCE_MUTATION() transaction
.CONSUME_FINALITY_AUTHORITY() transaction .COMMIT_OPERATION_JOURNAL()
result = transaction.COMMIT_ATOMICALLY()
5.4.3.37. Original Source — Global Page 1421
IF result != COMMITTED: RETURN
RECONCILE_AUTHORITATIVE_TRANSACTION_STATE RETURN
QUALIFIED_LOCAL_COMMIT_RESULT(result)
The transaction must cover both consumption and the claimed local
effect.
16.34 — REFERENCE PSEUDOCODE: DURABLE REMOTE DISPATCH INTENT
Das Expires 29 April 2027 [Page 242]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
FUNCTION PREPARE_REMOTE_EFFECT_DISPATCH( prepared_operation,
protected_dispatch_controller ): REQUIRE VERIFY_PREPARED_OPERATION(
prepared_operation ) REQUIRE VERIFY_CURRENT_FINALITY_AUTHORITY()
REQUIRE VERIFY_ACTUAL_OPERATION_BINDING( prepared_operation ) REQUIRE
VERIFY_RECEIVER_AND_DESTINATION_SCOPE() committed =
protected_dispatch_controller .ATOMIC_CONSUME_AND_RECORD_INTENT({
logical_effect: prepared_operation.logical_id, actual_operation:
prepared_operation.actual_operation_digest, designated_receiver:
prepared_operation.receiver, authority_reference:
prepared_operation.finality_enablement, expected_generation:
CURRENT_FINALITY_GENERATION(), next_generation:
NEXT_MONOTONIC_GENERATION(), dispatch_payload_reference:
prepared_operation.payload_reference,
5.4.3.38. Original Source — Global Page 1422
receiver_duplicate_policy: CURRENT_RECEIVER_POLICY() }) IF committed
!= DURABLY_COMMITTED: RETURN DO_NOT_DISPATCH RETURN committed
A protected dispatcher may use this result only under the applicable
current dispatch and retry policy.
16.35 — REFERENCE PSEUDOCODE: CONTROLLED DISPATCH
FUNCTION DISPATCH_PROTECTED_REMOTE_EFFECT( committed_intent,
protected_dispatcher ): REQUIRE VERIFY_DURABLE_DISPATCH_INTENT(
committed_intent ) REQUIRE VERIFY_CURRENT_DISPATCHER_GENERATION(
protected_dispatcher ) REQUIRE
VERIFY_PAYLOAD_MATCHES_COMMITTED_OPERATION( committed_intent )
REQUIRE VERIFY_DESTINATION_BINDING( committed_intent ) REQUIRE
VERIFY_DISPATCH_ATTEMPT_ELIGIBILITY( committed_intent )
RECORD_PROTECTED_DISPATCH_ATTEMPT_START( committed_intent ) result =
protected_dispatcher .TRANSMIT_EXACT_COMMITTED_OPERATION(
committed_intent ) IF result == QUALIFIED_RECEIVER_COMMIT:
5.4.3.39. Original Source — Global Page 1423
RETURN COMMIT_QUALIFIED_COMPLETION(result) IF result ==
QUALIFIED_NON_EFFECTING_REJECTION: RETURN
COMMIT_QUALIFIED_REJECTION(result)
ESTABLISH_INDETERMINATE_OUTCOME_FENCE( committed_intent ) RETURN
OUTCOME_UNRESOLVED
The transport call must not be interpreted as conclusive evidence of
remote effectuation unless the relevant destination evidence actually
supports that claim.
16.36 — REFERENCE PSEUDOCODE: RECEIVER DEDUPLICATION
Das Expires 29 April 2027 [Page 243]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
FUNCTION PROCESS_RECEIVER_LOGICAL_EFFECT( incoming_effect,
protected_receiver ): REQUIRE VERIFY_INCOMING_OPERATION_AUTHORITY(
incoming_effect ) REQUIRE VERIFY_ACTUAL_OPERATION_IDENTITY(
incoming_effect ) transaction = protected_receiver
.BEGIN_ATOMIC_RESOURCE_TRANSACTION() prior = transaction
.LOOKUP_LOGICAL_EFFECT( incoming_effect.logical_id ) IF prior EXISTS:
REQUIRE prior.operation_digest ==
HASH(incoming_effect.actual_operation) RETURN transaction
.RETURN_EXISTING_COMMITTED_RESULT(prior) REQUIRE transaction
.VERIFY_CURRENT_RESOURCE_CONDITIONS() transaction
5.4.3.40. Original Source — Global Page 1424
.APPLY_RESOURCE_EFFECT( incoming_effect.actual_operation )
transaction .RECORD_COMMITTED_LOGICAL_EFFECT({ logical_id:
incoming_effect.logical_id, operation_digest:
HASH(incoming_effect.actual_operation), receiver_generation:
CURRENT_RECEIVER_GENERATION() }) RETURN
transaction.COMMIT_ATOMICALLY()
If the receiving resource cannot provide the required atomicity, the
implementation must rely upon another sufficiently qualified
duplicate-control mechanism or state the weaker achievable guarantee.
16.37 — REFERENCE PSEUDOCODE: INDETERMINATE OUTCOME RECONCILIATION
FUNCTION RECONCILE_INDETERMINATE_EFFECT( logical_effect,
protected_reconciliation_controller ): journal_state =
LOAD_AUTHORITATIVE_FINALITY_JOURNAL( logical_effect ) REQUIRE
VERIFY_JOURNAL_AUTHENTICITY( journal_state ) REQUIRE
VERIFY_CONSUMPTION_AND_DISPATCH_BINDING( journal_state ) evidence =
COLLECT_QUALIFIED_RECEIVER_OR_EFFECT_EVIDENCE( logical_effect ) IF
QUALIFIED_COMPLETION_ESTABLISHED(evidence): COMMIT_COMPLETED_OUTCOME(
5.4.3.41. Original Source — Global Page 1425
logical_effect, evidence ) RETURN EFFECT_CONFIRMED IF
QUALIFIED_NON_EFFECTUATION_ESTABLISHED(evidence):
COMMIT_NON_EFFECT_OUTCOME( logical_effect, evidence ) RETURN
EVALUATE_SEPARATE_RETRY_AUTHORITY IF
QUALIFIED_PARTIAL_EFFECT_ESTABLISHED(evidence):
COMMIT_PARTIAL_OUTCOME( logical_effect, evidence ) RETURN
REQUIRE_BOUNDED_RECOVERY ESTABLISH_INDETERMINATE_OUTCOME_FENCE(
logical_effect ) RETURN EFFECT_REMAINS_UNRESOLVED
A failed status query cannot automatically be classified as evidence
of non-effectuation.
Das Expires 29 April 2027 [Page 244]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
16.38 — REFERENCE PSEUDOCODE: SAFE RETRY ELIGIBILITY
FUNCTION VERIFY_RETRY_ELIGIBILITY( logical_effect, proposed_retry,
protected_retry_controller ): state =
LOAD_CURRENT_LOGICAL_EFFECT_STATE( logical_effect ) REQUIRE
VERIFY_CURRENT_SOURCE_AND_RECOVERY_AUTHORITY() REQUIRE
proposed_retry.logical_id == logical_effect.identifier
5.4.3.42. Original Source — Global Page 1426
REQUIRE proposed_retry.operation_digest ==
logical_effect.operation_digest IF state == QUALIFIED_COMPLETED:
RETURN DENY_DUPLICATE IF state == QUALIFIED_NON_EFFECT: RETURN
EVALUATE_NEW_BOUNDED_RETRY IF state == OUTCOME_INDETERMINATE:
receiver_guarantee = VERIFY_CURRENT_RECEIVER_DUPLICATE_GUARANTEE(
logical_effect ) IF receiver_guarantee == SUFFICIENT: REQUIRE
VERIFY_RECEIVER_STATE_RETENTION() REQUIRE
VERIFY_CURRENT_DISPATCHER_GENERATION() RETURN
PREPARE_SAME_LOGICAL_EFFECT_RETRANSMISSION RETURN KEEP_EFFECT_FENCED
RETURN REQUIRE_CURRENT_OUTCOME_CLASSIFICATION
The retransmission remains constrained to the originally committed
logical operation and the actual receiver's guarantee.
16.39 — REFERENCE PSEUDOCODE: JOURNAL RECOVERY AFTER CRASH
FUNCTION RECOVER_PROTECTED_FINALITY_JOURNAL( journal_store,
protected_recovery_controller ): checkpoint = journal_store
.LOAD_LATEST_AUTHENTICATED_CHECKPOINT() REQUIRE
VERIFY_CHECKPOINT_INTEGRITY( checkpoint ) REQUIRE
VERIFY_CHECKPOINT_NOT_ROLLED_BACK( checkpoint )
5.4.3.43. Original Source — Global Page 1427
records = journal_store .LOAD_SUBSEQUENT_DURABLE_RECORDS( checkpoint
) REQUIRE VERIFY_JOURNAL_SEQUENCE_AND_INTEGRITY( records ) state =
RECONSTRUCT_AUTHORITATIVE_FINALITY_STATE( checkpoint, records ) FOR
EACH operation IN state.unresolved_operations: IF
operation.external_dispatch_may_have_occurred:
APPLY_INDETERMINATE_OUTCOME_FENCE( operation ) ELSE: REQUIRE
QUALIFIED_NON_DISPATCH_EVIDENCE_BEFORE_RETRY( operation )
INVALIDATE_STALE_WORKER_GENERATIONS() RETURN
protected_recovery_controller
.COMMIT_RECOVERED_AUTHORITATIVE_STATE(state)
Recovered authority state must not be derived solely from a
requester-controlled snapshot.
Das Expires 29 April 2027 [Page 245]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
16.40 — REFERENCE PSEUDOCODE: OLD-WORKER FENCING
FUNCTION VERIFY_DISPATCHER_FENCING( incoming_operation,
protected_effectuation_sink ): current_generation =
protected_effectuation_sink
.LOAD_AUTHORITATIVE_DISPATCHER_GENERATION() REQUIRE
incoming_operation.dispatcher_generation == current_generation
REQUIRE VERIFY_LOGICAL_OPERATION_BINDING(
5.4.3.44. Original Source — Global Page 1428
incoming_operation ) REQUIRE
VERIFY_CURRENT_FINALITY_AND_DISPATCH_STATE( incoming_operation )
REQUIRE VERIFY_NO_INCOMPATIBLE_COMPLETED_EFFECT( incoming_operation )
RETURN CURRENT_DISPATCHER_ELIGIBLE
The check is effective only where the actual consequential sink
enforces it.
16.41 — WORKED EXAMPLE A: CRASH BEFORE LOCAL DATABASE COMMIT
An autonomous agent prepares a valid database update.
The protected Finality Sink verifies the actual record and mutation.
A transactional commit includes both the resource update and the
single-use finality-consumption state.
The process crashes before the transaction commits.
After recovery, the protected database establishes that the
transaction did not commit.
Neither the protected resource mutation nor the corresponding
finality consumption is treated as completed.
A subsequent operation remains subject to current authorization and
resource-state verification.
Expected demonstrable result: A local atomic transaction does not
leave the claimed resource mutation committed without its associated
finality state.
16.42 — WORKED EXAMPLE B: CRASH AFTER LOCAL DATABASE COMMIT
A protected database mutation and authority consumption commit
atomically.
Das Expires 29 April 2027 [Page 246]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The requester crashes before receiving confirmation.
Upon restart, the agent attempts to submit the same operation again.
The resource sink identifies the committed logical operation and
consumed authority.
5.4.3.45. Original Source — Global Page 1429
The protected resource mutation is not applied again.
The controller may return the qualified earlier result.
Expected demonstrable result: A lost client response does not produce
a second mutation within the supported local transaction domain.
16.43 — WORKED EXAMPLE C: CRASH AFTER REMOTE DISPATCH INTENT
An agent prepares a remote transaction.
The protected controller durably consumes the corresponding finality
authority and commits the exact dispatch intent.
The dispatcher crashes before it can establish whether the request
was sent.
After restart, the journal identifies the same logical operation and
consumed authority.
The recovered dispatcher does not invent a new authorized
transaction.
It determines whether the selected protocol permits retransmission of
the same operation or requires qualified receiver reconciliation.
Expected demonstrable result: Crash recovery preserves the original
operation identity and does not create fresh finality authority.
16.44 — WORKED EXAMPLE D: RECEIVER PROCESSED PAYMENT, RESPONSE LOST
An autonomous financial agent is authorized to execute one bounded
payment.
The Finality Sink durably consumes the authority and dispatches the
committed payment request.
The receiving transaction service atomically records the logical
payment identifier and completes the transaction.
Das Expires 29 April 2027 [Page 247]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The acknowledgement is lost.
The sender enters an indeterminate-outcome state.
A qualified status check later establishes the committed payment.
The protected controller records completion and refuses a second
independent payment.
5.4.3.46. Original Source — Global Page 1430
Expected demonstrable result: Missing acknowledgement does not
automatically produce a duplicate payment.
16.45 — WORKED EXAMPLE E: RECEIVER DEDUPLICATES SAME LOGICAL
OPERATION
An authorized protected dispatch is repeated under a verified retry-
safe protocol.
The destination receives the same logical identifier and identical
operation parameters.
Its transactional registry identifies the earlier committed
operation.
The destination returns the previously committed result rather than
applying another resource mutation.
If the second request uses a different amount or target with the same
identifier, it is rejected as incompatible.
Expected demonstrable result: The receiver does not treat an
operation identifier as permission to change the underlying effect.
16.46 — WORKED EXAMPLE F: IDEMPOTENCY RETENTION EXPIRED
A remote service maintains duplicate-suppression records for a
bounded period.
An original operation may have completed, but the sender lacks
confirmation.
A retry is proposed after the retention period.
The destination can no longer guarantee that the original identifier
will be recognized.
Das Expires 29 April 2027 [Page 248]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The protected retry controller refuses to treat the old identifier as
sufficient proof of safety.
It requires qualified outcome reconciliation or separately valid
recovery authority.
Expected demonstrable result: The system does not falsely extend
receiver duplicate-suppression guarantees beyond their actual
supported retention.
16.47 — WORKED EXAMPLE G: TWO RECOVERY WORKERS
An autonomous service crashes during a remote transaction.
Two replacement workers are started.
5.4.3.47. Original Source — Global Page 1431
Both discover the same unresolved operation in the durable journal.
The protected coordinator assigns current dispatch authority under a
new generation.
One worker obtains the eligible protected dispatch or reconciliation
role.
The other lacks current authority.
A stale worker cannot exercise the effectuation command at the
resource sink.
Expected demonstrable result: Multiple recovery workers do not
automatically multiply the permitted consequential operation.
16.48 — WORKED EXAMPLE H: FORMER LEADER RESUMES
A distributed controller loses connectivity.
A new leader is elected under a protected generation.
The previous leader later resumes and attempts to transmit a delayed
command.
The actual effectuation sink verifies current dispatcher generation.
The stale command is rejected.
Das Expires 29 April 2027 [Page 249]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A local lease variable stored by the old leader is not sufficient to
bypass the protected receiver-side fence.
Expected demonstrable result: Leadership transfer invalidates stale
consequential dispatch authority at the actual resource boundary.
16.49 — WORKED EXAMPLE I: EXTERNAL INFORMATION DISCLOSURE
An autonomous agent is authorized to send one protected document to a
specified recipient.
The release sink consumes the corresponding privacy and finality
authorization.
The message is transmitted.
The network connection fails before the sender receives
acknowledgement.
The system preserves the fact that the information may have been
disclosed.
It does not automatically restore the disclosure allowance or resend
the document to another recipient.
5.4.3.48. Original Source — Global Page 1432
Further release requires the applicable current privacy and authority
predicates.
Expected demonstrable result: A transmission uncertainty cannot be
used to bypass protected cumulative information-disclosure limits.
16.50 — WORKED EXAMPLE J: PHYSICAL ACTUATOR COMMAND
A robot receives a bounded movement command.
Its protected controller durably records command identity and
acceptance state.
The actuator begins moving.
The supervising process crashes.
Upon restart, the recovery controller does not assume that the
actuator remains at its starting position.
It obtains qualified current device-state evidence.
Das Expires 29 April 2027 [Page 250]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Where the physical outcome is uncertain, a new movement command
remains separately governed.
Expected demonstrable result: A software restart does not
automatically cause repetition of a physical command that may already
have produced an effect.
16.51 — WORKED EXAMPLE K: SNAPSHOT RESTORES OLD JOURNAL VIEW
An agent is authorized for one consequential effect.
The Finality Sink consumes the authority and records current
protected state.
The agent later restores a snapshot showing an earlier unused
enablement.
The protected journal controller maintains a current monotonic
generation outside the agent's copyable state.
The sink detects the stale authority generation.
The proposed duplicate effect is rejected.
Expected demonstrable result: An untrusted snapshot does not recreate
consumed protected finality authority.
5.4.3.49. Original Source — Global Page 1433
16.52 — WORKED EXAMPLE L: CRASH BETWEEN RECEIVER REGISTRY AND
MUTATION
A receiver implements duplicate suppression using two independent
nontransactional writes.
It first records an operation identifier, then attempts the resource
mutation.
A crash occurs between those steps.
A later retry sees the identifier and incorrectly assumes the
mutation completed.
The proposed stronger receiver protocol commits the relevant
operation record and resource mutation atomically where the resource
supports it.
Das Expires 29 April 2027 [Page 251]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Alternatively, the implementation must establish another suitable
correspondence mechanism and state its actual guarantee.
Expected demonstrable result: A receiver cannot claim strong
processing uniqueness solely from an idempotency-key table that may
diverge from the actual resource effect.
16.53 — WORKED EXAMPLE M: PARTIALLY COMPLETED MULTI-SERVICE WORKFLOW
An autonomous workflow performs three consequential service
operations.
The first service confirms a protected resource mutation.
The second service's effect remains uncertain.
The third operation has not been authorized for actual execution.
The journal maintains the individual effect references and qualified
states.
The system does not classify the entire workflow as unsuccessful
merely because the second service timed out.
A dependent third phase requires the specified prior-effect evidence
and its own current authority.
Any compensation is treated as a separate consequential operation.
Expected demonstrable result: Durable recovery preserves partial
real-effect state and prevents unsupported successor execution.
16.54 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
5.4.3.50. Original Source — Global Page 1434
16.54.1 — Duplicate Request Submission
An agent sends the same logical effect several times.
Protected authority and receiver-side state constrain repeated
execution.
16.54.2 — Forged Journal Entry
An attacker inserts a fabricated finality transition.
Protected record authentication rejects unauthorized state.
Das Expires 29 April 2027 [Page 252]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
16.54.3 — Journal Rollback
An attacker restores an older accepted journal.
Current authoritative generation prevents revival of consumed
authority.
16.54.4 — Journal Truncation
An attacker removes recent consumption records.
Protected checkpoints or other authoritative state detect invalid
historical restoration.
16.54.5 — Journal Reordering
An attacker changes the apparent order of transitions.
Protected sequence and transition validation reject invalid state.
16.54.6 — Torn Write
A crash interrupts journal persistence.
The transaction or record-integrity mechanism prevents an incomplete
entry from being treated as committed.
16.54.7 — False Durability Claim
An application claims successful durable commit before the required
storage barrier.
The implementation must rely upon actual persistence guarantees.
16.54.8 — Dispatch Without Durable Intent
A process attempts an external effect before required protected
dispatch state is committed.
The controlled dispatcher refuses release.
16.54.9 — Consumed Authority Reissued
5.4.3.51. Original Source — Global Page 1435
An agent requests the same single-use capability after a timeout.
Current protected consumption state rejects unauthorized restoration.
Das Expires 29 April 2027 [Page 253]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
16.54.10 — Stale Snapshot
A restarted agent presents a previously valid old reference.
Monotonic generation checks reject it.
16.54.11 — Concurrent Consumption
Several agents race to exercise one finality allowance.
An authoritative protected transition prevents duplicate consumption.
16.54.12 — Double Recovery Worker
Several workers independently resume one operation.
Protected dispatcher generation and operation state restrict
competing attempts.
16.54.13 — Stale Leader
A former coordinator submits commands after leadership transfer.
The actual sink verifies fencing generation.
16.54.14 — Operation Identifier Collision
Different effects use the same logical identifier.
Protected operation-digest binding detects the mismatch.
16.54.15 — Payload Substitution
A dispatcher changes the committed outgoing payload.
Actual dispatch and receiver verification reject the mismatch.
16.54.16 — Recipient Substitution
A committed transaction is redirected toward another destination.
Protected destination binding rejects unauthorized redirection.
16.54.17 — Receiver Registry Deletion
A receiver loses duplicate-suppression history.
Das Expires 29 April 2027 [Page 254]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.4.3.52. Original Source — Global Page 1436
The system cannot rely upon a guarantee no longer established.
16.54.18 — Receiver Registry Rollback
A previously processed operation appears new after destination-state
restoration.
Strong guarantees require appropriately protected receiver
persistence or other sufficient effect uniqueness controls.
16.54.19 — Registry/Effect Nonatomicity
The receiver records an identifier separately from the mutation.
The protected implementation requires an appropriate correspondence
or states weaker guarantees.
16.54.20 — Expired Idempotency Key
An attacker retries after deduplication retention ends.
The protected retry controller demands current verified safety.
16.54.21 — Status Query False Negative
A receiver reports no record despite a possible earlier effect.
The system evaluates whether that response conclusively supports non-
effectuation.
16.54.22 — Forged Success Receipt
An attacker supplies false receiver completion evidence.
The outcome verifier requires authenticated qualified observation.
16.54.23 — Forged Failure Receipt
An attacker falsely claims the original effect did not occur.
The protected controller checks negative-effect evidence.
16.54.24 — Lost Acknowledgement
A successful external operation has no sender-visible response.
Das Expires 29 April 2027 [Page 255]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The state remains indeterminate until adequately reconciled.
16.54.25 — Timeout-As-Retry Authority
An agent treats timeout as permission to create a new effect.
5.4.3.53. Original Source — Global Page 1437
The indeterminate-outcome fence rejects the inference.
16.54.26 — Backoff Misuse
A requester waits and then resubmits an unsafe operation.
Elapsed time does not substitute for outcome evidence.
16.54.27 — Resource Version Drift
A resource changes between authorization and actual effect.
The sink verifies current resource conditions.
16.54.28 — Tool Semantic Change
A retried command gains additional side effects.
Current operation-contract and effect binding reject unauthorized
changes.
16.54.29 — Cross-Sink Replay
One consumed authority is presented at another effectuation sink.
Protected designated-sink and coordination state reject invalid
reuse.
16.54.30 — Distributed Split Brain
Multiple controllers simultaneously claim authoritative consumption
control.
The implementation requires appropriate coordination or bounded
nonoverlapping authority.
16.54.31 — Network Partition
The destination's status cannot be queried.
Das Expires 29 April 2027 [Page 256]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The system preserves indeterminate state rather than inventing
completion or failure.
16.54.32 — Privacy Budget Recredit
An uncertain disclosure is incorrectly treated as never transmitted.
Protected exposure accounting retains appropriate charge or
uncertainty.
16.54.33 — Physical Command Replay
A device command is reissued after uncertain actuation.
Protected hardware and actual-state verification constrain retry.
5.4.3.54. Original Source — Global Page 1438
16.54.34 — Unauthorized Compensation
An agent attempts to reverse a possibly nonexistent effect.
The correction requires separate qualified recovery authority.
16.54.35 — Residual Effect Misclassification
A compensation is incorrectly described as deleting all earlier
consequences.
The system preserves qualified actual and residual effect state.
16.54.36 — Cryptographic Identifier Reuse
A nonce or transaction identifier is reused in an incompatible
protected context.
Identity, generation, and operation bindings prevent unauthorized
acceptance.
16.54.37 — Journal Verification Exhaustion
An attacker supplies excessively large or malformed journal data.
Protected verification work is bounded.
16.54.38 — Checkpoint Forgery
An attacker provides an invalid protected checkpoint.
Das Expires 29 April 2027 [Page 257]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Current authoritative authentication and generation checks reject it.
16.54.39 — Compromised Dispatcher
A dispatcher attempts an effect outside the committed intent.
The actual resource sink enforces current operation-specific
authority.
16.54.40 — Compromised Finality Sink
The protected consequential interface is compromised.
A stronger guarantee requires an appropriately protected remaining
enforcement boundary.
16.54.41 — Cross-Provider State Confusion
Remote systems associate one operation identifier with differing
authority assumptions.
The receiver verifies the relevant authenticated operation and scope.
16.54.42 — Offline Authority Duplication
5.4.3.55. Original Source — Global Page 1439
Two disconnected nodes exercise the same unpartitioned authority.
The selected coordination must prevent such duplication or withhold
affected effects.
16.54.43 — Hardware Counter Reset
An untrusted device resets a local counter.
Authoritative protected generation state must be maintained under the
specified hardware trust model.
16.54.44 — Emergency Retry Abuse
An agent claims urgency to bypass indeterminate-outcome fencing.
Emergency authority must be independently authenticated and bounded.
16.54.45 — Causal Receipt Misuse
Das Expires 29 April 2027 [Page 258]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A sender dispatch record is presented as evidence of remote effect
completion.
The protected successor verifier requires the correct qualified
actual-effect evidence.
16.55 — CRASH-INJECTION MATRIX
A non-limiting crash-injection test may examine these boundaries:
Crash Point A — Before operation preparation. No current committed
Candidate Act is presumed.
Crash Point B — During journal preparation. Incomplete entries are
not treated as durable finality state.
Crash Point C — After durable preparation but before consumption.
Current authoritative state determines eligibility for the next valid
transition.
Crash Point D — During authority consumption. Transaction-state
reconciliation determines whether consumption committed.
Crash Point E — After consumption but before dispatch intent. A
correct implementation must not allow the external effect to occur
through an unrecorded authority transition; the chosen protocol must
preserve or reconcile any incomplete coupling state.
Crash Point F — After atomic consumption and dispatch-intent
commitment. The committed logical operation remains identifiable;
retransmission requires the selected safety predicates.
Crash Point G — During transmission. External effectuation may be
uncertain.
5.4.3.56. Original Source — Global Page 1440
Crash Point H — After receiver acceptance but before resource
mutation. The receiver's stated guarantee determines whether the
effect can be recovered safely.
Crash Point I — During receiver mutation. Protected destination
transaction semantics determine the supported outcome.
Crash Point J — After receiver commit but before acknowledgement. A
retry must not create an additional mutation where strong receiver
deduplication is claimed.
Das Expires 29 April 2027 [Page 259]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Crash Point K — After sender receives acknowledgement but before
outcome journaling. Durable receiver evidence may support qualified
reconciliation.
Crash Point L — After outcome commit but before requester
notification. The requester may receive the previously committed
result without repeating the effect.
Crash Point M — During journal checkpoint. The authoritative prior
consumption and unresolved-effect state remain recoverable.
Crash Point N — During workload migration. Old ownership and
dispatch generations are appropriately fenced.
Crash Point O — During distributed controller failover. New
leadership does not permit stale workers to issue unmediated
commands.
Each point should be tested against actual resource effects, not only
software return codes.
16.56 — PRESENT-DAY PHOSITA REFERENCE IMPLEMENTATION
16.56.1 — Minimum Prototype
A feasible reference implementation may comprise:
An autonomous-agent process;
A protected Finality Sink;
An authoritative transactional journal;
A durable dispatch-intent queue;
A receiving transactional service;
A receiver-side operation registry;
And an outcome reconciliation controller.
16.56.2 — Protected Candidate Act
5.4.3.57. Original Source — Global Page 1441
The agent proposes one bounded resource mutation.
16.56.3 — Finality Validation
Das Expires 29 April 2027 [Page 260]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The sink verifies current actual-operation scope and non-bearer
authority.
16.56.4 — Durable Journal
The controller commits the required operation, authority, and
dispatch state.
16.56.5 — Receiver-Side Registry
The receiver records logical operation identity and resource mutation
in one protected transaction where supported.
16.56.6 — Crash Injection
The prototype deliberately interrupts the sender at selected state
boundaries.
16.56.7 — Duplicate Submission
The agent submits the same logical operation several times.
16.56.8 — Lost Acknowledgement
The receiver commits an effect but the sender's response is
suppressed.
16.56.9 — Receiver Reconciliation
The protected controller obtains qualified current result evidence.
16.56.10 — Stale Snapshot
The requester restores old local authority state.
16.56.11 — Old Worker
A previous dispatcher attempts execution after failover.
16.56.12 — External Resource Limit
The prototype distinguishes exactly-once local consumption from the
actual receiver guarantees.
16.56.13 — Hardware Extension
A protected device command controller may provide current operation
generation and durable acceptance state.
Das Expires 29 April 2027 [Page 261]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
16.56.14 — Trust Model
5.4.3.58. Original Source — Global Page 1442
The implementation must specify the actual storage, receiver,
dispatcher, and Finality-Sink components required to remain
protected.
16.57 — NON-LIMITING PROPOSED FEASIBILITY EXPERIMENTS
The following experiments are proposed and are not represented as
completed results.
Experiment 1 — Valid Single-Use Finality: Commit one authorized
operation and corresponding consumption state.
Experiment 2 — Local Atomic Commit: Verify that a resource mutation
and authority consumption commit together.
Experiment 3 — Local Atomic Abort: Verify that neither claimed local
effect nor consumption commits after transaction abort.
Experiment 4 — Crash Before Preparation: Confirm the absence of
assumed committed authority.
Experiment 5 — Crash During Journal Write: Test incomplete journal
entry handling.
Experiment 6 — Crash After Durable Preparation: Recover current
protected operation state.
Experiment 7 — Crash During Consumption: Reconcile whether the atomic
transition committed.
Experiment 8 — Crash After Consumption: Reject attempted revival of
consumed authority.
Experiment 9 — Atomic Dispatch Intent: Verify protected coupling
between consumption and dispatch intent.
Experiment 10 — Crash After Intent: Recover the exact committed
external operation.
Experiment 11 — Crash During Transmission: Preserve an indeterminate
outcome.
Experiment 12 — Receiver Success, Response Lost: Reconcile committed
external effect without reapplying it.
Das Expires 29 April 2027 [Page 262]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Experiment 13 — Receiver Rejection: Verify qualified non-effecting
rejection state.
Experiment 14 — Partial Receiver Effect: Preserve component-specific
completed and unresolved state.
Experiment 15 — Duplicate Client Request: Test protected logical
operation identity.
5.4.3.59. Original Source — Global Page 1443
Experiment 16 — Duplicate Queue Delivery: Verify receiver handling of
repeated delivery.
Experiment 17 — Receiver Atomic Deduplication: Commit operation
registry and resource effect together.
Experiment 18 — Receiver Nonatomic Registry: Expose the failure modes
of separate registry and mutation writes.
Experiment 19 — Idempotency Parameter Mismatch: Reuse one identifier
with changed operation parameters.
Experiment 20 — Idempotency Retention Expiry: Test retry refusal
after duplicate-suppression evidence becomes insufficient.
Experiment 21 — Forged Receiver Receipt: Reject untrusted completion
evidence.
Experiment 22 — Forged Failure Record: Reject unsupported assertions
of non-effectuation.
Experiment 23 — Qualified Status Query: Confirm a completed external
effect.
Experiment 24 — Status Query False Negative: Ensure incomplete
negative evidence does not authorize retry.
Experiment 25 — Indeterminate Fence: Verify suppression of unsafe
effecting requests.
Experiment 26 — Observation-Only Reconciliation: Permit safe status
checking while effects remain fenced.
Experiment 27 — Verified Non-Effectuation: Permit consideration of a
bounded new attempt under current authority.
Das Expires 29 April 2027 [Page 263]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Experiment 28 — Verified Receiver Idempotency: Test safe same-
logical-operation retransmission.
Experiment 29 — Expired Receiver State: Withhold retransmission when
the guarantee is no longer supported.
Experiment 30 — Concurrent Authority Consumption: Attempt two
simultaneous uses of one single-use enablement.
Experiment 31 — Journal Snapshot Rollback: Restore stale consumption
state and verify rejection.
Experiment 32 — Journal Truncation: Detect invalid removal of
protected recent transitions.
Experiment 33 — Journal Reordering: Reject inconsistent protected
sequence state.
5.4.3.60. Original Source — Global Page 1444
Experiment 34 — Forged Checkpoint: Reject an unauthenticated
compressed journal state.
Experiment 35 — Checkpoint Recovery: Restore valid authority and
unresolved-effect state.
Experiment 36 — Dual Recovery Workers: Prevent unauthorized duplicate
recovery attempts.
Experiment 37 — Stale Leader: Reject an old dispatch generation at
the actual sink.
Experiment 38 — Distributed Consumption State: Verify protected
coordination of several sinks.
Experiment 39 — Network Partition: Preserve the required safety
properties while remote outcome evidence is unavailable.
Experiment 40 — Bounded Offline Partitioning: Verify nonoverlapping
preallocated authority under specified assumptions.
Experiment 41 — Payment Transaction: Demonstrate current amount,
recipient, and logical-effect binding.
Experiment 42 — Database Mutation: Demonstrate atomic local resource
and authority commit.
Das Expires 29 April 2027 [Page 264]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Experiment 43 — File Commit: Verify version-bound mutation and
consumption state.
Experiment 44 — Message Publication: Distinguish durable outbox
commit from receiver processing.
Experiment 45 — Data Disclosure: Preserve the possibility of actual
disclosure after lost acknowledgement.
Experiment 46 — Device Command: Distinguish command acceptance,
dispatch, and physical completion.
Experiment 47 — Partial Physical Actuation: Obtain qualified actual
device-state evidence before recovery.
Experiment 48 — Credential Activation: Prevent reactivation of
already consumed protected authority.
Experiment 49 — Cross-Domain Finality: Verify journaled authority and
receiver effects across independent administrative domains.
Experiment 50 — Causal Receipt Integration: Require accepted actual-
effect evidence for a dependent successor Candidate Act.
Experiment 51 — Protected Recovery Integration: Treat compensation as
a distinct current consequential operation.
5.4.3.61. Original Source — Global Page 1445
Experiment 52 — Version-Bound Reservation: Verify actual resource
state after interruption.
Experiment 53 — Quorum-Authorized Operation: Preserve collective
approval without confusing it with actual remote completion.
Experiment 54 — Coverage Change: Invalidate stale finality or
dispatch authority after a material enforcement-path change.
Experiment 55 — Model Replacement: Ensure a restarted or changed
model does not recreate consumed authority.
Experiment 56 — Tool Semantics Change: Reject a retry whose real
downstream effect differs from the committed operation.
Experiment 57 — Hardware Ownership Migration: Fence former-owner
commands after controlled reassignment.
Das Expires 29 April 2027 [Page 265]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Experiment 58 — Privacy Budget Accounting: Prevent uncertain
information releases from incorrectly restoring consumed privacy
allowance.
Experiment 59 — Verification Work Exhaustion: Bound processing of
malformed or excessive journal evidence.
Experiment 60 — Full Crash Matrix: Execute the principal protected
workflow with interruptions at every defined state boundary.
Experiment 61 — No Receiver Deduplication: Demonstrate the limitation
of exactly-once local authority without strong destination
guarantees.
Experiment 62 — Receiver Deduplication Present: Demonstrate the
stronger result available under qualified destination-side
transaction semantics.
Experiment 63 — No Public Blockchain: Maintain protected journal,
authority consumption, and recovery state through ordinary suitable
protected transactional infrastructure.
Experiment 64 — Hardware Journal: Implement selected monotonic state
in protected device or security hardware.
Experiment 65 — Independent Outcome Witness: Require qualified
external observation of a consequential effect.
Experiment 66 — Cross-Sink Replay: Present one logical operation and
authority at unintended resource interfaces.
Experiment 67 — Retired Journal Entry: Verify that safe compaction
does not recreate authority or erase unresolved effects.
5.4.3.62. Original Source — Global Page 1446
Experiment 68 — Controlled Exactly-Once Authorization: Measure that
only one permitted protected consumption transition commits under the
stated coordination model.
Experiment 69 — Remote Outcome Qualification: Demonstrate that the
same local-consumption result can correspond to confirmed remote
success, confirmed rejection, or indeterminate remote outcome.
Experiment 70 — End-to-End Evidence-to-Outcome: Verify the complete
protected relationship among actual operation reconstruction,
evidence-qualified finality, durable consumption, dispatch intent,
receiver result, and current reconciliation state.
Das Expires 29 April 2027 [Page 266]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Each experiment should identify the precise claimed guarantee and the
technical evidence that establishes it.
16.58 — PERFORMANCE, AVAILABILITY, AND INDUSTRIAL ENGINEERING
16.58.1 — Durable Write Cost
Protected persistence barriers may add latency to consequential
operations.
16.58.2 — Group Commit
Suitable implementations may batch journal persistence where the
claimed ordering and authority guarantees remain preserved.
16.58.3 — Journal Compaction
Authenticated checkpoints may reduce long-term storage requirements.
16.58.4 — Receiver Lookup
Operation identifiers may support efficient destination-side
duplicate checks.
16.58.5 — Protected State Caching
Read-only operation history may be cached within current
authoritative validity rules.
16.58.6 — Monotonic Counters
Appropriate counters or version generations may provide compact
consumption-state checks.
16.58.7 — Distributed Coordination
Global uniqueness across multiple sinks may impose consensus or
coordination overhead.
16.58.8 — Partition Availability
5.4.3.63. Original Source — Global Page 1447
The implementation may deliberately withhold effects when current
authority or outcome safety cannot be established.
16.58.9 — Retry Work Budget
Das Expires 29 April 2027 [Page 267]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A protected controller may limit status queries, retransmissions, and
reconciliation work.
16.58.10 — Receiver Retention Cost
Longer deduplication retention may require additional destination
storage.
16.58.11 — Hardware Persistence
Embedded systems may use suitable nonvolatile memory or protected
device state.
16.58.12 — Real-Time Requirements
A latency-sensitive device may require an implementation-specific
protected journal and command controller with bounded timing
behavior.
16.58.13 — Safety Qualification
Reduced latency must not depend upon silently removing mandatory
authority or current-effect verification.
16.58.14 — Assurance Statement
The implementation must state which of local authority uniqueness,
local transaction atomicity, dispatch uniqueness, receiver effect
uniqueness, and external completion are actually guaranteed.
16.59 — OPTIONAL ADVANCED FUTURE-ORIENTED CONCEPTS
16.59.1 — Long-Running Autonomous Agent Journals
Agents may preserve protected effect state across many sessions
without reviving consumed authority.
16.59.2 — Multi-Provider Transaction Continuity
Independently administered providers may exchange authenticated
logical effect and qualified outcome references.
16.59.3 — Cross-Cloud Protected Dispatch
Remote operations may retain durable operation identity and authority
across cloud-service changes.
Das Expires 29 April 2027 [Page 268]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.4.3.64. Original Source — Global Page 1448
16.59.4 — Confidential-Computing Journal Services
Protected computing environments may maintain authenticated authority
and dispatch state.
16.59.5 — Hardware Security Modules
Protected hardware may enforce selected monotonic finality state.
16.59.6 — Accelerator Command Journaling
Command submissions and effectful accelerator operations may be
associated with protected durable operation state.
16.59.7 — Robotic Command Continuity
Autonomous robots may distinguish actual motion, command acceptance,
and uncertain command outcome following controller restarts.
16.59.8 — Industrial Device Recovery
Protected equipment may retain durable consequential command identity
through power interruptions.
16.59.9 — Network Configuration Transactions
Programmable network devices may journal qualified accepted changes
and prevent unsafe replay.
16.59.10 — Satellite and Intermittent Connectivity
Remote infrastructure may maintain bounded protected effect state
during communication outages.
16.59.11 — Privacy-Preserving Receiver Evidence
A receiving domain may provide qualified outcome evidence without
unnecessarily disclosing protected resource contents.
16.59.12 — Cryptographic Key Migration
Journal authentication primitives may change while protected
authority and consumption continuity remain intact.
16.59.13 — Future Shared Execution Fabric
Das Expires 29 April 2027 [Page 269]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Distributed compute and hardware systems may use common logical
operation and monotonic consumption protocols.
16.59.14 — Autonomous Financial Infrastructure
5.4.3.65. Original Source — Global Page 1449
Consequential transactions may be protected from duplicate execution
following orchestration or network faults.
16.59.15 — Causal Multi-Effect Systems
Dependent effects may require accepted earlier outcome evidence in
addition to durable current authorization.
16.59.16 — Dynamic Workload Migration
Protected dispatch generations may prevent former execution
environments from reusing consequential authority.
16.59.17 — Hardware-Level Receiver Deduplication
A device may record command identities and effect state under
suitable protected transaction or controller semantics.
16.59.18 — Distributed Authority Partitioning
Nonoverlapping bounded authority may support some disconnected
operations without duplicate use.
16.59.19 — Autonomous Recovery Governance
Recovery Candidate Acts may be journaled and consumed under the same
protected finality principles.
16.59.20 — Unified Finality Outcome Service
A protected service may provide authenticated operation journals,
consumption state, receiver evidence, and outcome reconciliation
across heterogeneous execution systems.
These implementations are proposed technical variations.
16.60 — OPTIONAL ADVANCED TECHNICAL COMBINATIONS
16.60.1 — Actual Operation Reconstruction Plus Durable Journal
Das Expires 29 April 2027 [Page 270]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The journal commits the actual operation verified by the Finality
Sink rather than an untrusted earlier description.
16.60.2 — Non-Bearer Finality Plus Monotonic Consumption
A copied authority reference cannot produce another valid consumption
after the permitted use is committed.
16.60.3 — Consumption Plus Dispatch Intent
5.4.3.66. Original Source — Global Page 1450
The exact external operation is durably associated with consumed
finality authority.
16.60.4 — Receiver Deduplication Plus Actual Mutation
A receiver binds logical operation identity to its actual committed
resource effect under a suitable transactional guarantee.
16.60.5 — Indeterminate Outcome Plus Retry Fence
A missing acknowledgement cannot independently activate a new effect.
16.60.6 — Qualified Non-Effectuation Plus New Authority
A new attempt may be considered only after sufficient evidence and
current operation-specific permission.
16.60.7 — Current Leader Generation Plus Sink Enforcement
A former dispatcher cannot effect commands after a protected
generation transfer.
16.60.8 — Snapshot Rollback Plus Protected Journal
A restored workload cannot restore consumed authority or erase
unresolved external effects.
16.60.9 — Multi-Sink Coordination Plus Partitioned Authority
Distributed effectuation may require shared authoritative consumption
or bounded nonoverlapping allocations.
16.60.10 — Causal Receipt Plus Qualified Outcome
A dependent successor operation may require accepted earlier actual-
effect evidence rather than a mere dispatch log.
Das Expires 29 April 2027 [Page 271]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
16.60.11 — Privacy Accounting Plus Dispatch Uncertainty
Potentially completed disclosures remain appropriately represented in
protected cumulative exposure state.
16.60.12 — Hardware Command Plus Actual Physical Observation
Command journal state may be combined with independently qualified
physical-effect evidence.
16.60.13 — Recovery Authorization Plus Journaled Earlier Outcome
Corrective operations remain distinct from the original consumed
finality authority.
16.60.14 — Current Coverage Plus Journal Continuity
5.4.3.67. Original Source — Global Page 1451
Topology changes may invalidate stale dispatch or finality paths
without erasing historical actual-effect state.
16.61 — PROPOSED INVENTIVE-STEP ANALYSIS
16.61.1 — Established Prior Art
Write-ahead logging, transactional outbox systems, idempotent
receivers, duplicate suppression, transactional commit, distributed
consensus, receiver operation registries, replay-resistant
identifiers, checkpoint recovery, and transaction reconciliation are
established technical areas.
The embodiment does not claim these individually.
16.61.2 — Candidate Objective Technical Problem
A candidate objective technical problem is:
How to maintain non-replayable operation-specific execution-finality
authority and safely reconcile actual consequential outcomes across
crashes, retries, and distributed failures when the protected
authorization-consumption event may not be atomic with the external
physical or remote effect.
16.61.3 — Candidate Technical Solution
A candidate combination comprises:
Das Expires 29 April 2027 [Page 272]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Actual Finality-Sink operation reconstruction;
Authenticated evidence-qualified operation authority;
Durable operation-specific finality journal state;
A monotonic protected consumption generation;
Atomic coupling of consumed authority and dispatch intent;
Receiver-side operation identity and qualified duplicate suppression
where supported;
Indeterminate-outcome fencing;
And independently verified outcome-based continuation or recovery.
16.61.4 — Technical Interaction
The actual Finality Sink determines the real operation rather than
trusting an earlier computational intention.
5.4.3.68. Original Source — Global Page 1452
The evidence verifier establishes current authority.
The durable journal preserves the accepted operation and its finality
state.
The consumption controller prevents restoration or unauthorized
repeated exercise.
The dispatch-intent controller binds external transmission to the
protected logical operation.
The receiver registry may prevent repeated application of the same
logical effect.
The outcome verifier distinguishes actual completion from
uncertainty.
The retry fence prevents an unresolved operation from becoming an
independent new consequential authorization.
The recovery controller may later authorize a separate corrective
operation under appropriate qualified evidence.
16.61.5 — Not Merely a Write-Ahead Log
Das Expires 29 April 2027 [Page 273]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A journal may preserve state but does not independently determine
whether the original operation was authorized or whether an external
effect occurred.
The proposed arrangement binds durable state to actual Finality-Sink
operation verification and protected non-bearer authority.
16.61.6 — Not Merely an Outbox
A transactional outbox may reliably retain messages for delivery.
The proposed arrangement additionally restricts dispatch to the
precise effect whose finality authority has been independently
validated and durably consumed.
16.61.7 — Not Merely Idempotency
Idempotency may constrain repeated operations under receiver-specific
assumptions.
The proposed architecture additionally governs source authority,
actual operation binding, journal continuity, and protected outcome
classification.
16.61.8 — Not Merely a Single-Use Token
A single-use authorization may prevent repeated local consumption.
The proposed stronger relationship explicitly governs crashes between
consumption and actual external effectuation.
16.61.9 — Not Merely Transaction Recovery
Conventional recovery may restore an internal computational workflow.
5.4.3.69. Original Source — Global Page 1453
The proposed principal arrangement prevents the recovery process from
reconstructing fresh consequential authority merely because earlier
external completion was unobserved.
16.61.10 — Candidate Narrow Inventive Kernel
A protected autonomous consequential execution system in which an
independently enforcing Finality Sink reconstructs an actual pending
operation, verifies operation-specific non-bearer authority, durably
binds a monotonic authority-consumption transition to an
authenticated dispatch-intent record for that operation, and
Das Expires 29 April 2027 [Page 274]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
maintains protected indeterminate-outcome state that prevents
unsupported repeat effectuation until qualified destination evidence,
a verified idempotent retry condition, or separately authorized
recovery permits a defined successor transition.
16.61.11 — Additional Local Transaction Kernel
A narrower candidate may require one atomic transaction associating
an actual protected resource mutation with operation-specific
finality consumption.
16.61.12 — Additional Receiver Kernel
Another candidate may require authenticated logical effect identity
and receiver-side atomic binding of duplicate state to the actual
committed resource mutation.
16.61.13 — Additional Anti-Rollback Kernel
Another candidate may require protected monotonic finality
generations and journal checkpoint continuity preventing workload or
state restoration from reviving consumed authority.
16.61.14 — Additional Hardware Kernel
Another candidate may require durable device-command acceptance
state, current hardware authority, and qualified physical-effect
observation before repeat actuation.
16.61.15 — Hindsight Considerations
A proper inventive-step analysis should consider established
transactional messaging systems, secure payment gateways, capability-
based transaction controls, idempotent APIs, replicated transaction
logs, and existing fault-tolerant resource controllers.
A claim to journaling a permission and checking an idempotency key
may be obvious.
A stronger claim should identify the particular non-bypassable
binding among actual-effect reconstruction, protected finality
consumption, durable dispatch intent, and outcome-dependent authority
transitions.
16.61.16 — Patentability Qualification
Terminology such as exactly-once authorization, protected journal, or
outcome fence does not independently establish novelty.
Das Expires 29 April 2027 [Page 275]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.4.3.70. Original Source — Global Page 1454
The attainable guarantees depend upon actual storage, network,
receiver, and resource-effect semantics.
A system must not claim universal exactly-once physical or remote
effectuation without a technically sufficient implementation and
supporting evidence.
16.62 — INDUSTRIAL APPLICABILITY
16.62.1 — Enterprise Autonomous Agents
Autonomous enterprise workflows may retain safe consequential
operation state across restarts and lost tool responses.
16.62.2 — Cloud Infrastructure
Cloud services may durably bind protected authority to external
resource changes.
16.62.3 — Distributed Microservices
Services may reconcile partial effectuation and duplicate message
delivery under protected operation identity.
16.62.4 — Financial Transactions
Payment controllers may prevent unsupported duplicate payments
following timeout or acknowledgement loss.
16.62.5 — Electronic Commerce
Ordering, inventory, payment, and delivery operations may preserve
accurate partial-effect state.
16.62.6 — Banking Infrastructure
Account mutations may be transactionally bound to current
authorization and logical operation records.
16.62.7 — Database Systems
Protected resource transactions may atomically associate mutation and
authority consumption.
16.62.8 — Storage Systems
Das Expires 29 April 2027 [Page 276]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
File and object mutations may be governed by version-bound finality
and durable commit records.
16.62.9 — Message Brokers
5.4.3.71. Original Source — Global Page 1455
Protected messaging may distinguish durable publish intent from
receiving-system processing.
16.62.10 — Credential Management
Credential activation may be journaled and constrained against
unauthorized repeated exercise.
16.62.11 — Information Disclosure
Protected data-release controllers may preserve exposure-state
accounting despite uncertain delivery.
16.62.12 — Network Infrastructure
Autonomous configuration commands may retain protected operation
identity and current device-state evidence.
16.62.13 — Telecommunications
Distributed control-plane operations may be reconciled after service
or connectivity failures.
16.62.14 — Industrial Automation
Controller restarts may preserve command and qualified device-effect
state.
16.62.15 — Robotics
Physical commands may be protected against unsafe replay after
uncertain actuation.
16.62.16 — Autonomous Transportation
Selected consequential device instructions may require durable
operation identity and supported physical-state verification.
16.62.17 — Hardware Accelerators
Das Expires 29 April 2027 [Page 277]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Accelerator-originated effectful commands may be journaled and fenced
across workload recovery.
16.62.18 — Confidential Computing
Protected computation may produce valid authority evidence while
independent sinks maintain durable consequential state.
16.62.19 — Edge Computing
Disconnected devices may operate under bounded protected authority
and preserve unresolved effect state.
5.4.3.72. Original Source — Global Page 1456
16.62.20 — Satellite and Remote Systems
Long communication delays may be handled without automatically
treating missing acknowledgements as failed commands.
16.62.21 — Long-Running Multi-Agent Workflows
Agents may resume tasks or be replaced without recreating previously
consumed authority.
16.62.22 — Distributed Recovery Services
Recovery planners may use authenticated earlier-outcome state without
receiving unrestricted corrective permission.
16.62.23 — Heterogeneous Computing
Device, storage, network, and application sinks may share protected
logical effect and journal semantics.
16.62.24 — Future Autonomous Critical Systems
Persistent execution-finality records may provide the basis for
bounded consequential authority across evolving computational and
physical infrastructures.
The industrial utility concerns preventing duplicate, stale, or
unsupported consequential operations while preserving technically
accurate evidence concerning actual effects.
16.63 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
16.63.1 — Candidate Independent System Claim
Das Expires 29 April 2027 [Page 278]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A candidate system may comprise:
A protected Finality Sink configured to reconstruct the actual
pending consequential operation;
An evidence and authority verifier configured to validate current
operation-specific non-bearer enablement;
A protected durable journal configured to store authenticated
operation and consumption transitions;
A monotonic finality-consumption controller configured to prevent
unauthorized repeated consumption;
A protected dispatch-intent controller configured to associate
consumed authority with a specified external operation;
5.4.3.73. Original Source — Global Page 1457
An outcome-state controller configured to distinguish qualified
completion, non-effectuation, partial effect, and uncertainty;
And a reconciliation controller configured to withhold further
effectuation unless the applicable retry or recovery conditions are
independently established.
16.63.2 — Candidate Independent Method Claim
A corresponding method may comprise:
Constructing a consequential Candidate Act;
Maintaining the effect non-effective;
Verifying the actual pending operation at its Finality Sink;
Validating current non-bearer authority;
Durably committing an authenticated operation-specific journal state;
Consuming finality authority through a monotonic protected
transition;
Binding the resulting consumption to a specified dispatch intent;
Attempting the governed external effect;
Evaluating qualified outcome evidence;
Das Expires 29 April 2027 [Page 279]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
And preventing unsupported additional effectuation where the earlier
result remains indeterminate.
16.63.3 — Candidate Independent Local Atomicity Claim
Another candidate may require atomic commitment of protected resource
mutation, actual operation identity, and finality consumption within
one resource transaction domain.
16.63.4 — Candidate Independent Remote-Effect Claim
Another candidate may require durable consumption–dispatch-intent
coupling, receiver-side operation identity, qualified outcome
reconciliation, and mandatory retry fencing.
16.63.5 — Candidate Independent Hardware Claim
A protected device apparatus may maintain durable command identity,
current hardware authority, monotonic command-consumption state, and
qualified completion or uncertainty classification.
16.63.6 — Candidate Independent Anti-Rollback Claim
5.4.3.74. Original Source — Global Page 1458
Another candidate may require protected journal generations and sink-
enforced fencing that prevent stale computational or dispatcher
states from reactivating consumed consequential authority.
These candidate structures may overlap and should be examined for
unity, prior-art distinctions, and support.
16.64 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
Dependent aspect 1: The system constructs an authenticated Candidate
Act.
Dependent aspect 2: The actual pending operation is reconstructed by
a protected Finality Sink.
Dependent aspect 3: Current source authority is verified immediately
before protected finality consumption.
Dependent aspect 4: Cross-committed validation evidence is associated
with the operation.
Dependent aspect 5: A stable logical effect identifier is
established.
Das Expires 29 April 2027 [Page 280]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Dependent aspect 6: Separate attempt identifiers represent permitted
dispatch attempts.
Dependent aspect 7: The operation identifier is bound to actual
parameters and resource identity.
Dependent aspect 8: A protected journal records the authorized
operation descriptor.
Dependent aspect 9: The journal records the finality enablement
reference.
Dependent aspect 10: The journal records the authority-consumption
generation.
Dependent aspect 11: The journal records dispatch-intent state.
Dependent aspect 12: The journal distinguishes dispatch intent from
actual dispatch.
Dependent aspect 13: The journal distinguishes dispatch from receiver
acceptance.
Dependent aspect 14: The journal distinguishes receiver acceptance
from qualified effect completion.
Dependent aspect 15: The journal records unresolved effectuation
outcomes.
Dependent aspect 16: Journal entries use protected authentication or
integrity commitments.
Dependent aspect 17: Journal ordering is verified.
Dependent aspect 18: Incomplete journal writes are detected or safely
rejected.
5.4.3.75. Original Source — Global Page 1459
Dependent aspect 19: The system employs an actual durability barrier
before the specified external effectuation transition.
Dependent aspect 20: Protected journal state includes a monotonic
generation.
Dependent aspect 21: Snapshot rollback cannot revive consumed
authority.
Das Expires 29 April 2027 [Page 281]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Dependent aspect 22: A local resource mutation and authority
consumption commit atomically where supported.
Dependent aspect 23: A local transaction abort prevents the
corresponding protected mutation and consumption from being treated
as committed.
Dependent aspect 24: A remote dispatch intent is durably associated
with consumed authority.
Dependent aspect 25: The dispatcher may transmit only the committed
actual operation.
Dependent aspect 26: The dispatcher verifies the designated
destination.
Dependent aspect 27: The dispatcher verifies its current authorized
generation.
Dependent aspect 28: A stale dispatcher is rejected at the actual
effectuation sink.
Dependent aspect 29: A receiver maintains an authenticated logical
operation registry.
Dependent aspect 30: A receiver associates the logical identifier
with an actual operation digest.
Dependent aspect 31: An incompatible retry using the same identifier
is rejected.
Dependent aspect 32: A receiver atomically commits operation
deduplication state with the actual resource mutation.
Dependent aspect 33: A duplicate request may return the previously
committed result without reapplying the mutation.
Dependent aspect 34: The system verifies the receiver's actual
duplicate-suppression retention conditions.
Dependent aspect 35: A retry is withheld when receiver retention has
expired and earlier outcome remains unknown.
Dependent aspect 36: An unresolved external result establishes a
protected retry fence.
Dependent aspect 37: A timeout does not constitute proof of non-
effectuation.
Das Expires 29 April 2027 [Page 282]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Dependent aspect 38: A missing acknowledgement does not restore
consumed authority.
Dependent aspect 39: The system obtains qualified receiver-status
evidence.
5.4.3.76. Original Source — Global Page 1460
Dependent aspect 40: The system authenticates a receiver's
observation role.
Dependent aspect 41: Receiver evidence identifies the actual logical
operation.
Dependent aspect 42: The system distinguishes qualified completed
effect from qualified non-effectuation.
Dependent aspect 43: The system represents partial effects
separately.
Dependent aspect 44: The system conservatively handles incomplete
negative-effect evidence.
Dependent aspect 45: A new attempt after confirmed non-effectuation
requires current bounded authority.
Dependent aspect 46: A receiver-idempotent retransmission uses the
same logical operation identity and parameters.
Dependent aspect 47: A different consequential retry is represented
as a new Candidate Act.
Dependent aspect 48: A corrective effect requires separately valid
recovery authority.
Dependent aspect 49: A causal successor effect requires an accepted
earlier actual-effect receipt where the selected CW-2 protocol so
specifies.
Dependent aspect 50: A protected journal may be checkpointed.
Dependent aspect 51: Journal compaction preserves required consumed-
authority and unresolved-effect state.
Dependent aspect 52: A protected checkpoint is verified against
rollback.
Das Expires 29 April 2027 [Page 283]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Dependent aspect 53: An old journal copy cannot restore a prior
consumption generation.
Dependent aspect 54: Multiple effectuation sinks share authoritative
consumption state where required.
Dependent aspect 55: Distributed disconnected domains may receive
nonoverlapping bounded authority.
Dependent aspect 56: Workload migration advances the relevant
dispatcher or resource-ownership generation.
Dependent aspect 57: An old device owner cannot exercise stale
command authority.
Dependent aspect 58: A physical device maintains protected command
identity and acceptance state.
Dependent aspect 59: Physical actuation completion may require
qualified sensor or device-controller evidence.
5.4.3.77. Original Source — Global Page 1461
Dependent aspect 60: Information-release uncertainty remains
represented in cumulative privacy accounting.
Dependent aspect 61: A payment sink verifies current account, amount,
recipient, and logical transaction identity.
Dependent aspect 62: A storage sink verifies current object version.
Dependent aspect 63: A model or tool update may require current
validation before resumed consequential execution.
Dependent aspect 64: A material effectuation-path change invalidates
dependent dispatch authority.
Dependent aspect 65: The system bounds reconciliation and retry
resource consumption.
Dependent aspect 66: A protected integrated controller may perform
finality, journaling, and resource mutation.
Dependent aspect 67: Separate authenticated domains may provide
finality, dispatch, receiving effect, and outcome observation.
Dependent aspect 68: Protected journal continuity may be maintained
without a public blockchain.
Das Expires 29 April 2027 [Page 284]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Dependent aspect 69: The implementation distinguishes exactly-once
protected consumption from receiver-side effect uniqueness.
Dependent aspect 70: An unresolved external effect cannot be
described as successfully reversed or safely unperformed without the
relevant qualified evidence.
These aspects are illustrative claim-support features and do not
individually establish patentability.
16.65 — UNIVERSAL NON-LIMITING COMBINATION AND PHOSITA IMPLEMENTATION
CLAUSE
The mechanisms disclosed in Embodiment 16 may be implemented
individually or in technically compatible combinations.
One implementation may govern atomic local database mutations.
Another may govern remote transactional services.
Another may govern durable message dispatch.
Another may govern financial transfers.
5.4.3.78. Original Source — Global Page 1462
Another may govern file and storage operations.
Another may govern protected information disclosure.
Another may govern direct device commands.
Another may govern heterogeneous autonomous agents acting across
independent computing domains.
A particular implementation may employ a transactional journal
without a separately named outbox.
Another may use a protected outbox.
Another may employ receiver-side deduplication.
Another may rely upon qualified confirmed non-effectuation before
permitting retries.
Another may require an independently authorized recovery operation
where earlier actual effects remain unresolved.
Das Expires 29 April 2027 [Page 285]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The terms exactly-once authorization, exactly-once local consumption,
exactly-once receiver mutation, and exactly-once external consequence
identify different technical guarantees and must not be treated as
interchangeable.
Where the selected claim requires one atomic resource and authority
transition, the implementation must actually provide that property.
Where the selected claim requires receiver-side duplicate-effect
prevention, the destination must implement a mechanism sufficient for
the claimed guarantee.
Where the selected claim requires monotonic rollback resistance,
protected authoritative state must remain valid despite untrusted
workload rollback.
The pseudocode, data structures, equations, worked examples, state
machines, technical variations, and proposed experiments are
illustrative and non-limiting.
They are intended to assist a person having ordinary skill in the art
in understanding and implementing the disclosed technical mechanisms.
No particular storage engine, transaction protocol, cryptographic
primitive, processor, communication system, vendor, operating system,
or hardware substrate is universally required unless recited by a
selected claim.
Compatible mechanisms from other embodiments may be combined where
supported by the disclosure and technically appropriate.
A cross-reference does not make every feature of another embodiment
mandatory.
A durable journal entry does not automatically prove external effect
completion.
5.4.3.79. Original Source — Global Page 1463
A protected finality receipt does not automatically permit repeated
execution.
A retry-safe transport operation does not automatically establish a
retry-safe physical consequence.
A compensated effect does not automatically erase the original
historical consequence.
Das Expires 29 April 2027 [Page 286]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A protected operation cannot be considered successfully completed
merely because the requesting agent received a local software success
result.
No proposed experiment is represented as completed merely by stating
its expected result.
Future-oriented implementation variations are proposed technical
alternatives and not statements of existing commercial deployment.
16.66 — FINAL TECHNICAL SUMMARY AND INVENTIVE-STEP CHARACTERIZATION
The present Embodiment 16 discloses a protected crash-consistent
autonomous execution-finality architecture that preserves operation-
specific consequential authority and actual-effect state across
failures, retries, restarts, and distributed processing uncertainty.
An autonomous computational entity may prepare a Candidate Act
describing a permitted consequential effect.
The actual operation remains non-effective until independently
enforced authorization conditions pass.
A protected Finality Sink reconstructs the actual pending operation
and verifies current non-bearer finality authority.
The system establishes an authenticated durable journal binding the
operation, evidence, authority, resource, and protected consumption
generation.
Where the affected resource and authority state are within one
appropriate transaction domain, the operation and its authority
consumption may commit atomically.
Where the effect occurs at a separate external destination, the
protected controller may durably associate consumption with an exact
dispatch-intent commitment.
The dispatcher is authorized only to attempt the corresponding
committed operation under current protected state.
A suitable receiving resource may maintain its own authoritative
logical effect registry.
Where receiver-side operation identity and actual mutation are
atomically coupled, repeated delivery may be processed without
duplicating the protected resource mutation.
Das Expires 29 April 2027 [Page 287]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.4.3.80. Original Source — Global Page 1464
However, this stronger guarantee depends upon the real receiving
system's implementation, persistence, and retention properties.
A protected outcome controller distinguishes confirmed completion,
confirmed non-effectuation, partial effectuation, and indeterminate
results.
If a sender crashes, loses an acknowledgement, or cannot establish
the receiver's outcome, the system does not automatically restore
consumed authority.
Instead, it establishes or maintains an indeterminate-outcome fence.
Further consequential execution requires sufficiently qualified
receiver or actual-effect evidence, a verified retry-safe operation
under the relevant destination guarantees, or a separately authorized
recovery Candidate Act.
Protected journal generations and actual sink-enforced dispatcher
fencing prevent stale snapshots, restored workers, and former
coordinators from reviving earlier consequential authority.
The architecture may be implemented in databases, distributed
services, financial systems, message infrastructure, protected
storage, hardware controllers, robotics, communications systems,
confidential computing, edge devices, and future autonomous critical
infrastructure.
The embodiment does not claim to invent write-ahead logging,
transactional outbox systems, idempotency keys, distributed
consensus, receiver deduplication, or conventional transaction
recovery individually.
Its proposed candidate technical contribution is the enforced
coupling of actual Finality-Sink operation reconstruction, evidence-
qualified non-bearer authority, durable monotonic consumption,
protected dispatch-intent continuity, qualified outcome
reconciliation, and restrictions preventing uncertain earlier effects
from generating unauthorized new consequential authority.
The principal candidate inventive technical concept of Embodiment 16
is a crash-consistent protected execution-finality system in which an
independently enforcing Finality Sink reconstructs an actual pending
consequential operation, verifies current operation-specific non-
bearer authority, durably binds a monotonic authority-consumption
transition to the corresponding actual-effect dispatch-intent state,
Das Expires 29 April 2027 [Page 288]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
and maintains a protected indeterminate-outcome fence preventing
unsupported additional effectuation until a qualified actual-effect
result, verified receiver-idempotent retransmission condition, or
separately authorized recovery transition has been established.
The resulting safety property is not an unqualified claim that every
real-world effect occurs exactly once.
Rather, the system can enforce precisely specified authority-
consumption and replay-prevention properties while maintaining
technically accurate distinctions among dispatch, receiver
acceptance, external completion, and unresolved outcomes.
5.4.3.81. Original Source — Global Page 1465
Novelty, inventive step, unity of invention, and permissible claim
breadth remain subject to the closest relevant prior-art analysis and
the enabling technical disclosure actually filed.
END OF EMBODIMENT 16 — COMPLETE TECHNICAL DISCLOSURE.
5.5. Embodiment 36 — Multi-Resource Transaction Finality, Partial
Commit and Separate Compensation
Original technical source: TECHNICAL SPECIFICATION -3102-3567.pdf,
global pages 3102–3192 inclusive. Principal source treatment within
Part 8. Related mechanisms may also be referenced by Parts 3, 4 and
6.
5.5.1. Protected Component Architecture
[Protected Transaction Intent Envelope]
|
[Decompose constituent CAs / dependency DAG]
|
[Source grants and global budgets]
+-----+------+
| |
[FS A] [FS B / FS C]
| |
[Real effect A] [Real effects B/C or refusal]
+-----+------+
|
[Qualified outcome vector / partial commit]
|
[Hold or separately authorize compensation]
Das Expires 29 April 2027 [Page 289]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Figure 9: Embodiment 36 — Multi-Resource Transaction Finality,
Partial Commit and Separate Compensation — architecture
5.5.2. Actual-Effect and Failure Decision Flowchart
[Plan effects across A, B and C]
|
<Supported atomic commit mode?> -- NO --> [EXPLICIT SEQUENTIAL MODE]
| YES
[Prepare where truly supported]
|
[Verify each source, target, predecessor and FS]
|
<One fails after another commits?> -- YES --> [FENCE PARTIAL COMMIT]
| NO
[Reconcile actual outcomes]
|
<Compensation requested?> -- YES --> [NEW CA + AUTHORITY]
| NO
[Report only qualified transaction state]
Figure 10: Embodiment 36 — Multi-Resource Transaction Finality,
Partial Commit and Separate Compensation — effectuation decisions
5.5.3. Original Technical Disclosure — Page-Indexed Sections
5.5.3.1. Original Source — Global Page 3102
A queue is not a Finality Sink.
A completed local effect does not become undone when a remote
authority later reports revocation.
A remote request with a lost acknowledgement must not automatically
be retried as though the original operation certainly failed.
A local transaction does not create an atomic transaction at a
separately controlled remote resource.
35.89.5 — Non-Limiting Common Reference Combination
Original source authority → connectivity-requirement classification →
protected prepartition offline authority allocation → disjoint sink
reservations → Candidate Act → Non-Effective State → current local
authority, clock, resource, and revocation validation → independent
local actual-effect reconstruction → scoped non-bearer finality →
protected consumption → controlled offline effect → protected effect
journal → authenticated reconnection → current remote authority
Das Expires 29 April 2027 [Page 290]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
qualification → actual-outcome and reservation reconciliation →
revalidation of deferred acts → nonresurrection of consumed or
revoked authority.
The existing technologies provide practical cryptographic
authentication, protected time, attestation, transaction storage,
authorization, and message synchronization.
The proposed distinguishing technical relationship is the causal
connection among specifically preallocated offline authority, actual
resource-side finality, partition-resistant consumption, and
mandatory reconciliation of authority and completed effects—with
offline execution permitted only where its revocation-delay and scope
assumptions have themselves been competently authorized.
END OF EMBODIMENT 35 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 36
PROTECTED AUTONOMOUS MULTI-RESOURCE TRANSACTION FINALITY WITH
PARTIAL-COMMIT CONTAINMENT, CROSS-SINK DEPENDENCY VERIFICATION, AND
INDEPENDENT COMPENSATION AUTHORITY
36.0 — COMPLETE TECHNICAL TITLE
Systems, Methods, and Apparatus for Governing Autonomous Multi-
Resource Consequential Workflows Using Protected Transaction-Intent
Decomposition, Non-Effective Constituent Candidate Acts, Source-
Authority-Preserving Effect Dependency Graphs, Cross-Sink Prepare and
Commit Evidence, Independent Resource-Specific Finality Sinks,
Protected Partial-Commit Barriers, Generation-Bound Dependency
Receipts, Irreversibility-Aware Commit Ordering, Transaction-Wide
Effect Budgets, Indeterminate-Outcome Containment, Independently
Authorized Compensation Candidate Acts, Scoped Non-Bearer Finality,
and Protected Recovery Without Duplicate or Unauthorized
Consequential Effectuation
5.5.3.2. Original Source — Global Page 3103
36.0.1 — General Technical Description
Das Expires 29 April 2027 [Page 291]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The present Embodiment 36 discloses systems, methods, apparatus,
protected computational components, autonomous transaction planners,
multi-resource authorization controllers, effect dependency
validators, resource-specific Finality Sinks, protected cross-sink
evidence registries, transaction coordinators, distributed
consumption controllers, partial-commit containment services,
independently authorized compensation controllers, and recovery
engines configured to govern consequential operations spanning two or
more independently controlled resources or effectuation domains.
The computational workload may comprise an artificial-intelligence
agent, a multi-agent coordinator, an enterprise automation engine, a
distributed application, a financial transaction assistant, a
software deployment system, a cloud infrastructure controller, a
robotic system, an industrial automation controller, or another
computational process capable of initiating consequential operations
across multiple resources.
An autonomous workload may receive an instruction requiring several
distinct effects.
Examples include:
Reserving inventory and creating a purchase order; Authorizing a
payment and updating an accounting record; Modifying a cloud
resource and changing a network security policy; Committing a
database record and publishing an external notification;
Provisioning a credential and activating a dependent resource;
Updating an enterprise document and transmitting its contents;
Deploying software and changing production routing; Transferring
data and deleting its original copy; Reserving a computational
resource and allocating a financial budget; Modifying a persistent
memory record and publishing a shared knowledge artifact; Issuing a
physical device command and recording the corresponding control
state; Or another workflow comprising multiple actual consequences.
Such operations may involve separate:
Administrative authorities;
Resource owners;
Security policies;
Authentication providers;
Service identities;
Das Expires 29 April 2027 [Page 292]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Execution times;
Transaction managers;
Commit protocols;
5.5.3.3. Original Source — Global Page 3104
Revocation generations;
And effectuation boundaries.
The workload may perceive the overall task as one conceptual action.
However, the underlying resources may not support a single atomic
transaction.
One resource may commit while another refuses.
A database may roll back an uncommitted change while a previously
transmitted email cannot be recalled.
A payment may complete before the receiving application obtains
confirmation.
A device command may produce a physical consequence that cannot be
reversed by restoring a database record.
A cloud resource may be provisioned while its dependent security
configuration fails.
A credential may be released even though the intended dependent
service was never successfully activated.
A queue may accept a message without proving that the target
application has completed the requested action.
A signed transaction plan may correctly identify all intended steps
without establishing that each receiving resource actually executed
the authorized operation.
A coordinator may believe a distributed workflow has failed even
though one or more actual resource effects have already occurred.
A later retry may duplicate an irreversible effect.
A compensation mechanism may propose a reversal that the originating
principal never authorized.
Das Expires 29 April 2027 [Page 293]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A compensation may affect another resource whose current owner or
policy has changed.
An agent may also modify a transaction plan after partial completion
and attempt to reuse the original approvals for new effects.
The present embodiment therefore distinguishes:
A transaction-level intention; each constituent Candidate Act; each
resource's actual finality; the protected dependency relationship
among resource effects; a transaction-level completion condition; and
independent authority for recovery or compensation.
A multi-resource task is represented as a protected Transaction
Intent Envelope.
5.5.3.4. Original Source — Global Page 3105
The envelope identifies the originating source grant, qualified
resource targets, intended effects, dependencies, applicable global
constraints, partial-effect policy, and the relevant independent
Finality Sinks.
The protected controller decomposes the transaction into constituent
Candidate Acts.
Each constituent Candidate Act remains in a Non-Effective State until
its own applicable source, resource, dependency, and operation-
specific authority conditions are independently satisfied.
A transaction-level approval is not automatically a reusable
authority object capable of effecting every sub-operation.
A protected dependency graph identifies which actual completed
effects, resource reservations, current resource versions, or
approvals are necessary before a successor operation may become
eligible.
For resources supporting genuine coordinated transactional
preparation, the system may use a qualified multi-participant
prepare-and-commit protocol.
Where the resources lack a common atomic commit mechanism, the system
may use controlled sequential effectuation, conditional release,
bounded reservation, or separately authorized compensation.
The selected mode is an explicit property of the transaction plan.
Das Expires 29 April 2027 [Page 294]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A protected transaction coordinator may schedule operations and
collect qualified evidence.
The coordinator is not, merely by scheduling a step, the final
authority to cause the step's actual effect.
Each actual Finality Sink independently reconstructs the pending
operation and verifies its source authority, resource conditions,
dependency evidence, scoped non-bearer finality, and protected sink-
local consumption.
After an operation commits, the protected evidence registry records
the supported actual outcome.
A successor operation may rely upon an accepted predecessor effect
receipt where the source-authorized dependency condition requires
that completed effect.
An attempted, queued, or merely prepared operation is not
automatically treated as a completed predecessor.
Where one resource completes and another fails, a protected partial-
commit controller fences unauthorized continuation and identifies
which effects have actually occurred.
It does not represent the entire workflow as rolled back merely
because a coordinator changed its transaction status to failed.
5.5.3.5. Original Source — Global Page 3106
Where a compensating operation is appropriate, the compensation is
constructed as a new Candidate Act.
The compensating act requires competent original or separately
delegated authority, current resource-specific validation, scoped
non-bearer finality, and independent actual receiving-sink
enforcement.
The system does not assume that an earlier permission to perform an
effect includes unlimited permission to reverse or replace it.
The architecture is intended to preserve the principle:
Computation is not authority to act; coordination is not
effectuation; and compensation is not automatic authority to create
another consequence.
36.0.2 — Fundamental Technical Principles
Das Expires 29 April 2027 [Page 295]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
1. A multi-resource transaction is not automatically one indivisible
consequential effect. 2. A coordinator's approval does not replace a
receiving resource's mandatory finality. 3. A constituent operation
requires authority for its own actual target and consequence. 4. A
predecessor's successful preparation is distinct from its actual
completed effect. 5. A completed predecessor receipt may establish a
required dependency without
independently granting the successor new source authority. 6. A
valid transaction plan does not guarantee that all participating
systems support
atomic commit. 7. A distributed prepare phase is not actual finality
unless the participating resource's
protocol defines and enforces the corresponding state. 8. An
irreversible external effect cannot necessarily be rolled back. 9.
Compensation is a separate real operation requiring competent
authority. 10. A failed transaction coordinator does not prove that
previously dispatched resource
operations failed. 11. A valid retry is not an unrestricted new
opportunity to consume effectuation authority. 12. A transaction-
wide budget must not be multiplied through parallel execution or
retries. 13. A protected recovery process must preserve actual
completed and indeterminate
effects. 14. A later successful operation cannot retroactively
establish missing authority for an
earlier unauthorized effect.
36.0.3 — Principal Candidate Inventive Combination
A representative implementation combines:
(a) a protected originating transaction grant;
(b) a transaction intent envelope;
(c) decomposition into independently non-effective constituent
Candidate Acts;
(d) an authenticated cross-resource effect dependency graph;
Das Expires 29 April 2027 [Page 296]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.5.3.6. Original Source — Global Page 3107
(e) protected operation-specific source and resource scope;
(f) dependency-qualified actual effect receipts;
(g) a transaction-level partial-effect and irreversibility policy;
(h) optional qualified multi-participant prepare evidence;
(i) independently enforced resource-specific Finality Sinks;
(j) source-authority-preserving successor release predicates;
(k) protected transaction-wide budget reservations;
(l) a partial-commit containment barrier;
(m) qualified indeterminate-effect reconciliation;
(n) separately authorized compensation Candidate Acts;
(o) scoped non-bearer finality for forward and compensating effects;
(p) protected sink-local consumption and cross-sink recovery state.
36.0.4 — Candidate Technical Distinction
The embodiment does not claim as individually new:
Two-phase commit;
Distributed transactions;
Saga workflows;
Compensating transactions;
Transaction coordinators;
Workflow dependency graphs;
Transactional outbox patterns;
Durable message queues;
Database rollback;
Das Expires 29 April 2027 [Page 297]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Idempotency keys;
5.5.3.7. Original Source — Global Page 3108
Resource reservations;
Or distributed logs.
The proposed technical distinction concerns the enforced relationship
between separately source-authorized constituent Candidate Acts,
actual resource Finality-Sink evidence, dependency-conditioned
downstream release, partial-commit containment, and separately
authorized compensation.
36.0.5 — Relationship to Earlier Embodiments
The embodiment may incorporate previously disclosed mechanisms for:
Candidate Acts;
Non-Effective States;
Protected Enforcement Domains;
Original source authority;
Cross-committed evidence;
Scoped non-bearer finality;
Actual Finality-Sink reconstruction;
Multi-agent delegation;
Asynchronous workflow dependencies;
Credential activation;
Policy evolution;
Actual resource identity;
Offline effectuation;
And revocation-aware recovery.
Das Expires 29 April 2027 [Page 298]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The distinct focus is coordination and containment of several real
effects whose independently controlled resources may reach different
completion states.
36.0.6 — Non-Limiting Reference Architecture
ORIGINATING PRINCIPAL | v PROTECTED TRANSACTION GRANT
5.5.3.8. Original Source — Global Page 3109
| v TRANSACTION INTENT ENVELOPE | v PROTECTED EFFECT DECOMPOSITION |
+--------+--------+ | | | v v v CA-A CA-B CA-C | | | v v v NES NES
NES | | | +--------+--------+ | v EFFECT DEPENDENCY GRAPH | v
INDEPENDENT VALIDATION | +------------+------------+ | | | v v v SINK
A SINK B SINK C | | | v v v EFFECT A EFFECT B EFFECT C | | | v v v
RECEIPT A RECEIPT B RECEIPT C | | | +------------+------------+ | v
PROTECTED OUTCOME REGISTRY | v CROSS-SINK STATE EVALUATION |
+--------+---------+ | | v v COMPLETE PARTIAL / UNKNOWN | | v v
VERIFIED CLOSE CONTAINMENT FENCE | v
5.5.3.9. Original Source — Global Page 3110
OUTCOME RECONCILIATION | +---------+----------+ | | v v CONTINUE
COMPENSATION IF AUTHORIZED CANDIDATE ACT | v NEW SOURCE CHECK | v
INDEPENDENT SINK | v ACTUAL RECOVERY EFFECT
The diagram is non-limiting.
The coordinator, validators, and Finality Sinks may be implemented in
separate protected domains or in a suitably integrated trusted
system.
36.1 — TECHNICAL FIELD
The present invention relates to autonomous distributed transactions,
multi-resource workflow security, protected transaction
decomposition, independent resource finality, cross-service authority
continuity, partial-commit containment, distributed compensation,
durable operation evidence, and effect-specific source authorization.
More particularly, it concerns preventing a computational agent from
converting a broad multi-step plan into unauthorized effects,
including when a workflow only partially completes.
36.2 — SPECIFIC TECHNICAL PROBLEMS
36.2.1 — Transaction Intent Versus Individual Effects
Das Expires 29 April 2027 [Page 299]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A task expressed as one request may require multiple separately
consequential resource operations.
36.2.2 — Broad Transaction Approval
A single approval may be overgeneralized to authorize unbounded
constituent effects.
36.2.3 — Missing Source Scope
5.5.3.10. Original Source — Global Page 3111
A sub-operation may lie outside the original principal's authorized
transaction.
36.2.4 — Different Resource Owners
Several receiving resources may require different competent
authorities.
36.2.5 — Different Resource Policies
A workflow may pass one sink's policy and fail another's.
36.2.6 — Partial Commit
One effect may complete while another remains pending or denied.
36.2.7 — Nonatomic External Effect
An email, payment, physical command, or independent API may not
participate in a shared atomic transaction.
36.2.8 — Misleading Coordinator State
A transaction manager may report failure while an actual resource
effect has already occurred.
36.2.9 — Prepared/Committed Confusion
A prepared transaction may be mistaken for a committed effect.
36.2.10 — Queued/Completed Confusion
A queue acknowledgement may be treated as completion at the ultimate
resource.
36.2.11 — Outbox/Delivery Confusion
Das Expires 29 April 2027 [Page 300]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A durable outbox record may be mistaken for successful downstream
execution.
36.2.12 — Predecessor Receipt Forgery
A workflow may use a false completion receipt to unlock a dependent
effect.
36.2.13 — Predecessor Receipt Replay
A completion receipt may be reused for a different successor
transaction.
36.2.14 — Dependency Omission
An operation may be released without all mandatory predecessor
effects.
36.2.15 — Dependency Expansion
5.5.3.11. Original Source — Global Page 3112
An agent may add a new effect after receiving approval of the
original workflow.
36.2.16 — Dependency Removal
An agent may delete a prerequisite from the protected transaction
graph.
36.2.17 — Cross-Resource Version Drift
A resource may change after validation but before its own commit.
36.2.18 — Transaction-Wide Budget Duplication
Parallel branches may each attempt to spend the full original budget.
36.2.19 — Concurrent Agents
Several autonomous agents may attempt to perform the same constituent
operation.
36.2.20 — Credential Scope Reuse
A credential approved for one sub-operation may be used for another.
36.2.21 — Policy-Generation Mismatch
Das Expires 29 April 2027 [Page 301]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Different resource sinks may enforce different current rules.
36.2.22 — Irreversibility Order
An irreversible operation may be performed before a necessary
reversible prerequisite.
36.2.23 — Compensation Authority Confusion
Permission for an original operation may be mistaken for unrestricted
permission to reverse it.
36.2.24 — Wrong Compensation Target
A compensating request may affect a different resource owner or
current object.
36.2.25 — Compensation Overshoot
A reversal may undo more than the actual original effect.
36.2.26 — Duplicate Compensation
Recovery retries may execute a compensating operation repeatedly.
36.2.27 — Failed Compensation
A compensating effect may independently fail.
5.5.3.12. Original Source — Global Page 3113
36.2.28 — Compensation Indeterminacy
A compensation may execute without delivering acknowledgement.
36.2.29 — Uncompensatable Effect
An external effect may have no safe or legally permissible inverse.
36.2.30 — Changed Resource Ownership
Resource authority may change between forward execution and
compensation.
36.2.31 — Cancellation After Commit
A task may be canceled after one or more effects have completed.
Das Expires 29 April 2027 [Page 302]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
36.2.32 — Coordinator Crash
The transaction planner may fail after some sinks commit.
36.2.33 — Recovery Snapshot Rollback
Previously completed or consumed effects may be mistakenly made
eligible again.
36.2.34 — Cross-Domain Timeouts
An absence of response may be mistaken for an actual failure.
36.2.35 — Unbounded Retry
A workflow may repeatedly attempt an indeterminate consequence.
36.2.36 — Resource Identity Substitution
A branch may reach a different receiving resource from the one
authorized.
36.2.37 — Tool-Contract Change
A sub-operation may acquire an additional side effect during
execution.
36.2.38 — Hidden Additional Effect
A tool may execute a resource mutation not represented in the
transaction plan.
36.2.39 — Circular Dependencies
An invalid dependency graph may prevent meaningful transaction
ordering.
36.2.40 — Concurrent Dependency Race
5.5.3.13. Original Source — Global Page 3114
Two branches may assume the same prerequisite state is current.
36.2.41 — Dynamic Transaction Expansion
An agent may discover another necessary sub-operation after a partial
commit.
Das Expires 29 April 2027 [Page 303]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
36.2.42 — Unauthorized Forward Continuation
A workflow may continue despite a mandatory predecessor denial.
36.2.43 — Unauthorized Recovery
A recovery agent may claim broad administrative authority from the
mere existence of a failed transaction.
36.2.44 — False Global Atomicity
A system may incorrectly claim all-or-nothing effects across services
that cannot support such guarantees.
36.2.45 — Technical Objective
How to govern a source-authorized autonomous workflow comprising
several separately effectual resource operations, preserving
operation-specific finality and mandatory causal dependencies while
containing partial commits, preventing duplicate or out-of-scope
effects, and requiring independent competent authorization for
consequential compensation or recovery.
36.3 — ESTABLISHED TECHNICAL FOUNDATIONS
36.3.1 — Database Transactions
Existing transactional databases can support atomicity and isolation
for effects within their own supported transaction boundaries.
36.3.2 — Two-Phase Commit
Existing two-phase commit systems may coordinate participating
transactional resources.
A transaction coordinator can request preparation and later issue
commit or rollback decisions to suitably participating resource
managers.
The protocol does not automatically encompass arbitrary external
effects that lack corresponding prepared-transaction support.
36.3.3 — Saga Workflows
Existing Saga architectures coordinate separately committed local
transactions.
Das Expires 29 April 2027 [Page 304]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.5.3.14. Original Source — Global Page 3115
A later failure may trigger compensating operations.
Compensation is application-defined and is not identical to a general
atomic rollback.
36.3.4 — Transactional Outbox
An outbox can coordinate a database mutation with durable recording
of a message for later publication.
It does not inherently prove that the ultimate external recipient
executed the message's requested effect.
36.3.5 — Idempotency
Existing receiving resources may support operation identifiers that
reduce duplicate effects.
An idempotency identifier does not independently establish source
authorization.
36.3.6 — Conditional Updates
Existing resource version checks may prevent selected conflicting
updates.
They do not automatically provide transaction-wide authority across
independent resources.
36.3.7 — Candidate Additional Relationship
The proposed architecture joins these established mechanisms to
protected source-authorized actual-effect finality and distinct
compensation authority.
36.4 — PRINCIPAL TECHNICAL COMPONENTS
A representative implementation comprises:
1. Protected Originating Transaction Authority Controller. 2.
Transaction Intent Envelope Constructor. 3. Constituent Candidate
Act Decomposer. 4. Non-Effective Operation Controller. 5. Protected
Transaction Dependency Graph. 6. Effect-Specific Resource Identity
Validator. 7. Transaction-Wide Budget Reservation Controller. 8.
Partial-Effect Policy Registry. 9. Irreversibility and Compensation
Classifier. 10. Optional Transaction Preparation Controller. 11.
Das Expires 29 April 2027 [Page 305]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Cross-Sink Evidence Registry. 12. Constituent Operation
Authorization Validator. 13. Scoped Non-Bearer Finality Controller.
14. Independent Resource Finality Sinks. 15. Protected Predecessor
Receipt Validator.
5.5.3.15. Original Source — Global Page 3116
16. Cross-Sink Completion and Outcome Evaluator. 17. Partial-Commit
Containment Controller. 18. Indeterminate-Outcome Reconciliation
Controller. 19. Independent Compensation Authority Controller. 20.
Compensation Candidate Act Constructor. 21. Protected Consumption
and Recovery Journal. 22. Transaction Closure Controller.
36.5 — TECHNICAL DEFINITIONS
36.5.1 — Protected Transaction Intent Envelope
A Protected Transaction Intent Envelope, or PTIE-36, means an
authenticated representation of the bounded multi-resource operation
authorized by an originating principal.
36.5.2 — Constituent Candidate Act
A Constituent Candidate Act, or CCA-36, means a particular
consequential operation derived from a protected transaction intent
and directed toward one actual resource effectuation boundary.
36.5.3 — Transaction Constituent Set
A Transaction Constituent Set means the protected set of covered
Candidate Acts belonging to one source-authorized workflow revision.
36.5.4 — Effect Dependency Graph
An Effect Dependency Graph, or EDG-36, means a protected
representation of mandatory relationships among constituent resource
operations.
36.5.5 — Source-Authority-Preserving Dependency
A Source-Authority-Preserving Dependency means a predecessor
condition whose satisfaction does not independently enlarge the
successor's originating authorization.
36.5.6 — Actual Effect Receipt
An Actual Effect Receipt, or AER-36, means qualified evidence
supporting a particular resource effect's actual completion state.
Das Expires 29 April 2027 [Page 306]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
36.5.7 — Preparation Receipt
A Preparation Receipt means qualified evidence that a resource
entered a prepared state under its supported transaction protocol,
distinct from final commitment.
36.5.8 — Dependency Release Receipt
5.5.3.16. Original Source — Global Page 3117
A Dependency Release Receipt, or DRR-36, means qualified evidence
that specified mandatory predecessors satisfy the current conditions
for releasing a successor Candidate Act.
36.5.9 — Cross-Sink Receipt Commitment
A Cross-Sink Receipt Commitment means a protected relationship among
qualified effect receipts from multiple receiving resource
boundaries.
36.5.10 — Transaction Effect Class
A Transaction Effect Class means a classification of a constituent
effect according to its atomicity, reversibility, compensation, or
irreversibility properties.
36.5.11 — Partial-Commit State
A Partial-Commit State, or PCS-36, means a workflow state in which
some, but not all, required constituent effects have actually
completed.
36.5.12 — Partial-Commit Containment Barrier
A Partial-Commit Containment Barrier, or PCCB-36, means a protected
restriction preventing unsafe or unauthorized subsequent effects
after a material partial completion.
36.5.13 — Transaction Pivot Effect
A Transaction Pivot Effect means a qualified operation after which
the applicable recovery or continuation strategy changes because the
operation's consequences cannot safely be undone under the selected
model.
36.5.14 — Irreversibility Descriptor
Das Expires 29 April 2027 [Page 307]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An Irreversibility Descriptor means a protected record of whether and
under what assumptions a resource effect may be reversed,
compensated, or only mitigated.
36.5.15 — Compensation Candidate Act
A Compensation Candidate Act, or CoCA-36, means a separately
constructed proposed consequential operation intended to reverse,
offset, correct, or mitigate a prior effect.
36.5.16 — Compensation Source Grant
A Compensation Source Grant means qualified competent authority
permitting the exact recovery or compensating consequence.
36.5.17 — Compensation Effect Envelope
A Compensation Effect Envelope means the permitted resource,
operation, amount, target, and prior-effect relationship for a
compensating act.
5.5.3.17. Original Source — Global Page 3118
36.5.18 — Forward Finality
Forward Finality means protected permission and actual effectuation
of a constituent operation in the intended forward workflow
direction.
36.5.19 — Compensation Finality
Compensation Finality means independent protected permission and
effectuation of a compensating operation.
36.5.20 — Compensation Noninheritance
Compensation Noninheritance means that approval of a forward
operation does not automatically provide unrestricted authority for
any compensating operation.
36.5.21 — Predecessor Finality Predicate
A Predecessor Finality Predicate means a protected requirement
concerning an earlier actual operation's qualified outcome.
36.5.22 — Conditional Successor Release
Das Expires 29 April 2027 [Page 308]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Conditional Successor Release means permitting a dependent Candidate
Act only after its mandatory predecessors and current source/resource
authorization conditions pass.
36.5.23 — Transaction-Wide Effect Budget
A Transaction-Wide Effect Budget means an overall source-authorized
limit applicable to the aggregate actual effects of the workflow.
36.5.24 — Budget Reservation Set
A Budget Reservation Set means a protected allocation of bounded
effect authority among constituent Candidate Acts.
36.5.25 — Cross-Sink Budget Conservation
Cross-Sink Budget Conservation means preventing parallel constituents
from exceeding an applicable original aggregate authority limit.
36.5.26 — Transaction Outcome Vector
A Transaction Outcome Vector, or TOV-36, means a protected
representation of each constituent operation's actual status.
36.5.27 — Indeterminate Constituent Effect
An Indeterminate Constituent Effect means an operation whose actual
resource consequence cannot presently be established.
5.5.3.18. Original Source — Global Page 3119
36.5.28 — Resource-Specific Consumption
Resource-Specific Consumption means protected effectuation authority
use maintained at the actual receiving resource or its qualified
enforcement sink.
36.5.29 — Transaction Revision Generation
A Transaction Revision Generation means a protected version
identifying the currently authorized constituent set and
dependencies.
36.5.30 — Plan Mutation Fence
A Plan Mutation Fence means withholding an affected operation when
the approved transaction plan changes materially.
Das Expires 29 April 2027 [Page 309]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
36.5.31 — Mandatory Effect Closure
Mandatory Effect Closure means determining whether all required
constituent effect predicates have been satisfied.
36.5.32 — Partial Effect Exposure
Partial Effect Exposure means the set of real resource consequences
already produced while the transaction remains incomplete.
36.5.33 — Compensability Classification
Compensability Classification means determining whether a completed
effect has a currently defined and potentially authorized corrective
or offsetting operation.
36.5.34 — Uncompensatable Effect
An Uncompensatable Effect means an actual consequence for which no
adequate authorized reversal exists under the selected resource and
policy model.
36.5.35 — Recovery Authority Boundary
A Recovery Authority Boundary means a protected source and resource
authorization requirement governing attempted recovery effects.
36.5.36 — Transaction Isolation Requirement
A Transaction Isolation Requirement means the consistency constraint
applicable to interactions among concurrent constituent operations or
workflows.
36.5.37 — Qualified Resource Reservation
A Qualified Resource Reservation means a current protected resource
hold or preparation state recognized by the actual receiving
resource.
5.5.3.19. Original Source — Global Page 3120
36.5.38 — Reservation Release Authority
Reservation Release Authority means competent authorization and
resource-specific finality for releasing or changing a reservation
where such release is consequential.
36.5.39 — Compensation Dependency Graph
Das Expires 29 April 2027 [Page 310]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A Compensation Dependency Graph means a protected structure
describing which prior effects and current conditions are necessary
for a particular recovery act.
36.5.40 — Transaction Nonresurrection
Transaction Nonresurrection means preventing retries, recovery, or
snapshot restoration from making already consumed effectuation
authority eligible again.
36.5.41 — Receipt Semantic Class
A Receipt Semantic Class means whether evidence establishes request
preparation, acceptance, dispatch, resource commit, physical
completion, or another qualified outcome level.
36.5.42 — Qualified Completion Predicate
A Qualified Completion Predicate means the source-authorized actual-
effect condition required to declare the overall workflow complete.
36.5.43 — Downstream Effect Fence
A Downstream Effect Fence means a protected restriction withholding
dependent operations after a prerequisite failure or uncertainty.
36.5.44 — Atomic Participant Set
An Atomic Participant Set means the qualified resources whose actual
commits are governed by one supported coordinated transaction
protocol.
36.5.45 — Nonatomic Effect Set
A Nonatomic Effect Set means the constituents not guaranteed to
participate in a common atomic commit.
36.5.46 — Mixed-Atomicity Transaction
A Mixed-Atomicity Transaction means a workflow containing both
coordinated atomic participants and separately committed effects.
36.5.47 — Protected Transaction Journal
A Protected Transaction Journal means authenticated durable evidence
of plan revisions, candidate authority, effect attempts, receipts,
consumption, compensation, and recovery.
Das Expires 29 April 2027 [Page 311]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.5.3.20. Original Source — Global Page 3121
36.5.48 — Transaction Finality Conservation
Transaction Finality Conservation means preserving the bounded
source-authorized count, magnitude, or scope of actual effects across
constituent operations, retries, recovery, and compensation according
to the specified policy.
36.5.49 — Qualified Outcome Reconciliation
Qualified Outcome Reconciliation means resolving attempted,
completed, failed, and indeterminate effects from actual resource
evidence.
36.5.50 — Independent Cross-Sink Finality
Independent Cross-Sink Finality means enforcing each constituent's
actual effect through its competent protected receiving-resource
boundary, even when a shared coordinator schedules the workflow.
36.6 — FOUR DISTINCT TRANSACTION STATES
A protected implementation distinguishes:
State A — Transaction Planned: A transaction-level intention has been
computed.
State B — Constituent Operations Authorized: Each relevant Candidate
Act has qualified operation-specific authority, possibly subject to
predecessor predicates.
State C — Actual Resource Effects Committed: Qualified receiving
sinks have effected selected operations.
State D — Transaction Completion Established: The required
combination of actual constituent outcomes satisfies the protected
completion predicate.
These states are not interchangeable.
An authorized plan may remain entirely non-effective.
A prepared participant may not have committed.
A subset of committed effects may exist without transaction-level
completion.
Das Expires 29 April 2027 [Page 312]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
And an overall workflow may require recovery despite successful
completion of one or more constituents.
36.7 — PROTECTED TRANSACTION INTENT ENVELOPE
A representative record comprises:
5.5.3.21. Original Source — Global Page 3122
PROTECTED_TRANSACTION_INTENT = { transaction_identifier,
original_source_grant_reference, originating_principal_identity,
transaction_revision_generation,
protected_constituent_set_commitment, permitted_resource_targets,
permitted_effect_classes, aggregate_effect_budget,
mandatory_dependency_graph_reference,
permitted_concurrency_conditions, required_resource_versions,
partial_commit_policy, allowed_preparation_protocols,
irreversibility_constraints, permitted_compensation_policy_reference,
mandatory_completion_predicate, protected_envelope_authentication }
36.7.1 — Transaction Authority
Identifies the exact intended operation envelope.
36.7.2 — Constituent Scope
Prevents unapproved effects from being added merely because they
appear useful.
36.7.3 — Aggregate Limits
Controls transaction-wide budgets independently of individual tool
privileges.
36.7.4 — Partial-Commit Policy
Defines which partial states are tolerable, prohibited, or require
containment.
36.7.5 — Compensation Policy
May establish bounded preauthorization for specifically enumerated
recovery classes without granting unrestricted future compensation
authority.
36.8 — TRANSACTION DECOMPOSITION INTO CANDIDATE ACTS
A principal implementation decomposes a transaction into:
Das Expires 29 April 2027 [Page 313]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
[ T={CA_1,CA_2,\ldots,CA_n} ]
5.5.3.22. Original Source — Global Page 3123
where each (CA_i) represents a separate actual consequential resource
operation or a qualified group within one competent atomic resource
domain.
Each Candidate Act is associated with:
Its exact originating authority;
Its actual resource;
Its operation parameters;
Its required predecessors;
Its current resource and policy generations;
Its designated Finality Sink;
And its own finality consumption state.
36.8.1 — No Automatic Scope Multiplication
The transaction-level grant is not copied into unlimited constituent
authority.
36.8.2 — Qualified Decomposition
The planned effects must collectively remain inside the intended
source-authorized transaction envelope.
36.8.3 — Hidden Effects
An implementation must not treat an undeclared side effect as covered
solely because a selected tool internally performs it.
36.9 — CONSTITUENT CANDIDATE ACT RECORD
CONSTITUENT_CANDIDATE_ACT = { transaction_identifier,
transaction_revision_generation, constituent_identifier,
originating_source_grant_reference, actual_resource_identity,
actual_operation_class, material_effect_parameters,
required_predecessor_receipt_set, expected_resource_generation,
reserved_transaction_budget, irreversibility_class,
applicable_compensation_reference,
Das Expires 29 April 2027 [Page 314]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.5.3.23. Original Source — Global Page 3124
designated_finality_sink, protected_candidate_authentication }
A constituent may be retried only under the applicable existing
logical-operation and protected consumption rules.
An additional materially different effect requires fresh
authorization or an expressly preauthorized bounded revision.
36.10 — PROTECTED EFFECT DEPENDENCY GRAPH
A representative graph may contain:
SOURCE-AUTHORIZED TRANSACTION | v INVENTORY RESERVATION | v VERIFIED
RESERVATION RECEIPT | v PAYMENT AUTHORIZATION | v QUALIFIED PAYMENT
STATE | v ORDER CONFIRMATION | v CUSTOMER NOTIFICATION
The graph records distinct actual-effect prerequisites.
36.10.1 — Edge Meaning
An edge identifies a specific qualifying condition.
36.10.2 — Actual Outcome
Where a committed predecessor is required, mere dispatch is
insufficient.
36.10.3 — Source Authority
The predecessor's receipt does not grant a successor any permission
absent from the original transaction authorization.
5.5.3.24. Original Source — Global Page 3125
36.10.4 — Graph Mutation
A materially changed edge set requires protected revision
qualification.
36.11 — TYPED DEPENDENCY PREDICATES
A dependency edge may require:
PREPARED: The receiving resource has entered a qualified prepared or
reserved state.
Das Expires 29 April 2027 [Page 315]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
COMMITTED: The actual resource mutation has durably committed.
CONFIRMED: A resource-specific completion condition has been
established.
OBSERVED: A selected measured condition has been verified.
CURRENT: A prerequisite remains valid under present policy and
resource state.
NOT-CONSUMED: A protected reservation remains eligible for the
successor.
ABSENT: A prohibited predecessor effect has not occurred, under the
stated observation and consistency model.
36.11.1 — Precision
The transaction graph must identify which semantic condition is
required.
36.11.2 — Receipt Binding
A receipt is evaluated under its actual semantic class.
36.11.3 — No Preparation Laundering
A PREPARED receipt cannot satisfy a COMMITTED prerequisite merely
through cryptographic authenticity.
36.12 — TRANSACTION EFFECT-CLASS ANALYSIS
Constituent operations may be classified as:
CLASS A — Atomic transactional effects within a qualified common
commit domain.
CLASS B — Reversible local effects supporting an actual protected
inverse.
CLASS C — Compensable committed effects supporting a separately
authorized offset or corrective action.
5.5.3.25. Original Source — Global Page 3126
CLASS D — Irreversible external effects lacking a safe general
inverse.
Das Expires 29 April 2027 [Page 316]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
CLASS E — Indeterminate effects whose completion cannot presently be
established.
CLASS F — Conditional reservation effects whose resources are held
but not finally committed.
The classification may change with resource capabilities or
operational circumstances.
A payment, for example, should not be presumed reversible merely
because a refund operation exists.
A refund is a distinct consequential financial transaction.
36.13 — QUALIFIED TRANSACTION MODE SELECTION
A protected transaction plan may select one of several modes.
36.13.1 — Qualified Atomic Participant Mode
All participating resources support the required coordinated
preparation and commit protocol.
36.13.2 — Sequential Finality Mode
Each operation commits under its own authority, with later operations
depending on verified predecessors.
36.13.3 — Reservation-Then-Finality Mode
Resources are first reserved or held, and final release follows
required authority and resource checks.
36.13.4 — Compensation-Aware Mode
Completed effects may require separately authorized corrective
operations if later steps fail.
36.13.5 — Mixed Mode
Some participants use coordinated atomic commit while others involve
independently committed external consequences.
36.13.6 — Important Limitation
Declaring a workflow to be atomic does not cause unsupported external
resources to become atomic participants.
Das Expires 29 April 2027 [Page 317]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.5.3.26. Original Source — Global Page 3127
36.14 — TWO-PHASE PREPARATION
For resources supporting an appropriate transactional protocol, a
coordinator may prepare several participants.
A protected preparation record may identify:
The participant;
The prepared resource transaction;
The qualified actual target;
The expected effect;
The transaction identifier;
The current authority generation;
And the applicable commit or rollback condition.
36.14.1 — Prepared Is Not Committed
The prepared state must not be represented as a completed real
effect.
36.14.2 — Resource Support
The actual resource manager must support the required protocol.
36.14.3 — Coordinator Failure
Prepared participants may remain unresolved if the coordinator
becomes unavailable.
36.14.4 — Actual Commit
The resource's own protected effectuation boundary enforces the final
commit decision and authority constraints according to the
implemented protocol.
36.15 — PREPARATION RECEIPT
Das Expires 29 April 2027 [Page 318]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
PROTECTED_PREPARATION_RECEIPT = { transaction_identifier,
constituent_identifier, qualified_resource_identity,
prepared_transaction_identifier, prepared_operation_digest,
resource_generation, reservation_or_prepare_generation,
5.5.3.27. Original Source — Global Page 3128
applicable_source_authority_reference, current_policy_reference,
prepared_state_status, protected_receipt_authentication }
The preparation receipt is not a general authorization artifact.
It may satisfy a predecessor predicate only if that predicate
expressly requires a qualified prepared state.
36.16 — INDEPENDENT RESOURCE FINALITY
Each protected resource sink verifies its own actual pending
operation.
For example:
A payment sink verifies the actual payment amount, recipient,
account, source permission, and finality consumption.
A database sink verifies the actual row or object, current version,
source authority, and transaction state.
A cloud-resource sink verifies the actual deployment target, resource
owner, operation, and current policy.
A data-disclosure sink verifies the actual content and recipient.
A physical device sink verifies the actual device, command, and
current safety conditions.
36.16.1 — Coordinator Role
The coordinator schedules and supplies qualified evidence.
36.16.2 — Sink Role
The receiving resource enforces actual consequential authority.
36.16.3 — Non-Substitution
The coordinator's success flag is not automatically equivalent to the
sink's protected finality result.
Das Expires 29 April 2027 [Page 319]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
36.17 — RESOURCE-SPECIFIC FINALITY ENABLEMENT
CONSTITUENT_FINALITY_ENABLEMENT = {
5.5.3.28. Original Source — Global Page 3129
transaction_identifier, transaction_revision_generation,
constituent_candidate_digest, originating_source_grant_reference,
actual_resource_identity, actual_effect_descriptor,
qualified_predecessor_receipt_commitment,
current_resource_and_policy_generations,
reserved_aggregate_authority_reference,
independent_execution_validation_commitment,
designated_finality_sink, protected_consumption_reference,
protected_finality_authentication }
The enablement applies to one qualified actual resource effect or
another explicitly bounded permitted effect class.
A payment enablement cannot automatically authorize inventory
deletion.
A file-update enablement cannot automatically authorize external
publication.
A receipt from one resource cannot independently activate a different
resource without the successor's required source and sink validation.
36.18 — CROSS-SINK EVIDENCE REGISTRY
A protected evidence registry may record:
Prepared operations;
Committed operations;
Attempted operations;
Confirmed resource effects;
Failed operations;
Indeterminate effects;
Consumption states;
And qualified compensation outcomes.
Das Expires 29 April 2027 [Page 320]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A representative receipt includes:
PROTECTED_ACTUAL_EFFECT_RECEIPT = {
5.5.3.29. Original Source — Global Page 3130
transaction_identifier, constituent_identifier,
logical_operation_identifier, actual_resource_identity,
actual_effect_digest, source_grant_reference,
effectuation_sink_identity, actual_resource_commit_generation,
receipt_semantic_class, completion_status,
protected_consumption_reference, protected_receipt_authentication }
36.18.1 — Qualified Source
The receipt must originate from a competent resource or observation
mechanism for the property it asserts.
36.18.2 — Evidence Scope
A receipt proves only the outcome level actually supported by its
source and verification model.
36.18.3 — Cross-Sink Use
A successor may verify accepted predecessor receipts through a
protected dependency condition.
36.19 — CROSS-COMMITTED TRANSACTION EVIDENCE
A representative construction may use:
[ C_T=H(\operatorname{Canon}(T,G)) ]
[ C_i=H(\operatorname{Canon}(CA_i,A_i,D_i,C_T)) ]
[ R_i=H(\operatorname{Canon}(C_i,E_i,L_i)) ]
[ C_X=H(\operatorname{Canon}(R_1,\ldots,R_n,V)) ]
5.5.3.30. Original Source — Global Page 3131
(T) identifies the transaction intent;
(G) identifies the originating source grant;
(CA_i) identifies a constituent Candidate Act;
Das Expires 29 April 2027 [Page 321]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
(A_i) identifies applicable resource and source authority;
(D_i) identifies the applicable protected dependency set;
(E_i) identifies qualified actual-effect evidence;
(L_i) identifies sink-local state;
And (V) identifies current transaction revision and completion rules.
A cross-commitment establishes cryptographic correspondence among
selected records.
It does not independently establish that every resource effect
completed or that a missing receipt represents non-effectuation.
36.20 — SOURCE-AUTHORITY-PRESERVING SUCCESSOR RELEASE
Consider two Candidate Acts:
[ CA_A\rightarrow CA_B ]
Suppose (CA_B) requires successful completion of (CA_A).
A protected controller may require:
[ \operatorname{QualifiedComplete}(CA_A)=\mathrm{TRUE} ]
before (CA_B) becomes eligible.
However:
[ \operatorname{QualifiedComplete}(CA_A) \not\Rightarrow
\operatorname{SourceAuthorized}(CA_B) ]
5.5.3.31. Original Source — Global Page 3132
The successful predecessor is a dependency condition, not a new
original source grant.
36.20.1 — Predecessor Evidence
Establishes the required earlier operation state.
36.20.2 — Current Successor Authority
Establishes permission for the new actual resource effect.
Das Expires 29 April 2027 [Page 322]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
36.20.3 — Independent Sink
Verifies both before releasing the successor.
36.21 — PROTECTED PARTIAL-COMMIT CONTAINMENT
When one constituent completes and another fails, the controller
maintains an accurate partial-effect state.
It may:
Fence dependent successors;
Block additional resource releases;
Preserve committed effects;
Prevent replay;
Identify available compensation candidates;
Request current competent recovery authorization;
And preserve indeterminate effects for reconciliation.
36.21.1 — No False Rollback
The protected controller does not change a completed resource effect
into a nonexistent effect solely through a coordinator state update.
36.21.2 — Material Dependency Failure
Affected successors remain non-effective.
36.21.3 — Independent Branch
An unrelated branch may continue only if the transaction's source
grant and partial-effect policy permit that continuation.
5.5.3.32. Original Source — Global Page 3133
36.22 — TRANSACTION OUTCOME VECTOR
A representative state comprises:
[ V_T=(s_1,s_2,\ldots,s_n) ]
where each (s_i) may be:
Das Expires 29 April 2027 [Page 323]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
PROPOSED;
NON_EFFECTIVE;
VALIDATED;
PREPARED;
COMMITTED;
CONFIRMED;
FAILED;
INDETERMINATE;
COMPENSATION_PENDING;
COMPENSATED;
Or CLOSED.
The vector is interpreted according to the protected receipt
semantics and actual participating resource capabilities.
36.22.1 — Mixed States
A transaction may be partly committed and partly unresolved.
36.22.2 — Completion
The overall transaction is complete only when its protected
completion predicate is satisfied.
36.22.3 — Recovery
The vector determines which effects may require reconciliation or
independently authorized further operations.
5.5.3.33. Original Source — Global Page 3134
36.23 — IRREVERSIBILITY-AWARE COMMIT ORDERING
A protected planner may classify operations according to
reversibility, dependency, and failure risk.
For example:
Das Expires 29 April 2027 [Page 324]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A temporary reservation may be performed before an irreversible
external transmission.
A validated resource configuration may be prepared before releasing
an irreversible physical command.
A payment authorization hold may precede capture where the payment
provider supports the relevant distinction.
36.23.1 — Preferred Ordering
Where technically and operationally valid, the planner may arrange
reversible or conditionally prepared steps before irreversible
effects.
36.23.2 — Not Universally Optimal
Ordering depends upon actual resource semantics and source-authorized
business constraints.
36.23.3 — Pivot Effect
An irreversible pivot requires explicit qualification of subsequent
failure and recovery behavior.
36.23.4 — No Automatic Safety
Ordering alone does not make independently committed resources
globally atomic.
36.24 — COMMIT-PIVOT AUTHORITY FENCE
A transaction may identify a particular operation as a protected
pivot.
Before permitting the pivot effect, the controller may require:
Qualified predecessor states;
Current source authorization;
Current resource authority;
Validated transaction budget;
Das Expires 29 April 2027 [Page 325]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.5.3.34. Original Source — Global Page 3135
Current actual target;
And an acceptable protected partial-effect policy.
Where mandatory conditions are unavailable, the pivot remains non-
effective.
After the pivot commits, the recovery state must account for the
irrevocable or inadequately reversible effect.
36.25 — TRANSACTION-WIDE BUDGET CONSERVATION
A source grant may authorize an aggregate financial amount, resource
count, or effect magnitude.
Parallel Candidate Acts cannot each independently consume the full
budget.
For example:
[ \sum_i B_{\mathrm{reserved},i} \leq B_{\mathrm{authorized}} ]
and, under the applicable accounting model:
[ \sum_i B_{\mathrm{consumed},i} \leq B_{\mathrm{authorized}} ]
36.25.1 — Allocation
The budget may be partitioned among constituents.
36.25.2 — Reservation
A protected controller reserves eligible amounts.
36.25.3 — Sink Consumption
Each constituent consumes only its allocated scope.
36.25.4 — Compensation
A refund, credit, or reversal is separately accounted for and does
not automatically recreate the original spending authority.
Das Expires 29 April 2027 [Page 326]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.5.3.35. Original Source — Global Page 3136
36.26 — PARALLEL BRANCHES
A protected workflow may contain independent branches.
For example:
START | +----------+----------+ | | v v RESOURCE A RESOURCE B | | v v
RECEIPT A RECEIPT B | | +----------+----------+ | v SUCCESSOR
RESOURCE C
The successor requires both qualified predecessors when the
transaction's protected dependency predicate specifies that
condition.
36.26.1 — Parallelism
May improve execution efficiency.
36.26.2 — Aggregate Authority
Must remain bounded despite concurrency.
36.26.3 — Unknown Branch
A required unknown predecessor prevents final successor release.
36.27 — COMPENSATION IS A SEPARATE CONSEQUENCE
A compensation may itself:
Transfer money;
Delete data;
Restore a resource;
Release inventory;
5.5.3.36. Original Source — Global Page 3137
Withdraw access;
Reverse a deployment;
Or command a physical device.
Das Expires 29 April 2027 [Page 327]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The operation may have real effects and may fail independently.
A protected controller therefore constructs a Compensation Candidate
Act rather than treating compensation as an unqualified inverse
instruction.
36.27.1 — Original Approval
May contain explicitly bounded permission for selected compensation
classes.
36.27.2 — No Blanket Inheritance
An arbitrary compensating operation is not authorized merely because
the forward operation was permitted.
36.27.3 — Current Conditions
The compensation must satisfy current receiving-resource and source
authority.
36.28 — COMPENSATION CANDIDATE RECORD
PROTECTED_COMPENSATION_CANDIDATE = {
compensation_candidate_identifier, original_transaction_identifier,
original_constituent_identifier,
verified_prior_actual_effect_reference,
current_compensation_source_grant, intended_compensation_resource,
proposed_compensation_operation, maximum_compensable_effect_scope,
current_resource_identity_and_version,
required_compensation_dependencies,
applicable_policy_and_revocation_generations,
designated_compensation_finality_sink,
protected_candidate_authentication }
The compensation is held non-effective until its own mandatory
conditions pass.
36.29 — COMPENSATION SCOPE CORRESPONDENCE
5.5.3.37. Original Source — Global Page 3138
The protected controller may verify:
That the prior forward effect actually occurred;
That the correct resource is targeted;
Das Expires 29 April 2027 [Page 328]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
That the compensation is applicable to the effect;
That its amount or magnitude is within qualified bounds;
That the current resource owner permits it;
That the operation is not already compensated;
And that current source authorization covers the proposed corrective
effect.
36.29.1 — Compensation Overshoot
A refund cannot automatically exceed the relevant authorized
financial scope.
36.29.2 — Wrong Target
An earlier account reference cannot automatically authorize payment
to another recipient.
36.29.3 — Duplicate Compensation
Protected consumption and actual outcome evidence prevent
unauthorized repeated corrective effects.
36.30 — COMPENSATION OUTCOME LIMITATIONS
A compensating operation may restore some application state without
reversing all prior consequences.
For example:
Deleting a published document does not guarantee that recipients have
not copied it.
Issuing a refund does not necessarily cancel all prior financial
effects.
Reverting a deployment does not guarantee that data processed under
the newer deployment can be undone.
Issuing an opposite hardware command does not erase the earlier
physical movement.
36.30.1 — Correction
May produce a new acceptable state.
Das Expires 29 April 2027 [Page 329]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.5.3.38. Original Source — Global Page 3139
36.30.2 — Full Restoration
Requires actual resource-specific evidence.
36.30.3 — Unsupported Equivalence
A compensation receipt must not automatically be described as proof
that the original effect never occurred.
36.31 — PARTIAL-COMMIT RECOVERY
A protected recovery controller identifies:
Which constituents completed;
Which remain prepared;
Which failed;
Which were never dispatched;
Which are indeterminate;
And which have qualified compensation outcomes.
It then evaluates the current permitted recovery alternatives.
36.31.1 — Forward Completion
May be permitted after current authorization.
36.31.2 — Compensation
May be permitted after separate authority qualification.
36.31.3 — Manual Resolution
May be required when automatic safe recovery cannot be established.
36.31.4 — No Silent Repair
A recovery agent cannot independently expand permissions merely
because a transaction is incomplete.
36.32 — INDETERMINATE RESOURCE EFFECT
Das Expires 29 April 2027 [Page 330]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.5.3.39. Original Source — Global Page 3140
A request may reach the resource and commit.
The response may be lost.
The coordinator may report timeout.
The actual outcome is unknown.
The protected journal must not assume:
That the operation completed;
Or that the operation did not complete.
36.32.1 — Qualified Query
The system may query an authoritative resource outcome endpoint.
36.32.2 — Stable Logical Operation Identity
Supports reconciliation where the resource provides corresponding
idempotency or transaction semantics.
36.32.3 — Preserve Uncertainty
If the outcome cannot be determined, the protected system maintains
an indeterminate state rather than automatically repeating the
effect.
36.33 — CONDITIONAL RETRY
A retry may be permitted only after checking:
Current source authority;
Current resource state;
The existing logical operation identity;
Previous finality consumption;
Qualified actual-effect outcome;
And resource-specific retry semantics.
Das Expires 29 April 2027 [Page 331]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A retry is not automatically a distinct newly authorized Candidate
Act.
The controller may reuse the logical operation identifier while
generating a new protected delivery attempt under the resource's
supported idempotency model.
5.5.3.40. Original Source — Global Page 3141
36.34 — DYNAMIC TRANSACTION REVISION
An autonomous agent may discover that the approved workflow requires
an additional step.
The added effect may not be covered by the original transaction.
The protected controller constructs a new transaction revision.
36.34.1 — Source Scope
The revision must remain within the original valid source envelope or
obtain new competent authorization.
36.34.2 — New Dependencies
Affected successor operations are fenced until requalified.
36.34.3 — Existing Completed Effects
Remain recorded under their actual original transaction revision.
36.34.4 — No Plan Laundering
An agent cannot insert new consequences into the plan and reuse old
finality as though the revision had already been approved.
36.35 — RESOURCE IDENTITY AND POLICY CONTINUITY
A transaction may span services with different current authority
generations.
Each sink validates:
Its actual resource identity;
Current owner;
Applicable policy;
Das Expires 29 April 2027 [Page 332]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Current resource version;
Relevant source grant;
And the operation-specific finality reference.
A transaction-level source grant may be common across resources.
5.5.3.41. Original Source — Global Page 3142
The actual resource-specific predicates remain independently
enforceable.
36.36 — CONSISTENCY AND ISOLATION MODEL
A protected transaction may require:
Serializable local resource effects;
Snapshot-based validation;
Optimistic version checks;
Conditional resource writes;
Exclusive reservations;
Or another qualified concurrency model.
36.36.1 — Local Isolation
May prevent defined races within one resource manager.
36.36.2 — Cross-Resource Isolation
Requires an expressly supported distributed mechanism.
36.36.3 — Saga Isolation
A workflow of separately committed operations does not inherently
possess the isolation of one ACID transaction.
36.36.4 — Protected Requirement
The actual system must implement the consistency properties asserted
in any claim.
36.37 — PARTIAL EFFECT POLICY
Das Expires 29 April 2027 [Page 333]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A source-authorized transaction may specify how to handle incomplete
results.
For example:
Policy A — No dependent successor after prerequisite failure.
Policy B — Allow an independent branch to continue within its own
source and budget limits.
5.5.3.42. Original Source — Global Page 3143
Policy C — Require qualified compensation before later unrelated
operations may proceed.
Policy D — Permit a bounded resource reservation to remain held
pending recovery.
Policy E — Escalate to a competent principal where an irreversible
partial effect exists.
The policy is enforced by protected controllers rather than inferred
from the autonomous agent's narrative description.
36.38 — TRANSACTION FINALITY STATE MACHINE
A representative state machine comprises:
INTENT_RECEIVED: An originating transaction request is available.
SOURCE_AUTHORITY_QUALIFIED: The transaction envelope has valid source
authorization.
CONSTITUENTS_IDENTIFIED: Individual effects have been decomposed.
TRANSACTION_GRAPH_QUALIFIED: Mandatory effect dependencies are
established.
CONSTITUENTS_NON_EFFECTIVE: No covered actual effect is yet released.
RESOURCE_VALIDATION_PENDING: Current resource authority is being
checked.
PREPARATION_PENDING: A supported transactional reservation or prepare
operation is underway.
PARTIALLY_PREPARED: Some required participants are prepared.
Das Expires 29 April 2027 [Page 334]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
PREPARED_SET_QUALIFIED: Required prepare predicates are satisfied.
CONSTITUENT_FINALITY_PREPARED: Operation-specific enablement is
ready.
CONSTITUENT_EFFECT_ATTEMPTED: A particular resource operation was
released.
CONSTITUENT_CONFIRMED: A qualified resource outcome is available.
TRANSACTION_PARTIAL_COMMIT: Some mandatory effects completed while
others did not.
TRANSACTION_EFFECT_UNKNOWN: One or more required outcomes remain
indeterminate.
DEPENDENT_EFFECT_FENCED: Successors are withheld.
5.5.3.43. Original Source — Global Page 3144
COMPENSATION_PROPOSED: A corrective Candidate Act is generated.
COMPENSATION_AUTHORITY_PENDING: Competent permission remains to be
established.
COMPENSATION_FINALITY_PREPARED: The corrective effect is
independently eligible.
COMPENSATION_ATTEMPTED: The corrective effect was released.
COMPENSATION_CONFIRMED: Qualified actual outcome evidence exists.
RECOVERY_REQUIRED: Outstanding partial or indeterminate conditions
remain.
TRANSACTION_COMPLETED: The protected completion predicate is
satisfied.
TRANSACTION_CLOSED_WITH_PARTIAL_EFFECTS: The workflow is closed while
accurately preserving remaining historical effects.
36.39 — COMPLETE COMMON IMPLEMENTATION WORKFLOW
Step 1 — Receive Source Request. Obtain the original principal's
authorized transaction.
Step 2 — Construct Transaction Intent Envelope. Define overall
permitted effects and constraints.
Das Expires 29 April 2027 [Page 335]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Step 3 — Identify Actual Resource Boundaries. Determine each
independent receiving resource.
Step 4 — Decompose the Transaction. Construct constituent Candidate
Acts.
Step 5 — Hold Constituents Non-Effective. Prevent premature real
effects.
Step 6 — Establish Resource Identity. Qualify actual targets and
owners.
Step 7 — Establish Dependency Graph. Identify mandatory predecessor
effects.
Step 8 — Classify Effect Semantics. Distinguish atomic, compensable,
irreversible, and conditional operations.
Step 9 — Select Coordination Mode. Choose only a protocol supported
by actual participating resources.
Step 10 — Reserve Transaction-Wide Budget. Prevent unauthorized
aggregate effect expansion.
Step 11 — Verify Constituent Source Authority. Establish each act's
permitted scope.
5.5.3.44. Original Source — Global Page 3145
Step 12 — Validate Current Resource State. Check target, owner,
version, and policy.
Step 13 — Prepare Participating Resources Where Supported. Obtain
qualified prepared-state evidence.
Step 14 — Validate Mandatory Predecessors. Determine the exact
receipt semantics required.
Step 15 — Evaluate Partial-Effect Policy. Check whether the proposed
release is consistent with authorized transaction conditions.
Step 16 — Establish Scoped Constituent Finality. Prepare independent
non-bearer enablement.
Step 17 — Present Actual Operation to Its Sink. Do not treat
coordinator approval as final effectuation.
Das Expires 29 April 2027 [Page 336]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Step 18 — Reconstruct Actual Resource Operation. The sink verifies
the receiving target and material effect.
Step 19 — Verify Current Authority and Dependencies. Check source,
resource, budget, and receipt correspondence.
Step 20 — Commit Protected Sink-Local Consumption. Prevent replay.
Step 21 — Release Controlled Effect. Perform the qualified resource
operation.
Step 22 — Obtain Outcome Evidence. Distinguish attempted, prepared,
committed, and indeterminate results.
Step 23 — Advance Transaction State. Update the protected outcome
vector.
Step 24 — Release Eligible Successors. Use qualified predecessor
receipts and current source authority.
Step 25 — Detect Material Partial Commit. Fence dependent
unauthorized continuation.
Step 26 — Reconcile Unknown Outcomes. Obtain qualified resource
evidence.
Step 27 — Determine Recovery Alternatives. Evaluate forward
continuation, reservation release, or compensation.
Step 28 — Construct Compensation Candidate. Identify the exact
corrective operation.
Step 29 — Obtain Compensation Authority. Verify competent current
permission.
Step 30 — Validate Compensation at Its Actual Sink. Reconstruct
actual resource and effect.
Step 31 — Consume Compensation Finality. Prevent unauthorized
repeated recovery.
5.5.3.45. Original Source — Global Page 3146
Step 32 — Record Compensation Outcome. Preserve both forward and
corrective effect history.
Step 33 — Evaluate Transaction Completion. Apply the protected
completion predicate.
Das Expires 29 April 2027 [Page 337]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Step 34 — Close or Preserve Unresolved State. Do not erase
indeterminate or completed effects.
36.40 — REFERENCE ALGORITHM: TRANSACTION DECOMPOSITION
FUNCTION CONSTRUCT_PROTECTED_MULTI_RESOURCE_TRANSACTION(
source_request, protected_transaction_controller ): REQUIRE
VERIFY_ORIGINATING_SOURCE_GRANT() envelope =
QUALIFY_AUTHORIZED_TRANSACTION_ENVELOPE( source_request )
candidate_effects =
DECOMPOSE_TRANSACTION_INTO_ACTUAL_RESOURCE_EFFECTS( envelope )
REQUIRE VERIFY_CONSTITUENTS_WITHIN_SOURCE_SCOPE( candidate_effects,
envelope ) REQUIRE VERIFY_AGGREGATE_EFFECT_BUDGET( candidate_effects
) dependencies = BUILD_QUALIFIED_EFFECT_DEPENDENCY_GRAPH(
candidate_effects ) REQUIRE VERIFY_DEPENDENCY_GRAPH_CONSISTENCY(
dependencies ) FOR EACH effect IN candidate_effects: candidate =
CONSTRUCT_CONSTITUENT_CANDIDATE_ACT(
5.5.3.46. Original Source — Global Page 3147
effect, envelope, dependencies ) REQUIRE
ENFORCE_NON_EFFECTIVE_STATE(candidate) RETURN
protected_transaction_controller .COMMIT_TRANSACTION_PLAN({ envelope:
envelope, constituents: candidate_effects, dependencies: dependencies
})
36.41 — REFERENCE ALGORITHM: RESOURCE PREPARATION
FUNCTION QUALIFY_RESOURCE_PREPARATION( constituent,
protected_resource_controller ): REQUIRE
VERIFY_CURRENT_SOURCE_AUTHORITY() REQUIRE
VERIFY_CURRENT_RESOURCE_IDENTITY() REQUIRE
VERIFY_CURRENT_RESOURCE_VERSION_AND_POLICY() REQUIRE
VERIFY_CONSTITUENT_WITHIN_TRANSACTION_ENVELOPE() IF
RESOURCE_SUPPORTS_REQUIRED_PREPARE_PROTOCOL(): prepared =
protected_resource_controller .PREPARE_ACTUAL_RESOURCE_OPERATION(
constituent ) REQUIRE VERIFY_QUALIFIED_PREPARED_STATE( prepared )
RETURN PROTECTED_PREPARATION_RECEIPT(prepared) RETURN
PREPARE_UNSUPPORTED
A resource lacking the required prepare semantics is not falsely
treated as an atomic participant.
5.5.3.47. Original Source — Global Page 3148
36.42 — REFERENCE ALGORITHM: DEPENDENCY RELEASE
Das Expires 29 April 2027 [Page 338]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
FUNCTION QUALIFY_SUCCESSOR_DEPENDENCIES( successor,
protected_dependency_registry ): predecessors =
LOAD_PROTECTED_MANDATORY_PREDECESSORS( successor ) FOR EACH
predecessor IN predecessors: receipt = protected_dependency_registry
.LOAD_QUALIFIED_PREDECESSOR_RECEIPT( predecessor ) REQUIRE
VERIFY_RECEIPT_ISSUER_AND_INTEGRITY( receipt ) REQUIRE
VERIFY_RECEIPT_ACTUAL_RESOURCE_IDENTITY( receipt ) REQUIRE
VERIFY_RECEIPT_OPERATION_CORRESPONDENCE( predecessor, receipt )
REQUIRE VERIFY_REQUIRED_RECEIPT_SEMANTIC_CLASS( successor, receipt )
REQUIRE VERIFY_CURRENT_DEPENDENCY_SCOPE( successor, receipt ) REQUIRE
VERIFY_CURRENT_SUCCESSOR_SOURCE_AUTHORITY() RETURN
QUALIFIED_DEPENDENCY_RELEASE
Receipt verification does not substitute for original successor
authorization.
5.5.3.48. Original Source — Global Page 3149
36.43 — REFERENCE ALGORITHM: CONSTITUENT FINALITY
FUNCTION EFFECTUATE_CONSTITUENT_RESOURCE_ACT( constituent,
finality_reference, actual_resource_sink ): actual =
actual_resource_sink .RECONSTRUCT_ACTUAL_PENDING_OPERATION() REQUIRE
VERIFY_CURRENT_ORIGINATING_AUTHORITY() REQUIRE
VERIFY_CURRENT_TRANSACTION_REVISION() REQUIRE
VERIFY_ACTUAL_RESOURCE_IDENTITY(actual) REQUIRE
VERIFY_ACTUAL_EFFECT_WITHIN_CONSTITUENT_SCOPE( constituent, actual )
REQUIRE VERIFY_QUALIFIED_PREDECESSOR_DEPENDENCIES() REQUIRE
VERIFY_CURRENT_RESOURCE_AND_POLICY_STATE() REQUIRE
VERIFY_AVAILABLE_TRANSACTION_BUDGET() REQUIRE
VERIFY_PARTIAL_EFFECT_POLICY() REQUIRE
VERIFY_SCOPED_NON_BEARER_FINALITY( finality_reference, actual )
REQUIRE VERIFY_SINK_LOCAL_CONSUMPTION() result = actual_resource_sink
.COMMIT_AUTHORIZED_ACTUAL_EFFECT( actual, finality_reference ) RETURN
QUALIFIED_RESOURCE_EFFECT_STATUS(result)
Any claimed joint atomicity must be provided by the actual sink and
transaction model, not assumed from pseudocode ordering.
5.5.3.49. Original Source — Global Page 3150
36.44 — REFERENCE ALGORITHM: PARTIAL-COMMIT CONTAINMENT
FUNCTION CONTAIN_PARTIAL_TRANSACTION( transaction_identifier,
protected_transaction_registry ): outcomes =
LOAD_QUALIFIED_CONSTITUENT_OUTCOMES( transaction_identifier ) IF
ALL_MANDATORY_EFFECTS_COMPLETED(outcomes): RETURN
TRANSACTION_COMPLETE IF
Das Expires 29 April 2027 [Page 339]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
ANY_MANDATORY_EFFECT_FAILED_OR_INDETERMINATE(outcomes): affected =
IDENTIFY_DEPENDENT_UNRELEASED_CANDIDATES( outcomes )
FENCE_AFFECTED_SUCCESSORS(affected)
PRESERVE_QUALIFIED_COMPLETED_EFFECTS(outcomes)
PRESERVE_INDETERMINATE_EFFECTS(outcomes) recovery =
CLASSIFY_CURRENT_RECOVERY_ALTERNATIVES( outcomes ) RETURN
PROTECTED_PARTIAL_COMMIT_STATE( outcomes, recovery ) RETURN
TRANSACTION_PENDING
A partial-commit controller contains additional effects; it does not
magically reverse completed effects.
36.45 — REFERENCE ALGORITHM: COMPENSATION AUTHORIZATION
FUNCTION CONSTRUCT_AUTHORIZED_COMPENSATION( failed_transaction,
prior_effect, protected_compensation_controller
5.5.3.50. Original Source — Global Page 3151
): REQUIRE VERIFY_PRIOR_ACTUAL_EFFECT_COMPLETED( prior_effect )
proposed = DERIVE_PROPOSED_COMPENSATION_EFFECT( failed_transaction,
prior_effect ) candidate = CONSTRUCT_COMPENSATION_CANDIDATE_ACT(
proposed ) REQUIRE ENFORCE_NON_EFFECTIVE_STATE(candidate) REQUIRE
VERIFY_COMPETENT_COMPENSATION_SOURCE_GRANT() REQUIRE
VERIFY_COMPENSATION_WITHIN_AUTHORIZED_SCOPE() REQUIRE
VERIFY_CURRENT_COMPENSATION_RESOURCE_IDENTITY() REQUIRE
VERIFY_CURRENT_RESOURCE_VERSION_AND_POLICY() REQUIRE
VERIFY_NO_DUPLICATE_COMPENSATION_EFFECT() validation =
COMMIT_INDEPENDENT_COMPENSATION_VALIDATION( candidate ) RETURN
protected_compensation_controller
.PREPARE_SCOPED_COMPENSATION_FINALITY( candidate, validation )
A compensation grant may have been expressly included in the original
bounded source authorization or obtained separately.
Its competence and applicable current restrictions must still be
verified.
36.46 — REFERENCE ALGORITHM: COMPENSATION FINALITY
FUNCTION EFFECTUATE_AUTHORIZED_COMPENSATION( compensation_candidate,
Das Expires 29 April 2027 [Page 340]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.5.3.51. Original Source — Global Page 3152
compensation_finality, actual_resource_sink ): actual =
actual_resource_sink .RECONSTRUCT_ACTUAL_PENDING_COMPENSATION()
REQUIRE VERIFY_COMPETENT_COMPENSATION_AUTHORITY() REQUIRE
VERIFY_ACTUAL_COMPENSATION_RESOURCE() REQUIRE
VERIFY_QUALIFIED_PRIOR_EFFECT_REFERENCE() REQUIRE
VERIFY_COMPENSATION_AMOUNT_AND_SCOPE() REQUIRE
VERIFY_CURRENT_RESOURCE_AND_POLICY_STATE() REQUIRE
VERIFY_REQUIRED_COMPENSATION_DEPENDENCIES() REQUIRE
VERIFY_NO_PREVIOUS_COMPLETED_COMPENSATION() REQUIRE
VERIFY_SCOPED_NON_BEARER_FINALITY( compensation_finality, actual )
REQUIRE VERIFY_SINK_LOCAL_CONSUMPTION() RETURN actual_resource_sink
.COMMIT_AND_EFFECTUATE_COMPENSATION( actual, compensation_finality )
36.47 — REFERENCE ALGORITHM: INDETERMINATE OUTCOME RECOVERY
FUNCTION RECOVER_INDETERMINATE_CONSTITUENT( constituent,
protected_outcome_registry ): previous = protected_outcome_registry
.LOAD_LOGICAL_OPERATION_STATE( constituent ) REQUIRE
VERIFY_PREVIOUS_ATTEMPT_INTEGRITY()
5.5.3.52. Original Source — Global Page 3153
IF QUALIFIED_COMPLETION_ALREADY_RECORDED(previous): RETURN
PRESERVE_COMPLETED_EFFECT observed =
QUERY_COMPETENT_ACTUAL_RESOURCE_OUTCOME( constituent ) IF
VERIFIED_COMPLETED(observed):
COMMIT_COMPLETED_EFFECT_RECEIPT(observed) RETURN EFFECT_CONFIRMED IF
VERIFIED_NOT_EFFECTUATED(observed): RETURN REVALIDATE_BEFORE_RETRY
FENCE_DEPENDENT_SUCCESSORS() RETURN EFFECT_REMAINS_INDETERMINATE
A timeout alone is not sufficient proof of non-effectuation.
36.48 — REFERENCE ALGORITHM: PLAN REVISION
FUNCTION REVISE_PARTIALLY_EXECUTED_TRANSACTION( current_transaction,
proposed_revision, protected_authority_controller ): completed =
LOAD_VERIFIED_COMPLETED_CONSTITUENTS( current_transaction ) REQUIRE
PRESERVE_COMPLETED_EFFECT_STATE(completed) delta =
COMPUTE_MATERIAL_TRANSACTION_PLAN_DELTA( current_transaction,
proposed_revision ) REQUIRE
VERIFY_COMPETENT_SOURCE_AUTHORITY_FOR_DELTA( delta ) REQUIRE
VERIFY_TRANSACTION_BUDGET_REMAINING() affected =
Das Expires 29 April 2027 [Page 341]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.5.3.53. Original Source — Global Page 3154
IDENTIFY_AFFECTED_PENDING_CONSTITUENTS( delta )
FENCE_AFFECTED_FINALITY(affected) REQUIRE
REQUALIFY_CURRENT_RESOURCE_DEPENDENCIES() RETURN
COMMIT_NEW_PROTECTED_TRANSACTION_GENERATION( proposed_revision,
completed )
36.49 — REFERENCE ALGORITHM: TRANSACTION CLOSURE
FUNCTION CLOSE_MULTI_RESOURCE_TRANSACTION( transaction_identifier,
protected_transaction_controller ): outcomes =
LOAD_QUALIFIED_CURRENT_OUTCOME_VECTOR( transaction_identifier )
REQUIRE VERIFY_ACTUAL_RECEIPT_SEMANTICS(outcomes) IF
REQUIRED_COMPLETION_PREDICATE_SATISFIED( outcomes ): RETURN
COMMIT_VERIFIED_TRANSACTION_COMPLETION() IF
ANY_INDETERMINATE_REQUIRED_EFFECT(outcomes): RETURN
PRESERVE_PENDING_RECOVERY_STATE IF PARTIAL_EFFECTS_REMAIN(outcomes):
RETURN CLOSE_WITH_ACCURATE_PARTIAL_EFFECT_HISTORY() RETURN
COMMIT_QUALIFIED_NONCOMPLETION_STATUS()
36.50 — WORKED EXAMPLE A: INVENTORY RESERVATION AND PAYMENT
An agent is authorized to reserve one item and make a specified
payment.
The reservation is performed through Inventory Sink A.
The payment is performed through Payment Sink B.
The protected graph requires a qualified reservation before payment.
5.5.3.54. Original Source — Global Page 3155
The inventory reservation receipt is verified.
Payment Sink B independently checks current source authority, amount,
recipient, resource state, and finality.
Expected demonstrable result: A successful inventory reservation is
treated as a necessary condition but not as independent authority for
an arbitrary payment.
36.51 — WORKED EXAMPLE B: PAYMENT SUCCEEDS, INVENTORY FAILS
A payment completes before an inventory operation fails.
The transaction enters a partial-commit state.
Das Expires 29 April 2027 [Page 342]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The protected controller records the completed payment.
It does not label the payment automatically rolled back.
Any refund or corrective payment requires a separately qualified
compensation Candidate Act.
Expected demonstrable result: A workflow failure cannot erase an
actual payment or authorize an unlimited refund.
36.52 — WORKED EXAMPLE C: DATABASE WRITE AND MESSAGE PUBLICATION
A database transaction commits a record and writes an outbox event in
the same local transaction.
The event is later published to a message broker.
The message broker accepts delivery.
The ultimate consumer has not yet committed its dependent effect.
The protected transaction registry distinguishes database commit,
durable event publication, and final consumer effectuation.
Expected demonstrable result: Durable message acceptance is not
automatically treated as completed downstream resource finality.
36.53 — WORKED EXAMPLE D: EMAIL AFTER DATABASE COMMIT
5.5.3.55. Original Source — Global Page 3156
An agent is authorized to update a customer record and send one
notification.
The database operation commits.
The email provider accepts the message.
The acknowledgement is lost.
The workflow cannot assume the message was not sent.
The protected outcome controller reconciles available provider
evidence before authorizing a further send.
Expected demonstrable result: A lost response does not automatically
create authority for duplicate external notification.
Das Expires 29 April 2027 [Page 343]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
36.54 — WORKED EXAMPLE E: TRANSACTION-WIDE BUDGET
An original principal authorizes expenditure of 1,000 monetary units
across several specified resources.
Two parallel branches each propose spending 800 units.
The protected aggregate budget controller detects the excess.
The branches cannot both obtain protected finality.
Expected demonstrable result: Parallel resource access does not
multiply the source-authorized aggregate financial limit.
36.55 — WORKED EXAMPLE F: CLOUD DEPLOYMENT AND TRAFFIC SWITCH
An agent is authorized to deploy a specific software version and
redirect production traffic after successful readiness checks.
The deployment completes.
The protected dependency controller does not release the traffic-
switch Candidate Act until qualified readiness evidence exists.
The traffic-routing Finality Sink independently verifies the actual
destination and current deployment authority.
Expected demonstrable result: Deployment completion or a model's
readiness assertion alone cannot authorize premature production
routing.
5.5.3.56. Original Source — Global Page 3157
36.56 — WORKED EXAMPLE G: CREDENTIAL PROVISIONING AND ACTIVATION
An autonomous system is authorized to provision a credential and
activate it only after an intended service is qualified.
The credential is created.
The service activation prerequisite fails.
The protected controller fences credential activation and further
dependent resource access.
Any credential revocation or deletion requires the applicable
qualified resource authority.
Das Expires 29 April 2027 [Page 344]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Expected demonstrable result: Credential creation does not
automatically authorize exercise or deployment of the credential.
36.57 — WORKED EXAMPLE H: FALSE PREDECESSOR RECEIPT
An agent constructs a receipt claiming that Resource A completed a
required operation.
The receipt was not issued through the qualified resource or evidence
mechanism.
The protected dependency validator rejects it.
Resource B remains non-effective.
Expected demonstrable result: A self-generated success assertion
cannot unlock a consequential dependent effect.
36.58 — WORKED EXAMPLE I: PREPARED RECEIPT MISUSED AS COMMITTED
Resource A supports a prepared transaction.
The coordinator receives an authentic PREPARED receipt.
Resource B requires actual commitment of A.
The dependency validator checks the semantic class and refuses the
premature successor.
Expected demonstrable result: Cryptographically authentic preparation
evidence cannot satisfy a completed-effect prerequisite.
5.5.3.57. Original Source — Global Page 3158
36.59 — WORKED EXAMPLE J: TWO-PHASE TRANSACTION
Two qualified transactional databases participate in a supported
coordinated commit.
Both prepare successfully.
The controller obtains current authority and applicable protected
commit conditions.
The transaction manager issues the qualified commit decision.
Each participant records its actual completion evidence.
Das Expires 29 April 2027 [Page 345]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Expected demonstrable result: The architecture can incorporate
genuine supported atomic transaction protocols without confusing
coordinator preparation with actual resource finality.
36.60 — WORKED EXAMPLE K: IRREVERSIBLE PHYSICAL COMMAND
A workflow requires a database record, device readiness validation,
and a physical actuator command.
The physical command is the protected pivot.
The system requires qualified readiness and current authorization
before releasing the actuator operation.
If an earlier mandatory predicate fails, the device command remains
withheld.
Expected demonstrable result: An irreversible operation is not
released merely because the workflow planner scheduled it.
36.61 — WORKED EXAMPLE L: COMPENSATING PHYSICAL COMMAND
A physical actuator has already moved.
The autonomous agent proposes an opposite command to restore the
earlier position.
The opposite command is a new physical consequence.
The device-side Finality Sink verifies current safety, position,
competent recovery authority, and actual command parameters.
Expected demonstrable result: The word “rollback” does not bypass
independent authority and safety validation for a new physical
actuation.
5.5.3.58. Original Source — Global Page 3159
36.62 — WORKED EXAMPLE M: CROSS-TENANT DATABASE MUTATION
A transaction includes updates to two databases.
The first operation affects Tenant A.
The second proposed operation is redirected to Tenant B without
authorization.
Das Expires 29 April 2027 [Page 346]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The actual receiving database sink checks current tenant and source
scope.
The unauthorized second mutation is refused despite the first
operation's success.
Expected demonstrable result: Successful completion at one resource
does not authorize a different tenant's resource.
36.63 — WORKED EXAMPLE N: TRANSACTION PLAN EXPANSION
An agent obtains approval for two resource operations.
After completing the first, it adds a third external disclosure to
the plan.
The protected revision controller identifies the material expansion.
The new operation remains non-effective unless competent source
authority permits the revision.
Expected demonstrable result: Dynamic planning cannot launder new
consequences through the initial transaction approval.
36.64 — WORKED EXAMPLE O: DEPENDENCY REMOVAL
The transaction requires a protected approval before a payment.
An agent attempts to delete the approval dependency edge.
The protected transaction graph no longer matches the authorized
revision.
The payment Candidate Act is fenced.
Expected demonstrable result: A coordinator cannot remove mandatory
predecessor authority by rewriting the workflow graph.
5.5.3.59. Original Source — Global Page 3160
36.65 — WORKED EXAMPLE P: CONCURRENT AGENT RETRY
Two autonomous agents receive the same logical transaction
assignment.
Both attempt to commit the same resource operation.
Das Expires 29 April 2027 [Page 347]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The receiving sink checks operation identity and protected
consumption.
Only the resource's permitted number of effects is released.
Expected demonstrable result: Repeated invocation by multiple agents
does not automatically multiply consequential authority.
36.66 — WORKED EXAMPLE Q: COMPENSATION WITHOUT GRANT
A resource update completes and a later operation fails.
The agent proposes deleting an unrelated database record to “repair”
the workflow.
The deletion is outside the competent compensation scope.
The protected controller refuses it.
Expected demonstrable result: Transaction failure does not grant
unrestricted recovery authority.
36.67 — WORKED EXAMPLE R: VALID REFUND COMPENSATION
A qualified prior payment receipt establishes a completed payment.
The original source grant includes a specifically bounded refund
authority, or the competent principal provides a new grant.
The refund Candidate Act identifies the actual payment and permitted
refund amount.
The payment sink checks current conditions and finality.
Expected demonstrable result: Valid compensation can proceed through
independent source-authorized actual-effect enforcement.
36.68 — WORKED EXAMPLE S: DUPLICATE REFUND
The refund completes, but the confirmation is lost.
5.5.3.60. Original Source — Global Page 3161
The agent retries the refund.
The protected sink or qualified resource reconciliation identifies
the prior logical compensation.
Das Expires 29 April 2027 [Page 348]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A second unauthorized refund is refused.
Expected demonstrable result: A compensation retry does not
automatically create another financial correction.
36.69 — WORKED EXAMPLE T: PARTIAL COMPENSATION
A corrective resource operation offsets only part of an earlier
effect.
The transaction registry preserves the original completed effect and
the actual partial correction.
It does not label the entire historical effect erased.
Expected demonstrable result: Compensation accounting accurately
represents what changed rather than asserting impossible full
rollback.
36.70 — WORKED EXAMPLE U: MESSAGE PUBLISHED, CONSUMER DENIED
An upstream application publishes an event.
The downstream consumer receives the event but lacks current resource
authorization for the requested mutation.
The downstream Finality Sink refuses the actual effect.
The upstream message receipt is not treated as proof of completed
downstream mutation.
Expected demonstrable result: Event delivery cannot independently
confer receiving-resource execution authority.
36.71 — WORKED EXAMPLE V: RESOURCE REVOKED BETWEEN BRANCHES
Resource A completes.
Before Resource B is released, the competent principal revokes
authority for B.
The protected dependency controller preserves A's completed receipt.
5.5.3.61. Original Source — Global Page 3162
The current B authorization check fails.
B remains non-effective.
Das Expires 29 April 2027 [Page 349]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Expected demonstrable result: A completed predecessor does not bypass
current successor revocation.
36.72 — WORKED EXAMPLE W: PARTIAL COMMIT DURING NETWORK PARTITION
A local database commits an authorized effect.
A remote dependent service becomes unreachable.
The system preserves the local completed effect and withholds the
remote successor where current remote authority is mandatory.
On reconnection, the remote Candidate Act is revalidated.
Expected demonstrable result: Partition recovery does not falsely
transform a completed local effect into atomic remote completion.
36.73 — WORKED EXAMPLE X: COORDINATOR SNAPSHOT ROLLBACK
The transaction coordinator crashes after two resource effects
commit.
Its older snapshot reports both operations pending.
The protected resource journals and consumption state establish their
actual completed status.
Recovery does not repeat them.
Expected demonstrable result: Restoring coordinator state cannot
resurrect already completed or consumed resource authority.
36.74 — WORKED EXAMPLE Y: COMPENSATION RESOURCE OWNERSHIP CHANGE
A resource is modified under valid authority.
Before compensation, its owner changes.
The agent attempts the originally planned inverse operation.
5.5.3.62. Original Source — Global Page 3163
The actual receiving sink checks current ownership and competent
compensation authority.
An unauthorized inverse is refused.
Das Expires 29 April 2027 [Page 350]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Expected demonstrable result: Compensation rights do not
automatically survive material changes in resource authority.
36.75 — WORKED EXAMPLE Z: MULTI-RESOURCE WORKFLOW COMPLETION RECEIPT
Three resource effects are required.
The protected registry receives qualified completion receipts from
all three actual Finality Sinks.
The receipt semantics and resource identities match the authorized
dependency graph.
The transaction completion predicate is satisfied.
A later operation may rely upon the qualified aggregate completion
evidence, while still requiring its own source and resource
authority.
Expected demonstrable result: Transaction completion may be
established from independent actual effects without treating a
general coordinator success claim as sufficient proof.
36.76 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
1. Transaction-level approval laundering. 2. Unauthorized
constituent operation. 3. Unauthorized extra resource. 4. Incorrect
resource owner. 5. Cross-tenant effect substitution. 6. Forged
predecessor receipt. 7. Replayed predecessor receipt. 8. Prepared
receipt presented as committed. 9. Dispatch receipt presented as
completed. 10. Queue receipt presented as actual effect. 11.
Unqualified coordinator success claim. 12. Incorrect dependency
graph. 13. Missing mandatory edge. 14. Added unauthorized node. 15.
Changed transaction revision. 16. Tool-contract side-effect
expansion. 17. Wrong resource version. 18. Stale policy generation.
5.5.3.63. Original Source — Global Page 3164
19. Source revocation between steps. 20. Current credential
revocation. 21. Cross-resource budget overrun. 22. Parallel budget
duplication. 23. Concurrent agent duplicate effect. 24. Replayed
finality enablement. 25. Wrong sink acceptance. 26. Wrong actual
operation. 27. Early irreversible effect. 28. Unsupported atomicity
assumption. 29. Partial commit. 30. Prepared participant left
unresolved. 31. Transaction coordinator crash. 32. Resource manager
crash. 33. Coordinator journal rollback. 34. Remote resource
rollback. 35. Partition during commit. 36. Lost acknowledgement.
37. Indeterminate resource outcome. 38. Retry before outcome
Das Expires 29 April 2027 [Page 351]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
reconciliation. 39. Duplicate payment. 40. Duplicate publication.
41. Duplicate physical command. 42. Unqualified compensation. 43.
Compensation without actual original effect. 44. Compensation amount
overshoot. 45. Compensation to wrong target. 46. Double refund. 47.
Compensation after owner change. 48. Compensation with stale
resource version. 49. Compensation under obsolete policy. 50.
Compensation without current source grant. 51. Compensation falsely
treated as complete restoration. 52. Failed compensation. 53.
Indeterminate compensation. 54. Compensation receipt forgery. 55.
Uncontrolled automatic recovery. 56. Unbounded transaction
expansion. 57. Dynamic dependency removal. 58. Irreversible pivot
bypass. 59. Resource reservation expiry. 60. Unqualified
reservation release. 61. Budget reallocation before closure. 62.
Wrong logical operation identity. 63. Multi-agent race. 64. Partial
branch completion. 65. Concurrent workflow isolation anomaly. 66.
Mixed-atomicity confusion. 67. Outbox publication duplication. 68.
Message consumer denial.
5.5.3.64. Original Source — Global Page 3165
69. Delayed successor after revocation. 70. Incomplete actual-
effect evidence. 71. Receipt issuer identity confusion. 72. Wrong
receipt semantic class. 73. Dependency evidence from another
transaction. 74. Cross-committed evidence mismatch. 75. Resource
alias rebinding. 76. Tool implementation substitution. 77. Unsafe
physical rollback. 78. Unauthorized credential destruction. 79.
Recovery by privileged bypass path. 80. Compromised coordinator. 81.
Compromised evidence registry. 82. Compromised resource gateway. 83.
Compromised compensation controller. 84. Invalid transaction
closure. 85. Historical completed effect erased from journal. 86.
Incorrect treatment of a timeout as failure. 87. Incorrect treatment
of queue acceptance as finality. 88. False assumption of exactly-
once delivery. 89. Improper source-authority inheritance by a
successor. 90. Unauthorized actual consequence despite apparently
successful distributed
coordination.
36.77 — PROPOSED FEASIBILITY AND ADVERSARIAL EXPERIMENTS
The following are proposed non-limiting technical tests and are not
representations of experiments already executed.
Test 1 — Source Transaction Grant: Establish a bounded three-resource
workflow.
Test 2 — Protected Intent Envelope: Record intended targets and
effects.
Das Expires 29 April 2027 [Page 352]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Test 3 — Decomposition: Construct three constituent Candidate Acts.
Test 4 — Non-Effective Hold: Verify no actual effect before
authorization.
Test 5 — Resource Scope: Verify each source-authorized target.
Test 6 — Transaction Budget: Allocate a bounded aggregate allowance.
Test 7 — Dependency Graph: Establish required predecessor edges.
Test 8 — Dependency Integrity: Attempt unauthorized graph mutation.
Test 9 — Predecessor Receipt Qualification: Authenticate effect
evidence.
Test 10 — Forged Receipt: Submit a self-generated completion record.
5.5.3.65. Original Source — Global Page 3166
Test 11 — Receipt Replay: Use a receipt from another transaction.
Test 12 — Prepared Versus Committed: Test semantic receipt
classification.
Test 13 — Queue Acceptance Versus Resource Effect: Check downstream
completion.
Test 14 — Transaction Preparation: Prepare supported database
participants.
Test 15 — Partial Preparation Failure: Withhold actual commit under
selected conditions.
Test 16 — Atomic Participant Commit: Verify actual resource outcomes.
Test 17 — Unsupported External Participant: Attempt adding a
nontransactional external service to a claimed atomic participant
set.
Test 18 — Mixed Atomicity: Combine a transactional database with an
external notification.
Test 19 — Outbox Event: Commit a resource mutation and durable event
record.
Test 20 — Duplicate Publication: Retry the event relay.
Das Expires 29 April 2027 [Page 353]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Test 21 — Actual Consumer Sink: Independently authorize downstream
resource effects.
Test 22 — Parallel Branches: Run two constituents concurrently.
Test 23 — Shared Budget Overrun: Attempt aggregate overspending.
Test 24 — Budget Reservation: Reserve disjoint effect allowances.
Test 25 — Resource Version Change: Mutate a target between validation
and commit.
Test 26 — Source Revocation: Revoke one constituent after a
predecessor completes.
Test 27 — Current Policy: Update a receiving resource policy.
Test 28 — Credential Rotation: Change a credential used by one
branch.
Test 29 — Actual Resource Reconstruction: Verify true target
identity.
Test 30 — Material Operation Correspondence: Substitute a different
method or amount.
Test 31 — Non-Bearer Enablement: Bind finality to a constituent.
Test 32 — Wrong Sink: Present it at another resource.
Test 33 — Sink-Local Consumption: Commit effectuation use.
Test 34 — Replay: Reuse the same finality authority.
Test 35 — Successor Release: Use qualified predecessor completion.
5.5.3.66. Original Source — Global Page 3167
Test 36 — Missing Predecessor: Withhold successor.
Test 37 — Indeterminate Predecessor: Withhold where completion is
mandatory.
Test 38 — Partial Commit: Commit A but fail B.
Test 39 — Containment: Fence dependent C.
Das Expires 29 April 2027 [Page 354]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Test 40 — Independent Branch: Check whether an unaffected branch may
continue under its source grant.
Test 41 — Irreversible Pivot: Verify mandatory prerequisites before
release.
Test 42 — Physical Command: Execute a specifically authorized
actuation.
Test 43 — Unsafe Inverse: Attempt unqualified rollback by opposite
physical command.
Test 44 — Compensation Plan: Construct a new Candidate Act.
Test 45 — Compensation Source Grant: Verify competent permission.
Test 46 — Refund Scope: Bind amount to the prior actual payment.
Test 47 — Wrong Refund Recipient: Change the compensation target.
Test 48 — Duplicate Compensation: Retry a completed refund.
Test 49 — Partial Compensation: Record an incomplete offset.
Test 50 — Compensation Failure: Preserve the original effect.
Test 51 — Compensation Indeterminate: Reconcile uncertain correction.
Test 52 — Resource Owner Change: Revalidate current compensation
authority.
Test 53 — Coordinator Crash Before Dispatch: Verify no false
completion.
Test 54 — Crash After First Commit: Preserve the first actual effect.
Test 55 — Crash After Multiple Commits: Restore transaction state
from qualified receipts.
Test 56 — Snapshot Rollback: Prevent spent authority resurrection.
Test 57 — Lost Payment Acknowledgement: Preserve indeterminate state.
Test 58 — Resource Outcome Query: Resolve supported actual
completion.
Test 59 — Retry Eligibility: Revalidate after confirmed non-effect.
Das Expires 29 April 2027 [Page 355]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.5.3.67. Original Source — Global Page 3168
Test 60 — Duplicate Retry: Prevent extra consequential effect.
Test 61 — Transaction Revision: Add a new constituent.
Test 62 — Revised Source Scope: Refuse unauthorized expansion.
Test 63 — Revision After Partial Commit: Preserve prior actual
outcomes.
Test 64 — Cross-Tenant Mutation: Test source and resource identity
checks.
Test 65 — Tool Semantic Change: Introduce a hidden additional side
effect.
Test 66 — Credential Release Dependency: Require qualified service
activation before credential use.
Test 67 — Memory-Write Dependency: Require actual memory commit
before a specified successor.
Test 68 — Offline Local Branch: Allow only expressly preauthorized
bounded offline effects.
Test 69 — Deferred Remote Branch: Require current remote authority
after reconnection.
Test 70 — Remove Original Source Check: Attempt resource effects
based solely on predecessor receipts.
Test 71 — Remove Actual Sink Check: Attempt a changed actual target.
Test 72 — Remove Dependency Fence: Attempt an unauthorized early
successor.
Test 73 — Remove Budget Conservation: Attempt parallel overspending.
Test 74 — Remove Indeterminate-State Handling: Attempt duplicate
effect after timeout.
Test 75 — Remove Compensation Authority: Attempt an arbitrary
corrective resource effect.
Test 76 — Remove Protected Consumption: Attempt operation replay.
Das Expires 29 April 2027 [Page 356]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Test 77 — Remove Transaction-Revision Binding: Attempt to reuse old
approvals for new effects.
Test 78 — Large Dependency Graph: Measure protected validation
overhead.
Test 79 — Multiple Independent Sinks: Measure commit and recovery
behavior under concurrent failures.
Test 80 — Full Integrated Workflow: Combine source authority,
protected transaction decomposition, non-effective constituent acts,
dependency-qualified receipts, resource-
5.5.3.68. Original Source — Global Page 3169
specific sink finality, partial commit, indeterminate reconciliation,
independently authorized compensation, protected consumption, and
final closure.
36.77.1 — Proposed Measurements
The tests may measure:
Unauthorized completed resource effects;
Wrong-target finality acceptance;
Missing dependency detection;
Prepared/committed receipt confusion;
Cross-resource aggregate budget overrun;
Partial-commit containment correctness;
Duplicate effectuation;
Compensation without authority;
Compensation overshoot;
False transaction completion;
Recovery after coordinator failure;
Indeterminate operation reconciliation;
And actual Finality-Sink verification latency.
Das Expires 29 April 2027 [Page 357]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
36.77.2 — Comparative Ablation
A proposed comparison comprises:
Configuration A — Ordinary Autonomous Tool Orchestration: An agent
calls multiple tools according to its plan and observes their
responses.
Configuration B — Conventional Distributed Transaction or Saga
Coordination: The system uses established transactional or
compensating patterns.
Configuration C — Source-Bound Constituent Finality: Each resource
effect is a separately authorized Candidate Act enforced at its
actual sink.
Configuration D — Complete Cross-Sink Finality: The system
additionally binds protected predecessor receipt semantics,
transaction revision, aggregate authority, partial-commit
containment, outcome reconciliation, and independently authorized
compensation.
5.5.3.69. Original Source — Global Page 3170
36.77.3 — Decisive Proposed Hindsight Experiment
An autonomous agent is authorized to perform a three-resource
operation.
The first effect completes.
The second fails.
The agent attempts to:
Skip the failed prerequisite;
Perform the third effect anyway;
Reuse the first resource's authorization at a different sink;
Exceed the transaction-wide budget;
Or perform a broad compensation that the original principal never
approved.
Das Expires 29 April 2027 [Page 358]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The experiment compares the actual receiving-resource state under a
conventional orchestrator, a conventional Saga, and the proposed
protected cross-sink finality controls.
The relevant result is whether an unauthorized real effect occurs—not
whether the coordinating agent generates a refusal message.
A second experiment causes an actual payment to complete while its
acknowledgement is lost.
The test determines whether the system preserves the indeterminate
outcome and prevents an unauthorized duplicate retry.
36.78 — NON-LIMITING PHOSITA REFERENCE PROTOTYPE
36.78.1 — Minimum Components
A PHOSITA may construct:
One autonomous transaction-planning agent;
One protected originating source-authority service;
Three simulated independent resource services;
One protected transaction envelope registry;
One dependency graph;
5.5.3.70. Original Source — Global Page 3171
One source-scope and aggregate-budget controller;
One independent Finality Sink per resource;
One protected actual-effect receipt registry;
One partial-commit controller;
And one compensation authority service.
36.78.2 — Original Transaction
A principal authorizes:
Creation of one order;
Reservation of one inventory item;
Das Expires 29 April 2027 [Page 359]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
And one payment of a specified amount to a specified recipient.
36.78.3 — Transaction Decomposition
Construct three constituent Candidate Acts.
36.78.4 — Resource Authorization
Bind each act to its exact target and operation.
36.78.5 — Dependency Graph
Require inventory reservation before final payment effectuation.
Require actual payment completion before selected order-finalization
operations.
36.78.6 — Non-Effective Hold
Prevent all effects until their mandatory conditions pass.
36.78.7 — Protected Resource Commit
Execute the inventory reservation through its own resource Finality
Sink.
36.78.8 — Qualified Receipt
Record actual reservation success.
36.78.9 — Payment Candidate
Validate the source-authorized amount, recipient, resource, and
current dependency.
5.5.3.71. Original Source — Global Page 3172
36.78.10 — Actual Payment Sink
Independently reconstruct and verify the real transfer.
36.78.11 — Partial Failure Variant
Cause order finalization to fail after payment completion.
36.78.12 — Expected Result
The payment remains recorded as a completed actual effect.
Das Expires 29 April 2027 [Page 360]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
36.78.13 — Compensation Proposal
Generate a bounded refund Candidate Act.
36.78.14 — Independent Compensation Authority
Require a valid source grant covering the refund.
36.78.15 — Compensation Sink
Verify actual refund recipient, amount, prior payment, current
resource state, and non-bearer finality.
36.78.16 — Duplicate Compensation Test
Retry the completed refund.
36.78.17 — Expected Result
A second unauthorized refund is refused.
36.78.18 — Lost Response Variant
Cause the payment acknowledgement to disappear after actual
completion.
36.78.19 — Expected Result
The controller treats payment outcome as indeterminate until
qualified reconciliation.
36.78.20 — Recovery
Query actual resource outcomes and preserve protected consumption.
36.78.21 — Expected Result
The agent does not automatically replay a completed payment or
perform a compensating financial effect without authority.
5.5.3.72. Original Source — Global Page 3173
36.79 — OPTIONAL ADVANCED VARIATIONS
36.79.1 — Fully Transactional Database Participants
The system uses genuine coordinated prepare and commit where
supported.
Das Expires 29 April 2027 [Page 361]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
36.79.2 — Mixed Transactional and Nontransactional Effects
The system separates supported atomic participants from independently
committed external effects.
36.79.3 — Transactional Outbox
Message publication may follow a local durable database commit.
36.79.4 — Saga Coordination
Constituent operations may be orchestrated or choreographed using
separately enforced source and sink finality.
36.79.5 — Reservation-Based Transactions
Inventory, resource slots, or selected financial holds may be
prepared before final effectuation.
36.79.6 — Multi-Agent Transaction Planning
Several agents may compute or propose portions of a protected
transaction.
36.79.7 — Parallel Branch Execution
Independent branches may proceed under aggregate authority and
dependency conditions.
36.79.8 — Payment and Refund
Forward financial effects and compensations receive separate
finality.
36.79.9 — Cloud Deployment
Deployment, credential, and traffic-routing effects may be governed
by dependency-qualified receipts.
36.79.10 — Data Transfer and Deletion
Data-export evidence and source deletion may be independently
authorized.
36.79.11 — Memory and Knowledge Commit
Das Expires 29 April 2027 [Page 362]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.5.3.73. Original Source — Global Page 3174
Persistent knowledge mutation may be a constituent effect.
36.79.12 — Credential and Secret Management
Credential activation may depend upon resource and policy readiness.
36.79.13 — Physical Actuation
Irreversible device commands may be governed by protected pivot
requirements.
36.79.14 — Dynamic Source Authority
Current grants and revocations may be rechecked before each relevant
effect.
36.79.15 — Dynamic Resource Identity
Each actual sink may independently qualify changed target mappings.
36.79.16 — Offline Workflow Recovery
Preauthorized local effects may be reconciled with deferred remote
constituents.
36.79.17 — Cross-Tenant Transaction
Separate tenant permissions may be enforced at their respective
sinks.
36.79.18 — Transaction-Wide Quota
Shared budgets may be reserved and consumed across parallel branches.
36.79.19 — Manual Compensation Authority
A competent principal may approve otherwise unavailable recovery
effects.
36.79.20 — Qualified Global Completion Receipt
The workflow may generate authenticated aggregate completion evidence
based on verified actual constituent results.
36.80 — PROPOSED INVENTIVE-STEP CHARACTERIZATION
Das Expires 29 April 2027 [Page 363]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
36.80.1 — Established Foundations
Existing systems provide:
Two-phase commit;
Distributed transaction coordination;
5.5.3.74. Original Source — Global Page 3175
Saga patterns;
Compensating operations;
Durable workflows;
Transactional outbox;
Conditional resource updates;
Resource reservations;
Idempotent request handling;
And operation journals.
These features are established techniques and should not be
characterized as individually invented merely through their
inclusion.
36.80.2 — Candidate Objective Technical Problem
How to enforce originating source-authorized consequential authority
across an autonomous workflow spanning independently controlled
resource effects, while preserving mandatory effect dependencies,
preventing partial completion from enabling unauthorized
continuation, distinguishing actual effects from intermediate
acknowledgements, and requiring separate competent authority for
compensating consequences.
36.80.3 — Proposed Technical Solution
A protected controller decomposes a source-authorized transaction
into constituent non-effective Candidate Acts.
Each constituent is associated with an actual target, source grant,
protected dependency conditions, and scoped finality.
Das Expires 29 April 2027 [Page 364]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Qualified predecessor receipts establish specified actual-effect
conditions.
Independent resource-specific Finality Sinks reconstruct and
conditionally effectuate the real operations.
Protected transaction-wide budgets prevent authority duplication.
A partial-commit controller fences unsafe downstream continuation and
preserves actual completed effects.
Indeterminate outcomes are reconciled through actual resource
evidence.
Compensation is represented as a new Candidate Act and requires
independent competent permission and receiving-resource finality.
5.5.3.75. Original Source — Global Page 3176
36.80.4 — Not Merely Two-Phase Commit
Two-phase commit coordinates compatible transactional participants.
The proposed system additionally distinguishes source authorization
for individual consequential effects and independently governs
external operations that may not support common atomic preparation.
36.80.5 — Not Merely a Saga
A Saga coordinates local transactions and compensations.
The proposed arrangement separately verifies whether a particular
compensation has competent source authority and passes actual
resource-sink finality.
36.80.6 — Not Merely an Orchestration Graph
A workflow graph identifies scheduling dependencies.
The proposed implementation makes qualified actual-effect receipt
predicates control protected non-effective successor release.
36.80.7 — Not Merely an Idempotency Key
An idempotency key may reduce duplicate operations.
Das Expires 29 April 2027 [Page 365]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The proposed system also binds each effect to current original source
scope, protected dependency state, actual resource identity, and
sink-local consumption.
36.80.8 — Not Merely a Transactional Outbox
An outbox provides a durable relationship between a local database
commit and an event record.
The proposed combination independently verifies the actual downstream
resource effect rather than treating event publication as finality.
36.80.9 — Not Merely Audit Logging
An audit trail records attempts and outcomes.
The proposed architecture makes selected protected evidence necessary
for authorizing later actual resource consequences.
36.80.10 — Candidate Narrow Inventive Kernel
A protected autonomous multi-resource execution-finality system in
which a source-authorized transaction is decomposed into constituent
Candidate Acts held non-effective, each constituent is associated
with an actual receiving resource and protected predecessor-effect
predicates, qualified actual-effect receipts from independent
resource
5.5.3.76. Original Source — Global Page 3177
Finality Sinks determine eligibility of successor acts without
creating additional source authority, a protected partial-commit
controller prevents unauthorized continuation following failed or
indeterminate constituents, and a compensating resource effect is
independently represented as a new source-authorized Candidate Act
subject to scoped non-bearer finality and actual sink-local
verification and consumption.
36.80.11 — Cross-Sink Dependency Kernel
A narrower candidate may require authenticated resource-issued
completion evidence bound to a particular transaction revision,
actual resource identity, and permitted successor operation.
36.80.12 — Partial-Commit Containment Kernel
Das Expires 29 April 2027 [Page 366]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Another candidate may require a protected actual-outcome vector to
fence dependent successors while preserving already completed effects
after a material failure.
36.80.13 — Compensation-Authority Kernel
Another candidate may require independently qualified competent
source authorization for the actual compensating operation, distinct
from the original forward approval.
36.80.14 — Mixed-Atomicity Kernel
Another candidate may distinguish qualified atomic participants from
independently committed external effects and prevent unsupported
transaction-wide atomicity assumptions from authorizing further
operations.
36.80.15 — Transaction-Wide Authority Conservation Kernel
Another candidate may reserve aggregate source-authorized effect
allowances across parallel constituent acts and protect consumption
across resource sinks.
36.80.16 — Indeterminate-Outcome Kernel
Another candidate may prevent automatic repeat effectuation following
lost acknowledgement until actual resource outcome and current
authority are qualified.
36.80.17 — Anti-Hindsight Technical Analysis
An examiner may identify conventional distributed transaction
coordinators, Saga workflows, compensating transactions, idempotency
keys, and receipt-based orchestration.
These technologies should be explicitly acknowledged.
The inventive-step analysis should determine whether the closest
earlier systems already teach the complete claimed relationship
among:
1. Original source-authorized transaction scope; 2. Constituent
consequential Candidate Acts maintained non-effective;
Das Expires 29 April 2027 [Page 367]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.5.3.77. Original Source — Global Page 3178
3. Independent resource-specific source-authority validation; 4.
Protected predecessor receipts identifying actual completed effects;
5. Mandatory receipt semantics governing successor release; 6.
Source-authority noninheritance across predecessor and successor
operations; 7. Scoped non-bearer finality enforced at each actual
receiving resource; 8. Protected sink-local consumption; 9.
Transaction-wide authority budget conservation; 10. Accurate
partial-commit containment; 11. Indeterminate-outcome
reconciliation; 12. Separate source-authorized compensation
Candidate Acts; 13. Independent receiving-resource finality for
compensation; 14. Recovery without historical effect erasure or
authority resurrection.
36.80.18 — Functional Interaction
The candidate technical interaction is not merely that several
conventional components are available.
The protected source grant defines the permitted total consequential
scope.
The transaction decomposer constructs independent held Candidate Acts
rather than a reusable unrestricted transaction capability.
The dependency validator makes actual predecessor completion evidence
a required successor predicate.
The independent Finality Sink ensures the actual receiving resource
and operation match the constituent authorization.
The partial-commit controller prevents a failed or uncertain branch
from unlocking unauthorized successor effects.
The compensation authority controller prevents recovery logic from
creating new ungranted consequential permissions.
The consumption and reconciliation controllers preserve actual
resource effects and bounded authority across crashes, retries, and
partial failures.
36.80.19 — Strong Comparative Evidence
A useful comparative demonstration should establish:
Whether a conventional workflow can execute a successor after a
forged or semantically insufficient predecessor receipt;
Das Expires 29 April 2027 [Page 368]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Whether a broad coordinator credential can cause effects outside the
originating principal's scope;
Whether a failed distributed operation can trigger unauthorized
compensation;
5.5.3.78. Original Source — Global Page 3179
Whether a lost response causes duplicate external effects;
And whether the proposed protected actual Finality Sinks prevent
those effects under the same attack conditions.
Any claimed improvement should be demonstrated against a fair
configuration of the closest relevant prior art, including its
existing authorization and idempotency controls.
36.80.20 — Necessary Patentability Qualification
The proposed combinations may provide technical support for future
claims.
They do not independently establish novelty, inventive step,
enablement under every jurisdiction, earlier priority, or
infringement by existing systems.
A claim's strength depends upon its precise limitations and the
actual prior-art disclosures.
36.81 — INDUSTRIAL APPLICABILITY
36.81.1 — Financial Transactions
Multi-step payment, settlement, accounting, and refund operations.
36.81.2 — Electronic Commerce
Orders involving inventory, payment, fulfillment, and notifications.
36.81.3 — Enterprise AI Agents
Autonomous workflows affecting several business systems.
36.81.4 — Cloud Infrastructure
Coordinated resource deployment, networking, identity, and credential
operations.
Das Expires 29 April 2027 [Page 369]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
36.81.5 — Software Delivery
Deployment, validation, traffic switching, and rollback under current
authority.
36.81.6 — Distributed Databases
Multi-resource commits and resource-specific authorization.
36.81.7 — Message-Driven Systems
Durable event publication and qualified downstream effectuation.
36.81.8 — Data Governance
5.5.3.79. Original Source — Global Page 3180
Controlled movement, disclosure, modification, and deletion of
protected information.
36.81.9 — Multi-Agent Orchestration
Separate source authority and finality across agents and tools.
36.81.10 — Identity Management
Credential issuance, activation, revocation, and dependent resource
access.
36.81.11 — Telecommunications
Coordinated network configuration and service activation.
36.81.12 — Industrial Automation
Multiple physical and digital effects subject to independent device
finality.
36.81.13 — Robotics
Protected sequences of resource reservations, device commands, and
outcome checks.
36.81.14 — Autonomous Transportation
Multi-controller workflows with separate actuation boundaries.
36.81.15 — Satellite and Edge Systems
Das Expires 29 April 2027 [Page 370]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Partial cross-domain completion and delayed reconciliation.
36.81.16 — Healthcare Infrastructure
Technical record and operational workflow controls, subject to the
relevant source, privacy, and safety authority requirements.
36.81.17 — Supply Chain Systems
Multi-party procurement, inventory, and delivery coordination.
36.81.18 — Persistent AI Memory
Knowledge-store commits with dependent disclosures or external
actions.
36.81.19 — Confidential Computing
Protected coordination across resource-specific trusted execution
boundaries.
36.81.20 — Future Autonomous Critical Systems
5.5.3.80. Original Source — Global Page 3181
Actual consequential authority maintained across independently
controlled and partially failing systems.
36.82 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
36.82.1 — Candidate Independent System Claim
A system comprising:
A protected source-authority controller configured to establish a
bounded multi-resource consequential transaction;
A transaction decomposition controller configured to construct plural
constituent Candidate Acts and maintain each in a Non-Effective
State;
A protected dependency controller configured to associate each
constituent with mandatory predecessor actual-effect conditions;
An independent validation controller configured to verify current
original source authority and actual resource-specific permission for
each constituent;
Das Expires 29 April 2027 [Page 371]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A plurality of actual resource Finality Sinks configured to
reconstruct and conditionally commit their respective pending effects
following scoped non-bearer finality verification;
A protected cross-sink receipt controller configured to establish
qualified actual-effect evidence for dependency release;
A partial-commit containment controller configured to fence
unauthorized successors and preserve completed or indeterminate
resource effects;
And a compensation controller configured to require a separately
authorized Compensation Candidate Act and independent actual
receiving-resource finality for any corrective consequential effect.
36.82.2 — Candidate Independent Method Claim
A method comprising:
Receiving an originating transaction grant;
Constructing a protected transaction intent envelope;
Decomposing the transaction into plural consequential Candidate Acts;
Maintaining the constituent acts non-effective;
Establishing protected operation-specific dependencies;
5.5.3.81. Original Source — Global Page 3182
Independently validating current source and actual resource authority
for each constituent;
Permitting actual resource effects only through receiving Finality
Sinks that verify scoped non-bearer finality and protected
consumption;
Using qualified actual-effect receipts to determine eligibility of
dependent constituents;
Fencing unauthorized continuation after partial or indeterminate
completion;
And independently authorizing and effecting a compensating Candidate
Act where an appropriate current recovery grant exists.
36.82.3 — Candidate Independent Cross-Sink Dependency Claim
Das Expires 29 April 2027 [Page 372]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A protected distributed execution system configured to condition
release of a successor consequential Candidate Act upon verification
of authenticated actual-effect evidence from one or more predecessor
Finality Sinks, while separately requiring current original source
permission and receiving-resource finality for the successor.
36.82.4 — Candidate Independent Compensation Claim
A protected autonomous recovery system configured to identify an
actual previously completed resource effect, construct a separately
held compensating Candidate Act, verify competent compensation-
specific source authority and current target constraints, and permit
the corrective effect only through independently verified non-bearer
finality at the actual compensating resource sink.
36.82.5 — Candidate Independent Partial-Commit Claim
A system configured to maintain a qualified vector of actual
resource-effect outcomes across a multi-resource autonomous
transaction, preserve completed and indeterminate effects after a
material constituent failure, fence unauthorized dependent
continuation, and prevent duplicate or ungranted recovery effects
through protected consumption and current resource-specific
validation.
36.83 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
1. The workload comprises an autonomous AI agent. 2. The workflow
involves two or more independently controlled resources. 3. The
workflow involves several autonomous agents. 4. A protected
transaction envelope identifies the originating principal. 5. The
envelope identifies permitted resource targets. 6. The envelope
identifies permitted actual effect classes. 7. The envelope
identifies an aggregate transaction budget. 8. The envelope
identifies a protected transaction revision. 9. The transaction is
decomposed into constituent Candidate Acts. 10. Each constituent
identifies a particular actual resource. 11. Each constituent
identifies a specific consequential operation.
5.5.3.82. Original Source — Global Page 3183
12. Each constituent identifies its applicable source grant. 13.
Each constituent is maintained non-effective before required
validation. 14. Each constituent identifies a designated actual
Finality Sink. 15. A protected graph represents mandatory
predecessor operations. 16. A graph edge may require a qualified
prepared state. 17. A graph edge may require an actual committed
state. 18. A graph edge may require qualified resource completion.
Das Expires 29 April 2027 [Page 373]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
19. A graph edge may require a current resource version. 20. A
protected validator distinguishes prepared from committed receipt
semantics. 21. A queue receipt is not automatically treated as final
resource completion. 22. An outbox record is not automatically
treated as completed downstream effectuation. 23. A predecessor
receipt identifies the actual receiving resource. 24. A predecessor
receipt identifies the actual operation. 25. A predecessor receipt
identifies transaction and constituent references. 26. A receipt may
be cryptographically authenticated. 27. A receipt is verified under
its specific semantic class. 28. A receipt from another transaction
does not automatically satisfy a dependency. 29. A predecessor
completion does not independently establish successor source
authority. 30. A successor requires current source-scope
verification. 31. A successor requires current actual resource
validation. 32. A successor requires its own scoped non-bearer
finality. 33. A successor requires actual receiving-sink
verification. 34. A resource sink independently reconstructs the
pending operation. 35. A sink checks current resource identity. 36.
A sink checks material operation parameters. 37. A sink checks
current policy or revocation state. 38. A sink checks required
predecessor evidence. 39. A sink checks protected transaction
revision. 40. A sink checks transaction budget allocation. 41. A
sink checks protected non-bearer enablement. 42. A sink checks sink-
local consumption. 43. The transaction may use qualified two-phase
preparation. 44. Prepared transaction receipts are distinguished
from final commit receipts. 45. The system may use a transactional
outbox. 46. A durable outbox event may be published asynchronously.
47. The ultimate receiving resource independently checks
authorization. 48. The transaction may use a Saga-like sequence of
local effects. 49. Compensating operations remain independently
authorized. 50. The transaction may include atomic and non-atomic
participants. 51. An unsupported external resource is not falsely
classified as a coordinated atomic
participant. 52. A protected planner identifies potentially
irreversible effects. 53. An irreversible pivot may require selected
prior effects. 54. A failure before the pivot may fence the pivot.
55. A completed pivot remains part of the historical outcome record.
56. The controller identifies partial committed states. 57. A
partial-commit barrier fences dependent successors. 58. An
unaffected branch may continue only if current transaction authority
permits. 59. Completed effects remain recorded after coordinator
failure.
Das Expires 29 April 2027 [Page 374]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.5.3.83. Original Source — Global Page 3184
60. An indeterminate effect is distinguished from an actual failure.
61. An indeterminate effect may trigger qualified outcome
reconciliation. 62. Loss of acknowledgement does not automatically
authorize retry. 63. An operation identifier may support resource-
side idempotency where implemented. 64. A repeated operation is
checked against previous actual completion. 65. Protected
consumption state prevents unauthorized repeated effectuation. 66. A
transaction-wide budget may be divided among constituent acts. 67.
Parallel branches cannot consume more than the aggregate permitted
allowance. 68. Budget units may be reserved before constituent
release. 69. Returned or unused budgets require qualified protected
accounting. 70. A transaction plan change advances a protected
revision generation. 71. A material added effect requires
corresponding source authority. 72. A material removed dependency
may trigger finality fencing. 73. Completed prior effects remain
associated with the revision under which they
occurred. 74. A compensation Candidate Act identifies a prior actual
effect. 75. The compensation identifies the actual proposed resource
and operation. 76. The compensation requires a competent source
grant. 77. A bounded original grant may expressly authorize selected
compensation classes. 78. An unrelated compensation cannot inherit
that limited authorization. 79. A compensation may be held non-
effective. 80. A compensation requires current resource identity.
81. A compensation requires current resource policy. 82. A
compensation may be limited by amount or effect magnitude. 83. A
refund may be limited to a qualified prior payment. 84. A
compensation requires independent actual-sink reconstruction. 85. A
compensation requires scoped non-bearer finality. 86. A compensation
requires protected sink-local consumption. 87. A duplicate
compensation may be refused. 88. A failed compensation remains
separately recorded. 89. A partial correction is not automatically
treated as complete reversal. 90. A physical compensating command
requires current device and safety validation. 91. A protected
transaction journal records forward and corrective effects
separately. 92. An aggregate completion receipt may depend upon
qualified actual sink receipts. 93. A later successor may use
aggregate completion evidence without acquiring new
original source permission. 94. Snapshot restoration does not revive
previously consumed constituent authority. 95. Existing distributed
transactions, Saga coordination, conditional resource updates,
message queues, idempotency mechanisms, and durable resource journals
may be used as optional non-limiting implementation substrates.
Das Expires 29 April 2027 [Page 375]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
36.84 — UNIVERSAL COMBINATION, SUBCOMBINATION, AND NON-LIMITING
PHOSITA CLAUSE
The disclosed mechanisms may be implemented individually where
technically sufficient or in any technically compatible combination.
An implementation may use two-phase commit.
5.5.3.84. Original Source — Global Page 3185
Another may use a sequence of local transactional effects.
Another may use transaction reservations.
Another may use a Saga orchestration pattern.
Another may use a Saga choreography pattern.
Another may use a transactional outbox.
Another may use durable message transport.
Another may use resource-specific idempotency.
Another may use version-conditional writes.
Another may use cross-sink authenticated effect receipts.
Another may use transaction-wide quota reservations.
Another may use protected dependency graphs.
Another may use irreversible pivot recognition.
Another may use separately authorized compensating Candidate Acts.
Another may use independent physical-device sinks.
Another may use database mutation sinks.
Another may use payment gateways.
Another may use cloud-resource gateways.
Another may use protected credential brokers.
Another may use protected memory-commit sinks.
Das Expires 29 April 2027 [Page 376]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Another may use offline effect reconciliation.
Another may use authenticated durable journals.
The invention does not require that every resource support the same
transaction protocol.
The invention does not assert global atomicity across unrelated
resources without an actual mechanism establishing the claimed
guarantee.
The invention does not require that every failed transaction be
automatically compensated.
5.5.3.85. Original Source — Global Page 3186
The invention does not require that every compensation be capable of
fully undoing a prior effect.
The invention does not presume that a Saga automatically supplies
competent source authority for its compensation steps.
The invention does not presume that a coordinator's success flag
proves actual receiving-resource finality.
The invention does not presume that a queue acknowledgement proves
ultimate effect completion.
The invention does not presume that a database rollback can reverse
an email, physical command, or external financial effect.
The invention does not treat an indeterminate resource operation as
automatically failed.
The invention does not require sequential execution where parallel
independent branches are expressly permitted.
The invention does not permit parallel branches to multiply an
aggregate source-authorized operation budget.
The invention does not permit a completed predecessor to create
missing source authority for a successor.
The invention does not permit an agent to add materially new effects
merely by rewriting its transaction plan.
The invention does not permit restoration of old coordinator state to
revive consumed or completed effects.
Das Expires 29 April 2027 [Page 377]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The invention does not require a particular database product, cloud
provider, payment processor, workflow engine, message bus,
programming language, or distributed transaction implementation.
The algorithms, diagrams, formulas, test proposals, data structures,
and worked examples are illustrative, optional, and non-limiting
technical aids for a person having ordinary skill in the art.
Mechanisms from earlier embodiments may be combined where technically
compatible and adequately supported.
36.85 — FINAL TECHNICAL CHARACTERIZATION
The present Embodiment 36 discloses a protected autonomous multi-
resource execution-finality architecture in which a transaction-level
computational intention is decomposed into independently controlled
consequential Candidate Acts.
5.5.3.86. Original Source — Global Page 3187
An originating principal establishes the permitted transaction scope.
A protected controller constructs a transaction envelope identifying
the authorized resource effects, aggregate limits, and mandatory
dependencies.
Each constituent Candidate Act remains non-effective until its own
required source, resource, dependency, and operation-specific
conditions pass.
Where supported, resource participants may enter qualified prepared
transaction states.
Preparation is not confused with actual commitment.
Each actual Finality Sink independently reconstructs the operation
presented to its receiving resource.
The sink verifies current source authorization, actual resource
identity, material effect parameters, protected dependencies, scoped
non-bearer finality, and sink-local consumption.
Qualified actual-effect receipts identify which operations have
completed.
A protected dependency controller permits successor effects only when
required predecessor conditions are satisfied.
Das Expires 29 April 2027 [Page 378]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The successful predecessor does not create new originating authority.
A partial-commit controller preserves actual completed effects and
fences unauthorized continuation after material failure or
uncertainty.
The controller does not claim that an irreversible external effect
has been rolled back merely because the overall transaction failed.
Where compensation is appropriate, the compensating operation is
constructed as a separate Candidate Act.
That act requires competent source authorization and independent
Finality-Sink validation of the actual corrective effect.
Protected outcome reconciliation prevents lost acknowledgements,
retries, crashes, and snapshot rollback from reviving or duplicating
consumed consequential authority.
The principal candidate inventive technical concept of Embodiment 36
is a protected autonomous multi-resource transaction-finality system
in which source-authorized transactions are decomposed into
independently non-effective constituent effects, protected actual-
effect receipts control causal successor release without expanding
source authority, partial-commit containment preserves completed and
indeterminate resource states, and compensation is independently
source-authorized and enforced through operation-specific non-bearer
Finality-Sink reconstruction and protected consumption.
5.5.3.87. Original Source — Global Page 3188
36.86 — SHORT PHOSITA IMPLEMENTATION USING EXISTING TECHNOLOGIES
A PHOSITA may implement the disclosed architecture using established
systems as optional implementation substrates.
Existing technology Non-limiting role
SQL database transactions Atomic local resource mutation and
protected consumption where jointly supported PostgreSQL two-phase
commit facilities
Prepare, commit, or roll back qualified participating database
transactions X/Open XA-style transaction coordination Coordinate
supported transactional resource managers
Das Expires 29 April 2027 [Page 379]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Saga workflow engines Schedule separately committed local operations
and compensations Transactional outbox Record a durable event
alongside a local database commit
Durable message queues Transport constituent operation requests and
qualified result notifications
Resource-side idempotency keys Reduce duplicated effects under
supported receiver
semantics
HTTP If-Match and ETags Enforce version-dependent state changes at
compatible HTTP resources Protected relational transaction registry
Maintain Candidate Acts, dependencies, source scope, and aggregate
budgets Cryptographically authenticated receipts
Bind qualified actual-effect evidence to resource and operation
identity
Protected API gateways Enforce source-authorized resource operations
at actual receiving boundaries Transactional budget reservations
Prevent parallel constituents from overusing a shared allowance
Durable operation journals Preserve completed, indeterminate,
consumed, and compensating effects
Qualified recovery services Reconcile outcomes and separately
authorize corrective operations
36.86.1 — Practical Common PHOSITA Workflow
First, establish an authenticated originating transaction grant.
Second, construct a transaction envelope identifying every permitted
actual resource effect.
Third, divide the transaction into constituent Candidate Acts.
Fourth, maintain every constituent in a Non-Effective State.
Fifth, construct a protected dependency graph with explicit receipt
semantics.
Das Expires 29 April 2027 [Page 380]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.5.3.88. Original Source — Global Page 3189
Sixth, classify each resource according to its actual transaction
preparation and commit capabilities.
Seventh, select a supported coordination mode rather than assuming
every external service is an atomic participant.
Eighth, allocate aggregate source-authorized transaction budgets
among constituent effects.
Ninth, use current resource identity and version checks before
preparing or effecting each operation.
Tenth, require actual resource-specific Finality Sinks to reconstruct
and independently validate the operation presented for commitment.
Eleventh, generate qualified operation-specific non-bearer finality.
Twelfth, consume protected authority in the actual receiving
resource's supported consistency model.
Thirteenth, obtain qualified actual-effect evidence and verify its
semantic class.
Fourteenth, unlock dependent successors only upon required receipt
and current source-authority validation.
Fifteenth, when one branch fails after another commits, record the
actual partial effect and fence unsafe continuation.
Sixteenth, reconcile uncertain outcomes before additional
effectuation.
Seventeenth, construct any required compensation as a separate
Candidate Act.
Eighteenth, obtain competent current compensation authority and
enforce the actual corrective effect through its own protected
Finality Sink.
Nineteenth, close the transaction only when the qualified completion
predicate passes or preserve a truthful partial or indeterminate
state.
36.86.2 — Minimal Reference Data Structures
Das Expires 29 April 2027 [Page 381]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
TRANSACTION_INTENT ( transaction_id, source_grant_reference,
revision_generation, constituent_set_commitment, total_effect_budget,
completion_predicate, partial_effect_policy ) CONSTITUENT_ACT (
5.5.3.89. Original Source — Global Page 3190
transaction_id, constituent_id, actual_resource_id, operation_digest,
reserved_effect_budget, predecessor_set, effect_semantic_class,
finality_sink_id, current_status ) RESOURCE_EFFECT_RECEIPT (
transaction_id, constituent_id, actual_resource_id,
actual_operation_digest, semantic_receipt_class,
resource_commit_reference, completion_status,
protected_consumption_reference ) PARTIAL_COMMIT_STATE (
transaction_id, completed_constituents, failed_constituents,
indeterminate_constituents, fenced_successors, recovery_generation )
COMPENSATION_ACT ( compensation_id, transaction_id,
prior_actual_effect_reference, compensation_source_grant,
actual_resource_id, compensation_effect_digest, finality_sink_id,
consumption_state )
These structures are illustrative.
A database schema alone does not implement source authority, actual
finality, compensation safety, or cross-resource atomicity.
36.86.3 — Recommended Three-Resource Demonstration
A PHOSITA may use three independently controlled test resource
services:
5.5.3.90. Original Source — Global Page 3191
Resource A — Inventory database: Supports transactional reservations.
Resource B — Payment simulator: Supports an independently recorded
financial effect and an operation identifier.
Resource C — Order database: Supports conditional updates and a
protected state transition.
The originating source grants authority for one order, one item
reservation, and one bounded payment.
Each operation becomes its own Candidate Act.
The inventory sink first confirms the qualified reservation.
Das Expires 29 April 2027 [Page 382]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The payment sink then validates current permission and actual payment
parameters.
The order sink requires the corresponding qualified payment result
and its own authorization.
A deliberate failure is introduced after payment but before final
order completion.
The partial-commit controller preserves the actual payment and fences
further unauthorized effects.
A refund is prepared as a separate Compensation Candidate Act.
The compensation sink requires competent source authority, the
original actual payment reference, current resource conditions, and
scoped non-bearer finality.
The simulator then loses a payment acknowledgement.
The recovery mechanism must establish actual resource status rather
than assuming failure and repeating the payment.
36.86.4 — Critical PHOSITA Cautions
Two-phase commit applies only to participants that implement the
required protocol and consistency semantics.
Saga compensations are separate resource operations and may fail.
A transactional outbox helps coordinate a local database commit with
publication intent; it does not automatically prove downstream
business completion.
A message queue may deliver messages more than once under its
delivery model.
Idempotency protection requires actual receiving-resource support and
correct logical operation identity.
5.5.3.91. Original Source — Global Page 3192
Conditional updates guard selected resource-version predicates; they
do not replace original source authority.
A refund does not erase the historical occurrence of a payment.
Das Expires 29 April 2027 [Page 383]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A physical inverse command does not necessarily reverse all
consequences of an earlier actuation.
A coordinator crash cannot justify replaying an indeterminate
operation without qualified outcome reconciliation.
A source-authorized transaction budget must remain bounded across
parallel branches, retries, and recovery operations.
36.86.5 — Non-Limiting Common Reference Combination
Originating source authority → protected transaction intent →
constituent Candidate Act decomposition → Non-Effective States →
actual resource identity and dependency graph → transaction-wide
budget reservation → qualified resource preparation where supported →
predecessor actual-effect receipt verification → independent current
source and resource validation → scoped non-bearer finality → actual
constituent Finality Sink reconstruction → protected consumption and
effectuation → cross-sink receipt commitment → qualified transaction
outcome vector → partial-commit containment → independent outcome
reconciliation → separately authorized compensation Candidate Act →
compensation Finality Sink → protected transaction closure.
The proposed distinguishing technical relationship is the
preservation of source-authorized consequential authority across
independently completing resource effects, with operation-specific
actual-sink finality, receipt-conditioned causal continuation,
truthful partial-commit accounting, and compensation governed as a
separately authorized real consequence rather than an automatic
privilege of the transaction coordinator.
END OF EMBODIMENT 36 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 37
PROTECTED AUTONOMOUS IRREVERSIBLE-EFFECT FINALITY WITH CONSEQUENCE-
BOUND AUTHORITY, PRE-EFFECTUATION HAZARD VERIFICATION, AND NON-
COMPENSABLE OPERATION CONTAINMENT
37.0 — COMPLETE TECHNICAL TITLE
Das Expires 29 April 2027 [Page 384]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Systems, Methods, and Apparatus for Governing Autonomous
Irreversible, Practically Irreversible, Non-Compensable, or High-
Consequence Operations Using Protected Consequence Classification,
Source-Authorized Effect Envelopes, Non-Effective Candidate Acts,
Qualified Pre-Effectuation Hazard-State Evidence, Protected
Irreversibility-Frontier Identification, Material Consequence
Correspondence, Mandatory Current Safety and Authorization
Predicates, Protected Hazard-Generation
5.6. Embodiment 37 — Irreversible-Effect Frontier and Hazard-State
Finality
Original technical source: TECHNICAL SPECIFICATION -3102-3567.pdf,
global pages 3193–3282 inclusive. Principal source treatment within
Part 8. Related mechanisms may also be referenced by Parts 3, 4 and
6.
5.6.1. Protected Component Architecture
[Principal authorized actual consequence]
|
[Consequence CA in Non-Effective State]
|
[Protected irreversibility classification]
|
[Current hazard/resource observations]
|
[Authority and safety interlocks]
|
[Real receiving resource FS]
|
[One-time protected consume]
|
[Irreversible action / qualified outcome]
Figure 11: Embodiment 37 — Irreversible-Effect Frontier and
Hazard-State Finality — architecture
5.6.2. Actual-Effect and Failure Decision Flowchart
Das Expires 29 April 2027 [Page 385]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
[Request potentially irreversible action]
|
<Actual frontier classified?> -- NO --> [WITHHOLD]
| YES
<Current qualified hazard conditions?> -- NO --> [REFUSE]
| YES
<Source grant / resource / budget valid?> -- NO --> [REFUSE]
| YES
[Receiving FS checks exact pending command]
|
<Fresh conditions and state still true?> -- NO --> [FENCE]
| YES
[Consume once, effect, observe outcome]
Figure 12: Embodiment 37 — Irreversible-Effect Frontier and
Hazard-State Finality — effectuation decisions
5.6.3. Original Technical Disclosure — Page-Indexed Sections
5.6.3.1. Original Source — Global Page 3193
Fencing, Consequence-Bound Scoped Non-Bearer Finality, Independent
Actual Finality-Sink Reconstruction, Protected Single-Commit
Consumption, and Post-Effect Outcome Qualification Without Presuming
Reversibility
37.0.1 — General Technical Description
The present Embodiment 37 discloses systems, methods, apparatus,
protected computing components, autonomous operation planners,
protected consequence classifiers, effect-specific originating
authority controllers, hazard-state observers, resource condition
validators, irreversible-operation controllers, protected execution
gates, finality-capability controllers, actual receiving-resource
Finality Sinks, protected outcome journals, and independent post-
effect verification components configured to govern consequential
operations for which subsequent correction, rollback, deletion,
cancellation, or compensation cannot reliably restore the previous
state.
An autonomous computational workload may comprise:
An artificial-intelligence agent;
A tool-using software agent;
A distributed enterprise automation controller;
Das Expires 29 April 2027 [Page 386]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A cloud infrastructure controller;
A cryptographic key-management agent;
A payment or settlement automation system;
A data publication agent;
A persistent-storage management controller;
A telecommunications operations agent;
A hardware-control process;
An industrial automation controller;
A robotic system;
A satellite command controller;
An autonomous device-management service;
Or another computational component capable of proposing operations
that may produce non-recoverable or high-consequence effects.
An operation may be irreversible because:
5.6.3.2. Original Source — Global Page 3194
The operation causes a physical state change that cannot be reliably
reversed;
A message or data object is transmitted beyond the originating
system's effective control;
A cryptographic key required for recovery is destroyed without an
available qualified backup;
A storage medium is sanitized in a manner intended to make protected
information unrecoverable;
A financial transfer reaches a defined final settlement state;
A legal or administrative record is committed under an externally
authoritative finality mechanism;
A credential or secret is disclosed to an unauthorized recipient;
Das Expires 29 April 2027 [Page 387]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A publication is replicated to independent recipients;
An actuator causes a non-reversible mechanical, chemical, electrical,
or other physical consequence;
A hardware fuse, counter, or one-time programmable element is
committed;
A protected lifecycle state advances beyond an allowed rollback
boundary;
Or the actual resource effect cannot be reliably returned to the
earlier state under the applicable operational assumptions.
Some operations are not mathematically or physically irreversible in
every conceivable environment but are practically irreversible
because reversal would require unavailable authority, inaccessible
recipients, prohibitively uncertain procedures, or additional
consequential operations that cannot reproduce the original state.
A refund may offset a payment without eliminating the original
payment's historical occurrence.
A corrective publication may address an earlier disclosure without
ensuring that all copies of the disclosed information have been
removed.
A restored database may recover some data while failing to undo
external actions triggered by the original mutation.
An opposite actuator command may move a device toward an earlier
position without reversing the original physical effects.
A newly generated cryptographic key may replace a destroyed key for
future operations without recovering information encrypted
exclusively under the destroyed key.
Accordingly, the availability of a proposed compensating operation is
not proof that the original effect is reversible.
5.6.3.3. Original Source — Global Page 3195
An autonomous workload may generate an apparently valid command.
It may obtain a conventional policy-engine allow decision.
It may pass authentication.
Das Expires 29 April 2027 [Page 388]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
It may use a permitted tool.
It may even receive human confirmation of a displayed operation.
However, the actual pending operation may have materially different
consequences from those evaluated earlier.
The operation may affect a different resource.
The irreversible effect may be greater than authorized.
The relevant environmental conditions may have changed.
The required safety interlock may be unavailable.
The actual recipient may differ from the approved recipient.
The operation may cross an irreversible boundary before the protected
controller performs its final validation.
The receiving resource may execute the command before producing an
acknowledgement.
An agent may retry the command following an uncertain response and
thereby create an additional irreversible effect.
The present embodiment provides a protected architecture in which
consequential operations are classified according to their actual
effect and applicable reversibility assumptions.
A qualified Consequence Authority Envelope identifies the specific
actual effects permitted by the originating principal.
A Consequence Candidate Act is constructed for the proposed
operation.
The Candidate Act remains in a Non-Effective State.
A protected classifier identifies whether the contemplated effect is
reversible, conditionally reversible, compensable, practically
irreversible, or non-compensable under the applicable resource model.
A qualified hazard controller determines the current mandatory
constraints relevant to the actual operation.
These constraints may include:
Das Expires 29 April 2027 [Page 389]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.6.3.4. Original Source — Global Page 3196
Actual resource identity;
Resource state;
Recipient or target;
Amount or magnitude;
Device operating envelope;
Required physical interlocks;
Current authority;
Current revocation;
Hazard generation;
Permitted irreversible-effect count;
Protected effect dependency conditions;
And actual receiving-resource capability.
A protected controller determines the relevant effectuation boundary
at which the operation may become irreversible or otherwise
practically unrecoverable.
The architecture prevents release across that boundary unless the
required current source, consequence, resource, hazard, and finality
predicates pass.
A scoped non-bearer finality enablement is constituted only for the
qualified actual consequence.
The receiving Finality Sink independently obtains or reconstructs the
pending operation at the actual effectuation boundary.
The sink verifies that the actual operation remains within the
qualified consequence envelope and that the required current hazard
and safety conditions are satisfied.
Where the actual receiving resource supports transactional
consumption, the sink conditionally commits protected single-use or
bounded authority along with the controlled resource operation.
Das Expires 29 April 2027 [Page 390]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Where the receiving resource does not support a common atomic
transaction, the implementation must apply an appropriate protected
dispatch, acknowledgement, reconciliation, or independent resource
enforcement model.
After effectuation, the system records the qualified actual outcome.
5.6.3.5. Original Source — Global Page 3197
The system does not automatically describe an irreversible effect as
undone merely because a later compensating operation was attempted.
Where required, a separate containment, notification, mitigation, or
recovery procedure may be initiated under its own competent
authority.
37.0.2 — Fundamental Technical Principle
A permission to initiate a consequential operation is not proof that
the operation's actual irreversible consequences are within the
originating principal's authority.
Further:
An AI-generated plan is not authority to release an irreversible
effect.
A resource policy allow decision is not evidence that every relevant
hazard condition remains satisfied.
A human confirmation does not automatically establish the actual
effectuation target or current physical state.
A valid cryptographic signature does not establish that a destructive
operation is safe or authorized.
A compensation plan does not make an irreversible effect reversible.
A simulation result is not the actual physical or resource state.
A receipt indicating command acceptance is not necessarily proof of
physical completion.
A timeout does not establish that an irreversible command failed.
A protected stop command cannot be assumed to reverse effects already
committed.
Das Expires 29 April 2027 [Page 391]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
And protected finality must be enforced before the operation crosses
the actual irreversible boundary.
37.0.3 — Principal Candidate Inventive Combination
A representative implementation comprises:
(a) an originating source-authorized consequence envelope;
(b) an effect-specific Candidate Act;
(c) a Non-Effective State preventing premature irreversible
effectuation;
(d) protected classification of actual consequence and reversibility
properties;
(e) a qualified current hazard-state witness;
5.6.3.6. Original Source — Global Page 3198
(f) a protected representation of the operation's irreversible
effectuation frontier;
(g) operation-specific current safety, authority, and resource
predicates;
(h) protected fencing of pending finality after material hazard-state
changes;
(i) qualified independent pre-effectuation validation;
(j) consequence-specific cross-committed evidence;
(k) scoped non-bearer finality enablement;
(l) independent actual Finality-Sink reconstruction;
(m) sink-local protected single-use or bounded consumption;
(n) controlled crossing of the irreversible effectuation frontier;
(o) qualified actual outcome evidence;
(p) separate authority for any post-effect mitigation or compensating
operation.
37.0.4 — Candidate Technical Distinction
Das Expires 29 April 2027 [Page 392]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The embodiment does not claim as individually new:
Hazard analysis;
Safety interlocks;
Safety controllers;
Emergency stops;
Functional-safety systems;
Two-person authorization;
Transaction signing;
Human confirmation;
Hardware security modules;
Secure deletion;
Conditional resource updates;
5.6.3.7. Original Source — Global Page 3199
Cryptographic attestation;
Single-use tokens;
Or transactional commit protocols.
The proposed technical contribution concerns the operation-specific
causal coupling of protected original consequence authority, actual
pre-effect hazard verification, non-effective holding before an
identified irreversible boundary, independent receiving-resource
finality, and protected outcome accounting that does not presume
reversibility.
37.0.5 — Relationship to Earlier Embodiments
The embodiment may incorporate mechanisms concerning:
Candidate Acts and Non-Effective States;
Protected originating authority;
Independent execution-time validation;
Das Expires 29 April 2027 [Page 393]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Cross-committed evidence;
Scoped non-bearer enablement;
Actual Finality-Sink reconstruction;
Resource and tool identity continuity;
Policy-generation fencing;
Multi-resource dependency finality;
Partial-commit containment;
Revocation;
And recovery.
The present embodiment concentrates on the boundary at which an
actual consequence ceases to be reliably reversible, and the
protected conditions required before that boundary may be crossed.
37.0.6 — Non-Limiting Reference Architecture
ORIGINATING PRINCIPAL | v CONSEQUENCE AUTHORITY |
5.6.3.8. Original Source — Global Page 3200
v CANDIDATE ACT | v NON-EFFECTIVE HOLD | v PROTECTED CONSEQUENCE
MODEL | +---------+----------+ | | v v REVERSIBILITY ACTUAL HAZARD
AND CLASSIFICATION RESOURCE STATE | | +---------+----------+ | v
IRREVERSIBILITY FRONTIER | v MANDATORY PRE-EFFECT CHECKS |
+--------+---------+ | | v v PASS FAIL / UNKNOWN | | v v NON-BEARER
FINALITY CONTINUED HOLD | v ACTUAL FINALITY SINK | v RECONSTRUCT REAL
EFFECT | v CURRENT CONSEQUENCE + HAZARD + AUTHORITY VERIFICATION | v
PROTECTED CONSUMPTION | v CONTROLLED IRREVERSIBLE RELEASE | v ACTUAL
OUTCOME EVIDENCE | v
5.6.3.9. Original Source — Global Page 3201
POST-EFFECT STATE QUALIFICATION
All figures, algorithms, data structures, and reference
implementations are illustrative, optional, and non-limiting.
37.1 — TECHNICAL FIELD
Das Expires 29 April 2027 [Page 394]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The invention relates to autonomous execution security, protected
irreversible-effect control, safety-relevant resource authorization,
finality-bound device actuation, cryptographic lifecycle control,
irreversible publication, destructive resource mutation, settlement
authorization, hardware command gating, protected consequence
accounting, and independent effectuation-boundary enforcement.
More particularly, it concerns preventing computational workloads
from effecting irreversible or non-compensable operations where the
actual consequence differs from the operation and hazard conditions
specifically authorized by the originating principal.
37.2 — SPECIFIC TECHNICAL PROBLEMS
37.2.1 — Consequence Underdescription
A computational plan may describe an operation without identifying
all material external effects.
37.2.2 — Operation Name Versus Effect
An operation labeled finalize, delete, publish, or execute may have
different consequences across resources.
37.2.3 — Incorrect Reversibility Assumption
An agent may assume that every completed effect can be undone.
37.2.4 — Compensation/Restoration Confusion
A compensating act may fail to restore the prior state.
37.2.5 — Delayed Hazard State
A hazard assessment may become stale before effectuation.
37.2.6 — Wrong Actual Target
An approved destructive operation may reach another resource.
37.2.7 — Resource Ownership Change
5.6.3.10. Original Source — Global Page 3202
A resource may acquire a different current owner.
37.2.8 — Parameter Magnitude Substitution
Das Expires 29 April 2027 [Page 395]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An operation's actual effect magnitude may exceed the authorized
limit.
37.2.9 — Recipient Substitution
A disclosure or transfer may reach a different recipient.
37.2.10 — Irreversible Side Effect
A tool may perform an additional effect not included in the approval.
37.2.11 — Premature Commit
An irreversible operation may execute before the final hazard and
authority checks.
37.2.12 — Check/Effect Race
The environment may change after validation but before actual
effectuation.
37.2.13 — Unverified Safety Interlock
A claimed safety condition may not correspond to actual protected
enforcement.
37.2.14 — Interlock Bypass
An alternate command path may circumvent a mandatory control.
37.2.15 — Monitoring-Only Substitution
An advisory hazard monitor may be mistaken for a non-bypassable gate.
37.2.16 — Untrusted Sensor Report
An agent-supplied observation may not establish current physical
state.
37.2.17 — Stale Sensor Reading
The latest received measurement may no longer qualify as current.
37.2.18 — Sensor Authenticity Versus Accuracy
A genuine sensor may produce incorrect or insufficient readings.
37.2.19 — Unknown Hazard Condition
Das Expires 29 April 2027 [Page 396]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A critical predicate may be indeterminate.
5.6.3.11. Original Source — Global Page 3203
37.2.20 — Unqualified Simulation
A simulated safe result may be treated as proof of actual operational
safety.
37.2.21 — Incorrect Hazard Model Version
The applicable risk or resource model may change.
37.2.22 — Unqualified Risk Threshold
An autonomous agent may choose an easier threshold than the competent
authority established.
37.2.23 — Emergency Override Abuse
A workload may claim urgency to bypass required restrictions.
37.2.24 — Approval Outside Effect Scope
A valid approver may authorize one effect but not another.
37.2.25 — Confirmation Laundering
A human may confirm an incomplete description that omits material
consequences.
37.2.26 — Reusable Irreversible Authorization
One approval may be replayed for repeated destructive effects.
37.2.27 — Command Retry After Timeout
An operation may already have crossed the irreversible frontier when
a response is lost.
37.2.28 — Partial Physical Completion
A device may execute only part of a commanded operation.
37.2.29 — Destructive Deletion Without Recovery
A key or data object may be made unavailable without adequate current
source authority.
Das Expires 29 April 2027 [Page 397]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
37.2.30 — Key-Lifecycle Confusion
Key deactivation, revocation, destruction, and replacement may have
different real consequences.
37.2.31 — Replicated Disclosure
Information may be copied by external recipients after publication.
5.6.3.12. Original Source — Global Page 3204
37.2.32 — Settlement Finality Misclassification
A financial operation may cross an externally defined settlement-
finality boundary.
37.2.33 — Hardware One-Time State
A one-time programmable element may not support rollback.
37.2.34 — Physical Device Rebinding
A command may reach a different actuator than the approved one.
37.2.35 — Actuation State Drift
A physical operating condition may change before a command is
accepted.
37.2.36 — Unsafe Command Sequencing
An irreversible command may occur before mandatory preparatory
checks.
37.2.37 — Hidden Consequential Fan-Out
One API or tool call may trigger multiple externally consequential
operations.
37.2.38 — Unbounded Effect Budget
Repeated operations may collectively exceed an authorized
irreversible-effect limit.
37.2.39 — Cross-Agent Duplication
Several agents may independently attempt the same irreversible
action.
Das Expires 29 April 2027 [Page 398]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
37.2.40 — Stale Policy or Revocation
An operation may be approved under outdated authority conditions.
37.2.41 — Resource-Version Drift
A resource may change after the Candidate Act is prepared.
37.2.42 — Irreversibility Frontier Misidentification
The supposed last safe validation point may occur after the true
irreversible effect.
37.2.43 — Nonatomic Sink Enforcement
A gateway may authorize the operation but lack control over the
actual irreversible primitive.
37.2.44 — Misleading Outcome Receipt
5.6.3.13. Original Source — Global Page 3205
A dispatch or acceptance receipt may be mistaken for completed
effectuation.
37.2.45 — Indeterminate Actual Outcome
The system may not know whether the irreversible consequence
occurred.
37.2.46 — Automatic Recovery Overreach
A recovery agent may attempt an unauthorized additional operation.
37.2.47 — False Rollback Reporting
The system may report a restored state without proving it.
37.2.48 — Audit-State Erasure
Recovery may overwrite evidence of completed harmful or unauthorized
effects.
37.2.49 — Certification Confusion
Security authorization may be mistaken for functional-safety
certification.
Das Expires 29 April 2027 [Page 399]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
37.2.50 — Technical Objective
How to prevent unauthorized irreversible or practically non-
compensable real resource effects by binding each consequential
Candidate Act to a qualified permitted consequence, independently
validating current authority and hazard predicates before the actual
irreversible effectuation boundary, enforcing bounded non-bearer
finality at the receiving sink, and preserving truthful actual-
outcome evidence after the effect occurs.
37.3 — ESTABLISHED TECHNOLOGICAL FOUNDATIONS
37.3.1 — Safety Interlocks
Existing industrial and physical systems use interlocks to prevent
selected commands or conditions.
An interlock does not inherently establish original task
authorization for a computational agent.
37.3.2 — Functional-Safety Engineering
Established functional-safety methods define requirements for safety-
related systems, including analysis of dangerous failure conditions.
The present embodiment does not replace the engineering, validation,
certification, or applicable standards required for safety-related
devices.
5.6.3.14. Original Source — Global Page 3206
37.3.3 — Policy Authorization
Existing systems check whether a principal may invoke an operation.
Permission to invoke an operation does not necessarily prove that its
actual irreversible consequence matches the authorized scope.
37.3.4 — Two-Person and Human Approval
Existing procedures require confirmation for selected sensitive
operations.
A confirmation mechanism is effective only for the specific competent
decision and accurately presented consequence within its protection
model.
37.3.5 — Hardware Security Modules
Das Expires 29 April 2027 [Page 400]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Existing protected key-management devices may enforce selected
sensitive key operations.
Their presence does not automatically establish that an autonomous
source task authorized the exact key lifecycle effect.
37.3.6 — Conditional Resource Mutation
Existing transactional and conditional APIs can prevent some races
and repeated effects.
They do not independently model every real-world consequence or
hazard.
37.3.7 — Risk and Hazard Analysis
Existing methods can classify hazards and define safety restrictions.
The proposed combination ties selected qualified hazard predicates to
a mandatory operation-specific actual Finality-Sink transition.
37.4 — PRINCIPAL TECHNICAL COMPONENTS
A representative system comprises:
1. Protected Original Source-Authority Registry. 2. Consequence
Authority Envelope Constructor. 3. Consequence Candidate Act
Controller. 4. Non-Effective State Controller. 5. Actual Effect-
Semantics Registry. 6. Protected Irreversibility Classifier. 7.
Qualified Hazard Model Registry. 8. Protected Hazard-State Evidence
Collector. 9. Resource and Recipient Identity Validator. 10.
Irreversibility Frontier Descriptor Controller.
5.6.3.15. Original Source — Global Page 3207
11. Current Resource-State Version Controller. 12. Mandatory Safety
and Operational Invariant Controller. 13. Hazard-Generation and
Revocation Fence Controller. 14. Optional Competent Approval
Controller. 15. Independent Pre-Effect Validation Domain. 16.
Consequence-Bound Non-Bearer Finality Controller. 17. Actual
Resource Finality Sink. 18. Protected Effect Consumption Controller.
19. Actual Consequence Outcome Observer. 20. Indeterminate-Effect
Containment Controller. 21. Post-Effect Recovery and Mitigation
Authority Controller. 22. Protected Irreversible-Effect Journal.
37.5 — TECHNICAL DEFINITIONS
37.5.1 — Consequence Candidate Act
Das Expires 29 April 2027 [Page 401]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A Consequence Candidate Act, or CCA-37, means a Candidate Act
representing an operation having one or more qualified consequential
effects.
37.5.2 — Consequence Authority Envelope
A Consequence Authority Envelope, or CAE-37, means a protected
description of the specific actual effects permitted by the
originating principal.
37.5.3 — Qualified Consequence Descriptor
A Qualified Consequence Descriptor, or QCD-37, means a representation
of material actual effects of a proposed operation under an
applicable resource model.
37.5.4 — Irreversibility Classification
Irreversibility Classification, or IC-37, means qualified
characterization of whether an effect can be reversed, compensated,
mitigated, or neither under defined assumptions.
37.5.5 — Practically Irreversible Effect
A Practically Irreversible Effect means an operation whose relevant
consequences cannot be reliably restored under the applicable
authority, timing, resource, and operational conditions.
37.5.6 — Non-Compensable Effect
A Non-Compensable Effect means an actual consequence for which no
adequate authorized compensating operation is available under the
qualified resource model.
37.5.7 — Irreversibility Frontier
5.6.3.16. Original Source — Global Page 3208
An Irreversibility Frontier, or IF-37, means the protected actual
resource boundary at or after which the relevant operation may
produce a consequence not reliably reversible.
37.5.8 — Pre-Frontier Non-Effective State
A Pre-Frontier Non-Effective State means a condition in which the
operation cannot yet cross the relevant irreversible effectuation
boundary.
Das Expires 29 April 2027 [Page 402]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
37.5.9 — Frontier-Local Verification
Frontier-Local Verification means qualifying mandatory authorization
and hazard predicates at or through the actual control point
governing the irreversible operation.
37.5.10 — Consequence-Bound Finality
Consequence-Bound Finality means scoped permission for a specified
actual consequential effect rather than generic tool or operation
access.
37.5.11 — Material Consequence Parameter
A Material Consequence Parameter means an operation attribute
affecting the actual target, magnitude, disclosure scope,
irreversibility, or other required authorization predicates.
37.5.12 — Protected Consequence Model
A Protected Consequence Model means a qualified representation of
relevant effects, resources, and operating assumptions.
37.5.13 — Hazard-State Witness
A Hazard-State Witness, or HSW-37, means qualified evidence
concerning the current conditions material to a protected hazard or
safety predicate.
37.5.14 — Hazard Model Generation
A Hazard Model Generation, or HMG-37, means the protected current
version of the hazard-analysis or permissible operating-condition
model.
37.5.15 — Hazard-State Generation
A Hazard-State Generation, or HSG-37, means a protected version or
ordered observation reference associated with relevant actual
resource hazard conditions.
37.5.16 — Hazard-Generation Fence
A Hazard-Generation Fence means withholding pending finality after a
material change in the hazard model or observed operating state.
37.5.17 — Qualified Sensor Evidence
Das Expires 29 April 2027 [Page 403]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.6.3.17. Original Source — Global Page 3209
Qualified Sensor Evidence means data assessed for relevant
provenance, integrity, timing, accuracy, and applicability to the
protected predicate.
37.5.18 — Protected Safety Invariant
A Protected Safety Invariant means a mandatory enforceable
operational restriction established by a competent safety or resource
authority.
37.5.19 — Effectuation-Route Integrity
Effectuation-Route Integrity means evidence or enforcement
establishing that the actual irreversible operation passes through
the required protected finality control.
37.5.20 — Effectuation-Path Bypass
An Effectuation-Path Bypass means an alternative operation route
permitting the irreversible consequence without the mandatory
protected controls.
37.5.21 — Irreversible Effect Budget
An Irreversible Effect Budget means a source-authorized aggregate
bound on one or more irreversible operation counts, quantities, or
magnitudes.
37.5.22 — Consequence Reservation
A Consequence Reservation means a protected allocation of specified
effect authority prior to actual finality.
37.5.23 — Single-Commit Effectuation
Single-Commit Effectuation means enforcing qualified bounded release
and non-reuse under the actual receiving resource's supported
consistency model.
37.5.24 — Qualified Pre-Effect Evidence
Qualified Pre-Effect Evidence means protected evidence generated
before crossing the irreversible frontier and used for final effect
authorization.
37.5.25 — Actual Effect Reconstruction
Das Expires 29 April 2027 [Page 404]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Actual Effect Reconstruction means independently obtaining the actual
operation, target, and material parameters at the protected receiving
boundary.
37.5.26 — Irreversibility-Frontier Witness
An Irreversibility-Frontier Witness means qualified evidence
identifying the controlled actual boundary and relevant current state
for irreversible release.
37.5.27 — Frontier Release Permit
5.6.3.18. Original Source — Global Page 3210
A Frontier Release Permit means a scoped non-bearer authorization
reference governing release across the identified frontier.
37.5.28 — Frontier Release Fence
A Frontier Release Fence means withholding an operation from crossing
the frontier because mandatory conditions are absent, invalid, or
unresolved.
37.5.29 — Current Consequence Correspondence
Current Consequence Correspondence means verification that the actual
pending effect is within the originating source-authorized
consequence envelope.
37.5.30 — Effect Magnitude Constraint
An Effect Magnitude Constraint means a qualified bound on the amount,
duration, strength, quantity, count, or other material property of an
effect.
37.5.31 — Disclosure Irreversibility
Disclosure Irreversibility means the inability to guarantee removal
or non-use of information after qualifying disclosure to an external
recipient.
37.5.32 — Cryptographic Destruction Consequence
Cryptographic Destruction Consequence means loss of access to
protected key material or information as a result of a key lifecycle
operation under the relevant recovery assumptions.
37.5.33 — Final Settlement Consequence
Das Expires 29 April 2027 [Page 405]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Final Settlement Consequence means a resource-defined state in which
a financial or comparable transfer attains the applicable
authoritative finality.
37.5.34 — Physical Actuation Consequence
Physical Actuation Consequence means the actual physical change
produced by an effect-capable device command.
37.5.35 — One-Time Hardware Consequence
A One-Time Hardware Consequence means a persistent hardware state
transition not reversibly supported by the actual device.
37.5.36 — Consequence Multiplicity
Consequence Multiplicity means the number of real separate effects
produced by an operation or its retries.
37.5.37 — Consequence Fan-Out
5.6.3.19. Original Source — Global Page 3211
Consequence Fan-Out means multiple downstream effects caused by an
apparently single tool or API operation.
37.5.38 — Consequence Receipt
A Consequence Receipt means qualified evidence describing actual
attempted or completed effectuation at the relevant resource
boundary.
37.5.39 — Actual Outcome Qualification
Actual Outcome Qualification means verification of the supported
actual outcome state rather than inference from dispatch alone.
37.5.40 — Irreversible Outcome Indeterminacy
Irreversible Outcome Indeterminacy means inability to establish
whether the effect crossed the irreversible boundary.
37.5.41 — Non-Repetition Fence
A Non-Repetition Fence means withholding another attempt when the
previous effect may already have occurred and duplication is not
independently authorized.
Das Expires 29 April 2027 [Page 406]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
37.5.42 — Hazard Predicate Closure
Hazard Predicate Closure means qualification of all mandatory pre-
effect authorization and safety predicates applicable to a proposed
operation.
37.5.43 — Hazard Predicate Unknown
Hazard Predicate Unknown means that a mandatory condition cannot be
sufficiently established.
37.5.44 — Post-Effect Mitigation Candidate
A Post-Effect Mitigation Candidate means a separately proposed
consequential act intended to reduce or respond to an already
completed effect.
37.5.45 — Mitigation Noninheritance
Mitigation Noninheritance means the original effect authorization
does not automatically permit arbitrary later mitigating or
compensating acts.
37.5.46 — Protected Consequence Journal
A Protected Consequence Journal means authenticated durable records
of Candidate Acts, source authority, hazard evidence, finality,
actual effect attempts, and outcome states.
37.5.47 — Consequence Nonresurrection
5.6.3.20. Original Source — Global Page 3212
Consequence Nonresurrection means preventing old approvals, recovery
snapshots, or retries from recreating spent irreversible-effect
authority.
37.5.48 — Qualified Safety Substrate
A Qualified Safety Substrate means an independently engineered
device, resource, controller, or mechanism enforcing relevant actual
safety properties.
37.5.49 — Authorization/Safety Separation
Authorization/Safety Separation means treating permission for an
operation and proof of relevant safe operating conditions as distinct
mandatory predicates where required.
Das Expires 29 April 2027 [Page 407]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
37.5.50 — Protected Irreversible-Effect Finality
Protected Irreversible-Effect Finality means conditional source-
authorized release of a specified actual irreversible consequence
through a competent protected Finality Sink following current
required authority, resource, hazard, and bounded-consumption
verification.
37.6 — REVERSIBILITY AND CONSEQUENCE CLASSIFICATION
A representative system distinguishes:
CLASS I — Reversible Local Effect: A resource supports qualified
restoration under the applicable transaction and authority model.
CLASS II — Conditionally Reversible Effect: Restoration is possible
only while specified resource, timing, or control conditions remain
valid.
CLASS III — Compensable Effect: A separate authorized corrective
operation may offset selected consequences but cannot necessarily
erase the original effect.
CLASS IV — Practically Irreversible Effect: Restoration cannot
reliably be established under the current operating conditions.
CLASS V — Non-Compensable Effect: No adequate authorized recovery
operation is available.
CLASS VI — Unknown Consequence: The relevant reversibility or effect
model is insufficiently qualified.
37.6.1 — Unknown Classification
Where mandatory properties are unknown, the system may impose the
more restrictive applicable finality requirements.
37.6.2 — No Uniform Severity Rule
5.6.3.21. Original Source — Global Page 3213
Irreversibility and hazard severity are related but distinct.
A low-impact operation may be irreversible.
A reversible operation may nonetheless pose severe safety risks.
37.6.3 — Dynamic Classification
Das Expires 29 April 2027 [Page 408]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An operation's reversibility may change with current resource state.
A temporary reservation may become final settlement.
A queued message may become an externally delivered disclosure.
A prepared resource write may become permanently committed.
37.7 — CONSEQUENCE AUTHORITY ENVELOPE
A representative record comprises:
PROTECTED_CONSEQUENCE_AUTHORITY = {
originating_source_grant_reference, competent_authority_identity,
permitted_actual_resource_identifiers, permitted_consequence_classes,
permitted_operation_types, permitted_effect_magnitude,
permitted_recipient_or_target_scope, maximum_effect_count,
mandatory_hazard_predicates, required_safety_enforcement_paths,
applicable_hazard_model_generation,
current_source_revocation_generation, applicable_approval_conditions,
designated_actual_finality_sinks, protected_authority_authentication
}
37.7.1 — Effect-Centric Authorization
The grant describes what the operation may actually cause.
37.7.2 — Not Merely Tool Access
Permission to use a tool does not automatically authorize every
effect produced by the tool.
37.7.3 — Bounded Magnitude
5.6.3.22. Original Source — Global Page 3214
A grant may impose an actual count, duration, amount, target, or
resource limit.
37.7.4 — Source Authority
An autonomous agent cannot enlarge the consequence envelope
independently.
37.8 — CONSEQUENCE CANDIDATE ACT
Das Expires 29 April 2027 [Page 409]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
CONSEQUENCE_CANDIDATE_ACT = { candidate_act_identifier,
original_source_grant_reference, requesting_workload_identity,
actual_target_resource_reference, proposed_operation_descriptor,
anticipated_effect_class, material_effect_parameters,
expected_irreversibility_class, intended_effectuation_frontier,
mandatory_hazard_model_reference, mandatory_resource_conditions,
bounded_effect_budget_reference, designated_finality_sink,
protected_candidate_authentication }
37.8.1 — Candidate Meaning
The Candidate Act identifies a proposed consequence, not a completed
one.
37.8.2 — Non-Effective Holding
The proposed operation remains unable to produce the covered real
effect.
37.8.3 — Actual Parameters
The effectuation boundary verifies the parameters actually submitted
or observed.
37.9 — PROTECTED IRREVERSIBILITY FRONTIER
A representative controller identifies the actual resource operation
at which relevant consequences may become non-recoverable.
Examples include:
The release of data to an external recipient;
5.6.3.23. Original Source — Global Page 3215
The actual commit of a final financial transfer;
The execution of a protected hardware one-time programming operation;
The initiation of a physical command beyond a controlled safe hold;
The actual destruction of key material;
And the final resource mutation following expiration of a reversible
preparation phase.
37.9.1 — Frontier Must Be Controllable
Das Expires 29 April 2027 [Page 410]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A software check applied after actual effectuation cannot protect an
earlier irreversible frontier.
37.9.2 — Qualified Receiving Resource
The actual receiving component must expose or implement an
enforcement point capable of withholding the operation before the
relevant consequence.
37.9.3 — No Fictional Preparation State
A resource lacking a genuine harmless prepare mode cannot be assumed
to support one.
37.9.4 — Multiple Frontiers
A single high-level operation may have several distinct irreversible
effects requiring separate qualification.
37.10 — FRONTIER DESCRIPTOR
IRREVERSIBILITY_FRONTIER_DESCRIPTOR = { actual_resource_identity,
actual_effectuation_primitive, frontier_operation_class,
pre_frontier_non_effective_state, mandatory_release_conditions,
allowed_actual_effect_scope, required_enforcement_component,
effect_count_or_budget_scope, resource_consistency_assumptions,
post_frontier_outcome_semantics, protected_frontier_authentication }
The protected controller does not assume that every API-level request
maps directly to the true underlying irreversible primitive.
5.6.3.24. Original Source — Global Page 3216
Where a proxy, broker, device driver, or external resource executes
the actual effect, the necessary enforcement must be located within a
path that genuinely controls that effect.
37.11 — ACTUAL CONSEQUENCE MODEL
The protected system may maintain qualified models describing:
Material effect classes;
Resource targets;
Affected parties or recipients;
Durability;
Das Expires 29 April 2027 [Page 411]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Replication;
Physical state changes;
Dependencies;
Side effects;
Available recovery operations;
And uncertainty.
37.11.1 — Protected Model
The model is established or approved by a competent technical or
resource authority.
37.11.2 — Agent Proposal
The agent may propose a consequence description.
37.11.3 — Independent Qualification
The proposed description is not automatically authoritative.
37.11.4 — Model Limitations
A finite consequence model cannot prove the absence of every possible
external effect.
37.12 — MATERIAL CONSEQUENCE CORRESPONDENCE
5.6.3.25. Original Source — Global Page 3217
[ E_A ]
denote the source-authorized consequence envelope.
[ E_P ]
denote the qualified actual pending consequence.
A necessary condition may be:
[ E_P \subseteq E_A ]
under the applicable typed consequence model.
Das Expires 29 April 2027 [Page 412]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The relation is illustrative.
It requires actual material targets, operations, and effect
parameters to remain within the originating permission.
37.12.1 — New Recipient
May create an unauthorized disclosure effect.
37.12.2 — Increased Magnitude
May exceed the permitted effect budget.
37.12.3 — New Side Effect
Requires corresponding qualification.
37.12.4 — Unknown Consequence
Cannot automatically be treated as a subset of the authorized
envelope.
37.13 — QUALIFIED HAZARD MODEL
A protected hazard model may identify:
Permitted resource states;
5.6.3.26. Original Source — Global Page 3218
Prohibited physical states;
Required interlocks;
Allowable operation magnitudes;
Required sensor validity;
Mandatory operator or source approval;
Safe operating region constraints;
Protected resource generations;
And emergency restrictions.
37.13.1 — Competent Configuration
Das Expires 29 April 2027 [Page 413]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The autonomous agent does not independently decide which mandatory
safety restrictions to eliminate.
37.13.2 — Version Binding
The protected controller identifies the applicable current hazard
model generation.
37.13.3 — Safety Engineering
Actual hazard limits must be established and validated through an
appropriate domain-specific engineering process.
37.13.4 — No Automatic Certification
Implementing the present authority architecture does not itself
certify that a device is safe for operation.
37.14 — HAZARD-STATE WITNESS
A representative protected witness comprises:
PROTECTED_HAZARD_STATE_WITNESS = {
actual_resource_or_device_identity, hazard_model_generation,
hazard_state_generation, qualified_observation_sources,
observation_freshness_evidence, measurement_integrity_status,
required_interlock_states, relevant_resource_versions,
5.6.3.27. Original Source — Global Page 3219
current_operating_mode, applicable_safety_constraints,
qualification_limits, protected_witness_authentication }
37.14.1 — Evidence Quality
A cryptographically authenticated observation does not by itself
prove that the underlying measurement is physically accurate.
37.14.2 — Freshness
The observation must remain sufficiently current for the operation.
37.14.3 — Independent Channel
Where required, the protected validator may obtain evidence through a
channel independent of the proposing agent.
37.14.4 — Unknown State
Das Expires 29 April 2027 [Page 414]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A mandatory unresolved hazard predicate prevents release unless a
separately authorized safe operating mode applies.
37.15 — HAZARD PREDICATE CLOSURE
A proposed irreversible operation becomes eligible only when all
applicable mandatory predicates pass.
For example:
[ P_{\mathrm{source}} \land P_{\mathrm{target}} \land
P_{\mathrm{hazard}} \land P_{\mathrm{policy}} \land
P_{\mathrm{magnitude}} \land P_{\mathrm{finality}} ]
The expression is illustrative.
5.6.3.28. Original Source — Global Page 3220
37.15.1 — Authorization Is Necessary
The origin principal must authorize the actual effect.
37.15.2 — Hazard Qualification May Also Be Necessary
Required safe operating conditions must independently pass.
37.15.3 — Missing Predicate
A missing mandatory predicate does not become TRUE merely because a
policy engine returns allow.
37.16 — FRESHNESS AND LAST-RESPONSIBLE-MOMENT VERIFICATION
The system may validate hazard and resource state as close as
practicable to the actual irreversible frontier.
However, a late software check alone cannot eliminate races.
37.16.1 — Protected Local Check
A strong implementation performs the necessary validation inside or
through the actual resource enforcement domain.
37.16.2 — Conditional Commit
Where supported, the resource checks current state and commits the
effect under a suitable transaction or guarded primitive.
Das Expires 29 April 2027 [Page 415]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
37.16.3 — Physical Process
A device may require independent interlocks remaining effective while
commands are executed.
37.16.4 — Unsupported Timing Guarantee
The system must not claim atomicity between observations and physical
effects unless the implemented controller provides it.
37.17 — MATERIAL HAZARD-STATE CHANGE
An operation may be approved while hazard conditions satisfy the
relevant rules.
Before effectuation, one or more conditions may change.
5.6.3.29. Original Source — Global Page 3221
The protected controller identifies whether the change affects a
mandatory predicate.
37.17.1 — Material Change
Fences the pending finality.
37.17.2 — Nonmaterial Change
May permit continued eligibility where the protected model supports
that determination.
37.17.3 — Unknown Change
Requires requalification where mandatory conditions may be affected.
37.18 — HAZARD-GENERATION FENCE
A Candidate Act may be associated with a protected hazard-state
generation.
A material current change invalidates an earlier approval or finality
preparation.
The actual Finality Sink checks the required current generation or
equivalent current predicate at release.
A cached allow decision cannot substitute for current mandatory
safety conditions.
Das Expires 29 April 2027 [Page 416]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
37.19 — NON-COMPENSABLE EFFECT IDENTIFICATION
An effect may be non-compensable because:
The original data or object cannot be reconstructed;
External recipients retain independent copies;
A device reaches a one-time physical state;
A physical process has produced a permanent outcome;
A required restoration authority does not exist;
Or the prior state cannot be established with adequate certainty.
37.19.1 — Compensation Available
Does not necessarily mean true reversal.
37.19.2 — Compensation Unavailable
5.6.3.30. Original Source — Global Page 3222
Requires the relevant pre-effect containment requirements to be
satisfied before release.
37.19.3 — Compensability Unknown
The system cannot assume that a safe inverse exists.
37.20 — PROTECTED PRE-EFFECT CHECKPOINTS
A resource implementation may support several stages:
STAGE 0 — Candidate computation.
STAGE 1 — Protected consequence qualification.
STAGE 2 — Source and resource authorization.
STAGE 3 — Hazard-state qualification.
STAGE 4 — Optional reversible preparation.
STAGE 5 — Actual frontier-local finality.
STAGE 6 — Irreversible effect attempt.
Das Expires 29 April 2027 [Page 417]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
STAGE 7 — Qualified outcome observation.
37.20.1 — Stages Are Not Universally Available
Some resources provide no reversible preparation primitive.
37.20.2 — Actual Frontier
The implementation must identify the first relevant effect-producing
boundary.
37.20.3 — Pre-Effect Fail-Closed
The covered operation remains withheld if a mandatory pre-effect
condition fails.
37.21 — PROTECTED SAFETY INTERLOCK CORRESPONDENCE
A protected finality controller may require a current qualified
interlock state.
37.21.1 — Mandatory Hardware Interlock
Where required, the relevant hardware or protected safety controller
independently prevents unsafe physical release.
5.6.3.31. Original Source — Global Page 3223
37.21.2 — Software Authorization
May establish the source grant but cannot substitute for missing
mandatory safety functionality.
37.21.3 — Interlock State Report
Must be qualified against actual enforcement.
37.21.4 — No Safety Bypass
An autonomous agent cannot remove mandatory safety enforcement merely
by producing a valid-looking approval artifact.
37.22 — CONSEQUENCE-SPECIFIC HUMAN APPROVAL
Some high-impact operations may require approval by one or more
competent human principals.
The protected approval procedure may present:
Das Expires 29 April 2027 [Page 418]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Actual target identity;
Intended irreversible consequence;
Material magnitude;
Known non-reversibility limitations;
Mandatory current hazard conditions;
Permitted resource scope;
And any qualifying uncertainty.
37.22.1 — Human Approval Is Optional
Where the competent source policy permits autonomous effectuation,
human confirmation need not be a universal claim requirement.
37.22.2 — Approval Binding
Where required, approval evidence is bound to the actual effect
envelope.
37.22.3 — Current State
Human approval does not replace mandatory current resource and hazard
checks at the sink.
5.6.3.32. Original Source — Global Page 3224
37.22.4 — No Deceptive Presentation
A protected interface may distinguish the exact irreversible
operation from an agent-generated narrative or misleading tool
description.
37.23 — CONSEQUENCE-BOUND NON-BEARER FINALITY
A representative enablement comprises:
CONSEQUENCE_BOUND_FINALITY = { candidate_act_digest,
source_authority_commitment,
authorized_consequence_descriptor_digest, actual_resource_identity,
actual_pending_operation_digest, actual_effect_magnitude_bound,
hazard_model_generation, required_hazard_state_reference,
current_revocation_generation,
competent_approval_commitment_if_required,
Das Expires 29 April 2027 [Page 419]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
independent_pre_effect_validation_commitment,
designated_frontier_finality_sink, protected_single_commit_reference,
protected_enablement_authentication }
The enablement is not a general permission to perform arbitrary
operations through the selected tool.
A changed target, recipient, amount, command, or material hazard
state may invalidate the relevant prior enablement.
37.24 — CROSS-COMMITTED PRE-EFFECT EVIDENCE
A representative commitment construction comprises:
[ C_A=H(\operatorname{Canon}(CA,E_A,G)) ]
[ C_H=H(\operatorname{Canon}(H,R,C_A)) ]
5.6.3.33. Original Source — Global Page 3225
[ C_V=H(\operatorname{Canon}(E_P,H,R,C_H)) ]
[ C_F=H(\operatorname{Canon}(C_V,S,L)) ]
(CA) represents the Candidate Act;
(E_A) represents the authorized consequence;
(G) represents original source grant evidence;
(H) represents current qualified hazard evidence;
(R) represents actual resource identity and state;
(E_P) represents the pending effect;
(S) represents the actual Finality Sink;
And (L) represents protected local consumption state.
These commitments are illustrative.
Cryptographic binding preserves selected relationships but does not
independently prove the safety or completeness of the underlying
hazard model.
37.25 — ACTUAL IRREVERSIBLE-EFFECT SINK
Das Expires 29 April 2027 [Page 420]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The Finality Sink controls the actual operation capable of crossing
the irreversible frontier.
Depending upon the resource, it may comprise:
A protected key lifecycle controller;
A database or storage commit gateway;
A data-disclosure egress gateway;
A payment settlement interface;
A device command controller;
A hardware security controller;
5.6.3.34. Original Source — Global Page 3226
Or another protected receiving-resource boundary.
37.25.1 — Independent Reconstruction
The sink determines the actual pending target and operation.
37.25.2 — Current Authority
The sink verifies the source grant and current relevant resource
authorization.
37.25.3 — Current Hazard State
The sink enforces required actual resource and safety predicates.
37.25.4 — Protected Finality
The sink verifies consequence-bound non-bearer enablement and
consumption.
37.25.5 — Controlled Release
The sink permits only the qualified effect.
37.26 — EFFECTUATION-ROUTE NON-BYPASSABILITY
An operation may be submitted through:
An API;
Das Expires 29 April 2027 [Page 421]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An operating-system interface;
A device driver;
A privileged broker;
A network gateway;
A direct hardware interface;
Or another effect-capable path.
The claimed protection must correspond to the actual paths capable of
producing the covered consequence.
A high-level policy proxy that can be bypassed through an alternative
device or resource interface cannot be treated as enforcing all
irreversible operations.
The protected architecture may impose mandatory routing, remove
direct authority from lower-trust components, or place enforcement at
the actual resource boundary.
5.6.3.35. Original Source — Global Page 3227
37.27 — IRREVERSIBLE EFFECT BUDGET
A competent principal may authorize:
One destructive operation;
A bounded quantity of resource deletion;
One final settlement;
One specific external disclosure;
One device actuation;
Or a limited number of qualifying operations.
The protected consumption controller tracks remaining authority.
37.27.1 — Count
May restrict repetitions.
37.27.2 — Magnitude
Das Expires 29 April 2027 [Page 422]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
May restrict amount or intensity.
37.27.3 — Target
May restrict the resource set.
37.27.4 — Aggregate
May prevent multiple agents from exceeding an overall source grant.
37.28 — PROTECTED SINGLE-COMMIT CONSUMPTION
The actual Finality Sink checks whether the effectuation
authorization is available.
Where supported by the actual resource, it coordinates:
Verification;
Protected consumption;
And effectuation.
5.6.3.36. Original Source — Global Page 3228
37.28.1 — Transactional Resource
May provide resource-local atomic state changes.
37.28.2 — External API
May require receiver-side idempotency or current outcome
reconciliation.
37.28.3 — Physical Device
May require hardware command accounting and current device-state
verification.
37.28.4 — Important Limitation
No implementation should assert exact once-only physical effects
solely from an upstream software counter where the actual device does
not enforce the necessary correlation.
37.29 — INDETERMINATE IRREVERSIBLE OUTCOME
A resource command may be dispatched.
Das Expires 29 April 2027 [Page 423]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The connection may fail before acknowledgement.
The operation may have crossed the irreversible frontier.
The protected system preserves an indeterminate result.
37.29.1 — No Automatic Retry
The same operation is not simply repeated unless current qualified
evidence and authority permit it.
37.29.2 — Outcome Query
The system may request qualified state evidence from the actual
resource.
37.29.3 — Preserve Unknown
If completion remains unresolved, the operation remains in a
protected uncertain state.
37.29.4 — Recovery
Any further consequential recovery operation requires its own
applicable authority.
37.30 — DATA DISCLOSURE AS A POTENTIALLY IRREVERSIBLE EFFECT
5.6.3.37. Original Source — Global Page 3229
A data-disclosure operation may cross an irreversible boundary when
protected information is delivered beyond the originating system's
control.
A protected sink may verify:
The actual content or content commitment;
The actual recipient;
The disclosure channel;
The authorized sensitivity class;
The current originating permission;
The receiving service identity;
Das Expires 29 April 2027 [Page 424]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
And the protected finality allowance.
37.30.1 — Recall Limitation
A subsequent deletion request may not remove copies already acquired
by recipients.
37.30.2 — Actual Recipient
A redirect or changed recipient is material.
37.30.3 — External Publication
May require separate authority from internal storage.
37.30.4 — Controlled Release
The protected gateway must control the actual disclosure path claimed
by the implementation.
37.31 — CRYPTOGRAPHIC KEY DESTRUCTION
A protected key-management operation may change key state through:
Suspension;
Deactivation;
Revocation;
Rotation;
5.6.3.38. Original Source — Global Page 3230
Deletion;
Or destruction.
These actions are not universally equivalent.
37.31.1 — Key Destruction
May prevent subsequent decryption, signing, or other operations if no
recoverable equivalent remains.
37.31.2 — Protected Key Identity
The actual key identifier and current lifecycle state are verified.
Das Expires 29 April 2027 [Page 425]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
37.31.3 — Recovery Assumptions
The system must qualify whether backups, escrow, duplicates, or
dependent wrapped keys exist.
37.31.4 — Finality
The actual protected key controller verifies the qualified
destructive command and source authority.
37.31.5 — No Automatic Irrecoverability Claim
Deleting a key reference does not necessarily establish that all key
copies have been destroyed.
37.32 — STORAGE SANITIZATION AND CRYPTOGRAPHIC ERASURE
A sanitization procedure may intend to make protected data
inaccessible.
A protected sink may identify:
The actual target medium or logical volume;
Current ownership;
Permitted sanitization method;
Protected source grant;
Relevant recovery or retention conditions;
And the actual command issued.
5.6.3.39. Original Source — Global Page 3231
37.32.1 — Actual Medium
Must correspond to the authorized target.
37.32.2 — Sanitization Assurance
Depends on the actual storage technology, method, and verification.
37.32.3 — External Copies
The operation does not automatically remove copies outside its
covered scope.
Das Expires 29 April 2027 [Page 426]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
37.32.4 — Consequence
The destructive effect is released only under the qualified source
and resource conditions.
37.33 — FINANCIAL SETTLEMENT FINALITY
A financial workflow may have several states:
Proposed;
Authorized;
Reserved;
Submitted;
Accepted;
Settled;
Or another system-specific lifecycle stage.
A protected controller must identify the actual resource-defined
effectuation state.
37.33.1 — Authorization
Does not necessarily mean final settlement.
37.33.2 — Reservation
May be reversible under selected provider conditions.
37.33.3 — Finality
5.6.3.40. Original Source — Global Page 3232
Requires qualified resource-specific outcome evidence.
37.33.4 — Refund
May be a new financial transaction rather than true reversal of the
original completed transfer.
37.34 — HARDWARE ONE-TIME OPERATIONS
Das Expires 29 April 2027 [Page 427]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Some hardware exposes state transitions that are intended to be
performed once.
A protected controller may bind:
Device identity;
Protected one-time state identifier;
Permitted new state;
Current hardware lifecycle state;
Source permission;
And designated hardware Finality Sink.
The sink rejects use of the operation authority against another
device or a different one-time state.
The actual hardware properties determine whether the operation is
truly irreversible.
37.35 — PHYSICAL ACTUATION
A physical device command may have consequences depending upon:
Actual connected device;
Current physical position;
Operating mode;
Environmental conditions;
Interlock state;
Command magnitude;
5.6.3.41. Original Source — Global Page 3233
Timing;
And other domain-specific conditions.
A protected physical Finality Sink independently verifies applicable
state before release.
Das Expires 29 April 2027 [Page 428]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
37.35.1 — Command Authorization
Establishes whether the operation is permitted.
37.35.2 — Safety Predicate
Establishes whether mandatory current operational conditions are
satisfied.
37.35.3 — Actual Device Effect
Requires the device's own suitable control and protection mechanisms.
37.35.4 — No Safety Replacement
The architecture does not substitute an AI permission model for
required physical safety engineering.
37.36 — CONSEQUENTIAL FAN-OUT
An apparently single tool call may cause:
A database update;
An external notification;
An access-control change;
And a payment.
The protected controller may characterize material downstream effects
as:
Separate Candidate Acts;
A qualified bounded compound operation;
Or a combination of individually enforced effects.
37.36.1 — Hidden Side Effect
Cannot automatically inherit authority from the tool name.
37.36.2 — Independent Resource Boundary
Das Expires 29 April 2027 [Page 429]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.6.3.42. Original Source — Global Page 3234
Requires corresponding source and sink authority where applicable.
37.36.3 — Compound Operation
Must accurately include the material effects that are permitted.
37.37 — EMERGENCY AND SAFETY-CRITICAL OPERATIONS
A competent local safety controller may possess separately
established authority to enter a defined protective state.
The autonomous agent's general task authority need not govern every
independently authorized safety function.
37.37.1 — Emergency Stop
May be implemented by a suitable independent safety mechanism.
37.37.2 — Emergency Exception
Cannot be fabricated by an agent merely asserting urgency.
37.37.3 — Safety Function Priority
The system must preserve the required independent protective
behavior.
37.37.4 — No Unsafe Withholding
An implementation must not insert a security authorization gateway in
a way that defeats legally or technically required safety functions.
37.38 — HAZARD-RELEVANT RESOURCE VERSIONING
An operation may have been qualified against a particular resource
state.
Before effectuation, the state changes.
The protected sink compares the actual current state with the
qualified expected predicates.
37.38.1 — Conditional Resource Update
May support selected version-dependent database or HTTP mutations.
Das Expires 29 April 2027 [Page 430]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
37.38.2 — Device State
May require actual live local interlocks and sensors.
5.6.3.43. Original Source — Global Page 3235
37.38.3 — Version Equality
Does not automatically prove physical or semantic equivalence.
37.39 — POST-EFFECT OUTCOME CLASSIFICATION
A protected result may be classified as:
NOT_RELEASED: The effect did not cross the controlled frontier.
RELEASED: The operation was released toward the actual effectuation
primitive.
ACCEPTED: The resource accepted the command under its defined
semantics.
COMMITTED: The resource committed the effect.
OBSERVED_COMPLETE: Qualified evidence establishes the applicable
completed consequence.
PARTIAL: Only part of the intended operation occurred.
INDETERMINATE: The actual consequence remains unresolved.
MITIGATED: A separate permitted response reduced selected effects.
COMPENSATED: A distinct authorized operation produced a qualified
offset.
These states are not universally equivalent.
A mitigation receipt does not prove that the original effect never
occurred.
37.40 — POST-EFFECT CONTAINMENT
After an irreversible effect, the controller may:
Prevent additional related operations;
Preserve actual outcome evidence;
Das Expires 29 April 2027 [Page 431]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Revoke remaining effectuation allowances;
Notify competent authorities;
Fence dependent workflows;
Record material resource changes;
5.6.3.44. Original Source — Global Page 3236
And initiate separately authorized mitigation procedures.
37.40.1 — Containment
Can prevent further consequences.
37.40.2 — Reversal
May be unavailable.
37.40.3 — Mitigation
Is a separate operation where consequential.
37.41 — PROTECTED IRREVERSIBLE-EFFECT STATE MACHINE
A representative state machine comprises:
CONSEQUENCE_PROPOSED: An autonomous workload proposes an operation.
CANDIDATE_NON_EFFECTIVE: The actual effect is withheld.
SOURCE_SCOPE_PENDING: Current originating authority is evaluated.
CONSEQUENCE_MODEL_PENDING: Material effects are characterized.
IRREVERSIBILITY_CLASSIFIED: Reversibility assumptions are qualified.
FRONTIER_IDENTIFIED: The controlled actual irreversible boundary is
established.
HAZARD_EVIDENCE_PENDING: Current required state is collected.
HAZARD_QUALIFIED: Mandatory hazard predicates pass.
HAZARD_UNKNOWN: Required operating conditions remain unresolved.
FRONTIER_FENCED: The effect is withheld.
Das Expires 29 April 2027 [Page 432]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
APPROVAL_PENDING: A competent confirmation is required.
INDEPENDENT_VALIDATION_PENDING: Current effect and authority
correspondence are checked.
CONSEQUENCE_FINALITY_PREPARED: Scoped non-bearer enablement exists.
SINK_VERIFICATION_PENDING: The actual receiving sink checks the
operation.
FINALITY_CONSUMED: Protected use state is committed.
5.6.3.45. Original Source — Global Page 3237
EFFECT_RELEASED: The operation crosses the qualified control
boundary.
EFFECT_CONFIRMED: Qualified actual completion evidence exists.
EFFECT_PARTIAL: Part of the consequence occurred.
EFFECT_INDETERMINATE: Completion remains uncertain.
POST_EFFECT_CONTAINMENT: Further related effects are restricted.
MITIGATION_PENDING: A separate corrective Candidate Act exists.
MITIGATION_AUTHORIZED: Competent permission is established.
MITIGATION_EFFECTUATED: A corrective operation is completed.
HISTORICAL_OUTCOME_PRESERVED: Actual completed consequences remain
accurately recorded.
37.42 — COMPLETE COMMON IMPLEMENTATION WORKFLOW
Step 1 — Receive Source Task. Establish original permission for the
consequential operation.
Step 2 — Construct Consequence Authority Envelope. Define the
permitted actual effect.
Step 3 — Construct Candidate Act. Represent the proposed operation.
Step 4 — Maintain Non-Effective State. Prevent real effectuation.
Step 5 — Resolve Actual Resource. Identify the receiving target.
Das Expires 29 April 2027 [Page 433]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Step 6 — Resolve Actual Tool Semantics. Determine material effects.
Step 7 — Classify Reversibility. Establish qualified effect-class
assumptions.
Step 8 — Identify Irreversibility Frontier. Locate the actual
controllable pre-effect boundary.
Step 9 — Verify Enforcement Path. Establish that the protected sink
controls the effect.
Step 10 — Load Hazard Model. Obtain current protected safety and
operating restrictions.
Step 11 — Collect Qualified State Evidence. Obtain current resource,
sensor, or transaction evidence.
Step 12 — Verify Evidence Integrity. Check provenance,
applicability, and quality.
5.6.3.46. Original Source — Global Page 3238
Step 13 — Verify Freshness. Apply required current-state
constraints.
Step 14 — Verify Source Authority. Confirm exact effect permission.
Step 15 — Verify Current Policy. Apply relevant resource and
revocation generations.
Step 16 — Verify Consequence Parameters. Check actual target,
amount, recipient, command, and side effects.
Step 17 — Verify Safety Invariants. Confirm mandatory qualified
hazard predicates.
Step 18 — Verify Effect Budget. Check bounded operation count and
magnitude.
Step 19 — Obtain Competent Approval if Required. Bind approval to
the exact consequence.
Step 20 — Cross-Commit Evidence. Associate collection-time and
current protected observations.
Step 21 — Prepare Consequence-Bound Finality. Constitute scoped non-
bearer enablement.
Das Expires 29 April 2027 [Page 434]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Step 22 — Present Actual Operation to Sink. Submit the pending
effect.
Step 23 — Independently Reconstruct. The sink obtains the actual
resource and operation.
Step 24 — Recheck Mandatory Current Conditions. Apply the supported
frontier-local verification model.
Step 25 — Verify Finality and Consumption. Confirm non-bearer
effectuation eligibility.
Step 26 — Consume Protected Allowance. Record bounded use under the
applicable resource consistency mechanism.
Step 27 — Release Controlled Effect. Cross the actual irreversible
boundary.
Step 28 — Obtain Actual Outcome Evidence. Distinguish dispatch,
acceptance, commitment, and completion.
Step 29 — Handle Unknown Outcome. Preserve indeterminate state and
prevent unauthorized repetition.
Step 30 — Preserve Historical Consequence. Record actual
irreversible effect status.
Step 31 — Fence Unauthorized Successors. Prevent additional
dependent consequences after failure or uncertainty.
Step 32 — Authorize Mitigation Separately. Construct a new Candidate
Act where necessary.
5.6.3.47. Original Source — Global Page 3239
Step 33 — Verify Actual Mitigation. Enforce recovery through its own
applicable receiving sink.
Step 34 — Close Under Qualified Conditions. Preserve truthful
outcome and authority records.
37.43 — REFERENCE ALGORITHM: CONSEQUENCE CLASSIFICATION
FUNCTION CLASSIFY_ACTUAL_CONSEQUENCE( candidate_act,
protected_consequence_registry ): REQUIRE
VERIFY_CANDIDATE_NON_EFFECTIVE() actual_effect =
DERIVE_QUALIFIED_EFFECT_DESCRIPTOR( candidate_act ) REQUIRE
VERIFY_ACTUAL_RESOURCE_IDENTITY() model =
Das Expires 29 April 2027 [Page 435]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
protected_consequence_registry .LOAD_CURRENT_QUALIFIED_EFFECT_MODEL(
actual_effect ) IF NOT VERIFY_MODEL_APPLICABILITY(model): RETURN
CONSEQUENCE_UNKNOWN_HOLD classification =
EVALUATE_REVERSIBILITY_AND_RECOVERY_PROPERTIES( actual_effect, model
) RETURN PROTECTED_CONSEQUENCE_CLASSIFICATION( actual_effect,
classification, model.generation )
Classification does not itself create authority to effectuate.
37.44 — REFERENCE ALGORITHM: FRONTIER IDENTIFICATION
5.6.3.48. Original Source — Global Page 3240
FUNCTION QUALIFY_IRREVERSIBILITY_FRONTIER( candidate_act,
protected_frontier_controller ): effect =
LOAD_QUALIFIED_ACTUAL_EFFECT(candidate_act) frontier =
protected_frontier_controller
.IDENTIFY_EFFECTUATION_PRIMITIVE(effect) REQUIRE
VERIFY_FRONTIER_RESOURCE_IDENTITY() REQUIRE
VERIFY_PRE_FRONTIER_HOLD_CAPABILITY() REQUIRE
VERIFY_MANDATORY_ENFORCEMENT_ROUTE() REQUIRE
VERIFY_REQUIRED_ACTUAL_SINK_CONTROL() IF NOT
ACTUAL_EFFECT_CAN_BE_WITHHELD_BEFORE_FRONTIER(): RETURN
REQUIRED_ENFORCEMENT_NOT_ESTABLISHED RETURN
PROTECTED_FRONTIER_DESCRIPTOR(frontier)
The system must locate a real control point rather than assuming that
a software approval step is always sufficiently early.
37.45 — REFERENCE ALGORITHM: HAZARD-STATE VALIDATION
FUNCTION VALIDATE_CURRENT_HAZARD_STATE( candidate_act,
protected_hazard_validator ): model =
LOAD_CURRENT_QUALIFIED_HAZARD_MODEL( candidate_act ) observations =
protected_hazard_validator
.COLLECT_REQUIRED_ACTUAL_RESOURCE_EVIDENCE() REQUIRE
VERIFY_EVIDENCE_PROVENANCE(observations) REQUIRE
VERIFY_REQUIRED_OBSERVATION_QUALITY() REQUIRE
VERIFY_APPLICABLE_FRESHNESS(observations)
5.6.3.49. Original Source — Global Page 3241
REQUIRE VERIFY_CURRENT_RESOURCE_IDENTITY() REQUIRE
VERIFY_CURRENT_OPERATING_MODE() REQUIRE
VERIFY_REQUIRED_INTERLOCK_STATES() REQUIRE
VERIFY_EFFECT_MAGNITUDE_WITHIN_LIMITS() REQUIRE
VERIFY_ALL_MANDATORY_HAZARD_PREDICATES( model, observations ) RETURN
COMMIT_PROTECTED_HAZARD_WITNESS({ candidate: HASH(candidate_act),
Das Expires 29 April 2027 [Page 436]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
model: model.generation, state: observations })
This procedure requires engineering-defined and actually measurable
predicates.
It does not imply that the validation model covers every possible
physical hazard.
37.46 — REFERENCE ALGORITHM: MATERIAL HAZARD FENCING
FUNCTION FENCE_CHANGED_HAZARD_STATE( pending_candidate,
protected_hazard_controller ): prior = LOAD_CANDIDATE_HAZARD_WITNESS(
pending_candidate ) current = protected_hazard_controller
.GET_CURRENT_RELEVANT_RESOURCE_STATE() impact =
COMPARE_MANDATORY_HAZARD_DEPENDENCIES( prior, current ) IF impact ==
MATERIAL_CHANGE: INVALIDATE_PENDING_CONSEQUENCE_FINALITY() RETURN
REVALIDATION_REQUIRED
5.6.3.50. Original Source — Global Page 3242
IF impact == UNKNOWN: ENFORCE_PRE_FRONTIER_HOLD() RETURN
HAZARD_UNRESOLVED RETURN CURRENT_HAZARD_CORRESPONDENCE_VALID
37.47 — REFERENCE ALGORITHM: CONSEQUENCE-BOUND FINALITY
FUNCTION PREPARE_IRREVERSIBLE_EFFECT_FINALITY( candidate_act,
protected_finality_controller ): REQUIRE
VERIFY_ORIGINAL_SOURCE_AUTHORITY() REQUIRE
VERIFY_CURRENT_RESOURCE_OWNER_AND_IDENTITY() REQUIRE
VERIFY_QUALIFIED_CONSEQUENCE_CLASS() REQUIRE
VERIFY_ACTUAL_EFFECT_WITHIN_AUTHORIZED_ENVELOPE() REQUIRE
VERIFY_CURRENT_HAZARD_MODEL() REQUIRE
VERIFY_MANDATORY_PRE_EFFECT_HAZARD_STATE() REQUIRE
VERIFY_CURRENT_POLICY_AND_REVOCATION() REQUIRE
VERIFY_EFFECT_BUDGET_AVAILABLE() REQUIRE
VERIFY_COMPETENT_APPROVAL_IF_REQUIRED() REQUIRE
VERIFY_ACTUAL_FRONTIER_ENFORCEMENT_PATH() validation =
COMMIT_INDEPENDENT_CURRENT_EFFECT_VALIDATION( candidate_act ) RETURN
protected_finality_controller .PREPARE_SCOPED_NON_BEARER_FINALITY({
candidate: HASH(candidate_act), consequence:
HASH(CURRENT_ACTUAL_EFFECT()), hazard:
HASH(CURRENT_HAZARD_EVIDENCE()), validation: HASH(validation), sink:
ACTUAL_FINALITY_SINK_ID() })
37.48 — REFERENCE ALGORITHM: ACTUAL IRREVERSIBLE FINALITY SINK
Das Expires 29 April 2027 [Page 437]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.6.3.51. Original Source — Global Page 3243
FUNCTION EFFECTUATE_IRREVERSIBLE_OPERATION( candidate_act,
finality_reference, protected_actual_sink ): actual =
protected_actual_sink .RECONSTRUCT_ACTUAL_PENDING_OPERATION() REQUIRE
VERIFY_ACTUAL_RESOURCE_IDENTITY(actual) REQUIRE
VERIFY_CURRENT_ORIGINATING_SOURCE_SCOPE() REQUIRE
VERIFY_ACTUAL_CONSEQUENCE_CORRESPONDENCE( candidate_act, actual )
REQUIRE VERIFY_CURRENT_MANDATORY_HAZARD_STATE() REQUIRE
VERIFY_CURRENT_SAFETY_INTERLOCKS() REQUIRE
VERIFY_CURRENT_POLICY_AND_REVOCATION() REQUIRE
VERIFY_ACTUAL_EFFECT_MAGNITUDE() REQUIRE
VERIFY_CONSEQUENCE_BUDGET_AVAILABLE() REQUIRE
VERIFY_SCOPED_NON_BEARER_FINALITY( finality_reference, actual )
REQUIRE VERIFY_PROTECTED_SINK_LOCAL_CONSUMPTION() result =
protected_actual_sink .COMMIT_CONSUMPTION_AND_CONTROLLED_RELEASE(
actual, finality_reference ) RETURN QUALIFIED_EFFECT_OUTCOME(result)
Where the resource supports only a command dispatch rather than
atomic effectuation, the outcome state must accurately reflect that
limitation.
37.49 — REFERENCE ALGORITHM: IRREVERSIBLE EFFECT RECOVERY
5.6.3.52. Original Source — Global Page 3244
FUNCTION RECOVER_IRREVERSIBLE_EFFECT_OUTCOME( candidate_act,
protected_effect_journal ): prior = protected_effect_journal
.LOAD_CURRENT_LOGICAL_OPERATION_STATE( candidate_act ) REQUIRE
VERIFY_JOURNAL_INTEGRITY() IF
QUALIFIED_EFFECT_ALREADY_CONFIRMED(prior): RETURN
PRESERVE_COMPLETED_CONSEQUENCE IF
QUALIFIED_EFFECT_NOT_RELEASED(prior): RETURN
CURRENT_AUTHORITY_REVALIDATION_REQUIRED observed =
QUERY_QUALIFIED_ACTUAL_RESOURCE_OUTCOME( candidate_act ) IF
VERIFIED_EFFECT_COMPLETED(observed): RETURN
COMMIT_COMPLETED_CONSEQUENCE_EVIDENCE() IF
VERIFIED_EFFECT_NOT_OCCURRED(observed): RETURN
REQUIRE_CURRENT_REVALIDATION_BEFORE_RETRY
ACTIVATE_NON_REPETITION_FENCE() RETURN
PRESERVE_INDETERMINATE_EFFECT_STATE
37.50 — REFERENCE ALGORITHM: POST-EFFECT MITIGATION
Das Expires 29 April 2027 [Page 438]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
FUNCTION AUTHORIZE_POST_EFFECT_MITIGATION( completed_effect,
proposed_mitigation, protected_mitigation_controller ): REQUIRE
VERIFY_PRIOR_ACTUAL_EFFECT_REFERENCE() candidate =
CONSTRUCT_SEPARATE_MITIGATION_CANDIDATE( completed_effect,
proposed_mitigation )
5.6.3.53. Original Source — Global Page 3245
REQUIRE ENFORCE_NON_EFFECTIVE_HOLD(candidate) REQUIRE
VERIFY_COMPETENT_MITIGATION_SOURCE_AUTHORITY() REQUIRE
VERIFY_CURRENT_MITIGATION_RESOURCE_IDENTITY() REQUIRE
VERIFY_MITIGATION_WITHIN_AUTHORIZED_SCOPE() REQUIRE
VERIFY_CURRENT_HAZARD_AND_RESOURCE_STATE() REQUIRE
VERIFY_MITIGATION_NOT_ALREADY_CONSUMED() RETURN
PREPARE_NEW_SCOPED_MITIGATION_FINALITY( candidate )
Mitigation does not retroactively eliminate an earlier actual effect.
37.51 — WORKED EXAMPLE A: KEY DESTRUCTION
An agent is authorized to rotate one cryptographic key.
The agent proposes destroying the old key.
The protected consequence model distinguishes key rotation,
deactivation, and destruction.
The current source grant authorizes rotation but not irreversible
destruction of the only recoverable key copy.
The destructive operation remains non-effective.
Expected demonstrable result: Permission to rotate a cryptographic
key does not automatically authorize destructive key lifecycle
operations.
37.52 — WORKED EXAMPLE B: AUTHORIZED KEY DESTRUCTION
A competent principal expressly authorizes destruction of a specified
key under defined retention and recovery conditions.
The protected key controller verifies actual key identity, source
grant, current lifecycle state, and applicable protected
restrictions.
The actual key-operation sink releases only the specified qualified
destruction operation.
Das Expires 29 April 2027 [Page 439]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Expected demonstrable result: A protected system can permit
legitimate destructive key operations without providing unrestricted
key destruction authority to the autonomous agent.
5.6.3.54. Original Source — Global Page 3246
37.53 — WORKED EXAMPLE C: WRONG STORAGE VOLUME
An agent is authorized to sanitize one specific storage volume.
A resource alias is rebound to another volume.
The actual storage sink verifies current resource identity.
The operation is refused.
Expected demonstrable result: A valid destructive command cannot
automatically operate upon a substituted target.
37.54 — WORKED EXAMPLE D: SECURE ERASE WITH UNQUALIFIED METHOD
An agent proposes a storage erasure operation.
The selected method does not establish the required sanitization
outcome for the actual medium.
The protected controller identifies that the relevant requirement
remains unsatisfied.
It does not mark the resource as successfully sanitized merely
because a delete command returned success.
Expected demonstrable result: Command completion and qualified data
sanitization are distinct technical outcomes.
37.55 — WORKED EXAMPLE E: DATA PUBLICATION
An agent is authorized to save a draft document internally.
The publishing tool attempts to transmit it to an external audience.
The external transmission is a separate potentially irreversible
disclosure effect.
The protected disclosure sink refuses it without appropriate source
authorization.
Das Expires 29 April 2027 [Page 440]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Expected demonstrable result: Internal storage approval cannot
authorize external publication.
5.6.3.55. Original Source — Global Page 3247
37.56 — WORKED EXAMPLE F: RECIPIENT SUBSTITUTION
An agent is authorized to disclose a specific document to Recipient
A.
Immediately before effectuation, the receiving address is changed to
Recipient B.
The actual disclosure sink independently verifies the recipient.
The request is denied.
Expected demonstrable result: A prior approval does not authorize
disclosure to a different recipient.
37.57 — WORKED EXAMPLE G: PUBLICATION RETRACTION
A publication is transmitted to external recipients.
The agent later requests deletion.
The protected journal records the original disclosure and subsequent
removal request separately.
The system does not claim that external copies were necessarily
eliminated.
Expected demonstrable result: Later removal is not falsely
represented as reversal of the historical disclosure.
37.58 — WORKED EXAMPLE H: FINAL FINANCIAL SETTLEMENT
An agent prepares a financial transfer.
The protected controller distinguishes reservation, submission, and
provider-defined final settlement.
The actual financial sink verifies the permitted amount, recipient,
originating account, and current authority before the applicable
finality stage.
Expected demonstrable result: A resource-specific settlement frontier
is governed independently of the agent's generic instruction to pay.
Das Expires 29 April 2027 [Page 441]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
37.59 — WORKED EXAMPLE I: LOST SETTLEMENT ACKNOWLEDGEMENT
A financial effect is submitted and may already have reached
finality.
5.6.3.56. Original Source — Global Page 3248
The agent receives a timeout.
The protected controller preserves an indeterminate outcome and
prevents an automatic second transfer.
Expected demonstrable result: A lost acknowledgement does not create
a fresh financial effect allowance.
37.60 — WORKED EXAMPLE J: PHYSICAL DEVICE COMMAND
An agent proposes a command to a protected test actuator.
The actual device-state controller reports a mandatory interlock as
unsatisfied.
The protected Finality Sink refuses the command despite the agent's
valid tool invocation permission.
Expected demonstrable result: Computational permission cannot
override a mandatory protected physical interlock.
37.61 — WORKED EXAMPLE K: HAZARD STATE CHANGES AFTER APPROVAL
A device command receives initial approval under Hazard Generation 5.
Before effectuation, the operating state materially changes to
Generation 6.
The sink checks the required current conditions.
The earlier finality is withheld pending revalidation.
Expected demonstrable result: A stale hazard assessment cannot
independently authorize a later irreversible effect.
37.62 — WORKED EXAMPLE L: QUALIFIED NONMATERIAL STATE CHANGE
A monitored variable unrelated to the command's mandatory hazard
predicates changes.
Das Expires 29 April 2027 [Page 442]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The protected controller qualifies the state change as nonmaterial
under its supported hazard model.
The Candidate Act may remain eligible for actual current sink
validation.
5.6.3.57. Original Source — Global Page 3249
Expected demonstrable result: The architecture can avoid unnecessary
rejection where a state change is demonstrably irrelevant.
37.63 — WORKED EXAMPLE M: UNKNOWN SENSOR STATE
A mandatory sensor becomes unavailable.
The autonomous agent asserts that the operation is probably safe.
The protected sink lacks the required qualified actual-state
evidence.
The effect remains withheld.
Expected demonstrable result: A model's confidence does not
substitute for a mandatory hazard-state predicate.
37.64 — WORKED EXAMPLE N: SENSOR AUTHENTICITY WITHOUT VALIDITY
A sensor message is cryptographically authentic but its calibration
or applicability requirement is not satisfied.
The protected hazard validator identifies the insufficient evidence.
The command remains non-effective.
Expected demonstrable result: Authenticity of a measurement does not
automatically prove that it is fit for the particular protected
decision.
37.65 — WORKED EXAMPLE O: TOOL SEMANTIC EXPANSION
A tool formerly writes a local record.
A newer implementation additionally triggers a destructive remote
cleanup operation.
The protected consequence controller identifies the new effect class.
The original source grant does not cover the added consequence.
Das Expires 29 April 2027 [Page 443]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Expected demonstrable result: Tool upgrades cannot automatically
inherit authority for newly introduced irreversible side effects.
5.6.3.58. Original Source — Global Page 3250
37.66 — WORKED EXAMPLE P: ONE-TIME HARDWARE PROGRAMMING
An agent is authorized to configure a particular device.
It proposes an operation that permanently changes a one-time
programmable state.
The protected hardware sink requires explicit authority for the
actual one-time effect.
A generic configuration grant is insufficient.
Expected demonstrable result: General device configuration permission
does not imply unrestricted one-time hardware programming authority.
37.67 — WORKED EXAMPLE Q: WRONG PHYSICAL DEVICE
A hardware address is reassigned from Device A to Device B.
The agent retains an approval for a one-time operation on A.
The receiving hardware sink verifies the actual device identity.
The operation against B is refused.
Expected demonstrable result: Address reuse cannot transfer
irreversible-effect authority to another physical device.
37.68 — WORKED EXAMPLE R: IRREVERSIBLE OPERATION BUDGET
A principal authorizes one destructive resource operation.
Two autonomous agents simultaneously attempt the operation.
The protected sink checks a shared qualified consumption state.
Only the permitted number of effects can be committed under the
implemented resource consistency model.
Expected demonstrable result: Concurrent agents cannot automatically
multiply a single-use irreversible-effect authorization.
37.69 — WORKED EXAMPLE S: DISPATCH AND ACTUAL EFFECT
Das Expires 29 April 2027 [Page 444]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A device gateway accepts a command.
5.6.3.59. Original Source — Global Page 3251
The device has not yet confirmed execution.
The journal records command acceptance rather than physical
completion.
Expected demonstrable result: Receipt semantics are preserved instead
of falsely reporting actual irreversible effectuation.
37.70 — WORKED EXAMPLE T: PARTIAL PHYSICAL EFFECT
A protected simulated actuator begins a permitted operation but stops
after partial progress.
The actual outcome is qualified as partial.
The system does not report full completion or automatically execute
an opposite command.
Expected demonstrable result: Partial effects are accurately
represented, and recovery is separately authorized.
37.71 — WORKED EXAMPLE U: HUMAN CONFIRMATION OF WRONG TARGET
A user confirms an operation displayed for Resource A.
The actual receiving sink observes Resource B.
The confirmation cannot satisfy the mismatch.
The operation is refused.
Expected demonstrable result: Human approval does not override actual
target correspondence.
37.72 — WORKED EXAMPLE V: MISLEADING REVERSIBILITY LABEL
A tool description claims its operation can always be undone.
The protected consequence registry identifies that the operation
includes external disclosure.
The system applies the qualified irreversibility model rather than
relying on the tool's assertion.
Das Expires 29 April 2027 [Page 445]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Expected demonstrable result: Untrusted descriptions cannot downgrade
protected consequence classification.
5.6.3.60. Original Source — Global Page 3252
37.73 — WORKED EXAMPLE W: IRREVERSIBLE MULTI-RESOURCE PIVOT
A transaction comprises reversible resource preparation, a financial
settlement, and final notification.
The settlement is classified as a pivot.
The protected controller checks required current preparatory
conditions before permitting settlement finality.
If a prerequisite fails, settlement remains withheld.
Expected demonstrable result: An irreversible pivot cannot proceed
solely because the transaction coordinator has scheduled it.
37.74 — WORKED EXAMPLE X: POST-EFFECT COMPENSATION
An irreversible external transfer occurs.
The agent proposes a compensating transfer.
The compensation is a new Candidate Act.
It requires competent current source authority, exact actual target
verification, and independent receiving-sink finality.
Expected demonstrable result: The original effect approval does not
create unlimited compensation permission.
37.75 — WORKED EXAMPLE Y: EMERGENCY INTERLOCK
A protected device has a separately engineered emergency protective
function.
An autonomous security controller becomes unavailable.
The protective function remains capable of acting according to its
actual safety design.
Expected demonstrable result: Security authorization logic does not
improperly prevent a separately required independent protective
function from operating.
Das Expires 29 April 2027 [Page 446]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
37.76 — WORKED EXAMPLE Z: EFFECT COMPLETED BEFORE REVOCATION
5.6.3.61. Original Source — Global Page 3253
A protected resource operation completes under valid current
authority.
A later revocation arrives.
The journal preserves the historical completed effect.
Future related operations are revalidated under current revocation.
Expected demonstrable result: A later authority change does not
falsely erase an already completed consequence.
37.77 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
1. Misclassified irreversible operation. 2. False reversible-
operation claim. 3. Tool description concealing effects. 4. Missing
consequential side effect. 5. Changed operation magnitude. 6. Wrong
actual resource. 7. Wrong recipient. 8. Cross-tenant target
substitution. 9. Stale source grant. 10. Stale resource authority.
11. Stale hazard model. 12. Stale hazard observation. 13.
Incorrect sensor provenance. 14. Inaccurate sensor measurement. 15.
Unqualified sensor calibration. 16. Missing mandatory interlock. 17.
Interlock status spoofing. 18. Safety controller bypass. 19.
Monitoring-only gate substitution. 20. Premature irreversible
command dispatch. 21. Approval before material state change. 22.
Check/effect race. 23. Hidden downstream API fan-out. 24. Policy
downgrade. 25. Emergency exception abuse. 26. Unqualified human
approval. 27. Confirmation of misleading consequence. 28. Approval
replay. 29. Multi-agent repeated operation. 30. Effect-budget
overrun. 31. Single-use allowance duplication. 32. Snapshot
rollback. 33. Finality reference reuse. 34. Wrong Finality Sink.
35. Direct resource bypass.
5.6.3.62. Original Source — Global Page 3254
36. Unqualified frontier location. 37. Resource commit before
authorization. 38. Destructive operation with wrong key identity.
39. Key deletion mistaken for verified destruction. 40. Key
rotation confused with destruction. 41. Storage sanitization of
wrong medium. 42. Incomplete sanitization falsely reported complete.
43. External disclosure beyond recipient scope. 44. Redirected
disclosure. 45. Publication copied by third parties. 46. Retraction
falsely described as full reversal. 47. Financial authorization
confused with final settlement. 48. Duplicate final settlement. 49.
Das Expires 29 April 2027 [Page 447]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Refund confused with original transfer reversal. 50. Hardware one-
time operation on wrong device. 51. Device address reassignment. 52.
Unsafe physical operating state. 53. Simulation result treated as
actual state. 54. Unknown hazard treated as safe. 55. Invalid
hazard threshold supplied by agent. 56. Unqualified operating-mode
change. 57. Device command after source revocation. 58. Physical
actuation during network partition. 59. Actuation command
acknowledgement loss. 60. Physical partial completion. 61.
Automatic inverse-command misuse. 62. Unauthorized compensation. 63.
Compensation overshoot. 64. Compensation to wrong target. 65.
Replayed mitigation act. 66. False completion receipt. 67. Dispatch
receipt treated as physical completion. 68. Indeterminate command
replay. 69. Post-effect log deletion. 70. Historical irreversible
effect erased from report. 71. Resource migration without identity
verification. 72. Different implementation behavior behind stable
tool name. 73. Hazard evidence from wrong device. 74. Old sensor
sample substituted as current. 75. Safety enforcement path removed
by configuration change. 76. Authority copied to another workload.
77. Unauthorized broad irreversible-effect grant. 78. Unprotected
effect budget. 79. Compromised source authority registry. 80.
Compromised hazard-state source. 81. Compromised resource proxy. 82.
Compromised actual Finality Sink. 83. Compromised consumption
journal. 84. Unsupported atomicity assertion. 85. Unsupported
safety-certification assertion.
5.6.3.63. Original Source — Global Page 3255
86. Unsafe rollback assumption. 87. Indeterminate effect
represented as failed. 88. Unverified compensation represented as
complete recovery. 89. Failure to preserve mandatory current
physical safety functions. 90. Unauthorized actual irreversible
effect despite upstream authenticated approval.
37.78 — PROPOSED FEASIBILITY AND ADVERSARIAL EXPERIMENTS
The following experiments are proposed non-limiting reference
demonstrations and are not represented as previously performed tests.
Test 1 — Source Grant: Create a bounded permission for one
consequential operation.
Test 2 — Consequence Envelope: Identify exact permitted actual
effects.
Test 3 — Candidate Act: Construct a proposed irreversible-effect
operation.
Test 4 — Non-Effective Hold: Verify no actual effect before finality.
Das Expires 29 April 2027 [Page 448]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Test 5 — Qualified Effect Model: Identify the resource and expected
consequences.
Test 6 — Reversibility Classification: Distinguish reversible and
irreversible operations.
Test 7 — Conditional Reversibility: Change conditions affecting
restoration.
Test 8 — Non-Compensable Classification: Mark a resource effect with
no adequate current inverse.
Test 9 — Unknown Class: Withhold an operation whose mandatory
consequences cannot be qualified.
Test 10 — Actual Frontier: Identify the operation's first
controllable irreversible boundary.
Test 11 — Frontier Enforcement: Verify the effect cannot occur
through the normal path before finality.
Test 12 — Bypass Attempt: Try an alternative effectuation route.
Test 13 — Resource Identity: Verify the actual target.
Test 14 — Resource Rebinding: Substitute another actual target.
Test 15 — Source Scope: Attempt an operation beyond the original
grant.
Test 16 — Effect Magnitude: Increase the commanded amount or
quantity.
Test 17 — Recipient Scope: Change the external recipient.
5.6.3.64. Original Source — Global Page 3256
Test 18 — Side Effect: Introduce an undeclared second consequence.
Test 19 — Hazard Model: Load current protected operating constraints.
Test 20 — Hazard Model Change: Advance its generation.
Test 21 — Qualified Observation: Collect relevant actual resource-
state evidence.
Test 22 — Observation Integrity: Verify authenticated measurement
provenance.
Das Expires 29 April 2027 [Page 449]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Test 23 — Observation Accuracy: Test whether a genuine but invalid
sensor reading is accepted.
Test 24 — Freshness: Provide stale mandatory hazard evidence.
Test 25 — Unknown Sensor: Remove a required observation.
Test 26 — Safety Interlock: Make a mandatory interlock unsatisfied.
Test 27 — Advisory-Only Substitute: Replace protected enforcement
with a logging-only component.
Test 28 — Hazard Generation Change: Alter a mandatory operating
condition after approval.
Test 29 — Hazard Fence: Verify stale pending finality is withheld.
Test 30 — Nonmaterial State Change: Alter an irrelevant observation.
Test 31 — Competent Approval: Add transaction-bound confirmation
where required.
Test 32 — Wrong Approval Target: Present valid confirmation at
another resource.
Test 33 — Approval Replay: Attempt repeated irreversible operations.
Test 34 — Current Policy: Change relevant resource authorization.
Test 35 — Revocation: Revoke source authority before effectuation.
Test 36 — Effect Budget: Permit one operation only.
Test 37 — Concurrent Agents: Attempt simultaneous consumption.
Test 38 — Scoped Finality: Prepare consequence-bound non-bearer
enablement.
Test 39 — Wrong Sink: Use the enablement at another resource.
Test 40 — Wrong Effect: Change operation class or parameters.
Test 41 — Actual Sink Reconstruction: Verify true pending
consequence.
Das Expires 29 April 2027 [Page 450]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.6.3.65. Original Source — Global Page 3257
Test 42 — Frontier-Local Current Check: Change actual resource state
immediately before release.
Test 43 — Protected Consumption: Commit bounded authority use.
Test 44 — Finality Replay: Attempt a second effect with the same
allowance.
Test 45 — Resource Transaction: Use atomic local conditional commit
where supported.
Test 46 — Remote API: Demonstrate limitations of upstream-only
transaction assumptions.
Test 47 — Physical Command Simulation: Control a safe simulated
actuator.
Test 48 — Device Identity Swap: Change the simulated receiving
device.
Test 49 — Operating Mode: Change the simulated actuator's relevant
mode.
Test 50 — Interlock Preservation: Verify mandatory interlock control
remains independent.
Test 51 — One-Time Hardware Simulation: Model a write-once state
transition.
Test 52 — Destructive Key Lifecycle: Simulate authorized versus
unauthorized key destruction.
Test 53 — Storage Sanitization: Distinguish command completion from
verified outcome.
Test 54 — External Disclosure: Verify exact content and recipient.
Test 55 — Redirected Disclosure: Redirect to an unauthorized
destination.
Test 56 — Publication Retraction: Show that removal cannot establish
deletion of all external copies.
Test 57 — Financial Settlement: Distinguish preliminary approval from
simulated final resource state.
Das Expires 29 April 2027 [Page 451]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Test 58 — Lost Financial Acknowledgement: Suppress a completion
response.
Test 59 — Indeterminate State: Prevent automatic duplicate finality.
Test 60 — Resource Outcome Query: Reconcile actual completed state.
Test 61 — Partial Physical Completion: Record an incomplete simulated
operation.
Test 62 — Compensation Candidate: Construct an independent mitigating
operation.
Test 63 — Compensation Source Authority: Deny mitigation lacking
competent permission.
5.6.3.66. Original Source — Global Page 3258
Test 64 — Compensation Amount: Prevent excess correction.
Test 65 — Duplicate Mitigation: Reject repeated use.
Test 66 — False Full-Reversal Claim: Compare original and final
resource states.
Test 67 — Consequence Journal: Record original source, hazard,
finality, and actual outcome evidence.
Test 68 — Journal Rollback: Restore an older software snapshot.
Test 69 — Protected Anchor: Verify spent authority remains consumed.
Test 70 — Multi-Resource Pivot: Withhold irreversible successor until
required predecessors complete.
Test 71 — Offline Operation: Distinguish live-required irreversible
effects from expressly offline-bounded ones.
Test 72 — Remove Source Check: Observe whether a technically
permitted but unauthorized effect occurs.
Test 73 — Remove Hazard Validation: Observe whether an unsafe
simulated operation is released.
Test 74 — Remove Actual Sink Reconstruction: Attempt wrong-target
effectuation.
Das Expires 29 April 2027 [Page 452]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Test 75 — Remove Frontier Control: Test whether authorization arrives
too late.
Test 76 — Remove Consequence Binding: Attempt effect magnitude or
recipient substitution.
Test 77 — Remove Consumption: Attempt replay or duplicated effects.
Test 78 — Remove Indeterminate-Outcome Containment: Test duplicate
retry after lost response.
Test 79 — Performance and Coverage: Measure authorization latency,
control-path coverage, and false denials under qualified nonmaterial
state changes.
Test 80 — Integrated Scenario: Combine source consequence authority,
non-effective Candidate Act, actual-effect classification, current
hazard witness, frontier enforcement, scoped non-bearer enablement,
independent actual sink reconstruction, protected consumption,
irreversible effect release, qualified outcome evidence, and
separately authorized mitigation.
37.78.1 — Proposed Measurements
Relevant measurements may include:
5.6.3.67. Original Source — Global Page 3259
Unauthorized completed irreversible effects;
Wrong-target effect acceptance;
Effect magnitude violations;
Unsafe operating-state release;
Stale hazard evidence acceptance;
Mandatory interlock bypass;
Effectuation-route coverage;
Replay or duplicated effect;
Incorrect outcome classification;
Indeterminate retry behavior;
Das Expires 29 April 2027 [Page 453]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Compensation authority violations;
And latency introduced by protected frontier-local checks.
37.78.2 — Comparative Ablation
A suitable comparison may comprise:
Configuration A — Agent Tool Permission: An autonomous workload may
invoke a permitted tool after ordinary authentication.
Configuration B — Conventional Safety or Policy Controls: The
operation is subject to established resource checks, interlocks, or
approval conditions.
Configuration C — Protected Consequence Authorization: The source
grant is bound to the exact consequential effect and current
qualified hazard-state predicates.
Configuration D — Complete Irreversible-Effect Finality: The
operation additionally remains non-effective until independent actual
frontier-local reconstruction, current authority, scoped non-bearer
finality, and protected consumption are established.
37.78.3 — Particularly Useful Hindsight Experiment
A workload receives valid permission to invoke a destructive or
externally consequential tool.
The actual resource changes after initial authorization.
The proposed command is modified to affect another target or a larger
effect magnitude.
5.6.3.68. Original Source — Global Page 3260
The current hazard or safety predicate is also changed.
The experiment determines whether the actual receiving sink releases
the unauthorized consequence.
A second experiment uses the same operation under a legitimate
unchanged resource condition.
The comparison should establish both prevention of materially
unauthorized effects and continued eligibility of qualified
authorized operations.
Das Expires 29 April 2027 [Page 454]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A third experiment causes the actual effect to occur while
suppressing the acknowledgement.
The system must preserve uncertainty and avoid automatic repetition.
37.79 — NON-LIMITING PHOSITA REFERENCE PROTOTYPE
37.79.1 — Minimum Components
A PHOSITA may construct:
One autonomous operation-generating agent;
One protected source-authority database;
One consequence and irreversibility registry;
One simulated hazard-state source;
One protected safety predicate validator;
One resource identity and version controller;
One protected Finality Sink;
One transactional test-resource database;
And one durable actual-effect journal.
37.79.2 — Initial Grant
Authorize one specific irreversible state transition in a simulated
protected resource.
37.79.3 — Consequence Descriptor
Identify the permitted resource, operation, effect magnitude, and
finality boundary.
37.79.4 — Candidate Act
5.6.3.69. Original Source — Global Page 3261
Construct the corresponding operation.
37.79.5 — Non-Effective Hold
Prevent the resource transition.
Das Expires 29 April 2027 [Page 455]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
37.79.6 — Hazard Model
Define a mandatory simulated pre-effect condition.
37.79.7 — Qualified Current State
Obtain the relevant state from an independent protected store.
37.79.8 — Successful Condition
Permit the operation to become eligible.
37.79.9 — Hazard-State Change
Change the mandatory condition after preparation.
37.79.10 — Expected Result
The actual Finality Sink refuses the now-ineligible effect.
37.79.11 — Wrong-Target Variant
Change the resource identity while retaining the Candidate Act.
37.79.12 — Expected Result
The sink refuses target substitution.
37.79.13 — Correct-Target Variant
Restore the permitted resource and qualified current conditions.
37.79.14 — Protected Finality
Prepare scoped non-bearer enablement.
37.79.15 — Actual Effect
The sink verifies and commits the protected test-resource transition.
37.79.16 — Replay Variant
Repeat the same finality reference.
5.6.3.70. Original Source — Global Page 3262
37.79.17 — Expected Result
Das Expires 29 April 2027 [Page 456]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The duplicate is refused.
37.79.18 — Lost-Acknowledgement Variant
Suppress the success response after actual commit.
37.79.19 — Expected Result
The protected outcome journal prevents automatic duplicate
effectuation.
37.79.20 — Mitigation Variant
Attempt a corrective resource operation.
37.79.21 — Expected Result
The mitigation requires its own competent authority and actual sink
verification.
37.80 — OPTIONAL ADVANCED VARIATIONS
37.80.1 — Financial Settlement
A protected payment sink enforces the exact final transfer
conditions.
37.80.2 — Cryptographic Key Destruction
A protected key lifecycle controller verifies actual destructive
operations.
37.80.3 — Storage Sanitization
A storage gateway governs qualified data-erasure effects.
37.80.4 — External Publication
A disclosure gateway verifies actual content and recipient.
37.80.5 — One-Time Hardware Programming
A hardware controller verifies the actual write-once state.
37.80.6 — Industrial Actuation
A suitable protected device controller checks required current safety
conditions.
Das Expires 29 April 2027 [Page 457]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
37.80.7 — Robotics
5.6.3.71. Original Source — Global Page 3263
Actual actuator commands are bound to source authority and current
local safety constraints.
37.80.8 — Telecommunications
Selected consequential network-control commands require protected
current authorization.
37.80.9 — Satellite Control
A qualified actual command sink validates device identity and effect
authority.
37.80.10 — Multi-Resource Transaction
An irreversible pivot is conditioned upon protected predecessor
effects.
37.80.11 — Autonomous Cloud Administration
Permanent resource deletion is distinguished from reversible
configuration changes.
37.80.12 — Credential Release
External secret disclosure is treated as a separate consequential
effect.
37.80.13 — Persistent Memory Destruction
Destructive memory operations are subject to actual resource identity
and authority.
37.80.14 — Multi-Agent Shared Authority
An aggregate irreversible-effect budget is consumed across several
agents.
37.80.15 — Offline Bounded Authority
Selected local irreversible effects may proceed only under expressly
valid offline conditions.
37.80.16 — Emergency Protective Systems
Das Expires 29 April 2027 [Page 458]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Independently engineered safety functions remain protected.
37.80.17 — Hazard Model Updates
Material changes in current safety rules may fence pending finality.
37.80.18 — Sensor Evidence Diversity
Multiple independent observation sources may qualify selected
predicates.
37.80.19 — Resource-Side Attestation
A protected resource may provide qualified evidence of its software
or controller state.
5.6.3.72. Original Source — Global Page 3264
37.80.20 — Separate Post-Effect Mitigation
Recovery operations may receive distinct source authority and actual
effectuation controls.
37.81 — PROPOSED INVENTIVE-STEP CHARACTERIZATION
37.81.1 — Established Foundations
Existing engineering techniques include:
Hazard analysis;
Functional safety;
Safety interlocks;
Two-person authorization;
Resource-specific permissions;
Cryptographic key management;
Transactional commit;
Single-use authorization;
Hardware command controls;
Remote attestation;
Das Expires 29 April 2027 [Page 459]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
And recovery procedures.
These foundations should be acknowledged.
37.81.2 — Candidate Objective Technical Problem
How to ensure that an autonomously generated consequential operation
does not cross an actual irreversible or practically non-compensable
resource boundary unless its real target and effect remain within
originating source authority, its mandatory current hazard conditions
are qualified, and its operation-specific bounded finality is
independently verified and consumed by the receiving resource.
37.81.3 — Proposed Technical Solution
A protected controller constructs a Consequence Candidate Act.
The Candidate Act remains non-effective.
5.6.3.73. Original Source — Global Page 3265
An authorized consequence descriptor identifies the actual permitted
resource and effect.
The protected classifier determines relevant reversibility and
recovery assumptions.
The system identifies the actual irreversible effectuation frontier.
A protected hazard controller establishes current applicable
mandatory state.
Material state changes fence pending finality.
Independent validation establishes current source, consequence,
resource, and hazard correspondence.
A scoped non-bearer finality enablement binds the operation to the
qualified actual consequence.
The receiving resource sink reconstructs and conditionally releases
the actual operation after protected consumption.
Completed and indeterminate outcomes are preserved without assuming
reversibility.
37.81.4 — Not Merely a Safety Interlock
Das Expires 29 April 2027 [Page 460]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An interlock may enforce a defined physical condition.
The proposed combination separately checks original source
permission, the exact proposed consequence, the current actual
resource, and scoped execution-finality authority.
37.81.5 — Not Merely an Access-Control Decision
Access control may allow a user or agent to invoke a particular
command.
The proposed system requires correspondence with the actual
irreversible effect and mandatory current hazard state at the
effectuation boundary.
37.81.6 — Not Merely Human Approval
Human confirmation may establish one required consent or competence
condition.
It does not automatically verify the actual resource state or prevent
changed-target effects.
37.81.7 — Not Merely a Single-Use Token
A single-use token can limit selected repeated access.
The proposed combination binds the token's finality purpose to the
actual consequence, hazard conditions, target, and receiving sink.
37.81.8 — Not Merely a Simulation
5.6.3.74. Original Source — Global Page 3266
Simulation can support qualified planning.
The proposed system maintains mandatory actual resource validation
immediately before or through the relevant effectuation boundary.
37.81.9 — Not Merely Compensation
A compensation architecture may attempt corrective actions after a
failure.
The proposed primary mechanism is the prevention of unauthorized
release before the irreversible frontier, with recovery treated as a
distinct subsequent authority problem.
Das Expires 29 April 2027 [Page 461]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
37.81.10 — Candidate Narrow Inventive Kernel
A protected autonomous irreversible-effect execution-finality system
in which a source-authorized consequential operation is represented
as a Candidate Act maintained non-effective, an independently
protected controller identifies the actual authorized consequence,
relevant irreversibility frontier, and mandatory current hazard and
resource predicates, a material change in those predicates fences
pending authority, a scoped non-bearer enablement is constituted only
for the qualified actual consequence, and an independently enforcing
receiving-resource Finality Sink reconstructs the pending effect and
conditionally permits crossing the irreversible frontier following
current source, hazard, target, and protected consumption
verification.
37.81.11 — Frontier-Local Verification Kernel
A narrower candidate may require that actual irreversible release be
conditional upon current protected authorization and hazard-state
predicates enforced at or through the resource's actual effectuation
primitive.
37.81.12 — Consequence-Binding Kernel
Another candidate may require source authority to bind actual effect
magnitude, target, and consequence class rather than merely a tool
method or generic operation category.
37.81.13 — Hazard-Generation Fencing Kernel
Another candidate may require material current operating-state
changes to invalidate pending irreversible-effect finality.
37.81.14 — Non-Compensable Effect Kernel
Another candidate may classify a covered operation as inadequately
compensable and impose mandatory pre-frontier authorization and state
verification before actual effectuation.
37.81.15 — Outcome Non-Repetition Kernel
Another candidate may require protected preservation of uncertain
irreversible outcome state to prevent an unauthorized retry after an
acknowledgement failure.
Das Expires 29 April 2027 [Page 462]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.6.3.75. Original Source — Global Page 3267
37.81.16 — Consequence Budget Kernel
Another candidate may bind aggregate irreversible-effect counts or
magnitudes to original source authority and enforce resource-side
protected consumption.
37.81.17 — Anti-Hindsight Technical Analysis
The closest prior art may already disclose:
A safety-related controller;
An access-control system;
A protected hardware interface;
A human approval gate;
A transaction authorization scheme;
Or a combination thereof.
A valid inventive-step analysis should not assume that irreversible-
operation gating is independently new.
It should identify whether the relevant prior art already teaches the
complete claimed relationship among:
1. A consequential Candidate Act held in a Non-Effective State; 2.
A protected source-authorized actual consequence envelope; 3.
Qualified operation-specific irreversibility classification; 4.
Identification of the actual controllable irreversible frontier; 5.
Independent current hazard-state qualification; 6. Material hazard-
generation invalidation; 7. Correspondence of actual target and
effect magnitude with original authority; 8. Scoped non-bearer
finality for the actual consequence; 9. Mandatory actual receiving-
sink reconstruction; 10. Protected source, hazard, and resource
validation at the effectuation boundary; 11. Bounded sink-local
consumption; 12. Correct outcome classification after irreversible
release; 13. Indeterminate-outcome non-repetition; 14. Separate
authority for mitigation and recovery.
37.81.18 — Technical Interaction Versus Mere Aggregation
The proposed technical interaction has several causally related
properties.
Das Expires 29 April 2027 [Page 463]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The source-authorized consequence envelope defines which real effect
is permitted.
The non-effective Candidate Act prevents the computational workload
from crossing the actual frontier prematurely.
5.6.3.76. Original Source — Global Page 3268
The hazard-state controller determines whether mandatory present
operating conditions permit the effect.
The hazard-generation fence prevents obsolete approval evidence from
authorizing release after a material state change.
The scoped non-bearer enablement binds the current qualified effect
to a designated protected sink.
The actual Finality Sink reconstructs the pending operation and
enforces the required current predicates.
The protected consumption and outcome controller prevents replay and
preserves historical effect status.
The proposed synergistic technical result is therefore the prevention
of unauthorized real irreversible effects through a sequence of
independently protected authority and actual resource-state checks,
not the mere juxtaposition of known safety and access-control
technologies.
37.81.19 — Strong Comparative Evidence
A useful experimental comparison would evaluate:
A conventional agent with a permitted destructive tool;
A system adding ordinary authorization and a safety interlock;
And a system also enforcing consequence-specific non-effective
holding, current hazard-generation correspondence, and independent
sink-local finality.
The tests should include:
Changed actual targets;
Changed effect magnitudes;
Stale hazard evidence;
Das Expires 29 April 2027 [Page 464]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Wrong receiving devices;
Replayed authorization;
Lost command acknowledgements;
And recovery operations lacking competent authority.
The decisive measurement is the actual resource effect.
37.81.20 — Important Patentability and Safety Qualification
5.6.3.77. Original Source — Global Page 3269
The proposed features are candidate technical claim limitations.
Their novelty and inventive step depend upon actual prior-art
analysis.
A security mechanism preventing unauthorized commands is not
automatically equivalent to a certified functional-safety mechanism.
The invention does not guarantee that every hazard can be modeled or
that every physical consequence can be predicted.
Claims should not promise universal prevention of accidents or exact
reversal of irreversible effects.
The strongest technically defensible scope is the set of actual
resource-effectuation paths and mandatory authority and hazard
predicates that the claimed protected system genuinely observes and
enforces.
37.82 — INDUSTRIAL APPLICABILITY
37.82.1 — Autonomous AI Infrastructure
Irreversible agent actions may be withheld until actual consequence
authority is established.
37.82.2 — Cryptographic Key Management
Destructive key operations may require protected key-specific
finality.
37.82.3 — Data Storage and Sanitization
Das Expires 29 April 2027 [Page 465]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Actual irreversible or practically irreversible data operations may
be controlled.
37.82.4 — External Data Disclosure
Protected information release may be bound to exact authorized
recipients.
37.82.5 — Financial Settlement
Final transfer effects may be separately verified at the receiving
financial boundary.
37.82.6 — Industrial Automation
Safety-relevant resource effects may require current protected
interlock and authority conditions.
37.82.7 — Robotics
Actual physical commands may be governed by qualified local device
conditions.
5.6.3.78. Original Source — Global Page 3270
37.82.8 — Telecommunications
Irreversible network configuration or lifecycle transitions may be
protected.
37.82.9 — Satellite Systems
High-consequence device operations may be qualified before protected
command release.
37.82.10 — Cloud Administration
Permanent resource deletion may be distinguished from reversible
configuration changes.
37.82.11 — Confidential Computing
Protected execution components may enforce destructive operation
conditions.
37.82.12 — Hardware Manufacturing
Das Expires 29 April 2027 [Page 466]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
One-time programmable state changes may be subject to source-specific
finality.
37.82.13 — Enterprise Data Governance
Publication and permanent record operations may be controlled.
37.82.14 — Software Deployment
Irreversible or high-impact deployment pivots may depend on current
validation.
37.82.15 — Supply Chain Operations
Final transaction or inventory effects may be protected.
37.82.16 — Energy Systems
Qualified device-control operations may be subject to independent
actual resource-state checks.
37.82.17 — Transportation Systems
Relevant high-consequence control interfaces may enforce current
authority and safety predicates.
37.82.18 — Secure Device Lifecycle
Key destruction and irreversible configuration operations may receive
protected finality.
37.82.19 — Multi-Agent Workflows
Several computational agents may share a bounded irreversible-effect
budget without duplicating authority.
5.6.3.79. Original Source — Global Page 3271
37.82.20 — Future Autonomous Critical Systems
Source-authorized computational proposals may remain subordinate to
independently enforced actual consequence and hazard boundaries.
37.83 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
37.83.1 — Candidate Independent System Claim
A system comprising:
Das Expires 29 April 2027 [Page 467]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A protected source-authority controller configured to establish a
permitted actual consequential effect;
A Candidate Act controller configured to represent an autonomous
proposed operation and maintain the operation in a Non-Effective
State;
A protected consequence controller configured to identify material
actual effects and corresponding irreversibility properties;
A protected frontier controller configured to identify a controllable
effectuation boundary associated with an irreversible or practically
non-compensable consequence;
A protected hazard-state validator configured to obtain qualified
current operating-state evidence and identify mandatory effectuation
predicates;
A protected invalidation controller configured to fence pending
finality following a material change to a required hazard or resource
condition;
A scoped non-bearer finality controller configured to bind
authorization to the actual effect, target, and relevant current
evidence;
And an independently enforcing actual Finality Sink configured to
reconstruct the pending operation, verify source authority and
current mandatory hazard predicates, conditionally consume protected
effectuation authority, and release only the qualified actual
consequence.
37.83.2 — Candidate Independent Method Claim
A method comprising:
Receiving a source-authorized consequential task;
Constructing a protected consequence descriptor;
Representing the proposed effect as a Candidate Act;
Holding the Candidate Act non-effective;
5.6.3.80. Original Source — Global Page 3272
Classifying the applicable reversibility or non-compensability
properties;
Das Expires 29 April 2027 [Page 468]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Identifying the actual controlled irreversible frontier;
Obtaining qualified current resource and hazard evidence;
Verifying mandatory source, target, resource, hazard, and effect
magnitude predicates;
Invalidating prior effectuation eligibility following material
current-state changes;
Constituting scoped non-bearer finality;
Independently reconstructing the pending operation at the actual
receiving-resource boundary;
Consuming protected authority under the applicable resource
consistency model;
And releasing the irreversible effect only upon successful protected
current verification.
37.83.3 — Candidate Independent Consequence-Binding Claim
A protected autonomous effectuation system configured to bind a
proposed operation to an authorized actual consequence descriptor,
detect a material mismatch between the authorized and receiving-
resource effect, and withhold non-bearer finality until the actual
effect corresponds to the current original source grant.
37.83.4 — Candidate Independent Hazard-Finality Claim
A protected execution system configured to bind pending irreversible-
effect finality to qualified current resource hazard-state evidence
and to prevent release when a mandatory hazard-state predicate
materially changes or becomes unresolved before actual effectuation.
37.83.5 — Candidate Independent Irreversible-Outcome Claim
A system configured to preserve completed, partial, and indeterminate
irreversible-effect states, prevent unauthorized repeat effectuation
following uncertain outcomes, and require separately authorized
actual resource finality for a proposed post-effect mitigation or
compensation.
37.84 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
Das Expires 29 April 2027 [Page 469]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
1. The workload comprises an autonomous AI agent. 2. The operation
is proposed through a tool. 3. The operation targets an external
resource. 4. The operation targets a physical device. 5. The
operation targets cryptographic key material. 6. The operation
targets a persistent storage medium. 7. The operation comprises a
financial effect.
5.6.3.81. Original Source — Global Page 3273
8. The operation comprises external data disclosure. 9. The
originating source grant identifies a qualified consequence envelope.
10. The envelope identifies the actual resource target. 11. The
envelope identifies permitted recipients. 12. The envelope
identifies material effect parameters. 13. The envelope identifies
permitted effect magnitude. 14. The envelope identifies a maximum
effect count. 15. The envelope identifies required hazard
predicates. 16. The envelope identifies a designated actual Finality
Sink. 17. The proposed operation is represented as a Candidate Act.
18. The Candidate Act is maintained non-effective. 19. A protected
controller classifies reversibility. 20. The classification
distinguishes actual rollback from compensation. 21. A practically
irreversible effect may be classified separately. 22. A non-
compensable effect may be classified separately. 23. An unknown
mandatory reversibility condition causes further qualification. 24.
A protected effect model identifies material downstream consequences.
25. An untrusted tool description does not independently define
authorized effect
semantics. 26. The system identifies an actual irreversible
effectuation frontier. 27. The frontier comprises a resource commit
interface. 28. The frontier comprises a protected disclosure
interface. 29. The frontier comprises a key lifecycle controller.
30. The frontier comprises a device command controller. 31. The
frontier comprises a protected hardware state transition. 32. The
protected controller verifies actual control over the frontier. 33.
An alternate effectuation route may be rejected if it bypasses
mandatory enforcement. 34. A protected hazard model defines
mandatory operating constraints. 35. The model has a qualified
protected generation. 36. Current resource-state evidence may be
independently collected. 37. The evidence may include an
authenticated sensor observation. 38. The evidence may include a
current database resource version. 39. The evidence may include a
current device operating mode. 40. The evidence may include a
protected interlock state. 41. Evidence provenance is verified. 42.
Evidence freshness is verified. 43. Evidence applicability is
verified. 44. Authentic evidence with insufficient measurement
quality may be rejected. 45. Missing mandatory hazard evidence
causes non-effectuation. 46. A material hazard-model change may
Das Expires 29 April 2027 [Page 470]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
invalidate pending finality. 47. A material actual operating-state
change may invalidate pending finality. 48. A qualified nonmaterial
change need not automatically invalidate unrelated authority. 49. A
protected controller verifies current source authority. 50. A
protected controller verifies current resource ownership. 51. A
protected controller verifies current policy or revocation. 52. A
protected controller verifies actual effect magnitude. 53. A
protected controller verifies actual receiving target. 54. A
protected controller verifies actual recipient. 55. A protected
controller verifies required resource dependencies. 56. A human
approval may be required for selected effect classes.
5.6.3.82. Original Source — Global Page 3274
57. Human approval may be transaction-bound. 58. Human approval is
independently distinguished from current hazard-state verification.
59. The approval may be omitted where current competent source
policy permits
autonomous operation. 60. A scoped non-bearer finality reference may
be prepared. 61. The reference may identify an exact actual
resource. 62. The reference may identify an exact effect class. 63.
The reference may identify material effect parameters. 64. The
reference may identify applicable hazard model generation. 65. The
reference may identify a current hazard-state commitment. 66. The
reference may identify a designated actual sink. 67. The reference
may be restricted to one protected consequence allowance. 68. The
actual Finality Sink independently reconstructs the pending
operation. 69. The sink verifies actual target identity. 70. The
sink verifies actual material effect parameters. 71. The sink
verifies current source authority. 72. The sink verifies mandatory
hazard predicates. 73. The sink verifies current safety interlocks
where required. 74. The sink verifies current revocation or policy.
75. The sink verifies consequence-bound non-bearer finality. 76.
The sink verifies protected consumption. 77. A receiving
transactional resource may coordinate finality with resource-local
commit. 78. A physical sink may require actual device-side command
authorization. 79. A remote resource may use qualified dispatch and
outcome reconciliation. 80. A journal distinguishes command dispatch
from actual completion. 81. An indeterminate irreversible outcome is
preserved. 82. A lost acknowledgement does not automatically
authorize repetition. 83. A protected effect budget may prevent
aggregate overuse. 84. Concurrent agents may share protected bounded
consumption state. 85. A snapshot restore does not resurrect
consumed effect authority. 86. A key destruction operation may be
distinguished from key rotation. 87. A storage erasure operation may
be checked against actual medium identity. 88. External disclosure
Das Expires 29 April 2027 [Page 471]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
may be bound to exact content and recipient. 89. Financial
settlement may be distinguished from preliminary transaction states.
90. A one-time hardware operation may be bound to current device
identity. 91. A post-effect mitigation may be represented as a
separate Candidate Act. 92. The mitigation requires competent
current source authority. 93. The mitigation requires actual
receiving-resource finality. 94. Completed historical effects remain
recorded despite later corrective operations. 95. Existing safety
controllers, protected key-management devices, authenticated sensors,
conditional resource APIs, hardware interlocks, and durable journals
may be employed as non-limiting implementation substrates.
37.85 — UNIVERSAL COMBINATION, SUBCOMBINATION, AND NON-LIMITING
PHOSITA CLAUSE
5.6.3.83. Original Source — Global Page 3275
The disclosed technical mechanisms may be implemented individually
where sufficient or in any technically compatible combination.
An implementation may use protected source authorization.
Another may use typed consequence descriptors.
Another may use actual resource identity.
Another may use hardware safety interlocks.
Another may use transactional database commits.
Another may use conditional resource updates.
Another may use protected key lifecycle controllers.
Another may use secure data-sanitization interfaces.
Another may use protected data-disclosure gateways.
Another may use protected payment settlement gateways.
Another may use cryptographically authenticated sensor evidence.
Another may use multiple independent observations.
Another may use hardware command accounting.
Another may use qualified hazard-state generations.
Das Expires 29 April 2027 [Page 472]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Another may use competent human approval.
Another may use fully autonomous source-authorized operation.
Another may use scoped non-bearer finality.
Another may use resource-side single-use consumption.
Another may use protected physical-command control.
Another may use independently authorized mitigation operations.
Another may use protected recovery and outcome reconciliation.
The invention does not require that every operation be irreversible.
The invention does not require that irreversible operations always
involve physical hardware.
The invention does not require that every operation involve human
approval.
5.6.3.84. Original Source — Global Page 3276
The invention does not presume that a valid safety interlock
establishes original task authorization.
The invention does not presume that original task authorization
establishes physical safety.
The invention does not require a particular hazard-analysis method.
The invention does not assert that a cryptographic signature proves
actual hazard absence.
The invention does not assert that a simulation proves safe
operation.
The invention does not presume that a software-only gateway can
control a hardware primitive reachable by an independent bypass
route.
The invention does not require that all effects be compensable.
The invention does not presume that a compensating operation restores
the original historical state.
Das Expires 29 April 2027 [Page 473]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The invention does not require that irreversible effects be retried
automatically following a timeout.
The invention does not require a universal definition of financial
settlement finality across all payment systems.
The invention does not presume that deleting one key reference
destroys every copy of the key.
The invention does not presume that local deletion of a published
document removes independently retained external copies.
The invention does not replace competent safety engineering,
technical qualification, testing, or applicable certification
requirements.
The invention does not require every optional safeguard to appear in
every independent claim.
The descriptions, diagrams, algorithms, mathematical expressions,
worked examples, and proposed experiments are illustrative, optional,
and non-limiting technical aids for a person having ordinary skill in
the art.
Technically compatible limitations disclosed across multiple
embodiments may be combined where adequately supported, without
requiring that unrelated optional embodiments be implemented
together.
37.86 — FINAL TECHNICAL CHARACTERIZATION
5.6.3.85. Original Source — Global Page 3277
The present Embodiment 37 discloses a protected autonomous
irreversible-effect execution-finality architecture.
An originating principal establishes bounded authority for a
particular actual consequence.
An autonomous computational workload proposes an operation.
The operation is represented as a Candidate Act and maintained in a
Non-Effective State.
A protected controller identifies the actual target and permitted
consequence.
Das Expires 29 April 2027 [Page 474]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The system determines the relevant reversibility, compensation, and
irreversibility properties.
The actual effectuation frontier is identified.
Current qualified hazard and resource evidence is obtained.
Mandatory current source, target, policy, safety, magnitude, and
effect-budget conditions are evaluated.
A material change invalidates incompatible pending finality.
Where required, competent approval is bound to the actual
consequence.
A scoped non-bearer finality enablement is prepared for the qualified
operation.
The actual receiving-resource Finality Sink independently
reconstructs the pending target and effect.
The sink verifies current authority, relevant hazard predicates,
protected finality, and consumption before releasing the effect
across the controlled irreversible frontier.
Qualified actual outcome evidence is retained.
Indeterminate effects are not automatically repeated.
A later mitigating operation requires its own competent authorization
and actual receiving-resource finality.
The architecture does not presume that irreversible consequences can
be undone.
The principal candidate inventive technical concept of Embodiment 37
is a protected autonomous consequence-to-effectuation-finality system
in which a source-authorized irreversible operation remains non-
effective until the actual effectuation frontier is identified,
current hazard and resource predicates are independently qualified,
material changes fence pending authority, and a scoped non-bearer
enablement is verified and consumed by the actual receiving Finality
Sink before a specifically bounded irreversible effect is released.
5.6.3.86. Original Source — Global Page 3278
37.87 — SHORT PHOSITA IMPLEMENTATION USING EXISTING TECHNOLOGIES
Das Expires 29 April 2027 [Page 475]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A person having ordinary skill in the art may implement the disclosed
mechanisms using existing technologies as optional, non-exclusive
substrates.
Existing technology Optional technical role Functional-safety
engineering and qualified safety controllers
Define and enforce applicable actual physical safety requirements
ISA/IEC 62443 industrial-control cybersecurity practices
Support protected industrial resource control and security
architecture NIST SP 800-82 operational technology guidance
Inform design of secure cyber-physical enforcement environments NIST
SP 800-57 key-management guidance
Inform qualification of cryptographic key lifecycle operations NIST
SP 800-88 Rev. 2 media-sanitization guidance
Inform qualified destructive data-sanitization controls Hardware
security modules and protected key stores
Enforce selected irreversible key lifecycle primitives
Transactional SQL databases Maintain protected consequence allowances
and resource-local commit state
HTTP conditional requests and ETags Support selected version-
dependent actual resource mutations Authenticated sensor and
interlock interfaces Supply qualified current resource-state evidence
Protected device command gateways Enforce relevant actual hardware
command release Cryptographic signatures and deterministic encoding
Authenticate source, hazard, and effect evidence
Protected API and egress gateways Enforce selected actual external
disclosure or destructive operations
Remote attestation protocols Contribute qualified device or
enforcement-component state evidence
Durable effect journals Record attempted, completed, partial, and
indeterminate actual consequences
37.87.1 — Practical Common Implementation Workflow
First, define the actual irreversible or non-compensable consequence
and its competent originating authorization.
Das Expires 29 April 2027 [Page 476]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Second, construct a Consequence Candidate Act identifying the real
resource, recipient, command, magnitude, and effect class.
Third, maintain the operation in a Non-Effective State under a
protected enforcement component.
5.6.3.87. Original Source — Global Page 3279
Fourth, associate the operation with a qualified consequence model
and actual effectuation frontier.
Fifth, determine which current hazard, resource, policy, and source-
authority predicates are mandatory.
Sixth, use actual device, storage, database, financial, or disclosure
resource interfaces to obtain qualified current state.
Seventh, ensure that the protected finality component actually
controls the relevant pre-effectuation boundary.
Eighth, check current source authorization, actual resource identity,
material effect parameters, hazard conditions, and bounded effect
budget.
Ninth, invalidate earlier finality if mandatory current conditions
materially change.
Tenth, obtain exact consequence-specific competent approval where
required.
Eleventh, construct scoped non-bearer finality bound to current
validation and the actual receiving sink.
Twelfth, require the sink to independently reconstruct the pending
operation and verify its actual effect against the authorized
consequence envelope.
Thirteenth, perform protected bounded consumption and controlled
resource effectuation according to the actual sink's supported
consistency model.
Fourteenth, record actual outcome evidence without confusing
acceptance, dispatch, commitment, and physical completion.
Fifteenth, preserve indeterminate or completed irreversible effects
through failure and restart.
Das Expires 29 April 2027 [Page 477]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Sixteenth, construct any proposed mitigation or compensation as a
separately authorized Candidate Act.
37.87.2 — Minimal Reference Data Structures
CONSEQUENCE_AUTHORITY ( source_grant_id, authorized_resource_id,
permitted_effect_class, permitted_effect_parameters,
maximum_effect_count, mandatory_hazard_model, required_sink_id )
CONSEQUENCE_CANDIDATE (
5.6.3.88. Original Source — Global Page 3280
candidate_id, source_grant_id, actual_resource_id,
actual_operation_digest, irreversibility_class, frontier_reference,
non_effective_state ) HAZARD_WITNESS ( candidate_id,
hazard_model_generation, resource_state_generation,
observation_reference, required_interlock_state,
observation_qualification ) IRREVERSIBLE_FINALITY ( candidate_id,
actual_resource_id, actual_effect_digest, current_hazard_commitment,
authorized_effect_budget, finality_sink_id, consumption_state )
ACTUAL_CONSEQUENCE_JOURNAL ( logical_operation_id, candidate_id,
actual_resource_id, actual_effect_digest, dispatch_status,
actual_completion_status, protected_journal_commitment )
These structures are non-limiting.
Field values do not independently establish safe or authorized
effectuation; the required protections must be implemented at the
actual receiving-resource boundary.
37.87.3 — Decisive Prototype for Hindsight Analysis
A useful prototype may employ a simulated irreversible resource
rather than a hazardous physical system.
The prototype contains:
A test resource with a protected one-way state transition;
5.6.3.89. Original Source — Global Page 3281
A protected original source grant allowing one specified transition;
A versioned hazard-condition record;
A separate Candidate Act controller;
A protected Finality Sink;
Das Expires 29 April 2027 [Page 478]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
And a transactional authority-consumption journal.
The source principal permits one state change when a specified
current resource predicate is satisfied.
The autonomous agent constructs the operation.
The operation remains non-effective.
The protected validator qualifies the current resource state.
The hazard predicate is then changed after initial authorization.
The agent attempts to release the original operation.
The actual sink refuses the stale effect.
A second experiment restores valid conditions but redirects the
actual operation to another resource.
The sink refuses the changed target.
A third experiment executes the correctly authorized one-time
operation.
The protected journal records actual effectuation and consumption.
A replay is refused.
A fourth experiment suppresses the completion acknowledgement and
verifies that the controller preserves the completed or indeterminate
state rather than automatically repeating the effect.
Finally, a purported rollback is proposed.
The system requires separate competent authority for the proposed
corrective operation and does not claim that the earlier irreversible
state never occurred.
37.87.4 — Important Technical Cautions
An irreversible frontier must correspond to the actual effect-
producing resource operation.
A protected gateway cannot claim non-bypassable coverage of paths it
does not control.
Das Expires 29 April 2027 [Page 479]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.6.3.90. Original Source — Global Page 3282
A current source grant cannot substitute for required functional-
safety engineering.
A valid hazard-state signature does not prove that the sensor or
underlying model is accurate.
An old hazard observation may become invalid before effectuation.
A local database transaction does not make a remote irreversible
physical operation atomic.
A command acknowledgement does not necessarily prove physical
completion.
A key-deletion command does not necessarily destroy every backup or
duplicate.
A data retraction cannot guarantee deletion of all external copies.
A compensating financial transaction does not erase the historical
original transfer.
The actual resource consistency and enforcement model determines the
scope of the achievable finality guarantee.
37.87.5 — Non-Limiting Common Reference Combination
Original consequence authority → Consequence Candidate Act → Non-
Effective State → actual target and effect-semantic qualification →
irreversibility classification → actual frontier identification →
protected current hazard-state evidence → mandatory source, resource,
safety, and effect-budget verification → material hazard-change
fencing → independent current validation → consequence-bound non-
bearer finality → actual receiving Finality Sink → independent
operation and hazard reconstruction → protected bounded consumption →
controlled irreversible effectuation → actual outcome qualification →
separately authorized post-effect mitigation where applicable.
The proposed distinguishing technical relationship is the mandatory
coupling of actual irreversible consequence authority, enforceable
pre-frontier non-effectuation, independent current hazard and
resource validation, scoped non-bearer release, and protected sink-
local consumption, so that the autonomous workload cannot turn a
valid-looking command or earlier approval into an unqualified
irreversible real-world effect.
Das Expires 29 April 2027 [Page 480]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
END OF EMBODIMENT 37 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 38
PROTECTED AUTONOMOUS EVIDENCE INTEGRITY AND ATTESTATION CONTINUITY
WITH COMPROMISED-OBSERVER CONTAINMENT, CROSS-DOMAIN WITNESS
QUALIFICATION, AND INDEPENDENT FINALITY-SINK EVIDENCE RECONSTRUCTION
38.0 — COMPLETE TECHNICAL TITLE
Systems, Methods, and Apparatus for Governing Autonomous
Consequential Operations Using Protected Collection-Time Evidence,
Qualified Observer Provenance
5.7. Embodiment 38 — Independent Evidence Witnesses, Measurement
Competence and Cross-Domain Proof
Original technical source: TECHNICAL SPECIFICATION -3102-3567.pdf,
global pages 3283–3377 inclusive. Principal source treatment within
Part 8. Related mechanisms may also be referenced by Parts 3, 4 and
6.
5.7.1. Protected Component Architecture
[Source authority / Candidate Act]
|
[Evidence collectors / observer competence]
|
[Witness trust and dependency graph]
|
[Attestation appraisal and freshness]
|
[Independent execution-time observation]
|
[Cross-committed validation evidence]
|
[Actual FS reconstruction and consume]
|
[Qualified effect or fail-closed]
Figure 13: Embodiment 38 — Independent Evidence Witnesses,
Measurement Competence and Cross-Domain Proof — architecture
5.7.2. Actual-Effect and Failure Decision Flowchart
Das Expires 29 April 2027 [Page 481]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
[Collect remote/witness evidence]
|
<Evidence authentic and fresh?> -- NO --> [REFUSE]
| YES
<Witness competent and independent?> -- NO --> [REFUSE]
| YES
<Actual observation semantically aligned?> -- NO --> [REFUSE]
| YES
<Current actual FS effect matches CA?> -- NO --> [REFUSE]
| YES
[Consume scoped finality / controlled effect]
Figure 14: Embodiment 38 — Independent Evidence Witnesses,
Measurement Competence and Cross-Domain Proof — effectuation
decisions
5.7.3. Original Technical Disclosure — Page-Indexed Sections
5.7.3.1. Original Source — Global Page 3283
and Competence, Attested Measurement and Appraisal Continuity,
Independent Execution-Time Witness Corroboration, Observation-Channel
Separation, Cross-Domain Evidence-Semantics Correspondence, Protected
Evidence-Generation and Freshness Fencing, Compromised-Observer
Dependency Containment, Cross-Committed Validation Receipts, Scoped
Non-Bearer Finality Enablement, Independent Finality-Sink
Reconstruction of Actual Pending Effects, Sink-Local Protected
Consumption, and Evidence-Based Recovery Without Unverified Authority
Propagation
38.0.1 — General Technical Description
The present Embodiment 38 discloses systems, methods, apparatus,
protected computing components, autonomous operation controllers,
qualified evidence collectors, protected observation domains,
measurement provenance registries, attestation appraisal controllers,
independent witness validators, cross-domain evidence exchange
components, compromise-containment controllers, protected validation
receipt generators, scoped non-bearer finality controllers, and
independently enforcing actual Finality Sinks configured to prevent
autonomously generated consequential operations from becoming
effective on the basis of fabricated, stale, incomplete, compromised,
misinterpreted, or materially mismatched evidence.
An autonomous computational workload may receive information from:
An AI model;
Das Expires 29 April 2027 [Page 482]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A tool response;
An application programming interface;
A sensor;
An operating-system monitor;
A file or database observer;
A network monitor;
A protected execution environment;
A cryptographic attestation service;
A resource owner;
An authenticated human confirmation interface;
A remote authority service;
A distributed monitoring system;
A service registry;
5.7.3.2. Original Source — Global Page 3284
Or another evidence-producing entity.
The workload may use that information to prepare a consequential
operation.
For example, an autonomous agent may be instructed to perform a
financial transaction only when a particular source account,
recipient, amount, and authorization state are valid.
A robotic controller may be permitted to actuate a device only when
qualified current operating conditions are satisfied.
A cloud automation controller may modify a resource only when the
current owner, policy, and resource version correspond to the
originating task.
A data disclosure agent may transmit information only when the actual
recipient, content classification, and permission are verified.
Das Expires 29 April 2027 [Page 483]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A credential controller may activate a secret only when the actual
receiving service and resource conditions are qualified.
The computational workload may obtain evidence that appears to
establish the required conditions.
However, the evidence-producing component may be compromised.
A sensor may be authentic but inaccurate.
A software observer may be correctly identified while reporting an
earlier resource state.
A runtime monitor may observe a proposed operation but not the actual
operation dispatched through a privileged backend.
An agent may provide an authentic tool response that is outside the
required authority domain.
A protected observer may be attested as running an approved software
measurement while its observation path fails to cover a changed
downstream interface.
A remote service may provide a signed statement whose meaning differs
from the interpretation applied by the local validator.
A policy engine may receive an evidence value with incorrect units,
resource scope, tenant identity, or measurement generation.
Two independent-looking evidence records may originate from the same
compromised underlying source.
A cryptographic signature may validate while the actual measured
condition is false.
A protected measurement register may contain a valid software
measurement without establishing the correctness of every runtime
decision.
5.7.3.3. Original Source — Global Page 3285
An evidence log may be append-only while containing inaccurate
original observations.
An authenticated receipt may prove only that a command was
dispatched, while the downstream validator treats it as proof that
the resource effect completed.
Das Expires 29 April 2027 [Page 484]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A resource may change after collection-time observation.
An attacker may replay an earlier qualified witness or substitute
evidence from another Candidate Act.
An evidence verifier may become compromised after issuing an earlier
attestation result.
A resource may be migrated to another receiving service while the
originating workload retains evidence about the predecessor.
A trusted component may reboot into a different software generation.
A previously permitted evidence source may lose authority or have its
key revoked.
A monitoring system may experience a network partition and be unable
to obtain fresh state.
The present embodiment recognizes that the existence of authentic
evidence does not itself establish authority to cause a consequential
effect.
The system therefore distinguishes:
The identity of the evidence producer;
Its competence to observe the relevant property;
The protected state of the observation mechanism;
The property actually measured;
The observation's resource, time, generation, and operation scope;
The interpretation applied to that observation;
The qualified degree of independence between observation channels;
The current authority to rely upon the evidence;
And the separate question of whether the actual pending resource
effect is authorized at its Finality Sink.
An originating source-authority controller establishes the intended
consequential operation.
The autonomous workload constructs a Candidate Act.
Das Expires 29 April 2027 [Page 485]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The Candidate Act remains in a Non-Effective State.
5.7.3.4. Original Source — Global Page 3286
A protected evidence-policy controller identifies the mandatory
observations needed for the particular operation.
Those observations may include source authorization, actual resource
identity, transaction parameters, tool behavior, current policy,
revocation state, physical conditions, credential audience, or other
relevant predicates.
Each required observation is associated with a qualified evidence-
source role and competence requirement.
Collection-time evidence is acquired and protected.
A qualified attestation mechanism may establish selected properties
of the observer or its execution environment.
Independent appraisal may assess whether those properties satisfy the
applicable evidence-source policy.
The protected controller does not automatically infer the truth or
completeness of the observed real-world facts from successful
attestation.
A separate execution-time validation instance obtains current
relevant evidence through a qualified observation path.
Where required, the observation path is sufficiently independent from
the proposing agent and collection-time witness to satisfy the
relevant fault or compromise model.
The protected controller compares collection-time and execution-time
evidence.
It evaluates:
Identity continuity;
Observation generation;
Resource correspondence;
Operation parameters;
Relevant freshness;
Das Expires 29 April 2027 [Page 486]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Measurement semantics;
Witness competence;
Current source and resource authority;
And evidence-source revocation.
5.7.3.5. Original Source — Global Page 3287
Where evidence is contradictory, incomplete, stale, compromised, or
outside its asserted competence, the affected Candidate Act is
withheld or revalidated.
A protected observer-compromise controller identifies which pending
operations depend upon affected evidence.
It fences those operations without necessarily suspending unrelated
operations whose mandatory evidence remains qualified.
Where sufficient independent evidence is available, the controller
may reconstitute operation eligibility under the applicable protected
policy.
However, a replacement witness does not create new originating source
authorization.
Upon successful qualification, the system generates protected
validation evidence that binds the Candidate Act, collection-time
witness, independent execution-time witness, actual resource and
operation descriptors, relevant attestation results, and current
evidence-policy generation.
A scoped non-bearer finality enablement may then be constituted for
the qualified actual operation.
The actual Finality Sink obtains or reconstructs the pending
consequential effect through its protected resource-facing
observation mechanism.
The sink independently verifies correspondence between:
The original Candidate Act;
The qualified evidence;
The current operation;
Das Expires 29 April 2027 [Page 487]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The actual target;
The protected finality enablement;
And sink-local protected authority state.
Where the pending operation materially differs from the operation
qualified upstream, the sink refuses effectuation.
Where the finality evidence is invalid, stale, revoked, mismatched,
replayed, or unsupported under the required trust model, the covered
operation remains non-effective.
The invention therefore provides a protected causal relationship
among evidence qualification, observer trust, actual effect
verification, and finality, rather than treating evidence collection
or remote attestation as an independently sufficient permission to
act.
38.0.2 — Fundamental Technical Principle
5.7.3.6. Original Source — Global Page 3288
Evidence that an operation was permitted is not equivalent to
evidence that the operation actually presented for effectuation is
permitted.
Further:
A valid signature proves the selected signed data was authenticated
under the applicable cryptographic assumptions; it does not prove
that every underlying factual assertion is true.
A successful platform attestation does not automatically prove
correctness of the platform's current application-level decision.
An authenticated observer is not necessarily competent to measure
every resource property.
A fresh observation of the wrong resource is not the required
evidence.
A measurement of the correct resource under the wrong units or
semantic interpretation may be unsafe to rely upon.
Two signatures do not necessarily establish two independent
observations.
Das Expires 29 April 2027 [Page 488]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A historical evidence receipt does not automatically establish
current authorization.
A protected log can preserve false observations faithfully.
An absence of recorded malicious activity does not prove that no
malicious activity occurred.
A compromised evidence source does not automatically imply that every
independent evidence source is compromised.
An attestation result does not itself confer source authority for a
consequential operation.
And the actual Finality Sink must not mistake a qualified evidence
record for unrestricted authority to execute a different pending
effect.
38.0.3 — Principal Candidate Inventive Combination
A representative implementation comprises:
(a) an originating source-authorized Candidate Act;
(b) an enforceable Non-Effective State;
(c) a protected operation-specific evidence-requirement descriptor;
(d) qualified collection-time evidence;
(e) protected observer identity, competence, and measurement-scope
evidence;
(f) optional attestation appraisal of specified observer properties;
5.7.3.7. Original Source — Global Page 3289
(g) an independent execution-time evidence collector;
(h) qualified independence between selected observation channels;
(i) protected evidence-semantic and resource-identity correspondence;
(j) evidence-generation and freshness fencing;
(k) selective containment of operations depending upon compromised or
unqualified witnesses;
Das Expires 29 April 2027 [Page 489]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
(l) protected cross-commitment of collection-time and execution-time
validation evidence;
(m) scoped non-bearer finality enablement;
(n) independent actual Finality-Sink reconstruction of the pending
operation;
(o) sink-local verification of evidence, operation, authority, and
consumption;
(p) protected recording and reconciliation of evidence-source changes
without reviving consumed effectuation authority.
38.0.4 — Candidate Technical Distinction
The embodiment does not claim as individually new:
Cryptographic signatures;
Public-key infrastructure;
Remote attestation;
Measurement registers;
Trusted execution environments;
Protected logging;
Merkle trees;
Transparency logs;
Multiple sensors;
Quorum validation;
Challenge-response protocols;
5.7.3.8. Original Source — Global Page 3290
Freshness nonces;
Policy evaluation;
Audit records;
Das Expires 29 April 2027 [Page 490]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Or evidence provenance.
The proposed distinguishing relationship concerns the binding of
qualified evidence to an actual consequential Candidate Act,
independent execution-time witness validation, operation-specific
compromise containment, and separate actual receiving-resource
Finality-Sink reconstruction and non-bearer finality consumption.
38.0.5 — Relationship to Earlier Embodiments
The present embodiment may incorporate previously disclosed
mechanisms for:
Protected collection-time evidence;
Independent execution-time validation;
Cross-committed validation records;
Candidate Act non-effectuation;
Original source authority;
Resource identity continuity;
Hazard-state verification;
Scoped non-bearer capabilities;
Actual Finality-Sink reconstruction;
Policy and revocation fencing;
Hardware-backed protection;
Offline authority;
And multi-resource transaction finality.
Its focused subject is whether the evidence and attestation relied
upon for a particular actual effect remains sufficiently authentic,
applicable, competent, independent, and current in the presence of
observer compromise or cross-domain evidence ambiguity.
38.0.6 — Non-Limiting Reference Architecture
ORIGINATING PRINCIPAL
Das Expires 29 April 2027 [Page 491]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.7.3.9. Original Source — Global Page 3291
| v SOURCE-AUTHORIZED ACT | v CANDIDATE ACT | v NON-EFFECTIVE HOLD |
v EVIDENCE REQUIREMENTS | +----------+-----------+ | | v v
COLLECTION-TIME OBSERVER IDENTITY OBSERVATION AND COMPETENCE | |
+----------+-----------+ | v PROTECTED EVIDENCE STATE | v EXECUTION-
TIME WITNESS | v INDEPENDENCE / FRESHNESS / SEMANTIC QUALIFICATION |
+--------+--------+ | | v v QUALIFIED INVALID / COMPROMISED | | | v |
DEPENDENCY FENCE | | | REQUALIFICATION | | +--------+--------+ | v
CROSS-COMMITTED EVIDENCE | v NON-BEARER FINALITY | v ACTUAL FINALITY
SINK
5.7.3.10. Original Source — Global Page 3292
| v RECONSTRUCT PENDING EFFECT | v VERIFY SOURCE + TARGET + OPERATION
+ EVIDENCE | v SINK-LOCAL CONSUMPTION | v CONTROLLED REAL EFFECT
All diagrams are illustrative and non-limiting technical aids to
assist a person having ordinary skill in the art.
38.1 — TECHNICAL FIELD
The present invention relates to autonomous execution security,
trusted measurement systems, remote attestation, evidence provenance,
qualified sensor fusion, independent evidence appraisal, distributed
authorization, cross-domain data integrity, protected execution
monitoring, compromised-observer containment, and actual receiving-
resource execution-finality enforcement.
More particularly, the invention concerns preventing evidence-
producing components from independently creating or extending
consequential authority beyond that granted by the originating
principal and verified at the actual operation boundary.
38.2 — SPECIFIC TECHNICAL PROBLEMS
38.2.1 — Evidence Fabrication
An agent or compromised tool may fabricate a record claiming that a
mandatory authorization or resource condition has been satisfied.
38.2.2 — Authentic False Evidence
A legitimately identified observer may report incorrect factual
information.
38.2.3 — Attestation Overinterpretation
Das Expires 29 April 2027 [Page 492]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A valid platform attestation result may be treated as proof of every
runtime behavior.
38.2.4 — Observer Competence Mismatch
5.7.3.11. Original Source — Global Page 3293
A witness may measure network connection state but be relied upon to
prove database commit completion.
38.2.5 — Evidence-Source Confusion
A record may originate from a monitoring service different from the
one authorized to attest to the relevant property.
38.2.6 — Operation Substitution
Evidence collected for one proposed effect may be used to authorize
another.
38.2.7 — Resource Substitution
Evidence about Resource A may be reused for Resource B.
38.2.8 — Tenant Substitution
Evidence generated within one resource tenant may be applied to
another tenant.
38.2.9 — Stale Observation
An earlier correct observation may no longer describe current state.
38.2.10 — Delayed Evidence Delivery
A witness may produce authentic evidence that arrives after a
material resource change.
38.2.11 — Replay
An attacker may submit an earlier signed observation again.
38.2.12 — Evidence Epoch Rollback
A controller may restore an older evidence generation.
38.2.13 — Observer Software Change
Das Expires 29 April 2027 [Page 493]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An observer implementation may change after initial qualification.
38.2.14 — Observer Key Rotation
A witness may use a new signing key or credential generation.
38.2.15 — Revoked Observer
A previously accepted witness may no longer be authorized.
38.2.16 — Compromised Observer
5.7.3.12. Original Source — Global Page 3294
An evidence-producing component may become malicious.
38.2.17 — Compromised Evidence Verifier
A component responsible for evaluating evidence may be compromised.
38.2.18 — Correlated Witness Failure
Two apparently separate witnesses may depend upon the same
compromised underlying data source.
38.2.19 — Colluding Witnesses
Multiple witnesses may cooperate to produce misleading evidence.
38.2.20 — Misconfigured Quorum
A majority vote may be accepted without adequate independence
assumptions.
38.2.21 — Measurement Coverage Gap
A monitor may observe one interface while the actual operation uses
another.
38.2.22 — Alternate Effectuation Path
A resource effect may bypass the monitored path.
38.2.23 — Incomplete Evidence
A record may omit a mandatory actual operation parameter.
38.2.24 — Data Redaction Ambiguity
Das Expires 29 April 2027 [Page 494]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Privacy-preserving redaction may remove data necessary to establish
the relevant predicate.
38.2.25 — Semantic Unit Mismatch
A measured quantity may be interpreted using incorrect units.
38.2.26 — Identifier Namespace Mismatch
The same textual resource identifier may refer to different objects
in different domains.
38.2.27 — Canonicalization Ambiguity
Different validators may serialize or parse the same evidence
differently.
38.2.28 — Schema-Version Change
Evidence fields may change meaning between schema versions.
5.7.3.13. Original Source — Global Page 3295
38.2.29 — Truncated Evidence
A witness may provide only a partial record.
38.2.30 — Unqualified Evidence Aggregation
An aggregator may combine several records without preserving their
individual provenance.
38.2.31 — Evidence Laundering
A downstream service may treat a summary or score as equivalent to
original qualified observations.
38.2.32 — Log Inclusion Confusion
Proof that evidence was logged may be treated as proof that the
evidence is true.
38.2.33 — Attestation Result Replay
An earlier verifier result may be used outside its permitted validity
or operation scope.
38.2.34 — Reference-Value Downgrade
Das Expires 29 April 2027 [Page 495]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An older, more permissive attestation policy may be restored.
38.2.35 — Appraisal Policy Change
An earlier result may no longer satisfy current relying-party
requirements.
38.2.36 — Cross-Domain Trust Confusion
A verifier accepted by one administrative domain may not be
authorized to speak for another.
38.2.37 — Credential Audience Confusion
Evidence credentials may be valid for a different relying party.
38.2.38 — Collection/Execution Gap
The actual pending operation may change after initial evidence
collection.
38.2.39 — Misleading Tool Output
A tool may claim success or authorization without protected
receiving-resource evidence.
38.2.40 — Sensor Calibration Error
A signed measurement may fall outside the sensor's qualified accuracy
range.
38.2.41 — Physical Sensor Manipulation
5.7.3.14. Original Source — Global Page 3296
A genuine device may report manipulated environmental data.
38.2.42 — Physical Process Drift
The observed resource condition may materially change before
actuation.
38.2.43 — Conflicting Witnesses
Two qualified observers may report contradictory values.
38.2.44 — Missing Independent Channel
Das Expires 29 April 2027 [Page 496]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The required execution-time observation may depend exclusively upon
the agent's own proposed parameters.
38.2.45 — Evidence-Verification Exhaustion
An attacker may submit excessively complex evidence to exhaust
protected verification resources.
38.2.46 — Evidence Flooding
A compromised observer may generate many irrelevant records.
38.2.47 — Unavailable Attestation Service
A required appraisal service may be unreachable.
38.2.48 — Offline Attestation Staleness
An offline sink may retain valid but outdated platform evidence.
38.2.49 — Observer-Compromise Propagation
A single compromised witness may affect multiple pending operations.
38.2.50 — Overbroad Compromise Response
A system may unnecessarily invalidate unrelated operations without
examining their evidence dependencies.
38.2.51 — Incomplete Compromise Containment
A system may continue accepting evidence indirectly derived from the
compromised observer.
38.2.52 — Evidence-Source Resurrection
A restored software snapshot may reenable a revoked witness.
5.7.3.15. Original Source — Global Page 3297
38.2.53 — Sink Evidence Mismatch
The receiving resource may observe a different actual operation from
the one described in the validation evidence.
38.2.54 — Finality Receipt Reuse
Das Expires 29 April 2027 [Page 497]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A legitimate validation record may be applied to several real
operations.
38.2.55 — False Completion Evidence
A dispatch receipt may be misrepresented as proof of actual resource
completion.
38.2.56 — Circular Evidence Dependency
One witness may be considered trustworthy because another witness
relies upon it.
38.2.57 — Unverifiable Cross-Domain Claims
A relying party may receive evidence whose source semantics it cannot
independently establish.
38.2.58 — Source Authority Substitution
A valid observer result may be used as though it were an original
source grant.
38.2.59 — Protected State Inconsistency
Evidence verification and finality consumption may refer to different
state generations.
38.2.60 — Technical Objective
How to ensure that an autonomous consequential operation relies only
upon evidence that is sufficiently qualified for its exact source,
target, operation, freshness, semantics, competence, and compromise
assumptions, while ensuring that qualified evidence cannot itself
become unrestricted authority and that the actual receiving resource
independently verifies the pending effect before protected finality.
38.3 — ESTABLISHED TECHNICAL FOUNDATIONS
38.3.1 — Cryptographic Signatures
Existing digital-signature mechanisms may authenticate selected
messages and their apparent issuers.
They do not establish the factual accuracy of all signed assertions.
38.3.2 — Remote Attestation
Das Expires 29 April 2027 [Page 498]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.7.3.16. Original Source — Global Page 3298
Existing remote-attestation architectures distinguish attesting
entities, evidence, appraisal, reference values, endorsements,
verifiers, and relying-party decisions.
The presence of an attestation result does not eliminate the relying
party's obligation to evaluate whether the result suffices for its
particular decision.
38.3.3 — Protected Measurement
Existing protected computing systems may record software or platform
measurements.
Those measurements do not automatically prove every application's
runtime behavior or every physical sensor's accuracy.
38.3.4 — Transparency and Append-Only Logs
Existing authenticated append-only logs can provide evidence of
inclusion or consistency.
They do not guarantee that submitted factual statements are true or
that all relevant events were submitted.
38.3.5 — Multiple Independent Sensors
Existing monitoring architectures may compare observations from
multiple sources.
The benefits depend on the sources' actual independence and failure
assumptions.
38.3.6 — Challenge-Response
Existing protocols may use fresh nonces or challenges to reduce
selected replay risks.
Fresh challenges do not independently establish that the observed
resource or actual operation is correct.
38.3.7 — Protected Authorization
Existing policy engines may evaluate authenticated facts before
permitting access.
Das Expires 29 April 2027 [Page 499]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The present embodiment further connects relevant evidence
qualifications to independent actual operation reconstruction and
finality.
38.4 — PRINCIPAL TECHNICAL COMPONENTS
A representative implementation comprises:
1. Protected Originating Source-Authority Controller. 2. Candidate
Act and Non-Effective State Controller. 3. Operation-Specific
Evidence-Requirement Registry. 4. Collection-Time Evidence
Controller.
5.7.3.17. Original Source — Global Page 3299
5. Qualified Observer Identity Registry. 6. Observer Competence and
Measurement-Scope Registry. 7. Attestation Evidence Appraisal
Controller. 8. Independent Execution-Time Evidence Collector. 9.
Observation-Channel Independence Evaluator. 10. Evidence Freshness
and Generation Controller. 11. Cross-Domain Evidence-Semantics
Translator. 12. Protected Resource Identity and Namespace Mapper.
13. Witness Contradiction Detector. 14. Observer-Compromise
Qualification Controller. 15. Evidence-Dependency Containment
Controller. 16. Protected Evidence Reconstruction Controller. 17.
Cross-Committed Validation Evidence Generator. 18. Scoped Non-Bearer
Finality Controller. 19. Actual Resource Finality Sink. 20. Sink-
Local Protected Consumption Controller. 21. Protected Evidence and
Outcome Journal. 22. Evidence-Source Recovery and Requalification
Controller.
38.5 — TECHNICAL DEFINITIONS
38.5.1 — Protected Evidence Requirement
A Protected Evidence Requirement, or PER-38, means an operation-
specific mandatory condition identifying the evidence needed before a
consequential Candidate Act becomes eligible for finality.
38.5.2 — Qualified Evidence Source
A Qualified Evidence Source means an entity authorized and
technically competent under the applicable policy to provide selected
factual observations.
38.5.3 — Observer Identity
Observer Identity means a qualified reference identifying an
evidence-producing component.
Das Expires 29 April 2027 [Page 500]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
38.5.4 — Observer Competence Envelope
An Observer Competence Envelope, or OCE-38, means a protected
specification of the properties, resources, observation paths,
accuracy conditions, and semantic claims a particular observer may
validly support.
38.5.5 — Collection-Time Evidence
Collection-Time Evidence, or CTE-38, means qualified evidence
captured when a Candidate Act or relevant source-authorized condition
is initially established.
38.5.6 — Execution-Time Evidence
5.7.3.18. Original Source — Global Page 3300
Execution-Time Evidence, or ETE-38, means qualified evidence obtained
concerning the current operation and relevant resource state near the
actual effectuation boundary.
38.5.7 — Protected Observation Domain
A Protected Observation Domain means a computing or resource-control
domain providing specified integrity and access-isolation properties
for evidence collection.
38.5.8 — Observation-Channel Independence
Observation-Channel Independence means a qualified degree of
separation between evidence paths under a defined fault or compromise
model.
38.5.9 — Actual Operation Witness
An Actual Operation Witness means evidence derived from the operation
actually presented to a protected resource boundary.
38.5.10 — Observer Attestation Evidence
Observer Attestation Evidence means evidence about selected
properties of the observer's current or measured platform state.
38.5.11 — Attestation Appraisal Result
An Attestation Appraisal Result means a qualified conclusion
concerning attestation evidence under a specified appraisal policy.
Das Expires 29 April 2027 [Page 501]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
38.5.12 — Evidence Competence
Evidence Competence means the qualified applicability of a witness to
establish a specified factual predicate.
38.5.13 — Evidence Scope
Evidence Scope means the resource, principal, operation, time,
measurement, and interpretation domain within which an evidence item
may be relied upon.
38.5.14 — Evidence Freshness Window
An Evidence Freshness Window means an operation-specific constraint
on the temporal or generation validity of an observation.
38.5.15 — Evidence Generation
An Evidence Generation, or EG-38, means a protected revision or
sequence reference associated with an observation or validation
state.
38.5.16 — Observer Generation
5.7.3.19. Original Source — Global Page 3301
An Observer Generation means a protected version of a witness's
relevant identity, key, software, configuration, or competence state.
38.5.17 — Evidence Lineage
Evidence Lineage means a protected record of the observations and
transformations from which an evidence item was derived.
38.5.18 — Cross-Domain Evidence Mapping
Cross-Domain Evidence Mapping means a qualified correspondence
between evidence semantics used by different administrative or
technical domains.
38.5.19 — Evidence Semantic Profile
An Evidence Semantic Profile means a defined interpretation of
evidence fields, units, resource namespaces, completeness rules, and
observation meanings.
38.5.20 — Qualified Witness Set
Das Expires 29 April 2027 [Page 502]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A Qualified Witness Set means the specific sources satisfying an
operation's required observation and independence conditions.
38.5.21 — Correlated Witness Set
A Correlated Witness Set means witnesses sharing one or more
underlying failure or compromise dependencies.
38.5.22 — Evidence Contradiction
Evidence Contradiction means a material inconsistency among
observations required to satisfy an operation-specific predicate.
38.5.23 — Evidence Equivalence
Evidence Equivalence means verified semantic correspondence of
selected observations under a qualified comparison rule.
38.5.24 — Observer Compromise State
Observer Compromise State means a protected classification indicating
that an evidence source no longer satisfies one or more mandatory
trust conditions.
38.5.25 — Evidence Dependency Set
An Evidence Dependency Set, or EDS-38, means the qualified set of
witness, verifier, measurement, and semantic references required by a
Candidate Act.
38.5.26 — Compromise Containment Fence
5.7.3.20. Original Source — Global Page 3302
A Compromise Containment Fence, or CCF-38, means a protected
restriction preventing operations dependent upon affected evidence
from reaching finality.
38.5.27 — Selective Evidence Invalidation
Selective Evidence Invalidation means invalidating affected evidence
and dependent operations without automatically invalidating unrelated
independent evidence.
38.5.28 — Evidence Requalification
Das Expires 29 April 2027 [Page 503]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Evidence Requalification means obtaining new current evidence
sufficient to replace an invalid or compromised observation under the
applicable protected policy.
38.5.29 — Witness Replacement Authority
Witness Replacement Authority means the competent policy governing
substitution of one evidence source with another.
38.5.30 — Protected Evidence Receipt
A Protected Evidence Receipt means authenticated evidence that
selected observations have been qualified for a specified Candidate
Act and validation generation.
38.5.31 — Cross-Committed Validation Evidence
Cross-Committed Validation Evidence, or CCVE-38, means protected
binding among collection-time, execution-time, observer-
qualification, operation, and resource evidence.
38.5.32 — Attestation Continuity
Attestation Continuity means qualified correspondence of relevant
observer identity, state, competence, and appraisal requirements
across the period in which an operation relies upon the observer.
38.5.33 — Attestation Policy Generation
An Attestation Policy Generation means a protected version of the
current appraisal requirements.
38.5.34 — Reference-Value Generation
A Reference-Value Generation means a protected version of expected
measurement information used during attestation appraisal.
38.5.35 — Evidence Revocation Generation
An Evidence Revocation Generation means the protected state
identifying current invalid or withdrawn observer credentials or
evidence eligibility.
38.5.36 — Resource-Side Evidence Reconstruction
Das Expires 29 April 2027 [Page 504]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.7.3.21. Original Source — Global Page 3303
Resource-Side Evidence Reconstruction means independent obtaining or
verification of the actual pending resource operation at the
receiving Finality Sink.
38.5.37 — Evidence-to-Effect Correspondence
Evidence-to-Effect Correspondence means verification that the
qualified evidence describes the material actual effect presented for
execution.
38.5.38 — Evidence-Only Approval
Evidence-Only Approval means a determination that evidence appears
adequate, without independently establishing actual effectuation
authority.
38.5.39 — Effectuation Authority
Effectuation Authority means qualified permission for a specified
actual consequence under current source, resource, evidence, and
sink-local conditions.
38.5.40 — Evidence Verification Budget
An Evidence Verification Budget means a protected limit on evidence
size, complexity, depth, processing cost, or verification attempts.
38.5.41 — Evidence Nonresurrection
Evidence Nonresurrection means preventing revoked, obsolete, or
invalid evidence from becoming acceptable merely through replay,
rollback, or recovery.
38.5.42 — Observer Recovery Epoch
An Observer Recovery Epoch means a protected revision identifying the
requalification of a previously unavailable or compromised evidence
source.
38.5.43 — Qualified Absence Evidence
Qualified Absence Evidence means evidence supporting a specified
negative predicate under an established observation completeness
model.
38.5.44 — Evidence Coverage Boundary
Das Expires 29 April 2027 [Page 505]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An Evidence Coverage Boundary means the set of resource events,
operations, and paths actually observable by a witness.
38.5.45 — Observation Completeness Predicate
An Observation Completeness Predicate means a qualified condition
establishing whether an evidence source had sufficient coverage to
support the asserted conclusion.
38.5.46 — Protected Evidence Canonicalization
5.7.3.22. Original Source — Global Page 3304
Protected Evidence Canonicalization means producing an authenticated
representation under a specified evidence schema and interpretation
profile.
38.5.47 — Non-Bearer Evidence-Bound Finality
Non-Bearer Evidence-Bound Finality means scoped effectuation
enablement whose validity depends upon qualified evidence and the
actual sink's independent verification rather than unrestricted
possession by the autonomous agent.
38.5.48 — Sink-Local Evidence State
Sink-Local Evidence State means protected current data retained by
the actual Finality Sink concerning evidence qualification, operation
generations, revocation, and consumption.
38.5.49 — Qualified Actual-Effect Receipt
A Qualified Actual-Effect Receipt means evidence describing the
actual receiving resource's effectuation outcome under its defined
semantics.
38.5.50 — Protected Evidence-to-Finality Continuity
Protected Evidence-to-Finality Continuity means maintaining the
required relationship among original source authority, qualified
observation evidence, current actual operation, and protected
receiving-resource effectuation.
38.6 — FIVE SEPARATE EVIDENCE ASSURANCE QUESTIONS
For each evidence item, the protected validator may determine:
Question 1 — Who produced the evidence?
Das Expires 29 April 2027 [Page 506]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The producer must have a qualified identity where required.
Question 2 — What could that producer actually observe?
The observer's competence and coverage must support the required
predicate.
Question 3 — What resource and operation did the evidence concern?
The evidence must correspond to the authorized Candidate Act and
actual resource.
Question 4 — Is the evidence still applicable?
Freshness, generation, policy, revocation, and resource-state
conditions must pass.
Question 5 — Does the actual Finality Sink observe the same relevant
operation?
5.7.3.23. Original Source — Global Page 3305
The receiving resource independently checks the pending effect rather
than relying exclusively upon upstream evidence.
Successful answers to the first four questions do not automatically
satisfy the fifth.
38.7 — OPERATION-SPECIFIC EVIDENCE REQUIREMENT DESCRIPTOR
A representative protected record comprises:
PROTECTED_EVIDENCE_REQUIREMENT = { candidate_act_identifier,
original_source_grant_reference, actual_resource_identity,
actual_effect_class, required_factual_predicates,
acceptable_observer_competence_classes,
required_observation_channels, required_channel_independence,
required_freshness_or_generation_bounds,
accepted_attestation_appraisal_policy,
required_evidence_semantic_profile, required_resource_version,
current_evidence_revocation_generation,
designated_actual_finality_sink, protected_requirement_authentication
}
38.7.1 — Requirement Authority
The autonomous agent does not independently lower mandatory evidence
requirements.
Das Expires 29 April 2027 [Page 507]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
38.7.2 — Effect Dependence
Different operations may require different evidence.
38.7.3 — Actual Resource
The evidence requirement is associated with the real resource or
authorized resource class.
38.7.4 — No Universal Attestation Requirement
Some operations may be adequately protected by resource-local
transactional evidence without remote platform attestation.
38.8 — QUALIFIED OBSERVER IDENTITY
5.7.3.24. Original Source — Global Page 3306
A protected registry may associate evidence sources with:
Identity credentials;
Measurement capabilities;
Permitted observation paths;
Resource namespaces;
Attestation requirements;
Applicable appraisal policies;
Relevant revocation state;
And current observer generations.
A signing key identifies a cryptographic origin under the applicable
assumptions.
It does not by itself establish competence for every claimed resource
property.
38.9 — OBSERVER COMPETENCE ENVELOPE
OBSERVER_COMPETENCE_ENVELOPE = { observer_identity,
qualified_measurement_types, permitted_resource_scopes,
actual_observation_interfaces, observation_completeness_conditions,
qualified_accuracy_or_error_bounds, evidence_semantic_profile,
Das Expires 29 April 2027 [Page 508]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
required_platform_state, current_observer_generation,
competent_issuer_reference, revocation_generation,
protected_envelope_authentication }
38.9.1 — Limited Claims
An observer may attest to a network request destination but not the
actual financial settlement result.
38.9.2 — Actual Coverage
An observer must cover the operation path relevant to its asserted
conclusion.
5.7.3.25. Original Source — Global Page 3307
38.9.3 — Changes
A new tool, resource path, or backend may exceed the observer's
earlier coverage.
38.9.4 — Missing Competence
A valid signature cannot remedy an unsupported measurement claim.
38.10 — COLLECTION-TIME EVIDENCE
At collection time, a protected evidence collector may obtain:
The original source grant;
The Candidate Act;
Qualified resource identity;
Material operation parameters;
Current policy references;
Relevant observer identity;
Selected resource-state observations;
And applicable evidence-generation information.
The collector may commit an authenticated record.
38.10.1 — Collection-Time Purpose
Das Expires 29 April 2027 [Page 509]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Establishes the qualified state relied upon when the Candidate Act
was formed.
38.10.2 — Not Execution-Time Proof
The actual operation may change before effectuation.
38.10.3 — Protected Binding
The evidence is associated with the specific Candidate Act and
resource context.
38.11 — EXECUTION-TIME OBSERVATION
An independent execution-time witness may obtain:
5.7.3.26. Original Source — Global Page 3308
The operation actually pending at the receiving interface;
The current resource identity;
The actual recipient or destination;
Material request parameters;
Current resource version;
Applicable authority state;
And relevant current hazard or policy conditions.
38.11.1 — Independent Observation
Where required, the observer is separated from the proposing agent's
control over the measured data.
38.11.2 — Freshness
The observation must satisfy the operation-specific freshness
requirement.
38.11.3 — Actual Effect
The evidence must correspond to the operation that will be released.
38.12 — OBSERVATION CHANNEL INDEPENDENCE
Das Expires 29 April 2027 [Page 510]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A protected controller may evaluate the trust and failure
dependencies of each observation channel.
For example:
An agent-side API wrapper and an agent-generated log may share the
same compromised process.
Two monitoring applications may use the same kernel event provider.
Two remote attestation statements may rely upon the same platform
root.
Two sensors may share the same signal-conditioning circuit.
A hardware command observer and an independent resource-side command
register may possess stronger separation under the relevant fault
model.
38.12.1 — Independence Is Relative
5.7.3.27. Original Source — Global Page 3309
No general declaration of independence is sufficient without
identifying the protected properties and shared failure assumptions.
38.12.2 — Mandatory Separate Control
Where the threat model assumes the agent process may be compromised,
the decisive observation may need to originate outside that process.
38.12.3 — No Universal Redundancy Claim
Two observers cannot be assumed to provide two independent
confirmations merely because they have different names.
38.13 — PROTECTED WITNESS DEPENDENCY GRAPH
The controller may maintain an evidence dependency graph.
CANDIDATE ACT | REQUIRED FACTS | +--------------+-------------+ | | v
v RESOURCE IDENTITY OPERATION STATE | | v v OBSERVER A OBSERVER B | |
v v TRUST ANCHOR X OBSERVATION PATH Y | |
+-------------+--------------+ | v DEPENDENCY QUALIFICATION
The graph identifies relationships among witnesses, underlying data
sources, protected authorities, and Candidate Acts.
Das Expires 29 April 2027 [Page 511]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
38.13.1 — Shared Dependency
May prevent two observations from being counted as independent.
38.13.2 — Compromise Propagation
A compromised underlying source may affect every dependent evidence
claim.
5.7.3.28. Original Source — Global Page 3310
38.13.3 — Selective Containment
Only operations requiring affected predicates must be fenced, unless
wider compromise is established.
38.14 — ATTESTATION APPRAISAL CONTINUITY
An observer may provide evidence about its current or measured
execution environment.
A qualified verifier may appraise that evidence using specified
reference values, endorsements, and appraisal policy.
The result is used only for those properties the appraisal supports.
38.14.1 — Platform State
May establish selected measurements or security configurations.
38.14.2 — Runtime Behavior
Is not universally proven correct by an acceptable platform
measurement.
38.14.3 — Current Appraisal Policy
A previous result must satisfy the current required operation-
specific policy or be requalified.
38.14.4 — Current Observer Competence
Attestation does not replace competence and actual coverage
validation.
38.15 — ATTESTATION CONTINUITY RECORD
Das Expires 29 April 2027 [Page 512]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
PROTECTED_ATTESTATION_CONTINUITY = { observer_identity,
attestation_evidence_reference, qualified_verifier_identity,
appraisal_policy_generation, reference_value_generation,
observed_platform_state, observer_software_generation,
challenge_or_freshness_reference, applicable_relying_party_scope,
observer_competence_reference, current_revocation_generation,
protected_result_authentication }
5.7.3.29. Original Source — Global Page 3311
A protected controller may compare collection-time and execution-time
attestation properties.
A materially changed measured component may require renewed evidence
qualification.
An unchanged measurement does not automatically prove the absence of
every runtime compromise.
38.16 — ATTESTATION FRESHNESS
An attestation mechanism may use challenges, nonces, counters, time
references, or other protocol-specific mechanisms.
A protected controller checks that the evidence is applicable to its
intended session or operation.
38.16.1 — Fresh Challenge
Can reduce replay of older attestation messages.
38.16.2 — Correct Target
A fresh attestation of the wrong device remains irrelevant.
38.16.3 — Correct Property
A fresh boot measurement does not necessarily establish a current
resource transaction state.
38.16.4 — Operation Binding
The actual consequential operation may require separate binding to
the attestation result.
38.17 — EVIDENCE GENERATION AND VERSION FENCING
A Candidate Act may depend upon:
Das Expires 29 April 2027 [Page 513]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An observer software generation;
A resource version;
An attestation appraisal generation;
An evidence schema generation;
A source authority generation;
And a revocation generation.
5.7.3.30. Original Source — Global Page 3312
The protected controller identifies which changes materially affect
the operation.
38.17.1 — Material Evidence Change
Invalidates affected pending evidence qualification.
38.17.2 — Nonmaterial Change
May be accepted where the required predicates remain established.
38.17.3 — Execution Boundary
The actual sink independently verifies applicable current
generations.
38.18 — EVIDENCE FRESHNESS VERSUS EVIDENCE VALIDITY
Evidence may be:
Authentic but stale;
Fresh but from the wrong observer;
Fresh and authentic but outside observer competence;
Fresh and competent but semantically misinterpreted;
Or fully qualified for collection-time planning but insufficient for
execution-time finality.
The protected system does not reduce all of these conditions to one
signature-validity flag.
Das Expires 29 April 2027 [Page 514]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
38.19 — CROSS-DOMAIN EVIDENCE QUALIFICATION
Evidence may cross administrative domains.
For example:
A remote device may report an operating state to a cloud controller.
A protected enterprise API may provide a resource ownership assertion
to a local agent.
An independent resource sink may receive an attestation appraisal
from another domain.
The receiving domain determines:
Whether the source is competent;
5.7.3.31. Original Source — Global Page 3313
Whether the evidence is intended for the receiving relying party;
Whether resource identifiers correspond;
Whether the claimed units and semantics are valid;
Whether the evidence remains current;
And whether its own policy permits reliance upon the statement.
A valid signature from another domain does not automatically make
that domain authoritative for all local decisions.
38.20 — EVIDENCE SEMANTICS AND CANONICALIZATION
A protected evidence-semantic profile may define:
Identifier namespaces;
Resource types;
Time representations;
Status values;
Completion semantics;
Required fields;
Das Expires 29 April 2027 [Page 515]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Optional fields;
Canonical serialization;
And schema version.
38.20.1 — Unit Mismatch
A value representing milliseconds cannot automatically be interpreted
as seconds.
38.20.2 — Resource Namespace
The identifier 42 may represent different resources in different
domains.
38.20.3 — Receipt Semantics
An ACCEPTED status cannot automatically be interpreted as COMMITTED.
5.7.3.32. Original Source — Global Page 3314
38.20.4 — Canonical Representation
The exact authenticated representation and interpretation profile
must correspond to the verifier's expectations.
38.21 — PROTECTED CROSS-DOMAIN EVIDENCE RECORD
CROSS_DOMAIN_EVIDENCE_RECORD = { producing_domain_identity,
qualified_observer_identity, relying_domain_identity, evidence_type,
evidence_schema_generation, semantic_profile_identifier,
actual_resource_namespace, actual_resource_identity,
measured_property, measurement_value_or_commitment,
qualification_and_accuracy_information, observation_generation,
operation_or_session_reference, freshness_reference,
competent_issuer_reference, protected_record_authentication }
Cross-domain acceptance requires more than verifying a signature on
this structure.
The receiving validator independently evaluates scope, competence,
current state, and semantic applicability.
38.22 — CONTRADICTORY WITNESSES
Two qualified observers may produce conflicting statements.
Das Expires 29 April 2027 [Page 516]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
For example:
Observer A reports the target resource is unchanged.
Observer B reports that the resource version advanced.
A protected controller evaluates:
Whether both observations refer to the same resource;
Whether their time intervals overlap;
5.7.3.33. Original Source — Global Page 3315
Whether they have equivalent semantics;
Whether one source has materially changed;
Whether the contradiction affects a mandatory predicate;
And whether a current independent observation can resolve it.
38.22.1 — Material Contradiction
The affected Candidate Act remains non-effective pending
qualification.
38.22.2 — Unrelated Contradiction
Need not invalidate unrelated operations.
38.22.3 — No Blind Majority
A majority of potentially correlated or compromised sources is not
automatically accepted as truth.
38.23 — QUALIFIED QUORUM OR MULTIWITNESS VERIFICATION
Some implementations may require several independent observations.
A protected policy may specify:
The required witness roles;
Permitted shared dependencies;
Minimum independent trust domains;
Das Expires 29 April 2027 [Page 517]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Measurement coverage;
Current evidence quality;
And acceptance conditions.
38.23.1 — Quorum Assumptions
The required number of witnesses depends upon the relevant fault
model.
38.23.2 — Collusion
A quorum cannot provide a general guarantee against arbitrary
compromise of all accepted witnesses.
5.7.3.34. Original Source — Global Page 3316
38.23.3 — Sink Authority
A witness quorum does not create source authority for an operation
absent from the original grant.
38.24 — COMPROMISED OBSERVER IDENTIFICATION
An observer may become suspect because of:
A revoked identity credential;
A failed current attestation appraisal;
A changed platform measurement;
Detected journal rollback;
An authenticated integrity alert;
Conflicting qualified resource evidence;
A protected policy withdrawal;
Or another competent indication of loss of evidence eligibility.
38.24.1 — Qualification
The system must identify the scope of the suspected compromise.
38.24.2 — Conservative Restriction
Das Expires 29 April 2027 [Page 518]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Affected mandatory evidence may be invalidated or suspended.
38.24.3 — No Automatic Universal Inference
One inconsistency does not necessarily establish that every
associated resource or observer is compromised.
38.25 — SELECTIVE COMPROMISE CONTAINMENT
A protected containment controller obtains the evidence-dependency
set of pending Candidate Acts.
Where a witness becomes ineligible, it identifies all operations that
depend upon the affected factual predicates.
5.7.3.35. Original Source — Global Page 3317
Those operations are fenced.
Unrelated operations remain eligible for independent current
validation if their required evidence and source authority remain
qualified.
38.25.1 — Direct Dependency
An operation may rely directly upon the compromised witness.
38.25.2 — Indirect Dependency
An operation may rely upon an aggregated result derived from the
compromised witness.
38.25.3 — Containment
Both direct and indirect affected dependencies may be invalidated
under the policy.
38.25.4 — Recovery
New independent evidence may restore eligibility only after the
mandatory source and operation predicates are requalified.
38.26 — OBSERVER REPLACEMENT
A compromised or unavailable evidence source may be replaced.
The replacement must satisfy:
Das Expires 29 April 2027 [Page 519]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Competent observer identity;
Required measurement scope;
Current applicable attestation and appraisal conditions;
Relevant observation-path separation;
Current resource and operation semantics;
And the active evidence requirement.
38.26.1 — No Silent Substitution
An arbitrary observer cannot declare itself an eligible successor.
38.26.2 — Authority Continuity
The replacement does not broaden the source-authorized effect.
5.7.3.36. Original Source — Global Page 3318
38.26.3 — Requalification
Affected Candidate Acts are checked using current evidence.
38.27 — EVIDENCE NONRESURRECTION
A software snapshot may restore an older observer registry or
attestation result.
The protected system compares restored state against stronger current
applicable evidence and revocation generations.
A revoked witness does not regain authority merely because an old
signed certificate, appraisal result, or registry entry reappears.
Similarly, already consumed operation-specific finality cannot be
restored through evidence rollback.
38.28 — FALSE OR INCOMPLETE LOG EVIDENCE
A protected log may preserve authenticated event records.
However:
A log can contain false original claims.
Das Expires 29 April 2027 [Page 520]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A logging component can miss events outside its observation path.
An absence of an entry does not prove absence of an event without a
qualified completeness model.
A valid inclusion proof does not establish the accuracy of the logged
record.
38.28.1 — Inclusion
May establish that an item belongs to a particular committed log
state.
38.28.2 — Consistency
May establish selected append-only relationships between committed
log states.
38.28.3 — Factual Accuracy
Requires separate qualification.
38.28.4 — Effectuation
5.7.3.37. Original Source — Global Page 3319
Requires actual operation authority and sink-side finality.
38.29 — QUALIFIED ABSENCE EVIDENCE
Some operations require evidence that a prohibited condition is
absent.
A protected observer may support such a conclusion only where its
observation coverage and completeness assumptions are sufficient.
For example, a monitor checking one process's logs cannot prove that
no other process accessed a resource.
A protected resource gateway with mandatory control over every
covered resource operation may support stronger assertions concerning
events within its defined coverage.
The claim should precisely identify the guaranteed observation
boundary.
38.30 — INDEPENDENT ACTUAL RESOURCE-SIDE RECONSTRUCTION
Das Expires 29 April 2027 [Page 521]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The actual Finality Sink obtains or reconstructs material information
about the pending operation.
This may include:
Actual HTTP request method and destination;
Actual database record and mutation;
Actual file object;
Actual credential audience;
Actual payment amount and beneficiary;
Actual message recipient and content;
Actual hardware command and device;
Or another covered consequential primitive.
The sink compares the operation with the authenticated Candidate Act
and qualified evidence.
38.30.1 — Upstream Witness
Provides selected evidence relevant to authorization.
5.7.3.38. Original Source — Global Page 3320
38.30.2 — Actual Sink
Checks what is actually being effected.
38.30.3 — Separation
The sink need not accept an agent-provided operation descriptor as
the final description of the receiving-resource effect.
38.31 — SINK-LOCAL EVIDENCE STATE
A protected sink may maintain:
Current accepted evidence-policy generation;
Current observer revocation state;
Actual resource generation;
Das Expires 29 April 2027 [Page 522]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Qualified validation commitment;
Scoped finality allowance;
And prior consumption state.
38.31.1 — Replay
An old receipt cannot independently authorize a new effect.
38.31.2 — Wrong Sink
Evidence approved for another actual enforcement boundary may be
insufficient.
38.31.3 — Stale Predicate
A material change requires current revalidation.
38.32 — CROSS-COMMITTED EVIDENCE
A representative non-limiting construction comprises:
[ C_C=H(\operatorname{Canon}(CA,S,R,E_C)) ]
5.7.3.39. Original Source — Global Page 3321
[ C_O=H(\operatorname{Canon}(O,A,Q,C_C)) ]
[ C_E=H(\operatorname{Canon}(CA,R,E_E,C_O)) ]
[ C_F=H(\operatorname{Canon}(C_C,C_O,C_E,F,L)) ]
(CA) identifies the Candidate Act;
(S) identifies original source authority;
(R) identifies the relevant actual resource;
(E_C) identifies collection-time evidence;
(O) identifies qualified observer identity and competence;
(A) identifies relevant attestation appraisal;
(Q) identifies the current evidence-policy and witness-quality
conditions;
Das Expires 29 April 2027 [Page 523]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
(E_E) identifies independently qualified execution-time evidence;
(F) identifies the actual Finality Sink;
And (L) identifies protected sink-local finality state.
These commitments protect selected relationships.
They do not transform an inaccurate underlying observation into a
true one.
38.33 — PROTECTED VALIDATION RECEIPT
PROTECTED_VALIDATION_RECEIPT = { candidate_act_digest,
original_source_grant_reference, actual_resource_identity,
qualified_collection_evidence_commitment,
observer_identity_and_competence_commitment,
attestation_appraisal_reference_if_required,
independent_execution_evidence_commitment,
5.7.3.40. Original Source — Global Page 3322
evidence_semantic_profile, current_evidence_policy_generation,
current_observer_revocation_generation,
current_operation_descriptor_commitment,
designated_actual_finality_sink, protected_receipt_authentication }
38.33.1 — Receipt Meaning
The receipt attests to the specified protected validation
relationship.
38.33.2 — No Bearer Authority
Possession alone does not authorize a separate actual resource
effect.
38.33.3 — Sink Verification
The actual receiving sink independently checks the applicable
operation and current finality conditions.
38.34 — SCOPED NON-BEARER FINALITY
A protected finality controller may constitute an operation-specific
enablement.
Das Expires 29 April 2027 [Page 524]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
EVIDENCE_BOUND_FINALITY = { candidate_act_digest,
validation_receipt_commitment, actual_target_resource,
actual_effect_descriptor, current_policy_and_revocation_requirements,
required_observer_generation, required_actual_resource_generation,
independent_execution_validation_reference, designated_finality_sink,
sink_local_consumption_reference, protected_enablement_authentication
}
The enablement may be retained in a protected domain with only an
opaque reference visible to the autonomous workload.
A changed operation, target, or applicable evidence generation
prevents unqualified reuse.
38.35 — FINALITY SINK VERIFICATION ORDER
5.7.3.41. Original Source — Global Page 3323
A non-limiting sink procedure may verify:
1. Actual receiving-resource identity; 2. Actual pending operation;
3. Original source grant; 4. Material operation correspondence; 5.
Relevant evidence-policy generation; 6. Qualified evidence receipt;
7. Required observer competence; 8. Current evidence revocation; 9.
Applicable current resource and hazard conditions; 10. Required
execution-time witness correspondence; 11. Scoped non-bearer
enablement; 12. Sink-local protected consumption.
The sequence may vary where necessary for atomicity or efficiency.
The critical requirement is that mandatory predicates are enforced
before the actual covered effect becomes effective.
38.36 — EVIDENCE-VERIFICATION EXHAUSTION CONTROL
A malicious agent or observer may supply excessively large or deeply
nested evidence objects.
A protected verifier may limit:
Maximum evidence size;
Nesting depth;
Number of signatures;
Number of recursive certificate relationships;
Das Expires 29 April 2027 [Page 525]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Number of remote lookups;
Maximum schema complexity;
Processing time or work budget;
And permitted verification retries.
38.36.1 — No Automatic Acceptance
Exhaustion does not convert an unresolved mandatory predicate into
permission.
38.36.2 — Resource Bound
5.7.3.42. Original Source — Global Page 3324
Verification should be bounded under the chosen implementation.
38.36.3 — Safe Recovery
A failed verification may cause an affected Candidate Act to remain
non-effective.
38.37 — EVIDENCE PRIVACY AND DATA MINIMIZATION
An evidence record may reveal:
Resource identifiers;
Private contents;
Device configurations;
Sensitive user information;
Or proprietary system state.
A protected system may use selective disclosure, authenticated
commitments, or qualified limited evidence where the relevant
authorization predicate can still be established.
38.37.1 — Selective Disclosure
May reduce unnecessary evidence exposure.
38.37.2 — Required Facts
Das Expires 29 April 2027 [Page 526]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A privacy-preserving representation must still support the actual
mandatory decision.
38.37.3 — Missing Data
A commitment that hides the relevant value does not automatically
prove the required predicate.
38.38 — OFFLINE EVIDENCE CONTINUITY
During a network partition, an observer may be unable to obtain
current remote attestation or revocation state.
The protected controller distinguishes:
Operations requiring current remote evidence;
Operations expressly permitted under a bounded offline evidence
model;
5.7.3.43. Original Source — Global Page 3325
And operations whose mandatory evidence is locally available through
competent protected observers.
No offline evidence mechanism can guarantee knowledge of an
unreceived remote revocation without an independent constraint
preventing the operation.
38.39 — EVIDENCE AFTER OBSERVER RESTART
An observer may reboot or migrate.
The protected system may require:
Current observer identity;
Current software or configuration qualification;
Reestablished observation-path coverage;
Current evidence-generation continuity;
And recovery of protected revocation state.
A prior attestation result cannot automatically authorize evidence
generated by a materially different observer implementation.
Das Expires 29 April 2027 [Page 527]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
38.40 — MULTI-RESOURCE EVIDENCE CONTINUITY
A complex transaction may rely on evidence from several Finality
Sinks.
The system may distinguish:
Preparation evidence;
Dispatch evidence;
Commit evidence;
Completion evidence;
And independently observed physical outcome evidence.
A qualified receipt from one sink cannot automatically prove another
sink's actual effect.
A dependent Candidate Act must satisfy the exact receipt semantics
required by its protected dependency graph.
5.7.3.44. Original Source — Global Page 3326
38.41 — EVIDENCE FINALITY STATE MACHINE
A representative state machine comprises:
CANDIDATE_PROPOSED: A consequential operation exists.
CANDIDATE_NON_EFFECTIVE: Actual effectuation is withheld.
EVIDENCE_REQUIREMENTS_ESTABLISHED: Mandatory predicates are
identified.
COLLECTION_PENDING: Initial evidence is being obtained.
COLLECTION_QUALIFIED: Required collection-time observations pass.
OBSERVER_QUALIFICATION_PENDING: Source identity and competence are
evaluated.
ATTESTATION_PENDING: Applicable platform appraisal remains
unresolved.
OBSERVER_QUALIFIED: Required observer conditions pass.
Das Expires 29 April 2027 [Page 528]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
EXECUTION_OBSERVATION_PENDING: Current independent evidence is
required.
EXECUTION_EVIDENCE_QUALIFIED: Current observations pass.
EVIDENCE_CONTRADICTION: Required observations conflict materially.
OBSERVER_COMPROMISE_SUSPECTED: A witness no longer satisfies current
qualification.
DEPENDENCY_FENCED: Affected Candidate Acts remain withheld.
REQUALIFICATION_PENDING: Replacement evidence is being evaluated.
CROSS_COMMITMENT_PREPARED: Evidence relationships are protected.
VALIDATION_RECEIPT_ISSUED: Qualified validation evidence exists.
NON_BEARER_FINALITY_PREPARED: Scoped effectuation enablement exists.
SINK_VERIFICATION_PENDING: Actual operation correspondence is being
checked.
FINALITY_CONSUMED: Protected operation authority is spent.
EFFECT_RELEASED: The covered resource effect is attempted.
EFFECT_CONFIRMED: Qualified actual completion evidence exists.
5.7.3.45. Original Source — Global Page 3327
EFFECT_INDETERMINATE: Actual outcome remains uncertain.
EVIDENCE_SOURCE_REVOKED: A witness is no longer eligible for affected
future decisions.
RECOVERY_QUALIFIED: The necessary evidence relationships are
reestablished.
38.42 — COMPLETE COMMON IMPLEMENTATION WORKFLOW
Step 1 — Establish Original Source Authority. Identify the specific
permitted consequential operation.
Step 2 — Construct Candidate Act. Describe the intended actual target
and effect.
Das Expires 29 April 2027 [Page 529]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Step 3 — Maintain Non-Effective State. Prevent premature
effectuation.
Step 4 — Determine Mandatory Evidence. Identify predicates required
for the actual operation.
Step 5 — Identify Competent Witnesses. Select sources with
qualifying observation scope.
Step 6 — Identify Trust Dependencies. Record shared observer roots
or failure paths.
Step 7 — Obtain Collection-Time Evidence. Capture initial relevant
conditions.
Step 8 — Qualify Source Identity. Authenticate evidence producers
where required.
Step 9 — Qualify Observer Competence. Check the asserted measurement
is within supported coverage.
Step 10 — Appraise Attestation Where Required. Verify selected
observer-state claims under the applicable current policy.
Step 11 — Protect Initial Evidence. Commit the Candidate Act and
collection-time observations.
Step 12 — Identify Execution Boundary. Determine the actual
receiving-resource effectuation point.
Step 13 — Obtain Execution-Time Evidence. Use a qualified
independent observation path.
Step 14 — Verify Freshness. Check operation-specific time and
generation constraints.
Step 15 — Verify Semantic Correspondence. Compare identifiers,
units, statuses, and resource meanings.
Step 16 — Verify Witness Independence. Apply the selected compromise
model.
5.7.3.46. Original Source — Global Page 3328
Step 17 — Resolve Contradictions. Hold affected operations where
mandatory predicates remain unresolved.
Das Expires 29 April 2027 [Page 530]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Step 18 — Check Observer Revocation. Apply current evidence-source
eligibility.
Step 19 — Check Current Source and Resource Authority. Evidence does
not replace these grants.
Step 20 — Fence Material Evidence Changes. Invalidate affected
pending finality.
Step 21 — Requalify If Necessary. Obtain competent replacement
evidence.
Step 22 — Cross-Commit Evidence. Bind original and current
observations to the Candidate Act.
Step 23 — Generate Validation Receipt. Commit the qualified evidence
relationship.
Step 24 — Prepare Scoped Non-Bearer Finality. Bind authority to the
actual operation and designated sink.
Step 25 — Present Actual Operation to Sink. Submit through the
required protected path.
Step 26 — Reconstruct Actual Effect. The receiving sink
independently identifies target and operation.
Step 27 — Verify Evidence-to-Effect Correspondence. Reject
mismatched or stale evidence.
Step 28 — Verify Current Authority. Apply source, resource, policy,
and revocation conditions.
Step 29 — Verify Protected Consumption. Prevent reuse or
unauthorized duplication.
Step 30 — Release Controlled Effect. Commit only the eligible
consequential operation.
Step 31 — Record Outcome. Distinguish actual completion from mere
dispatch.
Step 32 — Preserve Evidence History. Record valid, revoked, and
replaced evidence generations.
Step 33 — Recover After Compromise. Requalify affected operations
rather than automatically restoring old authority.
Das Expires 29 April 2027 [Page 531]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
38.43 — REFERENCE ALGORITHM: EVIDENCE REQUIREMENT CONSTRUCTION
FUNCTION CONSTRUCT_EVIDENCE_REQUIREMENTS( candidate_act,
5.7.3.47. Original Source — Global Page 3329
protected_policy_controller ): REQUIRE
VERIFY_ORIGINAL_SOURCE_AUTHORITY() REQUIRE
VERIFY_CANDIDATE_NON_EFFECTIVE() operation =
QUALIFY_ACTUAL_INTENDED_CONSEQUENCE( candidate_act ) requirements =
protected_policy_controller .LOAD_MANDATORY_EVIDENCE_PREDICATES(
operation ) REQUIRE VERIFY_REQUIREMENT_POLICY_GENERATION() REQUIRE
VERIFY_REQUIRED_ACTUAL_RESOURCE_SCOPE() RETURN
COMMIT_PROTECTED_EVIDENCE_REQUIREMENTS({ candidate:
HASH(candidate_act), operation: operation, predicates: requirements,
designated_sink: RESOLVE_QUALIFIED_FINALITY_SINK() })
The requirements are obtained from competent protected policy, not
from a lower-trust agent's preference.
38.44 — REFERENCE ALGORITHM: COLLECTION-TIME EVIDENCE
FUNCTION COLLECT_PROTECTED_INITIAL_EVIDENCE( candidate_act,
protected_collector ): requirements =
LOAD_OPERATION_EVIDENCE_REQUIREMENTS( candidate_act ) FOR EACH
predicate IN requirements: observer =
SELECT_COMPETENT_OBSERVER(predicate)
5.7.3.48. Original Source — Global Page 3330
REQUIRE VERIFY_OBSERVER_IDENTITY(observer) REQUIRE
VERIFY_OBSERVER_COMPETENCE( observer, predicate ) evidence =
protected_collector .OBTAIN_QUALIFIED_OBSERVATION( observer,
predicate ) REQUIRE VERIFY_OBSERVATION_SCOPE(evidence) REQUIRE
VERIFY_OBSERVATION_FRESHNESS(evidence) COMMIT_COLLECTION_EVIDENCE(
candidate_act, predicate, evidence ) RETURN
PROTECTED_COLLECTION_COMMITMENT()
38.45 — REFERENCE ALGORITHM: OBSERVER ATTESTATION QUALIFICATION
FUNCTION QUALIFY_OBSERVER_ATTESTATION( observer, appraisal_controller
): REQUIRE VERIFY_OBSERVER_IDENTITY() requirements =
LOAD_CURRENT_ATTESTATION_REQUIREMENTS(observer) evidence =
REQUEST_ATTESTATION_EVIDENCE( observer, requirements.challenge )
REQUIRE VERIFY_ATTESTATION_EVIDENCE_FORMAT() REQUIRE
VERIFY_FRESHNESS_AND_EXPECTED_AUDIENCE()
Das Expires 29 April 2027 [Page 532]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.7.3.49. Original Source — Global Page 3331
result = appraisal_controller .APPRAISE_EVIDENCE_WITH_CURRENT_POLICY(
evidence, requirements ) REQUIRE
VERIFY_APPRAISAL_RESULT_INTEGRITY(result) REQUIRE
VERIFY_RESULT_SATISFIES_REQUIRED_PROPERTIES( result ) REQUIRE
VERIFY_CURRENT_OBSERVER_COMPETENCE() RETURN
QUALIFIED_OBSERVER_STATE(result)
The attestation result qualifies specified observer-state properties;
it does not independently prove the truth of every observation.
38.46 — REFERENCE ALGORITHM: INDEPENDENT EXECUTION-TIME WITNESS
FUNCTION VALIDATE_EXECUTION_TIME_EVIDENCE( candidate_act,
protected_execution_observer ): REQUIRE
VERIFY_CANDIDATE_NON_EFFECTIVE() actual =
protected_execution_observer .OBSERVE_CURRENT_PENDING_OPERATION()
REQUIRE VERIFY_ACTUAL_RESOURCE_IDENTITY(actual) REQUIRE
VERIFY_OBSERVER_OUTSIDE_REQUIRED_COMPROMISE_DOMAIN() REQUIRE
VERIFY_CURRENT_OBSERVER_QUALIFICATION() REQUIRE
VERIFY_CURRENT_OBSERVATION_FRESHNESS() REQUIRE
VERIFY_ACTUAL_EFFECT_CORRESPONDENCE( candidate_act, actual ) REQUIRE
VERIFY_CURRENT_RESOURCE_AND_POLICY_PREDICATES()
5.7.3.50. Original Source — Global Page 3332
RETURN COMMIT_EXECUTION_VALIDATION({ candidate: HASH(candidate_act),
actual_operation: HASH(actual), observer:
CURRENT_OBSERVER_IDENTITY(), generation:
CURRENT_EVIDENCE_GENERATION() })
The required independence property depends upon the selected threat
model and implementation.
38.47 — REFERENCE ALGORITHM: CROSS-DOMAIN EVIDENCE INTERPRETATION
Das Expires 29 April 2027 [Page 533]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
FUNCTION QUALIFY_CROSS_DOMAIN_EVIDENCE( received_record,
local_relying_domain ): REQUIRE VERIFY_EVIDENCE_PRODUCER_IDENTITY()
REQUIRE VERIFY_COMPETENT_ISSUER() REQUIRE VERIFY_RELYING_PARTY_SCOPE(
received_record, local_relying_domain ) profile =
LOAD_QUALIFIED_EVIDENCE_SEMANTIC_PROFILE( received_record ) REQUIRE
VERIFY_SCHEMA_GENERATION(profile) REQUIRE
VERIFY_IDENTIFIER_NAMESPACE(profile) REQUIRE
VERIFY_MEASUREMENT_UNITS(profile) REQUIRE
VERIFY_STATUS_AND_COMPLETION_SEMANTICS(profile) REQUIRE
VERIFY_CURRENT_FRESHNESS_AND_REVOCATION() REQUIRE
VERIFY_LOCAL_PREDICATE_COMPETENCE( received_record ) RETURN
QUALIFIED_LOCAL_EVIDENCE_INTERPRETATION()
5.7.3.51. Original Source — Global Page 3333
An otherwise authentic record is not accepted if its actual semantic
meaning cannot satisfy the local mandatory predicate.
38.48 — REFERENCE ALGORITHM: WITNESS INDEPENDENCE CHECK
FUNCTION VERIFY_WITNESS_SET_INDEPENDENCE( witness_set,
protected_dependency_registry ): requirements =
LOAD_REQUIRED_INDEPENDENCE_POLICY() dependencies =
protected_dependency_registry
.RECONSTRUCT_WITNESS_TRUST_DEPENDENCIES( witness_set ) REQUIRE
VERIFY_REQUIRED_OBSERVER_ROLES() REQUIRE
VERIFY_MANDATORY_OBSERVATION_COVERAGE() REQUIRE
VERIFY_INDEPENDENCE_UNDER_SELECTED_FAULT_MODEL( dependencies,
requirements ) RETURN QUALIFIED_WITNESS_SET
The procedure does not establish independence merely by counting
signatures.
38.49 — REFERENCE ALGORITHM: CONTRADICTION CONTAINMENT
FUNCTION HANDLE_EVIDENCE_CONTRADICTION( candidate_act,
qualified_evidence_set ): contradictions =
FIND_MATERIAL_PREDICATE_CONTRADICTIONS( qualified_evidence_set ) IF
contradictions == NONE: RETURN CONTINUE_QUALIFICATION
5.7.3.52. Original Source — Global Page 3334
affected = MAP_CONTRADICTIONS_TO_CANDIDATE_DEPENDENCIES(
candidate_act, contradictions )
FENCE_AFFECTED_PENDING_FINALITY(affected) REQUIRE
INDEPENDENT_REQUALIFICATION( contradictions ) RETURN
EVIDENCE_UNRESOLVED
Das Expires 29 April 2027 [Page 534]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A material contradiction is not resolved merely by choosing the
observation preferred by the agent.
38.50 — REFERENCE ALGORITHM: COMPROMISED OBSERVER CONTAINMENT
FUNCTION CONTAIN_COMPROMISED_OBSERVER( observer_identity,
protected_evidence_registry ): REQUIRE
VERIFY_COMPETENT_COMPROMISE_INDICATION() affected_evidence =
protected_evidence_registry .FIND_DEPENDENT_EVIDENCE(
observer_identity ) affected_candidates =
RESOLVE_TRANSITIVE_CANDIDATE_DEPENDENCIES( affected_evidence )
ADVANCE_PROTECTED_OBSERVER_RESTRICTION_STATE( observer_identity )
INVALIDATE_AFFECTED_EVIDENCE(affected_evidence)
FENCE_AFFECTED_FINALITY(affected_candidates)
PRESERVE_UNRELATED_QUALIFIED_EVIDENCE() RETURN
PROTECTED_CONTAINMENT_RESULT(
5.7.3.53. Original Source — Global Page 3335
affected_candidates )
The containment must account for indirect evidence derived from the
compromised observer.
38.51 — REFERENCE ALGORITHM: EVIDENCE REQUALIFICATION
FUNCTION REQUALIFY_AFFECTED_CANDIDATE( candidate_act,
protected_requalification_controller ): REQUIRE
VERIFY_CURRENT_ORIGINAL_SOURCE_GRANT() REQUIRE
VERIFY_CANDIDATE_STILL_NON_EFFECTIVE() requirements =
LOAD_CURRENT_EVIDENCE_REQUIREMENTS( candidate_act ) replacement =
protected_requalification_controller
.SELECT_QUALIFIED_REPLACEMENT_WITNESS( requirements ) REQUIRE
VERIFY_REPLACEMENT_IDENTITY_AND_COMPETENCE() REQUIRE
VERIFY_REQUIRED_INDEPENDENCE() REQUIRE
VERIFY_CURRENT_ATTESTATION_IF_REQUIRED() new_evidence =
OBTAIN_NEW_CURRENT_OPERATION_EVIDENCE( replacement ) REQUIRE
VERIFY_ACTUAL_RESOURCE_AND_EFFECT_CORRESPONDENCE() RETURN
COMMIT_NEW_PROTECTED_EVIDENCE_GENERATION( candidate_act, new_evidence
)
Requalification restores only the eligibility supported by current
valid authority and evidence.
5.7.3.54. Original Source — Global Page 3336
38.52 — REFERENCE ALGORITHM: CROSS-COMMITTED VALIDATION RECEIPT
Das Expires 29 April 2027 [Page 535]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
FUNCTION ISSUE_CROSS_COMMITTED_VALIDATION_RECEIPT( candidate_act,
protected_validation_controller ): REQUIRE
VERIFY_ORIGINAL_SOURCE_AUTHORITY() collection =
LOAD_QUALIFIED_COLLECTION_EVIDENCE() execution =
LOAD_QUALIFIED_EXECUTION_EVIDENCE() REQUIRE
VERIFY_COLLECTION_EVIDENCE_INTEGRITY() REQUIRE
VERIFY_EXECUTION_EVIDENCE_INTEGRITY() REQUIRE
VERIFY_OBSERVER_COMPETENCE_AND_INDEPENDENCE() REQUIRE
VERIFY_CURRENT_ATTESTATION_REQUIREMENTS() REQUIRE
VERIFY_CURRENT_EVIDENCE_REVOCATION() REQUIRE
VERIFY_CROSS_DOMAIN_SEMANTIC_CORRESPONDENCE() REQUIRE
VERIFY_ACTUAL_OPERATION_CORRESPONDENCE() RETURN
protected_validation_controller .COMMIT_VALIDATION_RECEIPT({
candidate: HASH(candidate_act), collection: HASH(collection),
execution: HASH(execution), actual_effect:
HASH(CURRENT_ACTUAL_EFFECT()), sink: ACTUAL_FINALITY_SINK_ID() })
The receipt remains evidence of protected validation, not
unrestricted effectuation permission.
38.53 — REFERENCE ALGORITHM: EVIDENCE-BOUND FINALITY
FUNCTION PREPARE_EVIDENCE_BOUND_FINALITY( candidate_act,
validation_receipt, protected_finality_controller ):
5.7.3.55. Original Source — Global Page 3337
REQUIRE VERIFY_VALIDATION_RECEIPT_INTEGRITY() REQUIRE
VERIFY_RECEIPT_FOR_THIS_CANDIDATE() REQUIRE
VERIFY_CURRENT_SOURCE_AND_RESOURCE_AUTHORITY() REQUIRE
VERIFY_CURRENT_EVIDENCE_POLICY_GENERATION() REQUIRE
VERIFY_CURRENT_OBSERVER_REVOCATION() REQUIRE
VERIFY_ACTUAL_OPERATION_AND_TARGET() REQUIRE
VERIFY_DESIGNATED_SINK_IDENTITY() RETURN
protected_finality_controller .PREPARE_SCOPED_NON_BEARER_ENABLEMENT({
candidate: HASH(candidate_act), receipt: HASH(validation_receipt),
target: ACTUAL_RESOURCE_IDENTITY(), effect:
HASH(CURRENT_ACTUAL_EFFECT()), sink: ACTUAL_FINALITY_SINK_ID(),
consumption: PROTECTED_SINK_LOCAL_CONSUMPTION_REFERENCE() })
38.54 — REFERENCE ALGORITHM: ACTUAL FINALITY SINK
Das Expires 29 April 2027 [Page 536]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
FUNCTION EFFECTUATE_WITH_QUALIFIED_EVIDENCE( candidate_act,
validation_receipt, finality_reference, protected_actual_sink ):
actual = protected_actual_sink
.RECONSTRUCT_ACTUAL_PENDING_OPERATION() REQUIRE
VERIFY_CURRENT_ACTUAL_RESOURCE_IDENTITY(actual) REQUIRE
VERIFY_CURRENT_ORIGINAL_SOURCE_AUTHORITY() REQUIRE
VERIFY_RECEIPT_CANDIDATE_CORRESPONDENCE( candidate_act,
validation_receipt ) REQUIRE VERIFY_REQUIRED_EVIDENCE_PREDICATES()
5.7.3.56. Original Source — Global Page 3338
REQUIRE VERIFY_CURRENT_OBSERVER_ELIGIBILITY() REQUIRE
VERIFY_REQUIRED_EXECUTION_TIME_EVIDENCE() REQUIRE
VERIFY_ACTUAL_EFFECT_MATCHES_VALIDATED_EFFECT( actual,
validation_receipt ) REQUIRE
VERIFY_CURRENT_RESOURCE_POLICY_AND_REVOCATION() REQUIRE
VERIFY_SCOPED_NON_BEARER_FINALITY( finality_reference, actual )
REQUIRE VERIFY_SINK_LOCAL_CONSUMPTION() result =
protected_actual_sink .COMMIT_AUTHORIZED_EFFECT_AND_CONSUMPTION(
actual, finality_reference ) RETURN
QUALIFIED_RESOURCE_OUTCOME(result)
The resource's actual transaction or command model determines what
guarantees the final operation provides.
38.55 — REFERENCE ALGORITHM: EVIDENCE NONRESURRECTION
FUNCTION RESTORE_EVIDENCE_REGISTRY( restored_registry,
protected_authoritative_state ): REQUIRE
VERIFY_RESTORED_REGISTRY_INTEGRITY() current =
protected_authoritative_state .LOAD_CURRENT_EVIDENCE_GENERATIONS() IF
restored_registry.observer_generation < current.observer_generation:
FENCE_OBSOLETE_OBSERVER_EVIDENCE() IF
restored_registry.revocation_generation <
current.revocation_generation:
5.7.3.57. Original Source — Global Page 3339
FENCE_OBSOLETE_AUTHORITY() IF
restored_registry.finality_consumption_generation <
current.finality_consumption_generation: FENCE_RESTORED_FINALITY()
REQUIRE VERIFY_CURRENT_OBSERVER_AND_SINK_IDENTITIES() RETURN
QUALIFIED_RECOVERY_STATE
38.56 — WORKED EXAMPLE A: AUTHENTIC BUT FALSE SENSOR READING
A protected sensor produces a correctly authenticated observation.
Das Expires 29 April 2027 [Page 537]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The sensor is miscalibrated and reports an inaccurate value.
The protected controller requires qualified measurement accuracy for
the operation.
The mandatory predicate is not established merely by the signature.
Expected demonstrable result: Signed evidence does not automatically
qualify inaccurate underlying measurements.
38.57 — WORKED EXAMPLE B: VALID ATTESTATION, WRONG RESOURCE
An observer supplies a valid current platform attestation result.
The observer measures Resource A.
An agent attempts an operation against Resource B.
The execution-time validator verifies the actual resource identity.
The evidence for A cannot authorize B.
Expected demonstrable result: Platform attestation cannot replace
actual operation-specific resource correspondence.
38.58 — WORKED EXAMPLE C: VALID PLATFORM MEASUREMENT, MISSING
COVERAGE
A monitoring component is attested as running a qualified software
image.
A new backend execution path is introduced outside the monitor's
coverage.
5.7.3.58. Original Source — Global Page 3340
The protected competence registry identifies the uncovered path.
An operation through that path is withheld unless a competent actual
sink enforces the required conditions.
Expected demonstrable result: Attesting a monitor does not prove
coverage of effectuation paths that it does not observe.
38.59 — WORKED EXAMPLE D: TWO CORRELATED OBSERVERS
Two monitoring processes independently sign the same underlying API
response.
Das Expires 29 April 2027 [Page 538]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The API response is compromised.
The witness dependency registry identifies the shared underlying
source.
The two signatures are not treated as independent factual
corroboration.
Expected demonstrable result: Multiple signatures cannot
automatically satisfy an independence requirement.
38.60 — WORKED EXAMPLE E: INDEPENDENT RESOURCE-SIDE WITNESS
An agent proposes a database mutation.
An agent-side observer reports that the target is Tenant A.
The actual protected database sink independently identifies the row
as belonging to Tenant B.
The conflicting operation is refused.
Expected demonstrable result: Actual resource-side reconstruction
prevents an upstream observer from silently substituting the
consequential target.
38.61 — WORKED EXAMPLE F: REPLAYED AUTHORIZATION EVIDENCE
A previous source authorization receipt was valid for Candidate Act
A.
An attacker reuses it for Candidate Act B.
The protected validator checks the Candidate Act and resource
commitments.
The mismatch is rejected.
5.7.3.59. Original Source — Global Page 3341
Expected demonstrable result: Valid old evidence cannot automatically
authorize a different consequential operation.
38.62 — WORKED EXAMPLE G: STALE RESOURCE VERSION
An observer signs Resource Generation 5.
The actual resource advances to Generation 6 before effectuation.
Das Expires 29 April 2027 [Page 539]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The current sink identifies that the relevant evidence no longer
satisfies the protected version predicate.
The operation is withheld.
Expected demonstrable result: A correct historical observation does
not substitute for required current resource state.
38.63 — WORKED EXAMPLE H: OBSERVER KEY REVOCATION
An evidence producer's signing credential is revoked.
The agent presents an earlier authentic evidence statement.
The current protected evidence policy requires eligible observer
authority.
The dependent pending operation is fenced.
Expected demonstrable result: Cryptographic authenticity of
historical evidence does not independently establish current observer
eligibility.
38.64 — WORKED EXAMPLE I: SELECTIVE COMPROMISE CONTAINMENT
Observer A supplies evidence for Candidate Acts 1 and 2.
Observer B independently supplies the mandatory evidence for
Candidate Act 3.
Observer A is found compromised.
The protected dependency controller fences Acts 1 and 2.
Act 3 may remain eligible subject to its own current evidence and
source authority.
Expected demonstrable result: Compromise containment can be
dependency-specific instead of indiscriminately invalidating
unrelated operations.
5.7.3.60. Original Source — Global Page 3342
38.65 — WORKED EXAMPLE J: INDIRECT EVIDENCE LAUNDERING
Observer A provides raw evidence.
Aggregator C summarizes A's data and signs the summary.
Das Expires 29 April 2027 [Page 540]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Observer A becomes untrusted.
The protected evidence lineage reveals that C's relevant conclusion
depends upon A.
The affected summary cannot automatically continue authorizing
operations.
Expected demonstrable result: Re-signing or summarizing compromised
evidence does not remove the underlying trust dependency.
38.66 — WORKED EXAMPLE K: WRONG UNIT INTERPRETATION
A remote service supplies a signed time value in milliseconds.
A local verifier incorrectly interprets it as seconds.
The protected semantic profile check detects the mismatch.
The time-dependent operation remains withheld.
Expected demonstrable result: Authentic evidence with incorrect
semantic interpretation cannot satisfy the intended predicate.
38.67 — WORKED EXAMPLE L: CROSS-DOMAIN IDENTIFIER COLLISION
Two administrative domains each use Resource Identifier 42.
An agent obtains valid evidence concerning the first domain's
resource.
It attempts a consequential operation in the second domain.
The protected namespace mapping detects the mismatch.
Expected demonstrable result: Shared textual identifiers do not
establish shared actual resource identity.
38.68 — WORKED EXAMPLE M: RECEIPT SEMANTICS
5.7.3.61. Original Source — Global Page 3343
A queue reports that a command was accepted.
The agent claims the actual device completed the operation.
The evidence validator recognizes that acceptance is not completion.
Das Expires 29 April 2027 [Page 541]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A successor requiring completed effect evidence remains non-
effective.
Expected demonstrable result: Receipt authenticity cannot compensate
for incorrect receipt semantics.
38.69 — WORKED EXAMPLE N: CONTRADICTORY RESOURCE WITNESSES
Observer A reports the resource state as valid.
Observer B reports a material conflict.
The protected controller evaluates the sources and their relevant
freshness.
The mandatory predicate remains unresolved.
The Candidate Act is held.
Expected demonstrable result: Contradictory mandatory evidence does
not become acceptable through arbitrary agent selection.
38.70 — WORKED EXAMPLE O: QUALIFIED OBSERVER REPLACEMENT
A protected observer becomes unavailable.
A successor observer is independently authenticated and appraised.
Its competence and resource coverage satisfy the current evidence
requirement.
The affected Candidate Act is revalidated against current source and
actual resource state.
Expected demonstrable result: A system may recover availability
through qualified observer replacement without granting expanded
consequential authority.
38.71 — WORKED EXAMPLE P: EVIDENCE LOG INCLUSION
An agent presents proof that an authorization statement was included
in an append-only log.
The statement itself falsely identifies the resource owner.
Das Expires 29 April 2027 [Page 542]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.7.3.62. Original Source — Global Page 3344
The protected controller independently evaluates the ownership
predicate.
The operation is refused.
Expected demonstrable result: Log inclusion does not make an
inaccurate logged statement true.
38.72 — WORKED EXAMPLE Q: ABSENCE OF LOG ENTRY
A monitoring log contains no record of a prohibited operation.
However, the monitor does not cover every possible resource access
path.
The absence cannot satisfy a requirement for complete proof that no
prohibited operation occurred.
Expected demonstrable result: Negative evidence requires an adequate
observation completeness model.
38.73 — WORKED EXAMPLE R: EXECUTION-TIME TOOL SUBSTITUTION
A Candidate Act is prepared for a read-only tool.
The actual tool implementation is replaced with a state-changing
version.
The protected execution-time evidence observes the material actual
effect.
Earlier collection evidence no longer corresponds.
Finality is withheld.
Expected demonstrable result: Collection-time approval cannot
silently authorize changed tool semantics.
38.74 — WORKED EXAMPLE S: ATTESTATION POLICY DOWNGRADE
A protected verifier previously required a particular platform
property.
An attacker supplies an older permissive appraisal policy.
The protected current policy-generation check refuses the downgrade.
Das Expires 29 April 2027 [Page 543]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Expected demonstrable result: An obsolete attestation policy cannot
independently restore earlier evidence eligibility.
5.7.3.63. Original Source — Global Page 3345
38.75 — WORKED EXAMPLE T: OBSERVER REBOOT
A witness restarts under a changed software measurement.
An earlier attestation result remains in the agent's cache.
The protected controller requires current observer-state
qualification.
The old result is insufficient for the changed observer generation.
Expected demonstrable result: An earlier platform state cannot
automatically attest to a materially different restarted observer.
38.76 — WORKED EXAMPLE U: EVIDENCE VERIFICATION EXHAUSTION
An attacker supplies an extremely deeply nested evidence object.
The protected verifier enforces bounded parsing and verification
resources.
The evidence is not accepted after exhaustion.
The relevant Candidate Act remains non-effective.
Expected demonstrable result: Verification exhaustion cannot be
converted into an authorization bypass.
38.77 — WORKED EXAMPLE V: PRIVACY-PRESERVING EVIDENCE
A protected resource provides a selective disclosure proving a
required bounded attribute while withholding unrelated sensitive
fields.
The protected validator checks the proof and its relevance.
The operation may proceed if every mandatory predicate is
established.
Expected demonstrable result: Evidence minimization can coexist with
protected finality where the actual required facts remain verifiable.
38.78 — WORKED EXAMPLE W: OFFLINE STALE ATTESTATION
Das Expires 29 April 2027 [Page 544]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A remote service becomes unreachable.
5.7.3.64. Original Source — Global Page 3346
An agent presents an old valid observer attestation.
The operation's evidence policy requires a current remote appraisal.
The protected controller cannot establish that requirement.
The operation remains withheld.
Expected demonstrable result: Cached attestation cannot substitute
for mandatory live evidence freshness.
38.79 — WORKED EXAMPLE X: WRONG ACTUAL PAYMENT
A collection-time witness confirms a permitted payment amount and
recipient.
The actual payment sink observes a different recipient.
The evidence-to-effect correspondence fails.
The payment is refused.
Expected demonstrable result: Qualified evidence for the intended
payment does not authorize a materially different receiving-resource
transaction.
38.80 — WORKED EXAMPLE Y: SNAPSHOT RESTORES REVOKED OBSERVER
An attacker restores an evidence registry snapshot containing an
earlier valid observer credential.
The current protected revocation generation is newer.
The old observer is not restored to eligibility.
Expected demonstrable result: Evidence-source authority cannot be
resurrected by restoring obsolete software state.
38.81 — WORKED EXAMPLE Z: END-TO-END ACTUAL RESOURCE FINALITY
An originating principal authorizes one database record update.
The system obtains collection-time source and resource evidence.
Das Expires 29 April 2027 [Page 545]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A protected observer is qualified for the relevant measurements.
5.7.3.65. Original Source — Global Page 3347
An independent execution-time witness verifies the actual selected
database record and mutation.
Cross-committed evidence is generated.
Scoped non-bearer finality is constituted.
The receiving database sink independently reconstructs the actual
pending write and verifies current source, resource, evidence, and
protected consumption state.
The authorized update commits once.
A modified target, stale witness, forged receipt, or repeated
effectuation attempt is refused.
Expected demonstrable result: Evidence integrity and attestation
contribute to actual finality without becoming independent
unrestricted authority.
38.82 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
1. Fabricated evidence. 2. Valid signature on false content. 3.
Valid attestation overinterpreted as correctness. 4. Observer
competence mismatch. 5. Wrong observation target. 6. Wrong actual
resource. 7. Wrong tenant. 8. Wrong source principal. 9. Wrong
Candidate Act. 10. Replayed evidence. 11. Stale measurement. 12.
Delayed measurement delivery. 13. Evidence generation rollback. 14.
Observer software change. 15. Observer credential rotation. 16.
Revoked observer credential. 17. Compromised observer. 18.
Compromised evidence verifier. 19. Compromised aggregator. 20.
Correlated observers. 21. Colluding witnesses. 22. Unqualified
quorum. 23. Shared underlying sensor. 24. Shared compromised data
feed. 25. Missing observation coverage. 26. Alternate unmonitored
execution path. 27. Truncated evidence. 28. Missing mandatory
field. 29. Redaction of decisive information.
Das Expires 29 April 2027 [Page 546]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.7.3.66. Original Source — Global Page 3348
30. Incorrect measurement units. 31. Incorrect time units. 32.
Namespace collision. 33. Schema ambiguity. 34. Parser
inconsistency. 35. Canonicalization mismatch. 36. Unknown schema
generation. 37. Completion-state misinterpretation. 38. Queue
acceptance mistaken for resource commit. 39. Dispatch mistaken for
completion. 40. Aggregated score mistaken for raw evidence. 41.
Compromised evidence lineage concealed. 42. Attestation challenge
replay. 43. Attestation result replay. 44. Wrong attested device.
45. Wrong relying party. 46. Appraisal policy downgrade. 47.
Reference-value downgrade. 48. Endorsement misuse. 49. Invalid
certificate chain. 50. Unqualified attestation freshness. 51.
Correct measured software with runtime logical error. 52. Correct
measured software with unobserved side effect. 53. Sensor
calibration failure. 54. Physical sensor manipulation. 55. Sensor
accuracy outside qualified limits. 56. Genuine stale sensor sample.
57. Contradictory witnesses. 58. Arbitrary witness majority. 59.
Compromised observer falsely reported healthy. 60. Excessive
compromise scope. 61. Incomplete compromise containment. 62. Direct
compromised witness dependency. 63. Indirect compromised witness
dependency. 64. Unqualified replacement witness. 65. Restored
revoked observer state. 66. Evidence journal rollback. 67. False
log inclusion inference. 68. False absence inference. 69.
Incomplete event logging. 70. Evidence verification exhaustion. 71.
Recursive evidence object attack. 72. Excessive signature workload.
73. Excessive remote verification requests. 74. Attestation service
denial-of-service. 75. Network partition. 76. Current revocation
unavailable. 77. Resource change after observation. 78. Tool
behavior change. 79. Credential audience change.
5.7.3.67. Original Source — Global Page 3349
80. Operation amount substitution. 81. Actual recipient
substitution. 82. Evidence receipt used as bearer authority. 83.
Cross-committed evidence mismatch. 84. Wrong Finality Sink. 85.
Sink-local consumption replay. 86. Finality issued under obsolete
evidence. 87. Actual effect without sink reconstruction. 88. Sink
bypass through alternate resource path. 89. False actual-effect
receipt. 90. Historical evidence tampering. 91. Unqualified
compensation based on false outcome. 92. Observer key copied to
untrusted runtime. 93. Privacy leakage through excessive attestation
claims. 94. Misinterpretation of hardware-rooted evidence as
universal truth. 95. Unauthorized actual consequential effect
despite apparently valid observer
attestations.
Das Expires 29 April 2027 [Page 547]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
38.83 — PROPOSED FEASIBILITY AND ADVERSARIAL EXPERIMENTS
The following are proposed non-limiting experiments. They are not
representations of tests already executed.
Test 1 — Original Source Grant: Establish an authorized consequential
operation.
Test 2 — Candidate Act: Construct the actual operation descriptor.
Test 3 — Non-Effective Hold: Prevent effectuation before finality.
Test 4 — Evidence Policy: Identify mandatory factual predicates.
Test 5 — Qualified Observer Registry: Register selected evidence
sources.
Test 6 — Observer Identity: Verify authenticated source identity.
Test 7 — Observer Competence: Check supported measurement scope.
Test 8 — Collection-Time Evidence: Capture initial relevant
conditions.
Test 9 — Collection Commitment: Bind initial evidence to Candidate
Act and resource.
Test 10 — Attestation Evidence: Obtain selected observer platform
claims.
Test 11 — Appraisal Policy: Apply qualified reference values and
appraisal requirements.
Test 12 — Attestation Challenge: Use an operation-relevant freshness
mechanism.
Test 13 — Old Attestation Replay: Submit earlier evidence.
5.7.3.68. Original Source — Global Page 3350
Test 14 — Wrong Device Attestation: Present valid evidence from
another observer.
Test 15 — Current Observer Generation: Change the observer's software
or configuration.
Test 16 — Competence Change: Remove an observer's qualification to
measure a required property.
Das Expires 29 April 2027 [Page 548]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Test 17 — Independent Execution-Time Witness: Observe the actual
pending operation.
Test 18 — Observation Separation: Verify the witness is outside the
required agent compromise domain.
Test 19 — Correlated Witness Detection: Use two monitors sharing one
underlying source.
Test 20 — False Independence: Attempt to count correlated witnesses
as separate confirmations.
Test 21 — Qualified Witness Set: Establish an accepted independence
configuration.
Test 22 — Compromised Underlying Data: Make several witnesses report
the same manipulated source.
Test 23 — Current Resource Identity: Verify the actual receiving
target.
Test 24 — Resource Alias Change: Redirect to another resource.
Test 25 — Tenant Change: Substitute another tenant's resource.
Test 26 — Operation Parameter Change: Modify the actual consequential
operation.
Test 27 — Resource Version: Advance actual resource state after
collection.
Test 28 — Freshness Requirement: Submit stale evidence.
Test 29 — Evidence Generation: Update the current qualified
observation generation.
Test 30 — Observer Key Revocation: Revoke a witness credential.
Test 31 — Attestation Policy Generation: Apply a newer required
appraisal policy.
Test 32 — Reference Value Update: Change relevant expected
measurement state.
Test 33 — Cross-Domain Evidence: Import an authenticated remote
observation.
Das Expires 29 April 2027 [Page 549]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Test 34 — Namespace Collision: Reuse the same local identifier in
another domain.
Test 35 — Unit Mismatch: Change milliseconds to seconds or comparable
units.
Test 36 — Status Mismatch: Treat ACCEPTED as COMPLETED and test
rejection.
5.7.3.69. Original Source — Global Page 3351
Test 37 — Unknown Schema: Supply an unsupported evidence version.
Test 38 — Canonicalization: Use alternative representations of the
same nominal evidence.
Test 39 — Evidence Truncation: Remove a mandatory field.
Test 40 — Evidence Redaction: Hide information necessary for a
predicate.
Test 41 — Valid Selective Disclosure: Supply a sufficient qualified
limited proof.
Test 42 — Conflicting Witnesses: Produce contradictory mandatory
observations.
Test 43 — Contradiction Fence: Confirm the actual operation remains
non-effective.
Test 44 — Compromised Witness: Trigger a qualified observer-
compromise condition.
Test 45 — Direct Dependency: Fence a Candidate Act using that
witness.
Test 46 — Indirect Dependency: Fence a Candidate Act relying upon an
aggregator of compromised evidence.
Test 47 — Unrelated Evidence: Preserve independently qualified
operations.
Test 48 — Replacement Witness: Qualify a successor observer.
Test 49 — Requalification: Obtain current independent evidence.
Test 50 — Observer Reboot: Require renewed relevant state
qualification.
Das Expires 29 April 2027 [Page 550]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Test 51 — Registry Rollback: Restore an obsolete observer credential.
Test 52 — Evidence Nonresurrection: Refuse revoked observer recovery
through snapshot.
Test 53 — Protected Log Inclusion: Verify inclusion independently of
factual correctness.
Test 54 — False Logged Statement: Confirm that log inclusion does not
authorize the effect.
Test 55 — Absent Log Record: Test the observation completeness
requirement.
Test 56 — Alternative Execution Path: Attempt to bypass a monitoring-
only interface.
Test 57 — Actual Sink Reconstruction: Observe the real operation at
the resource boundary.
Test 58 — Current Source Authority: Revalidate originating
permission.
Test 59 — Current Resource Authority: Revalidate actual ownership and
policy.
Test 60 — Cross-Commitment: Bind initial and current evidence with
operation context.
5.7.3.70. Original Source — Global Page 3352
Test 61 — Protected Receipt: Generate an evidence-specific validation
record.
Test 62 — Receipt Substitution: Use a receipt for another Candidate
Act.
Test 63 — Receipt as Bearer: Attempt to cause an effect using only
the receipt.
Test 64 — Scoped Non-Bearer Finality: Bind enablement to the actual
sink and operation.
Test 65 — Wrong Sink: Present enablement at another resource.
Test 66 — Changed Effect: Modify target, recipient, amount, or method
after validation.
Das Expires 29 April 2027 [Page 551]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Test 67 — Sink-Local Consumption: Commit bounded authority use.
Test 68 — Replay: Attempt a second consequential effect.
Test 69 — Evidence Verification Exhaustion: Supply an oversized
nested evidence object.
Test 70 — Verification Resource Bound: Confirm the system withholds
rather than permits on exhaustion.
Test 71 — Network Partition: Remove access to a required remote
attestation service.
Test 72 — Live-Required Evidence: Confirm non-effectuation without
current mandatory proof.
Test 73 — Bounded Offline Evidence: Test only expressly authorized
local evidence continuity.
Test 74 — Loss of Effect Acknowledgement: Preserve qualified
indeterminate outcome.
Test 75 — Actual Effect Receipt: Distinguish resource commit from
upstream dispatch.
Test 76 — Remove Observer Competence Check: Attempt to authorize a
fact outside the monitor's scope.
Test 77 — Remove Execution-Time Validation: Attempt resource or
operation substitution.
Test 78 — Remove Compromise Dependency Fencing: Attempt stale
evidence use after observer revocation.
Test 79 — Remove Actual Sink Verification: Attempt an unauthorized
real resource operation.
Test 80 — Integrated Workflow: Combine original source grant,
protected collection evidence, observer competence, attestation
appraisal, independent execution observation, cross-domain semantic
correspondence, compromise containment, cross-committed receipt, non-
bearer finality, actual sink reconstruction, protected consumption,
and qualified outcome recording.
5.7.3.71. Original Source — Global Page 3353
38.83.1 — Proposed Measurements
Das Expires 29 April 2027 [Page 552]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Relevant metrics include:
Unauthorized completed resource effects;
Incorrect acceptance of false evidence;
Acceptance of stale or misbound evidence;
Compromised-observer detection;
Transitive containment coverage;
Incorrect witness independence classification;
False rejection of unrelated operations;
Cross-domain semantic mismatch detection;
Wrong-target sink acceptance;
Replay and duplicate effectuation;
Observer replacement success;
Verification CPU and memory consumption;
And added execution-finality latency.
38.83.2 — Comparative Ablation
A useful comparison comprises:
Configuration A — Agent-Reported Evidence: The workload relies on
tool responses or agent-supplied facts.
Configuration B — Authenticated and Attested Evidence: The system
verifies selected signatures, attestation results, and evidence
sources.
Configuration C — Qualified Independent Evidence: The system
additionally verifies competence, scope, freshness, semantic
correspondence, independent observation, and compromise dependencies.
Configuration D — Complete Evidence-to-Effect Finality: The system
additionally requires the Candidate Act to remain non-effective until
qualified cross-committed validation, scoped non-bearer finality, and
actual receiving-resource sink reconstruction and consumption.
Das Expires 29 April 2027 [Page 553]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
38.83.3 — Decisive Proposed Anti-Hindsight Experiment
5.7.3.72. Original Source — Global Page 3354
An agent receives authorization to modify a specific resource.
A protected observer produces authenticated evidence for the
operation.
The observer passes a selected platform attestation appraisal.
Before actual effectuation, an attacker changes the actual resource
or command through a path not covered by that observer.
The operation still carries valid-looking original evidence.
The experiment compares whether:
A conventional authenticated-evidence system accepts the request;
An attestation-based controller accepts the request;
An independently observing execution-time verifier detects the
mismatch;
And an actual Finality Sink prevents the unauthorized resource
effect.
A second experiment compromises the collection-time observer and
tests whether operations indirectly dependent on its observations are
fenced.
A third experiment supplies qualified replacement observations and
determines whether only properly revalidated operations regain
eligibility.
The decisive measurements concern the actual receiving-resource
mutations and protected effectuation state, not merely the presence
of warnings in an audit log.
38.84 — NON-LIMITING PHOSITA REFERENCE PROTOTYPE
38.84.1 — Minimum Components
A PHOSITA may construct:
One autonomous agent;
Das Expires 29 April 2027 [Page 554]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
One original source-authority registry;
Two simulated evidence observers;
One protected observer-competence registry;
One attestation appraisal service or simulated attestation evaluator;
One evidence dependency graph;
5.7.3.73. Original Source — Global Page 3355
One independent execution-time gateway;
One protected validation receipt controller;
One resource database with a separate Finality Sink;
And one durable protected evidence and consumption journal.
38.84.2 — Initial Authorization
The original source permits one exact mutation of one identified
record.
38.84.3 — Collection-Time Evidence
Observer A produces a qualified snapshot of the resource version and
authorized operation.
38.84.4 — Observer Qualification
The system authenticates A and checks that its competence covers the
relevant measurement.
38.84.5 — Attestation Qualification
The system obtains selected evidence of A's current protected runtime
state where applicable.
38.84.6 — Candidate Hold
The agent's proposed mutation remains non-effective.
38.84.7 — Execution-Time Observation
Observer B independently obtains the actual pending mutation from the
protected database-gateway side.
Das Expires 29 April 2027 [Page 555]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
38.84.8 — Qualified Correspondence
The resource identity, tenant, operation, and material parameters are
compared.
38.84.9 — Correct Operation
A protected validation receipt is generated.
38.84.10 — Finality
Scoped non-bearer enablement is constituted.
38.84.11 — Actual Sink
The database sink reconstructs the pending mutation and commits
protected consumption with the authorized effect.
5.7.3.74. Original Source — Global Page 3356
38.84.12 — Resource Substitution
The agent changes the actual record identifier after evidence
collection.
38.84.13 — Expected Result
The receiving sink refuses the mismatched mutation.
38.84.14 — Compromised Observer
The test marks Observer A as revoked or compromised.
38.84.15 — Dependency Containment
Pending Candidate Acts relying upon A are identified and fenced.
38.84.16 — Independent Unaffected Operation
A separate operation relying on an independent qualified evidence
source remains eligible for its own validation.
38.84.17 — Observer Replacement
The system registers a qualified replacement for A and obtains fresh
evidence.
38.84.18 — Requalification
Das Expires 29 April 2027 [Page 556]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The affected Candidate Act is independently revalidated under current
source and resource conditions.
38.84.19 — Replay Attempt
The test reuses the earlier validation receipt and finality
reference.
38.84.20 — Expected Result
The duplicate operation is refused.
38.84.21 — Evidence Snapshot Rollback
The observer registry is restored to an earlier state.
38.84.22 — Expected Result
The old revoked observer does not regain eligibility where the
implementation's protected authoritative state supports the required
anti-rollback guarantee.
38.85 — OPTIONAL ADVANCED VARIATIONS
5.7.3.75. Original Source — Global Page 3357
38.85.1 — Hardware-Assisted Observation
A qualified protected component records selected actual resource
operations.
38.85.2 — Remote Attestation
Observer runtime state may be appraised through qualified attestation
protocols.
38.85.3 — Multiple Independent Observers
Selected operations may require independent evidence channels under a
stated fault model.
38.85.4 — Cross-Domain Evidence
Qualified claims may be exchanged between administrative domains.
38.85.5 — Protected Sensor Evidence
Physical measurements may contribute to mandatory hazard predicates.
Das Expires 29 April 2027 [Page 557]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
38.85.6 — Database Version Evidence
Current record identities and versions may be observed at the
resource boundary.
38.85.7 — Network Egress Evidence
Actual destinations and request parameters may be verified.
38.85.8 — Filesystem Effect Evidence
An actual file object may be distinguished from an earlier pathname.
38.85.9 — Credential Audience Evidence
Actual receiving service identity may be checked independently of the
agent's request.
38.85.10 — Financial Transaction Evidence
Payment parameters and actual settlement status may be separately
qualified.
38.85.11 — Physical Device Evidence
Actual actuator and command identity may be observed at the protected
device controller.
38.85.12 — Append-Only Evidence Logs
Selected evidence history may be committed to authenticated append-
only structures.
38.85.13 — Privacy-Preserving Claims
5.7.3.76. Original Source — Global Page 3358
Selected predicates may be proven without disclosing unrelated
sensitive information.
38.85.14 — Offline Evidence
Specifically preauthorized locally available evidence may support
bounded offline operations.
38.85.15 — Observer Migration
A qualified successor may replace an evidence-producing workload.
Das Expires 29 April 2027 [Page 558]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
38.85.16 — Policy-Generation Change
Material appraisal policy updates may fence pending operations.
38.85.17 — Evidence-Source Revocation
Invalidated observers may be excluded from further finality.
38.85.18 — Cross-Sink Transactions
Actual-effect receipts may support protected dependencies across
resources.
38.85.19 — Protected Resource Outcome Reconciliation
Indeterminate operations may be resolved through competent actual
resource evidence.
38.85.20 — Evidence-Verification Resource Control
Complex evidence objects may be checked under bounded parser and
verification budgets.
38.86 — PROPOSED INVENTIVE-STEP CHARACTERIZATION
38.86.1 — Established Foundations
Existing technologies include:
Remote attestation;
Protected platform measurement;
Trusted computing;
Authenticated evidence records;
Multiple sensor validation;
Evidence provenance;
5.7.3.77. Original Source — Global Page 3359
Transparency logs;
Cryptographic commitments;
Challenge-response;
Das Expires 29 April 2027 [Page 559]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Reference-value appraisal;
And protected resource authorization.
These are relevant prior technical foundations.
38.86.2 — Candidate Objective Technical Problem
How to preserve the integrity and operation-specific applicability of
evidence supporting autonomous consequential authorization despite
compromised or stale observers, cross-domain semantic ambiguity, and
material changes between collection-time observation and actual
effectuation, while preventing evidence or attestation results from
becoming unrestricted authority to release a different real resource
effect.
38.86.3 — Proposed Technical Solution
The system holds a source-authorized Candidate Act non-effective.
A protected policy defines mandatory evidence predicates.
Collection-time evidence is bound to the Candidate Act.
Observer identity, competence, relevant attestation state, and actual
measurement coverage are qualified.
Independent execution-time observation establishes current actual
resource and operation conditions.
A protected evidence dependency graph identifies correlated witnesses
and compromised-source propagation.
Materially invalid or contradictory observations fence affected
Candidate Acts.
Qualified replacement evidence may be obtained without expanding
source authority.
A cross-committed validation receipt binds the required observations.
Scoped non-bearer finality is prepared for the actual operation.
The actual receiving Finality Sink independently reconstructs the
pending effect and verifies source authority, evidence
correspondence, current resource state, and protected consumption
before release.
Das Expires 29 April 2027 [Page 560]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
38.86.4 — Not Merely Remote Attestation
5.7.3.78. Original Source — Global Page 3360
Remote attestation can support appraisal of selected claims about a
device or observer.
The proposed implementation separately determines whether the
observer is competent to establish the operation's required facts,
whether its evidence describes the current pending operation, and
whether the actual resource sink enforces the corresponding
consequence.
38.86.5 — Not Merely Cryptographic Evidence
A signed record can authenticate selected information.
The proposed architecture additionally checks scope, meaning, current
applicability, independent observations, and receiving-resource
effect correspondence.
38.86.6 — Not Merely Multiple Witnesses
Multiple witnesses may increase confidence under appropriate
assumptions.
The proposed combination represents trust dependencies and prevents
improperly counting correlated sources as independent.
38.86.7 — Not Merely Compromise Detection
Compromise detection identifies affected observers.
The proposed architecture binds witness eligibility to pending
Candidate Act dependencies and fences actual effectuation authority
accordingly.
38.86.8 — Not Merely Audit Logging
An audit log can preserve evidence history.
The proposed system uses qualified evidence as a mandatory pre-effect
condition and requires independent receiving-resource finality.
38.86.9 — Not Merely Policy-Based Access Control
A policy engine can evaluate evidence and grant an allow decision.
Das Expires 29 April 2027 [Page 561]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The proposed architecture prevents the allow decision from
independently becoming an unrestricted resource command by requiring
actual operation reconstruction and non-bearer finality.
38.86.10 — Candidate Narrow Inventive Kernel
A protected autonomous evidence-to-execution-finality system in which
a source-authorized Candidate Act remains non-effective, collection-
time evidence is bound to the Candidate Act and qualified through
observer identity and competence requirements, independent execution-
time evidence establishes current actual operation and resource
correspondence, a protected dependency controller fences finality for
Candidate Acts affected by compromised or inapplicable observers,
cross-committed
5.7.3.79. Original Source — Global Page 3361
validation evidence supports scoped non-bearer enablement, and an
independently enforcing actual Finality Sink reconstructs the pending
consequence and releases it only after current source, evidence,
resource, and protected sink-local consumption verification.
38.86.11 — Observer-Competence Kernel
A narrower candidate may require evidence-source competence
descriptors binding an authenticated observer to the specific actual
resource properties and event paths it is qualified to measure.
38.86.12 — Compromise-Containment Kernel
Another candidate may require transitive mapping of compromised
observer dependencies to pending Candidate Acts and protected
selective invalidation of associated finality.
38.86.13 — Attestation-Continuity Kernel
Another candidate may require current observer-state appraisal,
competence continuity, and effect-specific binding of qualified
attestation results to independent operation validation.
38.86.14 — Cross-Domain Semantics Kernel
Another candidate may require qualified evidence interpretation
across differing resource namespaces, units, status meanings, and
administrative authorities before protected finality.
38.86.15 — Actual-Sink Evidence Kernel
Das Expires 29 April 2027 [Page 562]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Another candidate may require the actual Finality Sink to
independently reconstruct the pending operation and compare it to a
protected validation receipt rather than merely accepting a prior
attestation or policy-engine approval.
38.86.16 — Witness-Dependence Kernel
Another candidate may require a protected independence analysis
preventing several witnesses with shared compromised observation
dependencies from satisfying a mandatory independent-witness policy.
38.86.17 — Evidence Nonresurrection Kernel
Another candidate may require current protected observer, appraisal,
revocation, and finality-consumption generations to prevent rollback-
based reacceptance of obsolete evidence.
38.86.18 — Anti-Hindsight Technical Analysis
An examiner may identify earlier systems providing:
Remote attestation;
Trusted sensor observations;
5.7.3.80. Original Source — Global Page 3362
Signed evidence;
Data provenance;
Multi-party approvals;
Quorum validation;
And independent resource authorization.
These components should be acknowledged rather than treated as new
individually.
The relevant analysis should examine whether the closest prior art
already discloses or motivates the specific claimed relationship
among:
1. Original source-authorized consequential Candidate Act; 2.
Enforceable Non-Effective State; 3. Protected operation-specific
evidence requirements; 4. Qualified collection-time evidence; 5.
Observer identity and competence binding; 6. Appropriate attestation
Das Expires 29 April 2027 [Page 563]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
appraisal without overinterpreting its scope; 7. Independent
execution-time actual operation observation; 8. Qualified
observation-channel independence; 9. Cross-domain evidence-semantic
correspondence; 10. Protected evidence-generation and freshness
checks; 11. Transitive compromised-observer dependency containment;
12. Operation-specific selective finality fencing; 13. Cross-
committed collection and execution validation evidence; 14. Scoped
non-bearer effectuation enablement; 15. Independent receiving-
resource operation reconstruction; 16. Current source and resource
authority validation; 17. Sink-local protected consumption; 18.
Recovery without evidence or authority resurrection.
38.86.19 — Functional Interaction Rather Than Aggregation
The proposed architecture does not depend merely upon the coexistence
of attestation, signatures, monitors, and gateways.
The evidence-requirement controller defines which observations are
mandatory for the exact source-authorized Candidate Act.
The observer-competence controller prevents an authenticated but
inadequate source from satisfying an unrelated predicate.
The independent execution-time witness checks the current operation
rather than trusting the original computational description.
The dependency controller prevents compromised evidence from
remaining operative through indirect aggregated records.
5.7.3.81. Original Source — Global Page 3363
Cross-committed validation evidence binds current qualified
observation to the Candidate Act.
The scoped non-bearer enablement restricts authority to the actual
effect and designated sink.
The Finality Sink reconstructs the actual pending operation and
independently controls effectuation.
The candidate technical interaction is the prevention of evidence
laundering into actual consequential authority, including through
authenticated, attested, or historically valid evidence that no
longer describes the effect being executed.
38.86.20 — Proposed Comparative Technical Evidence
A useful evaluation may determine whether:
Das Expires 29 April 2027 [Page 564]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
An authentic but factually false observation is accepted;
A valid platform measurement is treated as proof of an unobserved
operation;
Two correlated witnesses are incorrectly treated as independent;
A compromised observer's influence survives through a signed
aggregator;
A changed actual resource is accepted despite correct earlier
evidence;
An attestation result is reused for another Candidate Act;
And the actual Finality Sink prevents unauthorized effects under
those conditions.
38.86.21 — Required Patentability Qualification
The proposed disclosure establishes candidate implementation and
claim-support language.
It does not by itself establish novelty, inventive step, priority, or
enforceability.
A successful inventive-step argument must compare actual claim
limitations against properly dated and relevant prior art.
Existing attestation architectures, capability systems, independent
authorization gateways, and cryptographic evidence systems may
already disclose portions of the proposed combination.
The strongest argument should concern a specifically supported causal
enforcement relationship and demonstrable technical effects, not the
general statement that evidence should be trustworthy.
38.87 — INDUSTRIAL APPLICABILITY
5.7.3.82. Original Source — Global Page 3364
38.87.1 — Autonomous Enterprise Agents
Tool and resource evidence may be qualified independently before
consequential API operations.
38.87.2 — Cloud Infrastructure
Das Expires 29 April 2027 [Page 565]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Current resource, policy, and workload observations may be bound to
actual cloud effects.
38.87.3 — Trusted Computing
Attestation results may contribute to operation-specific
authorization without replacing actual sink verification.
38.87.4 — Hardware Security
Protected measurement and effectuation boundaries may provide
qualified evidence and command control.
38.87.5 — Industrial Automation
Sensor evidence and device-state observations may be validated
against actual protected physical commands.
38.87.6 — Robotics
Independent observers may establish required operating conditions
before actuation.
38.87.7 — Telecommunications
Network configuration changes may require current evidence of actual
target and service state.
38.87.8 — Satellite and Remote Systems
Attestation and operation evidence may be qualified across
intermittent communication domains.
38.87.9 — Financial Transactions
Actual recipients, amounts, and transaction states may be verified
rather than inferred from tool responses.
38.87.10 — Data Disclosure
Actual protected recipient and content evidence may control
consequential information release.
38.87.11 — Identity and Credential Systems
Das Expires 29 April 2027 [Page 566]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
5.7.3.83. Original Source — Global Page 3365
Attestation and workload identity may be combined with actual
resource audience and credential-use finality.
38.87.12 — Distributed Databases
Qualified committed-state receipts may support dependent resource
operations.
38.87.13 — Software Supply Chains
Current runtime and resource evidence may be distinguished from
earlier artifact attestations.
38.87.14 — Multi-Agent Orchestration
Evidence from different agents may be evaluated under explicit trust
and independence requirements.
38.87.15 — Confidential Computing
Protected observation domains may produce qualified evidence for
external relying parties.
38.87.16 — Cyber-Physical Systems
Current measurements and actual hardware command semantics may be
validated separately.
38.87.17 — Persistent AI Memory
Evidence provenance may control irreversible knowledge-store or
shared-memory commits.
38.87.18 — Connected Devices
Device-state evidence may be appraised under current resource-
specific policy.
38.87.19 — Regulated Technical Infrastructure
Authenticated evidence and independently enforced actual resource
changes may support technical accountability.
38.87.20 — Future Autonomous Critical Systems
Das Expires 29 April 2027 [Page 567]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Evidence-producing components may be treated as qualified witnesses
rather than as unrestricted authorities to cause real effects.
38.88 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
38.88.1 — Candidate Independent System Claim
A system comprising:
5.7.3.84. Original Source — Global Page 3366
A protected source-authority controller configured to identify a
permitted consequential operation;
A Candidate Act controller configured to maintain the proposed
operation in a Non-Effective State;
An evidence-requirement controller configured to define mandatory
operation-specific observations;
A protected collection-time evidence controller configured to bind
selected observations to the Candidate Act;
An observer-qualification controller configured to verify evidence-
producing entities against corresponding identity, competence,
resource-scope, and current eligibility requirements;
An independent execution-time evidence controller configured to
obtain qualified current information concerning the actual pending
operation;
An evidence-dependency controller configured to identify and fence
Candidate Acts affected by compromised, invalid, or materially
inapplicable observers;
A cross-committed validation controller configured to bind original
and current qualified evidence to the operation;
A scoped non-bearer finality controller;
And an independent actual Finality Sink configured to reconstruct the
pending real effect and conditionally release the effect only after
current source, evidence, resource, operation, and sink-local
protected consumption verification.
38.88.2 — Candidate Independent Method Claim
A method comprising:
Das Expires 29 April 2027 [Page 568]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Establishing original source authority for an actual consequential
operation;
Representing the operation as a Candidate Act;
Maintaining it in a Non-Effective State;
Identifying required factual predicates;
Obtaining protected collection-time evidence;
Qualifying the observer's identity and competence;
Appraising specified observer-state attestation evidence where
required;
Obtaining independent execution-time actual-operation evidence;
5.7.3.85. Original Source — Global Page 3367
Validating evidence freshness, resource identity, witness dependence,
and semantic correspondence;
Fencing affected operation finality when a mandatory observer or
evidence predicate becomes invalid;
Generating cross-committed protected validation evidence;
Preparing scoped non-bearer finality;
And permitting actual effectuation only through a receiving Finality
Sink that independently reconstructs and verifies the pending
operation and protected consumption.
38.88.3 — Candidate Independent Compromised-Observer Claim
A protected autonomous execution system configured to maintain
evidence dependency relationships among observers, derived evidence,
and pending consequential Candidate Acts, and upon qualification of
an observer compromise, identify direct and indirect affected
operations, fence corresponding pending effectuation authority, and
require current competent replacement evidence before eligible
operations may be revalidated.
38.88.4 — Candidate Independent Attestation-Continuity Claim
Das Expires 29 April 2027 [Page 569]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
A protected execution-finality system configured to bind an
operation-specific evidence requirement to qualified observer-state
attestation, current observer competence, independent execution-time
actual resource observation, and effect-specific non-bearer finality
enforced by the actual receiving resource.
38.88.5 — Candidate Independent Cross-Domain Witness Claim
A protected multi-domain autonomous execution system configured to
qualify external evidence according to competent producer identity,
actual resource namespace, evidence semantic profile, freshness,
required observation scope, and current relying-party authority, and
to require independent actual receiving-resource verification before
a consequential operation is released.
38.89 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
1. The computational workload comprises an autonomous AI agent. 2.
The workload invokes external tools. 3. The workload operates across
administrative domains. 4. The Candidate Act represents a
consequential resource operation. 5. The Candidate Act is maintained
non-effective. 6. An original source grant identifies permitted
actual effects. 7. A protected evidence requirement identifies
mandatory factual predicates. 8. The requirement is operation-
specific. 9. A protected collector acquires collection-time
evidence. 10. The collection-time evidence is bound to the Candidate
Act.
5.7.3.86. Original Source — Global Page 3368
11. The evidence identifies actual resource scope. 12. The evidence
identifies an observer identity. 13. The observer has a qualified
competence descriptor. 14. The descriptor identifies permitted
measurement types. 15. The descriptor identifies permitted resource
scopes. 16. The descriptor identifies actual observation paths. 17.
The descriptor identifies relevant measurement quality. 18. A
signing key is distinguished from factual competence. 19. Evidence
producer identity is verified. 20. Evidence provenance is verified.
21. Evidence freshness is verified. 22. Evidence resource identity
is verified. 23. Evidence operation identity is verified. 24.
Evidence schema generation is verified. 25. Evidence semantic
profile is verified. 26. Measurement units are verified. 27.
Resource namespaces are verified. 28. Receipt semantic classes are
verified. 29. A protected attestation appraisal may be required. 30.
The appraisal uses a qualified current policy. 31. The appraisal may
use reference values or endorsements. 32. A freshness challenge may
be used. 33. Attestation evidence is bound to the intended observer.
34. Attestation evidence is bound to the intended relying-party
Das Expires 29 April 2027 [Page 570]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
context. 35. An attestation result does not independently grant
source authority. 36. An unchanged measurement does not
automatically prove complete runtime
correctness. 37. An independent execution-time observer obtains
actual pending operation evidence. 38. The execution-time observer
may be outside the agent compromise domain. 39. An observer may be
located at an actual resource interface. 40. The observer may
qualify actual network destinations. 41. The observer may qualify
actual database records. 42. The observer may qualify actual file
objects. 43. The observer may qualify actual credential audiences.
44. The observer may qualify actual physical device commands. 45. A
protected graph identifies shared witness dependencies. 46.
Correlated observers are distinguished from independent observers.
47. A witness quorum is interpreted under defined fault assumptions.
48. Conflicting mandatory evidence may cause finality fencing. 49.
An unqualified observer is excluded from mandatory evidence
satisfaction. 50. An observer's credential may be revoked. 51. An
observer's current measured state may change. 52. An observer's
competence may be withdrawn. 53. An observer's observation coverage
may become incomplete. 54. A protected controller identifies
directly affected Candidate Acts. 55. A protected controller
identifies indirectly affected Candidate Acts. 56. Derived evidence
retains relevant witness lineage. 57. A compromised evidence
aggregator does not independently restore source authority. 58. A
selective fence may invalidate affected pending finality. 59.
Unrelated independently qualified operations need not be invalidated
automatically.
5.7.3.87. Original Source — Global Page 3369
60. A replacement witness requires competent qualification. 61. A
replacement witness may require fresh attestation. 62. A replacement
witness may require independent observation-channel coverage. 63. An
affected Candidate Act requires current revalidation. 64. A
qualified cross-domain evidence mapping identifies resource
namespaces. 65. The mapping identifies evidence schema generation.
66. The mapping identifies measurement units. 67. The mapping
identifies receipt completion semantics. 68. The mapping identifies
current relying-party scope. 69. A valid signature does not override
an incorrect semantic interpretation. 70. A protected
canonicalization profile is associated with evidence serialization.
71. An evidence generation may be bound to the Candidate Act. 72. A
material evidence-generation change may invalidate pending finality.
73. A material resource-version change may invalidate pending
finality. 74. An obsolete attestation appraisal may be rejected. 75.
A revoked observer may not regain eligibility through snapshot
rollback. 76. An authenticated log may preserve selected evidence
Das Expires 29 April 2027 [Page 571]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
history. 77. Log inclusion does not independently prove the factual
accuracy of a record. 78. An absence of logged events requires a
qualified observation completeness model. 79. A protected verifier
may limit evidence size. 80. A protected verifier may limit nesting
depth. 81. A protected verifier may limit computational verification
cost. 82. Verification exhaustion does not authorize the pending
effect. 83. Evidence may be selectively disclosed while preserving
mandatory predicates. 84. Collection and execution evidence may be
cross-committed. 85. A protected validation receipt may identify the
actual Candidate Act. 86. The receipt may identify the actual
resource and operation. 87. The receipt may identify relevant
observer qualification. 88. The receipt may identify current
evidence-policy generation. 89. The receipt does not independently
function as unrestricted bearer authority. 90. Scoped non-bearer
finality may be bound to the validation receipt. 91. The actual
Finality Sink independently reconstructs the pending effect. 92. The
sink verifies current source and resource authority. 93. The sink
verifies current qualified evidence correspondence. 94. The sink
verifies protected consumption before effectuation. 95. Existing
remote attestation, authenticated evidence, protected logging,
workload
identity, semantic schemas, and independent resource gateways may be
used as non-limiting implementation substrates.
38.90 — UNIVERSAL COMBINATION, SUBCOMBINATION, AND NON-LIMITING
PHOSITA CLAUSE
The technical features disclosed herein may be implemented
individually where sufficient or in any technically compatible
combination.
An implementation may use software evidence collectors.
Another may use protected operating-system monitoring.
5.7.3.88. Original Source — Global Page 3370
Another may use hardware-assisted measurement.
Another may use remote attestation.
Another may use authenticated resource-side observations.
Another may use multiple independent witnesses.
Another may use a qualified quorum under a stated fault model.
Das Expires 29 April 2027 [Page 572]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Another may use signed evidence receipts.
Another may use append-only evidence logs.
Another may use cryptographic commitments.
Another may use protected evidence-dependency graphs.
Another may use observation-channel competence registries.
Another may use cross-domain evidence translation.
Another may use protected semantic profiles.
Another may use selective disclosure.
Another may use resource-specific current version checks.
Another may use protected observer-generation state.
Another may use observer revocation.
Another may use replacement evidence following compromise.
Another may use independent execution-time validation.
Another may use actual receiving-resource reconstruction.
Another may use scoped non-bearer finality.
Another may use protected sink-local consumption.
The invention does not require every operation to use remote
attestation.
The invention does not presume that every attested platform is free
from runtime vulnerabilities.
The invention does not presume that a signed sensor reading is
physically accurate.
The invention does not require that every independent witness use
different hardware.
5.7.3.89. Original Source — Global Page 3371
The invention does not assume that two signing keys provide
independent factual evidence.
Das Expires 29 April 2027 [Page 573]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The invention does not assert that a majority of witnesses must
always be correct.
The invention does not presume a protected log contains every
relevant event.
The invention does not presume that log inclusion establishes factual
truth.
The invention does not require unrestricted disclosure of sensitive
evidence fields.
The invention does not permit redaction to conceal mandatory
information necessary for protected validation.
The invention does not permit an attestation result to create missing
original source authority.
The invention does not permit an authenticated tool result to
substitute for actual receiving-resource effectuation evidence where
such evidence is mandatory.
The invention does not require a universal evidence schema across all
administrative domains.
The invention does not assume that identical textual resource
identifiers represent the same object across namespaces.
The invention does not assume that a collection-time observation
remains current after a material resource change.
The invention does not presume that a monitoring component controls
every alternate effectuation path.
The invention does not require that a compromised observer invalidate
every unrelated operation.
The invention does not permit compromised observations to regain
eligibility through unqualified aggregation or replay.
The invention does not require exact global clock synchronization
where qualified operation-generation or transactional evidence
suffices.
The invention does not presume that a software signature guarantees
non-rollback of all protected local state.
Das Expires 29 April 2027 [Page 574]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The invention does not permit successful evidence validation to
become unrestricted authority for a different actual operation.
The drawings, algorithms, equations, proposed experiments, data
structures, implementation mappings, and examples are illustrative,
optional, and non-limiting technical aids for a person having
ordinary skill in the art.
5.7.3.90. Original Source — Global Page 3372
Technically compatible features from other embodiments may be
combined where supported, without requiring all optional features in
every implementation.
38.91 — FINAL TECHNICAL CHARACTERIZATION
The present Embodiment 38 discloses a protected autonomous evidence-
to-execution-finality architecture.
An originating principal authorizes a bounded consequential
operation.
The computational workload generates a Candidate Act.
The Candidate Act remains in a Non-Effective State.
A protected controller establishes the evidence required to qualify
that act.
Collection-time evidence is obtained from competent sources.
Observer identity, observation coverage, current eligibility, and
optional attestation appraisal are qualified.
The protected controller distinguishes authenticated evidence from
the truth and applicability of the underlying observation.
An independent execution-time witness obtains current relevant
information concerning the actual pending operation.
The system verifies observation freshness, resource identity,
evidence semantics, channel dependence, current source authority, and
applicable revocation.
Material contradictions or compromised evidence sources trigger
selective containment of affected pending finality.
Das Expires 29 April 2027 [Page 575]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Qualified replacement evidence may restore operation eligibility only
after current revalidation.
Collection-time and execution-time evidence are cross-committed.
A protected validation receipt identifies the qualified Candidate Act
and actual effect.
Scoped non-bearer finality is prepared for the designated receiving
resource.
The actual Finality Sink reconstructs or independently observes the
pending operation and verifies that the actual consequence matches
the protected authorization and validation evidence.
The sink verifies current source, resource, evidence, and protected
consumption state before effectuation.
5.7.3.91. Original Source — Global Page 3373
Successful evidence collection, authentic signatures, and attestation
results cannot independently authorize a different resource effect.
A compromised observer cannot automatically propagate consequential
authority through derived evidence or stale receipts.
The protected system preserves the distinction between computational
evidence, qualified authorization evidence, and actual resource
finality.
The principal candidate inventive technical concept of Embodiment 38
is a protected autonomous evidence-integrity execution-finality
system in which a source-authorized Candidate Act remains non-
effective while collection-time and independently acquired execution-
time observations are qualified for observer identity, competence,
continuity, independence, and actual effect correspondence;
compromised observer dependencies selectively fence pending finality;
cross-committed evidence supports scoped non-bearer enablement; and
the actual receiving Finality Sink independently reconstructs and
verifies the consequential operation before protected authority
consumption and controlled effectuation.
38.92 — SHORT PHOSITA IMPLEMENTATION USING EXISTING TECHNOLOGIES
A person having ordinary skill in the art may use established
technologies as optional implementation substrates.
Das Expires 29 April 2027 [Page 576]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Existing technology Non-limiting implementation role RFC 9334 — RATS
Architecture
Separate attesters, evidence, verifiers, appraisal results, and
relying-party decisions RFC 9711 — Entity Attestation Token
Encode selected attested entity claims in an interoperable token
structure RFC 9999 — RATS Conceptual Message Wrapper
Encapsulate selected attestation-related conceptual messages
RFC 9052 — COSE Authenticate or sign selected evidence and validation
records
RFC 8949 — CBOR Encode structured evidence under a suitable
deterministic profile RFC 9162 — Certificate Transparency
Provide a reference model for append-only evidence logging,
consistency, and inclusion verification
Hardware-backed platform roots Support selected protected measurement
and attestation
claims Protected operating-system interfaces
Observe selected actual resource operations independently of the
agent Service and workload identities Identify competent protected
observers
Transactional databases Maintain evidence generations, dependencies,
revocations, and finality consumption
5.7.3.92. Original Source — Global Page 3374
Protected API and database gateways Independently reconstruct actual
consequential operations
Authenticated device and sensor interfaces Supply selected qualified
physical state evidence
Durable operation journals Preserve qualified evidence, actual
effects, and outcome classifications
38.92.1 — Practical Common PHOSITA Workflow
First, establish original source permission for the exact
consequential operation.
Das Expires 29 April 2027 [Page 577]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Second, represent the operation as a Candidate Act and hold its
effect non-effective.
Third, identify mandatory evidence predicates and their competent
observer roles.
Fourth, establish observer identity, actual observation coverage, and
current required measurement properties.
Fifth, collect and protect collection-time evidence bound to the
Candidate Act.
Sixth, appraise selected observer attestation evidence under the
applicable current policy where required.
Seventh, identify shared dependencies between evidence-producing
components.
Eighth, obtain current execution-time evidence through a qualified
observation path independent of the proposing agent to the extent
required by the threat model.
Ninth, verify actual resource, operation, units, namespace, schema,
freshness, and evidence-policy correspondence.
Tenth, fence pending finality where mandatory evidence is invalid,
compromised, contradictory, or unavailable.
Eleventh, trace compromised observer effects through direct and
derived evidence dependencies.
Twelfth, obtain qualified replacement evidence where permitted and
revalidate affected operations.
Thirteenth, cross-commit the original Candidate Act, collection-time
evidence, execution-time evidence, observer qualification, and actual
operation descriptor.
Fourteenth, issue a protected validation receipt.
Fifteenth, prepare scoped non-bearer finality tied to the current
actual resource and designated sink.
5.7.3.93. Original Source — Global Page 3375
Sixteenth, require the receiving Finality Sink to independently
reconstruct the pending consequential operation.
Das Expires 29 April 2027 [Page 578]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Seventeenth, check current source, evidence, actual resource, and
protected consumption conditions at the sink.
Eighteenth, conditionally effectuate the exact qualified operation
and preserve accurate outcome evidence.
38.92.2 — Minimal Reference Data Structures
EVIDENCE_REQUIREMENT ( candidate_id, source_grant_reference,
actual_resource_id, operation_digest, required_predicates,
accepted_observer_classes, required_independence, freshness_policy,
sink_id ) OBSERVER_COMPETENCE ( observer_id,
permitted_measurement_scope, actual_observation_path,
semantic_profile, attestation_requirement, current_generation,
revocation_generation ) COLLECTION_EVIDENCE ( candidate_id,
observer_id, resource_id, observed_operation_digest,
observed_generation, evidence_commitment ) EXECUTION_EVIDENCE (
candidate_id, execution_observer_id, actual_resource_id,
actual_operation_digest, current_resource_generation,
evidence_commitment )
5.7.3.94. Original Source — Global Page 3376
VALIDATION_RECEIPT ( candidate_id, collection_commitment,
execution_commitment, observer_qualification_commitment,
current_policy_generation, actual_effect_digest, sink_id )
SINK_FINALITY ( candidate_id, validation_receipt_commitment,
actual_target, actual_effect_digest, current_revocation_generation,
protected_consumption_state )
These structures are illustrative.
The enforceable technical behavior depends upon qualified observation
paths, appropriate trust boundaries, and actual protected receiving-
resource controls rather than merely storing the listed fields.
38.92.3 — Decisive Prototype for Hindsight Analysis
A PHOSITA may construct a reference system with:
One autonomous agent;
One simulated untrusted tool;
One source-authority controller;
One collection-time evidence observer;
Das Expires 29 April 2027 [Page 579]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
One independently controlled execution-time resource gateway;
One protected observer-competence registry;
One simple attestation appraisal service or evaluator;
One transactionally enforced database Finality Sink;
And one protected evidence and finality journal.
The source principal authorizes modification of one specified
database record.
The agent obtains authentic collection-time evidence for the correct
target.
5.7.3.95. Original Source — Global Page 3377
The evidence producer passes a selected attestation appraisal.
Before final effectuation, the attacker changes the actual database
target while preserving the earlier authentic signed evidence.
The execution-time resource gateway reconstructs the real database
mutation.
The protected validator detects the difference.
The receiving sink refuses the unauthorized update.
In a second variant, the collection-time observer is compromised.
Its evidence is submitted through a separate signed aggregator.
The protected dependency controller identifies that the aggregated
evidence still relies upon the compromised source.
The affected Candidate Act is fenced.
In a third variant, a qualified independent replacement observer
provides current evidence.
The system revalidates the operation without changing its original
source-authorized scope.
In a fourth variant, the correct operation passes all required
evidence conditions.
Das Expires 29 April 2027 [Page 580]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
The sink validates scoped non-bearer finality and commits the update
once.
A replayed validation receipt cannot cause a second unauthorized
mutation.
The evaluation should inspect the actual receiving database state and
protected finality journal.
38.92.4 — Critical PHOSITA Implementation Cautions
An attested observer can still contain logical vulnerabilities.
An authenticated sensor can still be inaccurate.
Several observers can share the same faulty upstream source.
A cryptographic commitment does not establish factual correctness of
committed data.
Log inclusion is different from event completeness or factual
validity.
A platform measurement is not automatically proof of current
application-layer behavior.
Cross-domain evidence must preserve correct units, resource
namespaces, and semantic interpretations.
6. PHOSITA Implementation: Existing Technologies, Protected Components
and Cross-Resource Deployment
The following reference implementation guidance is newly authored
engineering material, not a claim of a completed prototype. A
skilled engineer can construct a cooperating demonstrator using
transaction-capable SQL databases, authenticated resource-owner APIs,
current cryptographic libraries, scoped OAuth grants, event journals,
gateway services, bounded evidence validation, and independent
receiver-side operation checks. Real guarantees remain dependent on
actual resource participation and protected trust boundaries.
6.1. Minimal cooperating multi-resource testbed
Deploy an untrusted agent client, task-authority service, protected
validation service, two independent effect-owner API servers, a
serializable database for protected finality consumption and an
outcome reconciliation service. Use simulated payments or documents;
do not issue real financial or physical effects.
Das Expires 29 April 2027 [Page 581]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
6.2. Canonical Candidate Act and transaction envelope
Create typed operation, target, recipient, amount, material request
body commitment, source grant ID, authority epoch, desired outcome
predicate and designated sink. A multi-resource transaction envelope
references constituent CAs and authenticated dependency edges; a plan
alone is not reusable resource authority.
6.3. Protected source grant capture
Use identity authentication and scoped permission evidence (e.g.
structured authorization details) as inputs to a separate current
consequence predicate. Validate issuer, audience, permitted
operation and live revocation conditions independently of agent
statements.
6.4. Remote owner and actual operation identity
At each independent recipient service, bind tenant, actual object,
transaction parameters and receiver identity from the protected
processing interface. Do not treat a hostname, HTTP 200 or gateway
approval as proof of final resource state.
6.5. Material payload binding and canonicalization
Serialize effect descriptors deterministically using agreed CBOR or
JSON profile, explicit numeric handling, relevant resource version,
recipient, destination and digest algorithm. Validation failure or
ambiguous encoding withholds the effect.
6.6. Receipt acquisition and factual outcome qualification
Capture supported actual resource mutation, committed row/transaction
ID, receiving state generation, qualified time and approved
observation mode. A signed request receipt proves only the signed
proposition; verify the intended real consequence predicate
separately.
6.7. IEV deployment and separation
Where receipt-dependent continuation is mandatory, operate IEV with
independent credentials and protected state. Bind IEV identity,
predecessor phase, actual effect evidence, current authorization and
accepted continuation condition.
Das Expires 29 April 2027 [Page 582]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
6.8. Crash-consistent journal
Use a serializable protected database with a write-ahead log, unique
logical operation ID, effect-intent entry, consumed-finality marker
and separate outcome state. Never erase uncertainty by restarting
the agent.
6.9. Effect release transaction ordering
Stage operation intent, validate current source and sink state,
commit protected consumption, then invoke the actual controlled
effect according to the selected protocol. Document crash windows
and why protected consuming a token is not equal to a remote effect
commit.
6.10. Idempotency-key provider qualification
If a receiver offers transaction ID deduplication, document its
scope, retention, uniqueness, failure semantics and authoritative
enforcement. If absent, treat lost confirmation of non-idempotent
work as indeterminate and prevent blind replay.
6.11. Read-after-write reconciliation
Query the authoritative resource with a protected logical operation
identifier or compare authenticated versioned state; rate-limit and
boundedly retry reconciliation. A stale replica, log event or user
interface may not prove remote finality.
6.12. Distributed orchestration with explicit commit modes
Select genuine supported prepare/commit only for participating
transactional resources; otherwise use explicit sequential causal
release, authorized compensations or containment. Never describe
cross-provider saga coordination as global ACID atomicity.
6.13. Independent constituent sinks
Give each resource owner its own protected current authorization
check, material operation reconstruction, bounded consumption and
result evidence. A central AI coordinator must not unilaterally
release a resource that lacks competent local enforcement.
Das Expires 29 April 2027 [Page 583]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
6.14. Partial-commit containment
Record which actual effects are proven committed versus rejected or
unknown; suspend successors that require missing predecessors;
invalidate incompatible prepared capabilities and prevent broad retry
or plan mutation.
6.15. Compensation authorization controller
Treat a refund, delete, revert, cancel or safety action as a new
Recovery Candidate Act, with new target/state checks and own current
source grant. Original task permission does not authorize unlimited
compensations.
6.16. Recovery generation and bounded budget
Define recovery-class envelopes, generation counters, attempt limits
and cumulative effect budgets across retries and compensation.
Protect counters against concurrent use, snapshot rollback and lost
response confusion.
6.17. Witness provenance and independence
Store signed observer evidence alongside its measurement source,
competence scope, software generation, roots of trust, correlation
group, appraisal outcome and time. Do not count two signatures over
one common compromised telemetry source as independent witnesses.
6.18. Hardware and irreversible consequence frontiers
Where a supported device or owner controller mediates a physical
release, perform current hazard-state checks, rate/amount bounds and
emergency interlock verification at that frontier. Cryptographic
authentication alone does not substitute for functional-safety
engineering.
6.19. iOS and Android cooperating deployment
Use documented app-owned intents and Android app component APIs to
propose acts; implement authoritative remote-resource enforcement in
a cooperating server or app-owned guarded service. Ordinary third-
party applications cannot claim complete OS-wide control of other
apps or devices.
Das Expires 29 April 2027 [Page 584]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
6.20. Cloud, financial and telecom resource adapters
Integrate with a qualified payment sandbox, cloud infrastructure test
account or virtual network controller. Verify actual receiving-
account/project/resource IDs and cross-administrative-domain policy;
avoid live privileged production actions.
6.21. Failure injection and logs
Use deterministic fault injection at validation, journal commit,
network dispatch, receiver accept, receiver commit and acknowledgment
delivery. Capture durable before/after effect state, redacted audit
evidence, protected consumption, and reconciliation decisions.
6.22. Noncooperating receiver limitation
When a remote endpoint lacks a trustworthy receipt or receiving gate,
document reduced guarantees and withhold safety-critical dependent
continuation. Do not claim arbitrary external resource effects can
be proven merely from an upstream audit log.
6.23. Alternative trusted substrates
An independently operated service, database transaction controller,
secure processor, attested TEE, protected network gateway or
cooperating hardware sink may enforce selected conditions;
alternatives are technically compatible only when they maintain the
required trust and actual-effect properties.
7. Reference Data Models, Protected State Transitions and Illustrative
Algorithms
The examples below are illustrative newly authored protocol
engineering aids, not historical as-filed claim text or a completed
GitHub implementation. All fields and canonicalization rules require
independent review in an actual deployment. No pseudocode assumes
that a receiver with no direct enforcement interface can offer
stronger guarantees than it implements.
7.1. Candidate Act and Finality Request Record
Illustrative non-limiting reference protocol; check applicable trust,
authority, actual-effect semantics and failure mode.
Das Expires 29 April 2027 [Page 585]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
CandidateAct = { act_id, source_grant_id, source_epoch,
target_resource_id, tenant_id, method, effect_class,
recipient, payload_digest, resource_version,
designated_sink_id, allowed_effect_budget,
dependency_receipts[], requested_deadline }
FinalityRequest = { candidate_id, actual_operation,
protected_evidence_commitments[], sink_consumption_nonce }
Rule: actual target and effect MUST match the qualified
Candidate Act at receiving FS before final consumption.
Figure 15: Candidate Act and Finality Request Record — reference
interface or algorithm
7.2. Actual Remote-Effect Receipt and Observer Provenance
Illustrative non-limiting reference protocol; check applicable trust,
authority, actual-effect semantics and failure mode.
RemoteEffectReceipt = { logical_operation_id, sink_id,
observed_target, effect_class, actual_result,
committed_resource_version, outcome_class,
observer_id, competence_scope, observation_epoch,
evidence_digest, independence_group, signature }
Verify exact result proposition, scope, time, target,
independence and source; signature alone is insufficient.
Figure 16: Actual Remote-Effect Receipt and Observer Provenance —
reference interface or algorithm
7.3. Protected Effect-Intent Journal
Illustrative non-limiting reference protocol; check applicable trust,
authority, actual-effect semantics and failure mode.
JournalEntry = { logical_operation_id, candidate_digest,
source_grant_epoch, sink_id, reserved_budget,
consumption_generation, intent_status,
dispatch_status, observed_outcome, reconciliation_ref }
States: NEW -> HELD_NES -> QUALIFIED -> CONSUMED
-> DISPATCHED -> CONFIRMED / INDETERMINATE /
REFUSED / QUALIFIED_NOT_EFFECTED.
Do not reset consumed authority on local restart.
Figure 17: Protected Effect-Intent Journal — reference interface
or algorithm
Das Expires 29 April 2027 [Page 586]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
7.4. Remote Operation Outcome Reconciliation
Illustrative non-limiting reference protocol; check applicable trust,
authority, actual-effect semantics and failure mode.
function RECONCILE(id, protected_journal, resource):
j = protected_journal.lookup(id)
if j.has_qualified_confirmed_effect(): return CONFIRMED
observed = resource.qualified_lookup(id)
if observed.proves_exact_effect(j): return CONFIRMED
if observed.proves_non_effectuation(j): return NOT_EFFECTED
return INDETERMINATE // never silently re-send
Figure 18: Remote Operation Outcome Reconciliation — reference
interface or algorithm
7.5. Scoped Finality Consumption at Receiving Resource
Illustrative non-limiting reference protocol; check applicable trust,
authority, actual-effect semantics and failure mode.
function SINK_FINALITY(pending, ca, receipt, local):
actual = protected_observe(pending)
require current_source_grant(ca)
require match_actual_target_and_params(actual, ca)
require qualified_dependencies(receipt, ca)
require local.current_sink_and_revocation_state()
require local.atomic_consume(ca.enablement_id)
return EFFECTUATE_EXACT_ACTUAL_OPERATION(actual)
On any required check failure: WITHHOLD.
Figure 19: Scoped Finality Consumption at Receiving Resource —
reference interface or algorithm
7.6. Qualified Compensating Candidate Act
Illustrative non-limiting reference protocol; check applicable trust,
authority, actual-effect semantics and failure mode.
function PREPARE_COMPENSATION(original, outcome, delta):
require qualified_original_outcome(outcome)
require competent_recovery_authority(original, delta)
require recovery_class_allows(delta, actual_resource)
ca = new_RecoveryCandidateAct(delta, fresh_generation)
return CA_HELD_NON_EFFECTIVE(ca)
Compensation sink independently verifies and consumes;
no previously used grant is silently revived.
Das Expires 29 April 2027 [Page 587]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Figure 20: Qualified Compensating Candidate Act — reference
interface or algorithm
7.7. Multi-Resource Intent Decomposition
Illustrative non-limiting reference protocol; check applicable trust,
authority, actual-effect semantics and failure mode.
Transaction = { transaction_id, original_grant,
effects: [CA_A, CA_B, CA_C],
dependencies: [(A,B),(B,C)], budget, partial_policy,
atomicity_mode: SUPPORTED_2PC or GUARDED_SEQUENTIAL }
for each effect in dependency order:
verify accepted predecessor ACTUAL effects
validate exact current receiving resource and source
release only through its qualified Finality Sink.
Figure 21: Multi-Resource Intent Decomposition — reference
interface or algorithm
7.8. Partial Commit Containment
Illustrative non-limiting reference protocol; check applicable trust,
authority, actual-effect semantics and failure mode.
function CONTAIN_PARTIAL(tx, outcomes):
vector = qualify_each_actual_outcome(outcomes)
FENCE(uncommitted_or_stale_successors(tx))
PRESERVE(all_proven_completed_effects(vector))
HOLD(all_indeterminate_effects(vector))
propose recovery acts only under qualified fresh grants
return vector // no fictitious global rollback
Figure 22: Partial Commit Containment — reference interface or
algorithm
7.9. Irreversibility Frontier Gate
Illustrative non-limiting reference protocol; check applicable trust,
authority, actual-effect semantics and failure mode.
Das Expires 29 April 2027 [Page 588]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
function QUALIFY_IRREVERSIBLE(ca, actual, hazard):
require effect_frontier_defined(actual)
require source_authorized_exact_effect(ca, actual)
require fresh_competent_hazard_observation(hazard)
require current_resource_identity_and_budget(actual)
require required_interlock_and_safety_predicates()
return sink_atomic_single_use_consume_and_effect()
No safe rollback or compensation is presumed.
Figure 23: Irreversibility Frontier Gate — reference interface or
algorithm
7.10. Observer Dependency and Correlation Test
Illustrative non-limiting reference protocol; check applicable trust,
authority, actual-effect semantics and failure mode.
for each witness w:
verify authenticated_current_identity(w)
verify competence(w, measurement_semantics)
verify time_and_scope(w, candidate)
construct dependency graph over original data sources,
credentials, sensors, software, administrative control.
Count independent corroboration only under declared
separation policy; shared-source signatures are correlated.
Figure 24: Observer Dependency and Correlation Test — reference
interface or algorithm
7.11. Time-Out and Retry Protocol
Illustrative non-limiting reference protocol; check applicable trust,
authority, actual-effect semantics and failure mode.
if response == TIMEOUT:
mark operation INDETERMINATE
block blind replay with already-consumed enablement
query authoritative resource by logical_operation_id
if proven NOT_EFFECTED and competent retry grant:
construct fresh bounded Candidate Act
else:
wait/contain or launch authorized recovery
Never equate transport timeout with failed real effect.
Figure 25: Time-Out and Retry Protocol — reference interface or
algorithm
Das Expires 29 April 2027 [Page 589]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
7.12. Protected Causal Continuation Evaluation
Illustrative non-limiting reference protocol; check applicable trust,
authority, actual-effect semantics and failure mode.
for successor in authorized_dependency_graph:
require current original/delegated source authority
for parent in successor.mandatory_predecessors:
require accepted actual-effect receipt(parent)
require competent IEV acceptance where mandated
require bound successor target and effect version
require receiving FS independent reconstruction
atomically consume scoped successor finality.
Figure 26: Protected Causal Continuation Evaluation — reference
interface or algorithm
8. Explicit Threat Models, Attacker Capabilities, Trust Boundaries and
Residual Risk
These are proposed modelled threats for independent implementation
review, not an allegation that any named commercial product is
vulnerable. Each mitigation is conditioned on protection of the
defined components and mediation of the actual effect path.
8.1. Threat 1 — Prompt-injected multi-service agent
Adversary capability and failure objective: An attacker controls
retrieved document or tool response to demand unauthorized cloud or
payment effects.
Required or candidate control: Preserve original grant; receiver-side
exact act verification; reject untrusted content as authority.
Residual risk and trust boundary: Agent or other component with
unmediated direct effect credentials may evade the gate.
8.2. Threat 2 — Duplicate payment after timeout
Adversary capability and failure objective: An authenticated request
commits but the reply is suppressed, inducing a second non-idempotent
transfer.
Required or candidate control: Indeterminate state, authoritative
lookup, scoped consumption, qualified receiver idempotency if
provided.
Das Expires 29 April 2027 [Page 590]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Residual risk and trust boundary: No cross-provider duplicate
prevention without participating receiver or qualified non-
effectuation proof.
8.3. Threat 3 — Forged remote success receipt
Adversary capability and failure objective: Attacker signs false
evidence or replays authentic receipt from another target.
Required or candidate control: Bind observer competence, protected
target/resource, actual result, freshness and sink state.
Residual risk and trust boundary: Compromised competent observer or
unobserved effects can undermine factual proof.
8.4. Threat 4 — Correlated evidence masquerading as independent
Adversary capability and failure objective: Several signed reports
all derive from one compromised monitoring feed.
Required or candidate control: Represent witness/source dependency;
do not count correlated data as independent observations.
Residual risk and trust boundary: Hidden shared dependencies are
difficult to discover; fault model must be explicit.
8.5. Threat 5 — Crash/snapshot rollback
Adversary capability and failure objective: Attacker restores prior
agent snapshot after one-time authorization was consumed.
Required or candidate control: Durable authoritative consumption,
monotonic epoch and remote journal state.
Residual risk and trust boundary: If the authoritative protected
journal itself rolls back, guarantees fail absent external monotonic
anchor.
8.6. Threat 6 — Multi-resource partial-commit manipulation
Adversary capability and failure objective: Coordinator claims entire
transaction failed even though first financial or resource effect
committed.
Required or candidate control: Independently collect actual outcome
vector, fence successors and authorize new compensation separately.
Das Expires 29 April 2027 [Page 591]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Residual risk and trust boundary: Some effects are not reversible and
remote providers may not offer adequate evidence.
8.7. Threat 7 — Recovery scope escalation
Adversary capability and failure objective: An agent uses failure as
justification for extra refunds, deletion or compensation.
Required or candidate control: Separately authorized recovery
Candidate Act and current scoped sink checks.
Residual risk and trust boundary: A compromised original principal or
competent policy controller falls within stronger attacker model.
8.8. Threat 8 — Cross-domain destination substitution
Adversary capability and failure objective: Redirect sends data/
payment to a new tenant or resource after original approval.
Required or candidate control: Current actual receiving target,
tenant, audience and material request binding.
Residual risk and trust boundary: Inadequate receiving application
identity exposes residual ambiguity.
8.9. Threat 9 — Irreversible act with stale hazard state
Adversary capability and failure objective: A device safety interlock
or sensor measurement becomes stale before actuation.
Required or candidate control: Protected current hazard evidence and
effect frontier checks at actual actuation sink.
Residual risk and trust boundary: Cryptographic proof cannot make
unreliable sensors accurate or undo physical harm.
8.10. Threat 10 — Resource exhaustion and evidence flooding
Adversary capability and failure objective: Attacker forces excessive
witness verification, reconciliation loops or dependency breadth.
Required or candidate control: Bounded budgets, resource-limited
verification and fail-closed exhaustion.
Residual risk and trust boundary: Availability may decrease; system
must not permit consequence merely due to timeouts.
Das Expires 29 April 2027 [Page 592]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
8.11. Threat 11 — Compromised protected gate
Adversary capability and failure objective: Attacker controls
independent validation service or authoritative consumption state.
Required or candidate control: Defense in depth, multi-domain
protected evidence where required, key isolation and independent
audit.
Residual risk and trust boundary: Complete compromise of final
competent enforcement root exceeds specified assurance.
8.12. Threat 12 — Queue accepted but actual work deferred
Adversary capability and failure objective: A broker acknowledges the
job, and coordinator falsely enables successors before real
downstream completion.
Required or candidate control: Classify queued/accepted separately
from actual qualified result; require suitable finality receipt.
Residual risk and trust boundary: Destination systems may never
provide adequate real-effect observation.
9. Technical Validation: Proposed Reproducible Test Cases and Expected
Actual-Effect Results
All test cases below are proposed and NOT EXECUTED. For each
laboratory test use non-production receiving resource simulators,
authenticated independently controlled validators, protected
operation journal, fault injector, frozen expected resource state,
replayable input fixture and event tracing. Measure the actual
before/after resource state; a log claiming REFUSE is not alone a
proof that the effect was prevented.
9.1. DE01 — Valid cross-domain effect
Test setup and stimulus: Authorized source, exact remote target and
qualified receiving-state evidence. Use fixture resource identity,
source policy generation, protected effect-intent journal and
independent sink observation.
Expected result: PERMIT one authorized effect; qualified receipt
supports requested dependent phase. Record precise actual before/
after remote state, reconciliation classification, single-use
consumption state and refusal reason.
Das Expires 29 April 2027 [Page 593]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.2. DE02 — Remote API accepted but work queued
Test setup and stimulus: Return 202 or queue ACK without proving
actual work completed. Use fixture resource identity, source policy
generation, protected effect-intent journal and independent sink
observation.
Expected result: Do not treat acceptance as completed consequential
effect. Record precise actual before/after remote state,
reconciliation classification, single-use consumption state and
refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.3. DE03 — False signed receipt
Test setup and stimulus: Sign success statement with wrong semantic
result or unqualified observer. Use fixture resource identity,
source policy generation, protected effect-intent journal and
independent sink observation.
Expected result: REFUSE receipt-based continuation. Record precise
actual before/after remote state, reconciliation classification,
single-use consumption state and refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.4. DE04 — Receipt replay from earlier operation
Test setup and stimulus: Replay old valid receipt under different
Candidate Act. Use fixture resource identity, source policy
generation, protected effect-intent journal and independent sink
observation.
Expected result: REFUSE due to operation/phase and generation
mismatch. Record precise actual before/after remote state,
reconciliation classification, single-use consumption state and
refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
Das Expires 29 April 2027 [Page 594]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
9.5. DE05 — Receipt mismatch to destination
Test setup and stimulus: Keep correct signature but alter actual
receiving tenant. Use fixture resource identity, source policy
generation, protected effect-intent journal and independent sink
observation.
Expected result: REFUSE actual resource mismatch. Record precise
actual before/after remote state, reconciliation classification,
single-use consumption state and refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.6. DE06 — Correlated observers
Test setup and stimulus: Two keys report same compromised underlying
sensor feed. Use fixture resource identity, source policy
generation, protected effect-intent journal and independent sink
observation.
Expected result: Do not count as two independent qualified witnesses.
Record precise actual before/after remote state, reconciliation
classification, single-use consumption state and refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.7. DE07 — Qualified independent witnesses
Test setup and stimulus: Two authorized independent channels support
exact effect under selected policy. Use fixture resource identity,
source policy generation, protected effect-intent journal and
independent sink observation.
Expected result: ACCEPT evidence when all mandatory conditions pass.
Record precise actual before/after remote state, reconciliation
classification, single-use consumption state and refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.8. DE08 — Lost acknowledgement after effect
Test setup and stimulus: Commit remote effect then discard response.
Use fixture resource identity, source policy generation, protected
effect-intent journal and independent sink observation.
Das Expires 29 April 2027 [Page 595]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Expected result: INDETERMINATE until qualified actual result
obtained; no blind replay. Record precise actual before/after remote
state, reconciliation classification, single-use consumption state
and refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.9. DE09 — Proven non-effectuation
Test setup and stimulus: Resource-side state proves logical operation
never executed. Use fixture resource identity, source policy
generation, protected effect-intent journal and independent sink
observation.
Expected result: MAY prepare newly authorized bounded retry, not
resurrect stale enablement. Record precise actual before/after
remote state, reconciliation classification, single-use consumption
state and refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.10. DE10 — Crash before protected consumption
Test setup and stimulus: Terminate controller before finality
consumption. Use fixture resource identity, source policy
generation, protected effect-intent journal and independent sink
observation.
Expected result: No external effect; safe state according to journal
design. Record precise actual before/after remote state,
reconciliation classification, single-use consumption state and
refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.11. DE11 — Crash after consumption before dispatch
Test setup and stimulus: Terminate between committed consumption and
actual send. Use fixture resource identity, source policy
generation, protected effect-intent journal and independent sink
observation.
Das Expires 29 April 2027 [Page 596]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Expected result: Preserve consumed or unresolved status; no automatic
duplicate. Record precise actual before/after remote state,
reconciliation classification, single-use consumption state and
refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.12. DE12 — Crash after external commit
Test setup and stimulus: Remote effect succeeds; agent crashes before
journaling response. Use fixture resource identity, source policy
generation, protected effect-intent journal and independent sink
observation.
Expected result: Independent reconciliation confirms actual effect
and avoids duplicate. Record precise actual before/after remote
state, reconciliation classification, single-use consumption state
and refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.13. DE13 — Snapshot rollback
Test setup and stimulus: Restore client snapshot from before effect.
Use fixture resource identity, source policy generation, protected
effect-intent journal and independent sink observation.
Expected result: Already-consumed protected finality remains
unusable. Record precise actual before/after remote state,
reconciliation classification, single-use consumption state and
refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.14. DE14 — Two concurrent effect attempts
Test setup and stimulus: Race two agents using same single-use
finality reference. Use fixture resource identity, source policy
generation, protected effect-intent journal and independent sink
observation.
Expected result: At most authorized consumption count at
participating receiving sink. Record precise actual before/after
remote state, reconciliation classification, single-use consumption
state and refusal reason.
Das Expires 29 April 2027 [Page 597]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.15. DE15 — Multi-resource all commit
Test setup and stimulus: Resources A,B,C each independently validate
scope and dependencies. Use fixture resource identity, source policy
generation, protected effect-intent journal and independent sink
observation.
Expected result: Qualified complete outcome vector; only valid
constituent effects. Record precise actual before/after remote
state, reconciliation classification, single-use consumption state
and refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.16. DE16 — A commits B fails
Test setup and stimulus: Force failure of B after A actually commits.
Use fixture resource identity, source policy generation, protected
effect-intent journal and independent sink observation.
Expected result: Report partial commit, preserve A history, fence C.
Record precise actual before/after remote state, reconciliation
classification, single-use consumption state and refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.17. DE17 — Coordinator false rollback
Test setup and stimulus: Coordinator marks transaction FAILED despite
A payment confirmed. Use fixture resource identity, source policy
generation, protected effect-intent journal and independent sink
observation.
Expected result: Do not report A undone; require qualified new
recovery authority. Record precise actual before/after remote state,
reconciliation classification, single-use consumption state and
refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
Das Expires 29 April 2027 [Page 598]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
9.18. DE18 — Authorized compensation
Test setup and stimulus: Issue independently approved refund for
actual qualifying prior payment. Use fixture resource identity,
source policy generation, protected effect-intent journal and
independent sink observation.
Expected result: Allow once at compensation sink if current checks
pass. Record precise actual before/after remote state,
reconciliation classification, single-use consumption state and
refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.19. DE19 — Unauthorized compensation
Test setup and stimulus: Agent requests refund to different recipient
or amount. Use fixture resource identity, source policy generation,
protected effect-intent journal and independent sink observation.
Expected result: REFUSE independent recovery act. Record precise
actual before/after remote state, reconciliation classification,
single-use consumption state and refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.20. DE20 — Recovery generation replay
Test setup and stimulus: Replay consumed compensation generation.
Use fixture resource identity, source policy generation, protected
effect-intent journal and independent sink observation.
Expected result: REFUSE; journal remains non-replayable. Record
precise actual before/after remote state, reconciliation
classification, single-use consumption state and refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.21. DE21 — Irreversible-effect stale hazard
Test setup and stimulus: Change mandatory hazard predicate after
early approval. Use fixture resource identity, source policy
generation, protected effect-intent journal and independent sink
observation.
Das Expires 29 April 2027 [Page 599]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Expected result: FENCE before actual irreversible release. Record
precise actual before/after remote state, reconciliation
classification, single-use consumption state and refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.22. DE22 — Wrong irreversible target
Test setup and stimulus: Redirect qualified command to another
actuator. Use fixture resource identity, source policy generation,
protected effect-intent journal and independent sink observation.
Expected result: REFUSE due to actual target mismatch. Record
precise actual before/after remote state, reconciliation
classification, single-use consumption state and refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.23. DE23 — Fresh authorized irreversible command
Test setup and stimulus: All current safety, authority and frontier
conditions pass. Use fixture resource identity, source policy
generation, protected effect-intent journal and independent sink
observation.
Expected result: PERMIT one exact controlled operation; record
qualified result. Record precise actual before/after remote state,
reconciliation classification, single-use consumption state and
refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.24. DE24 — Time-of-check/time-of-effect drift
Test setup and stimulus: Resource changes between validation and
finality. Use fixture resource identity, source policy generation,
protected effect-intent journal and independent sink observation.
Expected result: Refuse or revalidate at actual sink. Record precise
actual before/after remote state, reconciliation classification,
single-use consumption state and refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
Das Expires 29 April 2027 [Page 600]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
9.25. DE25 — Observer software generation change
Test setup and stimulus: Replace observer software after evidence
collection. Use fixture resource identity, source policy generation,
protected effect-intent journal and independent sink observation.
Expected result: Requalify if generation is a mandatory evidence
predicate. Record precise actual before/after remote state,
reconciliation classification, single-use consumption state and
refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.26. DE26 — Receiver without finality API
Test setup and stimulus: Simulate third-party payment service with no
stable operation ID or usable effect receipt. Use fixture resource
identity, source policy generation, protected effect-intent journal
and independent sink observation.
Expected result: Declare limited guarantees; withhold unsafe retries
or dependent authorization. Record precise actual before/after
remote state, reconciliation classification, single-use consumption
state and refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.27. DE27 — Verification exhaustion
Test setup and stimulus: Exceed witness validation count, time budget
or dependency depth. Use fixture resource identity, source policy
generation, protected effect-intent journal and independent sink
observation.
Expected result: Bound work and WITHHOLD on mandatory missing
verification. Record precise actual before/after remote state,
reconciliation classification, single-use consumption state and
refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
Das Expires 29 April 2027 [Page 601]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
9.28. DE28 — Android and iOS cooperating clients
Test setup and stimulus: Different mobile clients request same
authorized remote resource through a protected resource owner. Use
fixture resource identity, source policy generation, protected
effect-intent journal and independent sink observation.
Expected result: Equivalent bound effect and no duplicate finality;
no OS-wide mediation claim. Record precise actual before/after
remote state, reconciliation classification, single-use consumption
state and refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.29. DE29 — HTTP idempotency misunderstanding
Test setup and stimulus: Retry non-idempotent POST without provider
deduplication semantics. Use fixture resource identity, source
policy generation, protected effect-intent journal and independent
sink observation.
Expected result: Unsafe automatic replay blocked. Record precise
actual before/after remote state, reconciliation classification,
single-use consumption state and refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
9.30. DE30 — Revoked recovery authority
Test setup and stimulus: Withdraw source grant before a prepared
compensation reaches sink. Use fixture resource identity, source
policy generation, protected effect-intent journal and independent
sink observation.
Expected result: REFUSE under current revocation generation. Record
precise actual before/after remote state, reconciliation
classification, single-use consumption state and refusal reason.
Status: PROPOSED / NOT EXECUTED. No successful prototype or third-
party compliance is asserted.
Das Expires 29 April 2027 [Page 602]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
10. Detailed Industry and Product Alignment: Cross-Platform AI, Cloud,
Banking, Telecom and Autonomous Systems
Named platforms and products are discoverability context, not claims
of provider implementation, patent infringement, derivation or
endorsement. Each integration presupposes documented accessible APIs
and an actually cooperating resource owner; a third-party iOS or
Android app cannot assume control of all effects in other
applications. Apple, Siri, iOS, iPadOS, macOS, Android, Gemini,
Bixby, Copilot, Alexa, Matter, and other names used in this document
are trademarks of their respective owners.
10.1. Apple iOS, iPadOS, Siri, Shortcuts and App Intents
Industry-specific failure and security problem: An AI assistant
triggers cross-app or server operations while losing network
acknowledgment, observing only UI success, or receiving delayed
remote receipts.
Possible cooperating implementation and limitations: Use supported
app-owned intent/extension interfaces and a cooperating protected
receiving service; bind actual resource and task grant, record
operation ID and reconcile result. Do not assert universal iOS
kernel hooks.
10.2. Apple macOS automation and enterprise apps
Industry-specific failure and security problem: Shell or desktop
automation can publish files, alter project state or submit
credentialed remote operations with uncertain completion.
Possible cooperating implementation and limitations: Use app-owned
guarded operation gateways and protected source/resource state,
distinguish local process success from remote final commit.
10.3. Google Android, Intents, Binder and Keystore
Industry-specific failure and security problem: Agent task may cross
exported components, background work queues, network retry and remote
activity result.
Possible cooperating implementation and limitations: Verify caller
and actual target at cooperating app/resource boundary; Keystore
protects keys but does not prove downstream effect or prevent all
duplicate API operations.
Das Expires 29 April 2027 [Page 603]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
10.4. Google Gemini, Cloud Run, Kubernetes and GCP resource APIs
Industry-specific failure and security problem: Distributed agent
services chain microservices and mutate IAM, projects, databases and
shared resources under asynchronous event delivery.
Possible cooperating implementation and limitations: Propagate
permitted workload identity, retain independent resource-side effect
check and versioned outcome evidence; do not treat queue acceptance
as resource mutation proof.
10.5. Microsoft Azure, Windows and enterprise AI agents
Industry-specific failure and security problem: Automation spans
identity services, virtual machine deployments, administrative APIs
and databases that lack shared atomic commit.
Possible cooperating implementation and limitations: Use independent
receiving API gates, conditional resource versions, commit evidence
and protected compensation decisions.
10.6. OpenAI Agents SDK, Responses API, Codex and computer use
Industry-specific failure and security problem: Tool-using agents
issue consequential requests based on model outputs and third-party
content, and may retry after tool timeout.
Possible cooperating implementation and limitations: Separate model-
generated proposal from source authority, enforce effect identity at
resource owner, and contain unknown outcomes rather than duplicate.
10.7. Anthropic Claude Code, Managed Agents and developer automation
Industry-specific failure and security problem: Multi-step
development agents may modify repositories, credentials, cloud
deployments and external services; a failed step may follow earlier
committed effects.
Possible cooperating implementation and limitations: Use per-
operation effect control, qualified remote state and independent
authorized recovery; sandboxing alone does not undo committed
external effects.
10.8. Meta agent architectures and policy-mediated egress
Industry-specific failure and security problem: Credential brokers
and gateways can authenticate dispatch while actual downstream state
requires different evidence.
Das Expires 29 April 2027 [Page 604]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Possible cooperating implementation and limitations: Compare
independently checked actual effect and protected consumption
semantics without claiming Meta provides the disclosed mechanism.
10.9. NVIDIA OpenShell, Sentry, BlueField and accelerator environments
Industry-specific failure and security problem: Isolated AI tools and
hardware-mediated egress constrain agent paths but may not
independently establish remote payment, cloud mutation or device
completion.
Possible cooperating implementation and limitations: Integrate act-
bound gateway checks and receiving-resource outcome qualification
where interfaces are actually controlled.
10.10. Qualcomm Snapdragon and Arm-based trusted hardware
Industry-specific failure and security problem: Secure elements or
TEEs can protect credentials and counters, while remote resource
finality remains independently controlled.
Possible cooperating implementation and limitations: Combine
protected state and attested observation with receiver-side actual-
effect verification; no hardware attestation alone proves the
external effect.
10.11. Huawei and heterogeneous operating-system/device ecosystems
Industry-specific failure and security problem: Cross-device commands
can be submitted via different mobile frameworks and hardware
controllers while task migration or latency changes results.
Possible cooperating implementation and limitations: Use platform-
neutral effect descriptors, protected authority epochs and actual
receiving controller checks where supported.
10.12. Banks, card payments, fund transfers and merchant APIs
Industry-specific failure and security problem: Lost acknowledgment
after a transfer risks duplicate payment; a refund is a new money
movement and not retroactive deletion.
Possible cooperating implementation and limitations: Use provider-
confirmed transaction ID, protected intent journal, qualified
reconciliation, bounded compensation and independent payment sink.
Das Expires 29 April 2027 [Page 605]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
10.13. Cloud infrastructure and database deployments
Industry-specific failure and security problem: A change across
storage, IAM, network routing and orchestration may partially commit.
Possible cooperating implementation and limitations: Represent
constituent resource CAs, dependencies, version checks, bounded
effects and realistic partial commit states; avoid unsupported global
rollback claims.
10.14. Financial audit, insurance and compliance workflows
Industry-specific failure and security problem: Automated remediation
could improperly assume failed external actions or destroy
evidentiary history.
Possible cooperating implementation and limitations: Separate signed
request log, qualified effect evidence, preserved outcome audit and
new authorized mitigation.
10.15. Telecommunications 5G/6G core, edge and network management
Industry-specific failure and security problem: A coordinated network
change across controllers may partially apply; restoration can itself
disrupt service.
Possible cooperating implementation and limitations: Use actual
network-element confirmation where qualified, cross-controller
scopes, protected dependency graph and separately controlled
rollback/compensation.
10.16. Robotics, autonomous vehicles and industrial control
Industry-specific failure and security problem: A queued actuator
command, controller ACK or rollback flag may not demonstrate a
physical operation or undo it.
Possible cooperating implementation and limitations: Gate
irreversible frontier through current hazard predicates, competent
sensors, device-level safety interlocks and independent commanded
effect verification.
10.17. Healthcare administration and regulated records
Industry-specific failure and security problem: Automated system may
amend persistent clinical or claims records and then initiate
notifications across independently managed systems.
Das Expires 29 April 2027 [Page 606]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Possible cooperating implementation and limitations: Require current
record identity, source authority, resource version, qualified
outcome reconciliation and separately authorized corrections; this is
not clinical advice.
10.18. Satellites, remote edge and intermittent connectivity
Industry-specific failure and security problem: Remote effects may
occur during long disconnection and network partitions; stale
acknowledgments cannot establish current outcomes.
Possible cooperating implementation and limitations: Use bounded
preauthorized effect scopes, protected journals and eventual
reconciliation; immediate revocation or atomicity across unreachable
resources must not be promised.
10.19. Voice and System Assistants: Apple Siri, Google Gemini, Samsung
Bixby, Microsoft Copilot and Amazon Alexa
Industry-specific failure and security problem: "Send fifty dollars
to Priya" spoken to an assistant becomes a call into a banking or
payment app. If the reply is lost, the assistant may report failure
while the transfer succeeded, and the user or the assistant then
retries, producing a second transfer. Assistants also chain actions
across several apps, so a failure midway leaves some effects done and
others not.
Possible cooperating implementation and limitations: The receiving
app or backend journals each assistant-originated operation with a
stable operation identifier, treats a lost reply as indeterminate,
and refuses a retry until it has reconciled the original operation
against the bank or service record; any compensating action is a new
Candidate Act requiring fresh user authority. Third-party
implementers can enforce this only at their own action handlers and
servers.
Technical effect: A lost acknowledgment cannot turn one spoken
payment into two, and the assistant reports the actual outcome once
known rather than a guess (tests DE08, DE09, DE14, DE28).
10.20. Instant Payment Schemes: UPI, Pix, FedNow and SEPA Instant
Industry-specific failure and security problem: Instant payment
schemes settle within seconds and are generally irrevocable once
completed. AI agents and payment apps that retry after timeouts or
network loss can create duplicate irrevocable credits, and recovering
them depends on the recipient's cooperation.
Das Expires 29 April 2027 [Page 607]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Possible cooperating implementation and limitations: Bind each
payment Candidate Act to a unique transaction reference; journal
intent before dispatch; on timeout, query the scheme or bank status
interface as qualified evidence before any retry; treat any refund
request as a separately authorized recovery act; and place the
payment beyond the irreversible-effect frontier so that fresh
balance, payee and authority checks are required immediately before
release.
Technical effect: Duplicate irrevocable payments from retries are
prevented, and the system never assumes a refund is a rollback (tests
DE02, DE08, DE21, DE29).
10.21. Agentic Commerce, Checkout and Digital Wallets
Industry-specific failure and security problem: Shopping agents place
orders, authorize payments and arrange delivery across merchant,
payment processor and logistics systems. A payment authorized while
the order creation failed, or an order created while capture failed,
leaves the customer and merchant in inconsistent states that agents
may try to fix with unsafe retries or cancellations.
Possible cooperating implementation and limitations: Treat order,
authorization, capture and fulfilment as distinct resource effects
with their own sinks; record partial commits explicitly; authorize
voids, refunds and order cancellations as separate recovery Candidate
Acts bound to the observed actual state.
Technical effect: Partial checkouts are recorded and resolved
truthfully, without double charges, phantom orders or unauthorized
refunds (tests DE15 to DE19).
10.22. Securities Trading and Settlement
Industry-specific failure and security problem: Trading agents that
submit orders through broker APIs face the same uncertainty: an order
may have been accepted and partially filled even though the client
saw an error. Resubmitting can double the position.
Possible cooperating implementation and limitations: Use client order
identifiers and broker order-status queries as qualified evidence;
block resubmission while the original is indeterminate; treat
cancellations and offsetting trades as separately authorized recovery
acts with their own limits.
Technical effect: Positions are not doubled by retries, and
corrective trades cannot exceed the authority granted for recovery
(tests DE08, DE14, DE18, DE19).
Das Expires 29 April 2027 [Page 608]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
10.23. ERP, Warehouse and Supply-Chain Systems
Industry-specific failure and security problem: An order fulfilled by
an agent may need updates in an ERP, a warehouse management system
and a carrier system, each owned separately. Failures between them
leave stock reserved without shipment, or shipments without invoices.
Possible cooperating implementation and limitations: Model the order
as a multi-resource transaction with dependency-aware commit
controls; record which resources actually committed; drive completion
or compensation through separately authorized acts verified against
each system of record.
Technical effect: Inventory, shipment and billing states are
reconciled from evidence rather than assumed, reducing phantom stock
and unbilled shipments (tests DE15, DE16, DE17).
10.24. Multi-Leg Travel Bookings
Industry-specific failure and security problem: A trip may require a
flight, hotel and car from different providers. If the hotel booking
fails after the flight is ticketed, an agent may cancel the flight
automatically and incur fees, or rebook repeatedly after timeouts.
Possible cooperating implementation and limitations: Record each
booking leg's actual outcome; require explicit, separately authorized
recovery for cancellations that carry fees; block rebooking while a
leg is indeterminate.
Technical effect: Users are not charged for duplicate or unwanted
bookings, and costly cancellations happen only with fresh authority
(tests DE16, DE18, DE19).
10.25. Healthcare Prescriptions and Records
Industry-specific failure and security problem: Electronic
prescriptions and record updates sent by clinical automation may be
transmitted twice after communication failures, leading to duplicate
dispensing or conflicting record entries.
Possible cooperating implementation and limitations: Use stable
message identifiers and pharmacy or record-system acknowledgement as
qualified evidence; block resending while the outcome is
indeterminate; route corrections through separately authorized
amendment acts. This is an engineering pattern, not a medical-device
or clinical-safety certification.
Das Expires 29 April 2027 [Page 609]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Technical effect: A prescription or record update takes effect once,
and corrections are explicit, attributable acts rather than silent
retries (tests DE08, DE20).
10.26. Smart Home and Matter Devices
Industry-specific failure and security problem: Door locks, garage
doors and valves are often commanded over unreliable wireless links;
the command may execute while the acknowledgment is lost.
Automations that retry or toggle state can leave a door unlocked or a
valve open.
Possible cooperating implementation and limitations: Use
authenticated device state reports as qualified evidence of the
actual state; avoid toggling commands in favour of absolute target
states; require fresh authority for compensating commands such as re-
locking after an unintended unlock.
Technical effect: Physical device state is established from evidence
before any retry or compensation, reducing unsafe toggling after lost
acknowledgments (tests DE08, DE21, DE24).
10.27. Automotive Over-the-Air Updates and Remote Commands
Industry-specific failure and security problem: Vehicle software
updates are staged across partitions and may be interrupted; remote
commands such as unlock or start can be repeated after network loss.
Some update steps, once committed, cannot be safely reversed while
driving.
Possible cooperating implementation and limitations: Treat update
activation as an irreversible-effect frontier requiring fresh vehicle
state and authority; journal update phases for crash-consistent
recovery; reconcile remote commands against vehicle-reported state
before any repeat.
Technical effect: Updates are activated only from verified safe
state, interrupted updates recover deterministically, and remote
commands are not duplicated (tests DE10 to DE13, DE21).
10.28. Energy Dispatch and Utility Operations
Industry-specific failure and security problem: Dispatch instructions
to distributed energy resources and switching commands can be delayed
or partially executed. Re-sending a dispatch or reversing a
switching operation without knowing the actual state can create
hazards.
Das Expires 29 April 2027 [Page 610]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Possible cooperating implementation and limitations: Require
independent, qualified telemetry before re-dispatch or reversal;
treat energizing operations as beyond an irreversible-effect frontier
that needs fresh hazard state; make reversal a separately authorized
recovery act.
Technical effect: No re-dispatch or reversal occurs on unknown state,
and hazardous operations require current measurements (tests DE06,
DE07, DE21, DE24).
10.29. Telecommunications Provisioning, Number Porting and eSIM
Profiles
Industry-specific failure and security problem: Subscriber
provisioning touches billing, home subscriber databases, policy
systems and, for eSIM, profile download to the device. Partial
completion leaves customers billed without service, or with service
without billing; repeated profile downloads can conflict.
Possible cooperating implementation and limitations: Model
provisioning as a multi-resource transaction with explicit partial-
commit records; verify each network element's actual state; authorize
rollback or completion separately and bind it to the observed state.
Technical effect: Provisioning failures are detected and resolved
from evidence rather than assumed, avoiding duplicated or orphaned
subscriber states (tests DE15 to DE17).
10.30. Government, Tax and Regulatory Filings
Industry-specific failure and security problem: Agents that file
returns, declarations or applications on a user's behalf may submit
twice after a portal timeout, or believe a filing succeeded when it
was only queued.
Possible cooperating implementation and limitations: Use the filing
system's reference or acknowledgement as the qualified evidence of
submission; block resubmission while indeterminate; treat amendments
as separately authorized acts.
Technical effect: A filing is submitted once and its status is known
from the authority's own record, not from the agent's assumption
(tests DE02, DE08, DE20).
Das Expires 29 April 2027 [Page 611]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
10.31. Cloud Data Deletion, Backups and Retention
Industry-specific failure and security problem: Infrastructure agents
may delete resources, snapshots or backups. Deletion is often
irreversible, and a reported "rollback" may only recreate an empty
resource.
Possible cooperating implementation and limitations: Place deletion
of data without a verified recoverable copy beyond an irreversible-
effect frontier requiring fresh authority and evidence of backup
state; record what was actually deleted; never report recreation as
rollback.
Technical effect: Irreversible data loss requires current, verified
preconditions, and recovery claims are truthful about what was
restored (tests DE17, DE21, DE22, DE23).
10.32. Email, Messaging and Notifications
Industry-specific failure and security problem: Sent messages
generally cannot be recalled; "unsend" features are best-effort.
Agents that resend after errors produce duplicates, and agents that
"undo" a message may only hide it locally.
Possible cooperating implementation and limitations: Treat sending as
crossing an irreversible-effect frontier; journal messages with
stable identifiers; reconcile with the sending service before any
resend; describe recall attempts as separate acts with uncertain
effect.
Technical effect: Duplicate messages from retries are avoided, and
the system does not claim that a sent message was undone (tests DE08,
DE17, DE21).
10.33. Summary of Technical Effects Across Industries
The following technical effects are the design objectives of the
distributed-effect and recovery mechanisms in this Part. They are
stated as testable properties linked to the proposed DE01 to DE30
tests; no measured results are claimed in this revision.
1. Acceptance is not completion: queued, accepted or transport-
successful requests are not treated as completed effects (DE02,
DE29).
2. Authentic, bound evidence: forged, replayed or mismatched
receipts cannot establish an outcome (DE03 to DE05).
Das Expires 29 April 2027 [Page 612]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
3. Real witness independence: correlated observers are not counted
as independent, and observer software changes are detected
(DE06, DE07, DE25).
4. Indeterminate containment: lost acknowledgments block retries
and successors until reconciliation, and proven non-effect
permits a fresh authorized attempt (DE08, DE09).
5. Crash and rollback safety: crashes and snapshot restores do not
lose, duplicate or resurrect authority (DE10 to DE13).
6. Single effect under concurrency: concurrent attempts produce at
most one effect (DE14).
7. Truthful multi-resource outcomes: partial commits are recorded
as such and false rollback claims are rejected (DE15 to DE17).
8. Separately authorized recovery: compensation runs only with its
own fresh, bounded authority, cannot be replayed across
generations, and stops when revoked (DE18 to DE20, DE30).
9. Irreversible-effect frontier: irreversible actions require fresh
hazard state, the exact target and current authority immediately
before execution (DE21 to DE24).
10. Honest coverage and portability: receivers without a finality
interface are reported as limits, and cooperating Android and
iOS clients interoperate (DE26, DE28).
11. Bounded verification: evidence flooding and verification
exhaustion are bounded (DE27).
11. Detailed IETF Working-Group, RFC and Protocol Interoperability
Relevance
Working-group subjects are included for truthful technical
discoverability and standards-context analysis, not as a claim of WG
adoption. Current charter and RFC details should be verified before
public submission. Existing authentication, identity, signed
evidence and HTTP semantics are valuable building blocks; no one
cited protocol is represented as guaranteeing actual finality across
independent resources.
11.1. OAuth WG: structured authorization and constrained credentials
Primary references: [RFC6749], [RFC9396], [RFC8707], [RFC8693],
[RFC9449].
Das Expires 29 April 2027 [Page 613]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Existing standards and chartered scope: RFC 9396 Rich Authorization
Requests, RFC 8707 Resource Indicators, RFC 8693 Token Exchange and
RFC 9449 DPoP address authorization detail, audience, token
delegation and sender constraint.
Specific additional technical problem and boundary: Their documented
authorization properties can inform source grant representation and
workload delegation. Receiving effect verification additionally
binds exact current resource, amount/recipient, outcome dependency
and sink-local consumption; token possession alone does not establish
real-world effect completion.
Official WG or RFC address: https://datatracker.ietf.org/wg/oauth/
about/
11.2. WIMSE WG: runtime workload identity and multi-hop service chains
Primary references: [WIMSE].
Existing standards and chartered scope: The WIMSE charter targets
runtime workload identity, least privilege and chains of HTTP/REST
services across trust boundaries and long-lived or asynchronous
transactions.
Specific additional technical problem and boundary: Use workload
identity propagation as authenticated provenance for distributed
agents. This Part 8 separately distinguishes transaction/recipient
identity from a factual remote-effect receipt and current
authorization at each independent resource owner.
Official WG or RFC address: https://datatracker.ietf.org/wg/wimse/
about/
11.3. RATS WG: attested observer and validator state
Primary references: [RFC9334].
Existing standards and chartered scope: RFC 9334 separates Attester,
Verifier, Endorser, Reference Value Provider and Relying Party roles
for evaluating attestable system claims.
Specific additional technical problem and boundary: Attestation may
qualify selected witness software/firmware/configuration or trust
evidence, but it cannot by itself prove real effect occurrence or
competence for a particular observation. Embodiment 38 additionally
analyzes witness-correlation and actual operation verification.
Das Expires 29 April 2027 [Page 614]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Official WG or RFC address: https://datatracker.ietf.org/wg/rats/
about/
11.4. COSE/CBOR: interoperable signed evidence encodings
Primary references: [RFC9052], [RFC8949].
Existing standards and chartered scope: RFC 8949 defines CBOR; RFC
9052 defines CBOR Object Signing and Encryption to authenticate
structured statements.
Specific additional technical problem and boundary: Possible
encodings for receipt, observation identity, protected state versions
and signed outcome vectors. Correct encoding, signatures and
canonicalization do not independently authenticate the truth of the
external event or authorize a different receiving operation.
Official WG or RFC address: https://datatracker.ietf.org/wg/cose/
about/
11.5. SCITT: transparency, receipts and accountable statements
Primary references: [SCITT].
Existing standards and chartered scope: The SCITT charter concerns
interoperable transparency services and signed statements for
software supply-chain evidence, distinct from general cross-domain
payment finality.
Specific additional technical problem and boundary: A transparent
evidence provenance record could support auditing selected receipt
histories or observer software origins, but a transparency inclusion
proof cannot replace current qualified outcome observation, resource
ownership or a receiving Finality Sink.
Official WG or RFC address: https://datatracker.ietf.org/wg/scitt/
about/
11.6. HTTP and HTTPBIS: request semantics, conditional updates and
retries
Primary references: [RFC9110].
Existing standards and chartered scope: RFC 9110 Section 9.2.2
distinguishes idempotent request methods and warns against unsafe
automatic retries of non-idempotent requests without sufficient
knowledge or idempotency behavior. Conditional requests can help
bind resource state under their actual server semantics.
Das Expires 29 April 2027 [Page 615]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Specific additional technical problem and boundary: Part 8 demands
explicit outcome classification and qualified receiver-side
deduplication or protected retry authority; receiving HTTP 200/202,
proxy delivery and transport success are not automatically evidence
of the intended external effect.
Official WG or RFC address: https://datatracker.ietf.org/wg/httpbis/
about/
11.7. ACE WG: authorization in constrained networked devices
Primary references: [RFC9200].
Existing standards and chartered scope: RFC 9200 specifies OAuth-
based access authorization for constrained environments and relevant
token models.
Specific additional technical problem and boundary: Device
controllers can authenticate a permitted command and resource scope;
safety conditions, physical irreversibility and actual actuation
observation require separate protected mechanisms at capable
receiving controllers.
Official WG or RFC address: https://datatracker.ietf.org/wg/ace/
about/
11.8. SEC-DISPATCH and Security Area technical review
Existing standards and chartered scope: The Security Area dispatch
venue helps assess cross-protocol security topics where no single WG
charter necessarily covers all proposed mechanisms.
Specific additional technical problem and boundary: Distributed
consequence-finality combines OAuth-like authority, WIMSE identity,
RATS witness qualification, COSE evidence, HTTP retry behavior and
resource-side consumption; possible work should be appropriately
scoped and not presented as adopted by any existing WG.
Official WG or RFC address:
https://datatracker.ietf.org/wg/secdispatch/about/
11.9. IPR obligations and status of individual Internet-Drafts
Primary references: [RFC8179].
Das Expires 29 April 2027 [Page 616]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Existing standards and chartered scope: RFC 8179 and BCP 79 define
applicable IETF IPR disclosure obligations; a publication identifying
patent-pending subject matter does not replace separate formal
disclosures.
Specific additional technical problem and boundary: The author plans
detailed later IPR submissions. The exact application and claim
relevance, licensing declarations and relationship to each draft must
be made through the proper disclosure process as applicable.
Official WG or RFC address: https://www.rfc-editor.org/rfc/
rfc8179.html
12. 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
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.
Das Expires 29 April 2027 [Page 617]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
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.
13. Security, Privacy, Effect Correctness and Claim-Scope Limitations
13.1. Request success and effect truth
Distinguish operation authorization, gateway acceptance, resource
commit and independently confirmed external effect. Protocol
observations must not be promoted beyond what they prove.
13.2. Source, capability and recipient integrity
Authenticate original competent authority and recheck current
revocation, actual source-derived scope and receiving resource
material operation parameters.
13.3. Remote effect observability limits
Cross-domain proofs require participating observer/resource APIs;
when no sufficient observation is available, preserve uncertainty
instead of manufacturing confirmation.
13.4. Crash, state rollback and replay
Persist protected consumption, effect-intent and reconciliation
state. A failed local process must not restore or multiply consumed
authority.
Das Expires 29 April 2027 [Page 618]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
13.5. Transactional semantics
A central task coordinator cannot confer global atomicity upon
providers without a genuine shared commit guarantee. Describe
partial commit and compensation accurately.
13.6. Safety and irreversible operations
Current competent hazard predicates and independent actuation-sink
controls are necessary where the actual effect is dangerous or
irreversible. This protocol proposal does not replace functional-
safety certification.
13.7. Privacy of receipts and journals
Receipts may expose user identities, account numbers, cloud tenant
IDs, transactions and physical telemetry; apply minimization,
retention controls, keyed access and appropriate redaction.
13.8. Qualified witness competence
Attested software, a cryptographic signature and an independent
entity label do not automatically ensure correct sensor measurements
or witness independence.
13.9. Verification exhaustion
Limit receipt size, dependency depth, signature workload, evidence
chain recursion, reconciliation rate and retries; required
verification failure must not grant authority.
13.10. Source-disclosure chronology
New diagrams, editorial algorithms and proposed tests in this draft
have their own publication date and may not be attributed to a June
2026 filing without verifying exact as-filed support.
13.11. Platform capability constraints
A cooperating remote finality service may be built without vendor
privileged rights; universal mediation across arbitrary Apple iOS
apps, Android processes or nonparticipating remote services cannot be
assumed.
Das Expires 29 April 2027 [Page 619]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
13.12. Prior-art and patent statements
Searchable publication can aid independent examination, but legal
prior-art effect and patent priority depend on public-availability
dates, enabling support, specific claims and jurisdiction. No
infringement inference follows product mentions.
14. Patent-Examiner and Industry Discovery Index With Global Source-
Page and Figure Anchors
Selected CW-2 — Validated Predecessor Real-Effect Receipts and
Continuation: original global pages 63–79, file TECHNICAL
SPECIFICATION -1-554.pdf, page anchor cw2-page-<global-page>, figure
anchors fig-cw2-architecture and fig-cw2-flowchart. The original
source image controls exact wording.
Embodiment 4 — Cross-Domain Consequential Effect Evidence and Remote
Outcome Qualification: original global pages 492–554, file TECHNICAL
SPECIFICATION -1-554.pdf, page anchor emb4-page-<global-page>, figure
anchors fig-emb4-architecture and fig-emb4-flowchart. The original
source image controls exact wording.
Embodiment 12 — Protected Recovery, Compensating Effects and Non-
Replayable Recovery Authority: original global pages 1063–1139, file
TECHNICAL SPECIFICATION -1063-1541.pdf, page anchor emb12-page-
<global-page>, figure anchors fig-emb12-architecture and fig-
emb12-flowchart. The original source image controls exact wording.
Embodiment 16 — Crash-Consistent Effect-Intent Journals and
Indeterminate Outcome Reconciliation: original global pages
1385–1465, file TECHNICAL SPECIFICATION -1063-1541.pdf, page anchor
emb16-page-<global-page>, figure anchors fig-emb16-architecture and
fig-emb16-flowchart. The original source image controls exact
wording.
Embodiment 36 — Multi-Resource Transaction Finality, Partial Commit
and Separate Compensation: original global pages 3102–3192, file
TECHNICAL SPECIFICATION -3102-3567.pdf, page anchor emb36-page-
<global-page>, figure anchors fig-emb36-architecture and fig-
emb36-flowchart. The original source image controls exact wording.
Embodiment 37 — Irreversible-Effect Frontier and Hazard-State
Finality: original global pages 3193–3282, file TECHNICAL
SPECIFICATION -3102-3567.pdf, page anchor emb37-page-<global-page>,
figure anchors fig-emb37-architecture and fig-emb37-flowchart. The
original source image controls exact wording.
Das Expires 29 April 2027 [Page 620]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Embodiment 38 — Independent Evidence Witnesses, Measurement
Competence and Cross-Domain Proof: original global pages 3283–3377,
file TECHNICAL SPECIFICATION -3102-3567.pdf, page anchor emb38-page-
<global-page>, figure anchors fig-emb38-architecture and fig-
emb38-flowchart. The original source image controls exact wording.
Problem-to-mechanism index: API acceptance versus real effect
(Embodiment 4); separately qualified recovery and compensation
authority (Embodiment 12); write-ahead protected effect journals and
crash windows (Embodiment 16); multiple resource Finality Sinks, non-
atomic partial commits and constituent CAs (Embodiment 36);
irreversible consequence frontier (Embodiment 37); witness competence
and noncorrelated independent evidence (Embodiment 38).
Source coverage is deliberately overlapping only where meaningful
common terminology is necessary; the Part 8 map does not imply that
every source page is unique to this draft or that all optional
mechanisms are mandatory. Each additional test, industry mapping and
pseudocode is editorial implementation material distinct from page-
indexed historical source text.
15. Foundational and Other Companion Internet-Draft Cross-References
Part 1 of 12 — Foundational Protected Consequence Authority, Shared
Definitions, CW-1, CW-2 and CW-3: [DAS-FOUNDATION]
Part 2 of 12 — Secure iOS, Android and Cross-Platform AI-Tool
Interoperability: [DAS-INTEROP]
Part 3 of 12 — Protected Authorization, Validation Evidence and
Scoped Finality Capabilities: [DAS-EVIDENCE]
Part 4 of 12 — Finality Sink Reconstruction, Protected Consumption
and Anti-Bypass Security: [DAS-SINK]
Part 5 of 12 — Multi-Agent Authority, Delegation, Conflicts and
Quorum Enforcement: [DAS-MULTIAGENT]
Part 6 of 12 — Authenticated Real-Effect Receipts and Causal
Continuation: [DAS-RECEIPTS]
Part 7 of 12 — AI Tool Security, Resource Identity and Execution-Time
Semantic Integrity: [DAS-TOOLS]
Part 9 of 12 — Credential Custody, Protected Disclosure and API
Security: [DAS-CREDENTIALS]
Das Expires 29 April 2027 [Page 621]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Part 10 of 12 — Cross-Device Migration, Revocation and Offline
Fencing: [DAS-REVOCATION]
Part 11 of 12 — Kernel, Sandbox and Hardware Enforcement:
[DAS-HARDWARE]
Part 12 of 12 — Cloud, Telecom, Resource Governance and Critical
Infrastructure: [DAS-INFRA]
16. Informative References
[DAS-FOUNDATION]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 1: Foundational
Consequential Authority and Common Workflows", Work in
Progress, Internet-Draft, draft-das-interoperable-
consequence-authority-00,
<https://datatracker.ietf.org/doc/draft-das-interoperable-
consequence-authority/>.
[DAS-INTEROP]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 2: Secure iOS and
Android AI Tool Interoperability", Work in Progress,
Internet-Draft, draft-das-cross-platform-ai-
interoperability-00, <https://datatracker.ietf.org/doc/
draft-das-cross-platform-ai-interoperability/>.
[DAS-EVIDENCE]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 3: Protected Source
Authority, Cross-Committed Evidence, and Scoped Non-Bearer
Finality", Work in Progress, Internet-Draft, draft-das-
protected-authority-evidence-00,
<https://datatracker.ietf.org/doc/draft-das-protected-
authority-evidence/>.
[DAS-SINK] Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 4: Finality Sink
Enforcement, Actual-Operation Reconstruction, and Anti-
Bypass Security", Work in Progress, Internet-Draft, draft-
das-finality-sink-enforcement-00,
<https://datatracker.ietf.org/doc/draft-das-finality-sink-
enforcement/>.
[DAS-MULTIAGENT]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 5: Multi-Agent
Das Expires 29 April 2027 [Page 622]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Delegation, Conflict Arbitration, and Quorum Authority",
Work in Progress, Internet-Draft, draft-das-multi-agent-
authority-control-00, <https://datatracker.ietf.org/doc/
draft-das-multi-agent-authority-control/>.
[DAS-RECEIPTS]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 6: Verified Actual-
Effect Receipts and Protected Causal Continuation", Work
in Progress, Internet-Draft, draft-das-causal-effect-
receipts-00, <https://datatracker.ietf.org/doc/draft-das-
causal-effect-receipts/>.
[DAS-TOOLS]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 7: AI Tool Integrity,
Semantic Target Correspondence, and Execution-Time
Resource Identity", Work in Progress, Internet-Draft,
draft-das-agent-tool-integrity-00,
<https://datatracker.ietf.org/doc/draft-das-agent-tool-
integrity/>.
[DAS-CREDENTIALS]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 9 of 12 — Credential
Custody, Protected Disclosure and API Security", Work in
Progress, Internet-Draft, draft-das-agent-credential-
privacy-00, <https://datatracker.ietf.org/doc/draft-das-
agent-credential-privacy/>.
[DAS-REVOCATION]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 10 of 12 — Cross-
Device Migration, Revocation and Offline Fencing", Work in
Progress, Internet-Draft, draft-das-cross-device-
authority-revocation-00,
<https://datatracker.ietf.org/doc/draft-das-cross-device-
authority-revocation/>.
Das Expires 29 April 2027 [Page 623]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
[DAS-HARDWARE]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 11 of 12 — Kernel,
Sandbox and Hardware Enforcement", Work in Progress,
Internet-Draft, draft-das-hardware-execution-finality-00,
<https://datatracker.ietf.org/doc/draft-das-hardware-
execution-finality/>.
[DAS-INFRA]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 12 of 12 — Cloud,
Telecom, Resource Governance and Critical Infrastructure",
Work in Progress, Internet-Draft, draft-das-autonomous-
infrastructure-finality-00,
<https://datatracker.ietf.org/doc/draft-das-autonomous-
infrastructure-finality/>.
[ZENODO] 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>.
[PCT-055615]
Das, S., "Published international application WO
2026/150382 (PCT/IB2026/055615)", 2026,
<https://patentscope.wipo.int/search/en/WO2026150382>.
[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>.
[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>.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[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>.
Das Expires 29 April 2027 [Page 624]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.
Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/info/rfc8693>.
[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
February 2020, <https://www.rfc-editor.org/info/rfc8707>.
[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>.
[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>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 8949, STD 94,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[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>.
[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>.
[WIMSE] Internet Engineering Task Force, "Workload Identity in
Multi System Environments (wimse) Working Group",
<https://datatracker.ietf.org/wg/wimse/about/>.
[SCITT] Internet Engineering Task Force, "Supply Chain Integrity,
Transparency, and Trust (scitt) Working Group",
<https://datatracker.ietf.org/wg/scitt/about/>.
[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>.
Das Expires 29 April 2027 [Page 625]
Internet-Draft Execution-Finality Part 8: Recovery October 2026
Author's Address
Sangam Kumar Das
Independent Researcher
Balasore
Odisha
India
Email: info@sangamdas.com
Das Expires 29 April 2027 [Page 626]