Secure AI Execution-Finality for iOS, Android, and Cross-Platform AI Agents, Part 6: Verified Actual-Effect Receipts and Protected Causal Continuation
draft-das-causal-effect-receipts-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-causal-effect-receipts-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 6: Verified Actual-Effect Receipts and Protected Causal
Continuation
draft-das-causal-effect-receipts-00
Abstract
An AI agent that reports "done" has not proven that anything
happened. Multi-step tasks run by Apple Siri through App Intents and
Shortcuts, by Google Gemini across Android apps, by enterprise
copilots, and by autonomous agents across iOS, iPadOS, macOS,
Android, Windows, Linux, cloud services, payment systems, connected
devices, and industrial systems often start the next consequential
step because a scheduler reported success, an API returned "202
Accepted", or the agent generated a plausible completion message,
even though the required earlier real-world effect never occurred or
cannot be established. The results include prompt-injection-driven
phase skipping, false shipment or settlement claims, payment before
goods are reserved, unsafe device actuation after an unconfirmed
safety step, replayed acknowledgements, and duplicated or misdirected
changes after lost replies.
This document, Part 6 of a twelve-part series, specifies how a later
step is allowed to proceed only on verified evidence that the earlier
effect actually took place. It defines an identity-authenticated
Interim Effectuation Validator (IEV); qualified actual-effect
evidence; Protected Effect Receipts (PER); Validator-Accepted Effect
Receipts (VAER); a single-use Causal Continuation Condition (CCC);
and receipt-constituted authority for the next phase, checked again
by an independently enforcing Finality Sink. It keeps distinct the
source permission, request dispatch, observation, accepted evidence,
continuation authority, and actual successor effect, and it treats
lost or ambiguous outcomes as indeterminate rather than successful.
Reference algorithms, ten threat models, and twenty-four reproducible
tests, including an iOS and Android cooperating-gateway case, are
included. Part 1 of the series defines the shared terminology and
common workflows.
The document relates these mechanisms to OAuth 2.0 authorization,
Rich Authorization Requests, Resource Indicators, Token Exchange,
Demonstrating Proof of Possession (DPoP), and token revocation;
Workload Identity in Multi-System Environments (WIMSE); Remote
Das Expires 29 April 2027 [Page 1]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
ATtestation procedureS (RATS) for trustworthy validators and
observers; CBOR Object Signing and Encryption (COSE) for receipt
objects; Supply Chain Integrity, Transparency, and Trust (SCITT)
signed statements; Authentication and Authorization for Constrained
Environments (ACE); and HTTP semantics for asynchronous effects and
conditional requests. It identifies discussion points for these
groups and for Security Area dispatch, without claiming working-group
adoption or IETF consensus.
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; Microsoft Windows and Azure; agent platforms from OpenAI,
Anthropic, Google Cloud, and Meta; NVIDIA, Qualcomm, Arm, and Huawei
hardware; banking and payment APIs; agentic commerce and digital
wallets; e-commerce logistics and returns; healthcare ordering and
dispensing workflows; insurance claims and lending; travel booking;
smart homes using Matter; automotive assistants and over-the-air
updates; energy and utility switching; government digital identity,
including the EU Digital Identity Wallet; customer-service refunds;
laboratory and manufacturing execution; software release pipelines;
robotics; and telecommunications. For each, the document states the
technical effect: a successor operation is withheld unless a
qualified, unreplayed receipt proves the predecessor effect. Product
names are illustrative and imply no endorsement or implementation by
any vendor. For the EU Artificial Intelligence Act (Regulation (EU)
2024/1689), receipt-gated continuation and auditable phase records
can help providers and deployers address record-keeping,
traceability, human-oversight, and robustness 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 6: Receipts 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: Causal Security Problem, Document Purpose and
Twelve-Part Series . . . . . . . . . . . . . . . . . . . 9
1.1. Full Series Directory: What Each Part Contains and Proposed
Datatracker Address . . . . . . . . . . . . . . . . . . . 10
1.1.1. Part 1 of 12 — Foundational Definitions, Trust Model
and Common Workflows CW-1/CW-2/CW-3 . . . . . . . . . 10
1.1.2. Part 2 of 12 — Secure Apple iOS, Android and
Cross-Platform AI Tool Interoperability . . . . . . . 10
1.1.3. Part 3 of 12 — Protected Authorization, Cross-Committed
Validation Evidence and Scoped Finality . . . . . . . 10
1.1.4. Part 4 of 12 — Finality Sink Enforcement,
Actual-Operation Reconstruction and Anti-Bypass
Security . . . . . . . . . . . . . . . . . . . . . . 11
1.1.5. Part 5 of 12 — Multi-Agent Security, Delegation,
Conflict Arbitration and Quorum Authority . . . . . . 11
1.1.6. Part 6 of 12 — Verified Real-Effect Receipts and
Protected Causal Continuation for AI Workflows . . . 11
1.1.7. Part 7 of 12 — AI Tool Security, Resource Identity and
Execution-Time Semantic Integrity . . . . . . . . . . 11
1.1.8. Part 8 of 12 — Distributed Autonomous Effects,
Multi-Resource Transactions and Recovery . . . . . . 12
1.1.9. Part 9 of 12 — Protected Agent Credential Custody, API
Authorization and Data Privacy . . . . . . . . . . . 12
1.1.10. Part 10 of 12 — Cross-Device Authority Continuity,
Revocation Fencing and Offline Authorization . . . . 12
1.1.11. Part 11 of 12 — Hardware-Assisted, Kernel and Sandbox
Finality Enforcement . . . . . . . . . . . . . . . . 12
1.1.12. Part 12 of 12 — Autonomous Cloud, Telecom and Critical
Infrastructure Resource Security . . . . . . . . . . 13
2. Source Publication, Principal Patent-Pending PCT, Formal IETF
IPR Disclosure and Future GitHub Reference . . . . . . . 13
3. Keywords and Searchable Security and Industry Terminology . . 14
4. Foundational Dependencies and Receipt-Specific Terminology . 14
4.1. Candidate Act (CA) . . . . . . . . . . . . . . . . . . . 14
4.2. Non-Effective State (NES) . . . . . . . . . . . . . . . . 14
Das Expires 29 April 2027 [Page 3]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
4.3. Protected Enforcement Domain (PED) . . . . . . . . . . . 14
4.4. Finality Sink (FS) . . . . . . . . . . . . . . . . . . . 15
4.5. Interim Effectuation Validator (IEV) . . . . . . . . . . 15
4.6. Protected Effect Receipt (PER) . . . . . . . . . . . . . 15
4.7. Validator-Accepted Effect Receipt (VAER) . . . . . . . . 15
4.8. Causal Continuation Condition (CCC) . . . . . . . . . . . 15
4.9. Receipt-Constituted Continuation Authority . . . . . . . 15
4.10. Effect predicate . . . . . . . . . . . . . . . . . . . . 15
4.11. Observed effect versus submitted request . . . . . . . . 16
4.12. Source authority and continuation authority . . . . . . . 16
4.13. Causal lineage and phase identity . . . . . . . . . . . . 16
4.14. Outcome indeterminacy . . . . . . . . . . . . . . . . . . 16
4.15. Non-bearer capability and consumption . . . . . . . . . . 16
5. Mandatory Conceptual Security Invariants and Optional
Realizations . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Invariant 1 . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Invariant 2 . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. Invariant 3 . . . . . . . . . . . . . . . . . . . . . . . 16
5.4. Invariant 4 . . . . . . . . . . . . . . . . . . . . . . . 17
5.5. Invariant 5 . . . . . . . . . . . . . . . . . . . . . . . 17
5.6. Invariant 6 . . . . . . . . . . . . . . . . . . . . . . . 17
5.7. Invariant 7 . . . . . . . . . . . . . . . . . . . . . . . 17
5.8. Invariant 8 . . . . . . . . . . . . . . . . . . . . . . . 17
5.9. Invariant 9 . . . . . . . . . . . . . . . . . . . . . . . 17
5.10. Invariant 10 . . . . . . . . . . . . . . . . . . . . . . 17
5.11. Invariant 11 . . . . . . . . . . . . . . . . . . . . . . 17
5.12. Invariant 12 . . . . . . . . . . . . . . . . . . . . . . 17
5.13. Invariant 13 . . . . . . . . . . . . . . . . . . . . . . 18
5.14. Invariant 14 . . . . . . . . . . . . . . . . . . . . . . 18
5.15. Invariant 15 . . . . . . . . . . . . . . . . . . . . . . 18
5.16. Invariant 16 . . . . . . . . . . . . . . . . . . . . . . 18
6. Part 6 Reference Causal-Effect Architecture, Boundaries and
Overall Flow . . . . . . . . . . . . . . . . . . . . . . 18
7. PHOSITA Implementation With Existing Technologies, Current
Platform Capabilities and Explicit Limits . . . . . . . . 20
7.1. Minimum cooperating-resource reference deployment . . . . 20
7.2. Protected source authority versus workflow scheduler . . 21
7.3. Canonicalization and effect description . . . . . . . . . 21
7.4. Existing HTTP resource primitives . . . . . . . . . . . . 21
7.5. Credential proof and existing OAuth primitives . . . . . 21
7.6. Validator identity and evidence authentication . . . . . 21
7.7. Evidence storage and independent observation . . . . . . 22
7.8. Authorization and receipt-state database . . . . . . . . 22
7.9. Protected CCC realization alternatives . . . . . . . . . 22
7.10. Receiving Finality Sink actual-operation validation . . . 22
7.11. Strong retry protection and indeterminate outcomes . . . 22
7.12. Multiple predecessors and conditional branches . . . . . 22
7.13. Apple iOS, iPadOS and macOS integration . . . . . . . . . 23
Das Expires 29 April 2027 [Page 4]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
7.14. Android apps, Binder and Keystore integration . . . . . . 23
7.15. Cloud, SaaS and cross-provider transactions . . . . . . . 23
7.16. Payments, inventory and settlements . . . . . . . . . . . 23
7.17. Industrial hardware, robotics and offline constraints . . 23
7.18. Implementation evidence and reproducibility . . . . . . . 23
7.19. Explicit limits and assumptions . . . . . . . . . . . . . 24
8. Reference Interfaces, Receipt Data Structures, Phase-State
Machines and Illustrative Algorithms . . . . . . . . . . 24
8.1. Predecessor Candidate Act and Protected Effect
Predicate . . . . . . . . . . . . . . . . . . . . . . . 24
8.2. Protected Effect Receipt . . . . . . . . . . . . . . . . 24
8.3. IEV Eligibility and Verification . . . . . . . . . . . . 25
8.4. Validator-Accepted Effect Receipt . . . . . . . . . . . . 25
8.5. Constitute Causal Continuation Condition . . . . . . . . 26
8.6. Successor Finality-Sink Verification . . . . . . . . . . 26
8.7. Multi-Predecessor Dependency Graph . . . . . . . . . . . 26
8.8. Idempotent, Durable Consumption and Indeterminate
State . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.9. Remote Witness Qualification . . . . . . . . . . . . . . 27
8.10. Causal Successor Denial and Recovery . . . . . . . . . . 28
8.11. Effect Receipt and Finality Audit Event . . . . . . . . . 28
9. Original Page-Indexed Source Technical Disclosures: CW-2,
Embodiment 2 and Qualified Supporting Material . . . . . 28
9.1. Common Workflow CW-2: Causally Ordered Real-Effect
Execution and Protected Validator-Accepted Receipts . . . 29
9.1.1. Architecture and Protected Trust-Relationship
Diagram . . . . . . . . . . . . . . . . . . . . . . . 29
9.1.2. Operational Decision Flowchart and Refusal
Conditions . . . . . . . . . . . . . . . . . . . . . 29
9.1.3. Original Source Page-Indexed Technical Content . . . 30
9.2. Common Workflow Implementation Clarification: Optional
Causal Controls and Correct Relationship to CW-1 and
CW-3 . . . . . . . . . . . . . . . . . . . . . . . . . . 98
9.2.1. Architecture and Protected Trust-Relationship
Diagram . . . . . . . . . . . . . . . . . . . . . . . 98
9.2.2. Operational Decision Flowchart and Refusal
Conditions . . . . . . . . . . . . . . . . . . . . . 99
9.2.3. Original Source Page-Indexed Technical Content . . . 99
9.3. Embodiment 2: Identity-Bound Interim Effectuation Validator
and Non-Bypassable Receipt-Constituted Authority . . . . 120
9.3.1. Architecture and Protected Trust-Relationship
Diagram . . . . . . . . . . . . . . . . . . . . . . . 120
9.3.2. Operational Decision Flowchart and Refusal
Conditions . . . . . . . . . . . . . . . . . . . . . 120
9.3.3. Original Source Page-Indexed Technical Content . . . 121
9.4. Supplementary Disclosure for Embodiment 2: Non-Replayable
Receipt-Gated Phase Activation . . . . . . . . . . . . . 206
Das Expires 29 April 2027 [Page 5]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.4.1. Architecture and Protected Trust-Relationship
Diagram . . . . . . . . . . . . . . . . . . . . . . . 206
9.4.2. Operational Decision Flowchart and Refusal
Conditions . . . . . . . . . . . . . . . . . . . . . 206
9.4.3. Original Source Page-Indexed Technical Content . . . 207
9.5. Combined Embodiments 1 and 2: Concurrent-Effect
Compatibility Versus Required Causal Ordering . . . . . . 241
9.5.1. Architecture and Protected Trust-Relationship
Diagram . . . . . . . . . . . . . . . . . . . . . . . 241
9.5.2. Operational Decision Flowchart and Refusal
Conditions . . . . . . . . . . . . . . . . . . . . . 241
9.5.3. Original Source Page-Indexed Technical Content . . . 242
9.6. Supporting Original Embodiment 4 Disclosure: Cross-Domain
Actual-Effect Evidence for Causal Receipt Qualification . 281
9.6.1. Architecture and Protected Trust-Relationship
Diagram . . . . . . . . . . . . . . . . . . . . . . . 281
9.6.2. Operational Decision Flowchart and Refusal
Conditions . . . . . . . . . . . . . . . . . . . . . 282
9.6.3. Original Source Page-Indexed Technical Content . . . 282
10. Detailed Security Threat Models, Adversary Capabilities,
Controls and Residual Risks . . . . . . . . . . . . . . . 357
10.1. Threat Model 1: Prompt Injection and Fabricated Phase
Success . . . . . . . . . . . . . . . . . . . . . . . . 358
10.2. Threat Model 2: Replayed, Substituted or Cross-Workflow
Effect Receipt . . . . . . . . . . . . . . . . . . . . 358
10.3. Threat Model 3: Forge or Impersonate Validator or Outcome
Observer . . . . . . . . . . . . . . . . . . . . . . . 358
10.4. Threat Model 4: Request Acceptance Confused With Completed
Real Effect . . . . . . . . . . . . . . . . . . . . . . 359
10.5. Threat Model 5: Privilege Escalation Through Causal
Continuation . . . . . . . . . . . . . . . . . . . . . 359
10.6. Threat Model 6: Non-Bypassable Gateway Failure and
Alternate Effectuation Path . . . . . . . . . . . . . . 359
10.7. Threat Model 7: Time-of-Check/Time-of-Use and Stale Effect
State . . . . . . . . . . . . . . . . . . . . . . . . . 360
10.8. Threat Model 8: Lost Acknowledgement, Duplicate Retry and
Crash Recovery . . . . . . . . . . . . . . . . . . . . 360
10.9. Threat Model 9: Causal Graph Cycle, Dependency
Substitution and Branch Skipping . . . . . . . . . . . 361
10.10. Threat Model 10: Compromised Infrastructure, State
Rollback and Validator Denial of Service . . . . . . . 361
11. Reproducible Validation Plan and Twenty-Four Proposed Security
Tests . . . . . . . . . . . . . . . . . . . . . . . . . . 361
11.1. CR01 — Valid two-phase effect and continuation . . . . . 362
11.2. CR02 — Agent fabricates a success message . . . . . . . 362
11.3. CR03 — HTTP 202 but no committed effect . . . . . . . . 362
11.4. CR04 — Wrong predecessor resource . . . . . . . . . . . 363
11.5. CR05 — Wrong predecessor phase . . . . . . . . . . . . . 363
Das Expires 29 April 2027 [Page 6]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
11.6. CR06 — Incorrect effect predicate . . . . . . . . . . . 364
11.7. CR07 — Forged observer evidence . . . . . . . . . . . . 364
11.8. CR08 — Forged validator acceptance . . . . . . . . . . . 364
11.9. CR09 — Valid VAER with changed successor recipient . . . 365
11.10. CR10 — Revocation after IEV acceptance . . . . . . . . . 365
11.11. CR11 — Expired predecessor observation . . . . . . . . . 365
11.12. CR12 — Replay a consumed CCC . . . . . . . . . . . . . . 366
11.13. CR13 — Crash after protected consumption . . . . . . . . 366
11.14. CR14 — Network timeout with remote success . . . . . . . 367
11.15. CR15 — Network timeout with confirmed non-effect . . . . 367
11.16. CR16 — Required multiple predecessor receipts . . . . . 367
11.17. CR17 — Causal graph branch substitution . . . . . . . . 368
11.18. CR18 — Missing independent IEV gate . . . . . . . . . . 368
11.19. CR19 — Direct alternate API bypass attempt . . . . . . . 369
11.20. CR20 — Wrong designated Finality Sink . . . . . . . . . 369
11.21. CR21 — Concurrent double successor . . . . . . . . . . . 369
11.22. CR22 — Insufficient remote causation evidence . . . . . 370
11.23. CR23 — Android and iOS cooperating gateway . . . . . . . 370
11.24. CR24 — DoS and verifier exhaustion . . . . . . . . . . . 371
12. Detailed Industry and Product Alignment: Causal Security for
Mobile, AI Agents, Enterprise APIs and Critical Systems . 371
12.1. Apple iOS, iPadOS, Siri, Shortcuts and App Intents . . . 371
12.2. Apple macOS Desktop Agents and Secure Automation . . . . 372
12.3. Google Android, Gemini, Intents, Binder and Keystore . . 372
12.4. Microsoft Windows, Azure and Enterprise Agent
Governance . . . . . . . . . . . . . . . . . . . . . . 372
12.5. OpenAI Responses API, Agents SDK, Codex and Tool
Calling . . . . . . . . . . . . . . . . . . . . . . . . 373
12.6. Anthropic Claude, Claude Code and Managed Agents . . . . 373
12.7. Google Cloud and Enterprise SaaS Orchestration . . . . . 373
12.8. Meta Muse/Sentinel Agent Security . . . . . . . . . . . 374
12.9. NVIDIA OpenShell, BlueField, Sentry and Accelerators . . 374
12.10. Qualcomm Snapdragon, Arm, Huawei and Device Security . . 374
12.11. Banking, Payment APIs and Digital Commerce . . . . . . . 375
12.12. Industrial Robotics, Vehicles and Connected Devices . . 375
12.13. Telecommunications, Edge Networks and 5G/6G . . . . . . 375
12.14. Storage, Databases, Release Pipelines and Content
Distribution . . . . . . . . . . . . . . . . . . . . . 376
12.15. Voice and System Assistants: Apple Siri, Google Gemini,
Samsung Bixby, Microsoft Copilot and Amazon Alexa . . . 376
12.16. Agentic Commerce, Checkout and Digital Wallets . . . . . 377
12.17. E-Commerce Logistics, Shipping and Returns . . . . . . . 377
12.18. Healthcare Ordering, Dispensing and Clinical Workflow
Automation . . . . . . . . . . . . . . . . . . . . . . 378
12.19. Insurance Claims, Lending and Disbursement . . . . . . . 378
12.20. Travel and Booking Chains . . . . . . . . . . . . . . . 379
12.21. Smart Home, Matter Devices and Physical Access . . . . . 379
Das Expires 29 April 2027 [Page 7]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
12.22. Automotive Assistants, Apple CarPlay, Android Auto and
Over-the-Air Updates . . . . . . . . . . . . . . . . . 380
12.23. Energy, Utilities and Grid Switching . . . . . . . . . . 380
12.24. Government Digital Identity, Electronic Signatures and the
EU Digital Identity Wallet . . . . . . . . . . . . . . 381
12.25. Customer Service, CRM and Refund Agents . . . . . . . . 381
12.26. Laboratory Automation, Manufacturing Execution Systems and
Quality Release . . . . . . . . . . . . . . . . . . . . 382
12.27. Software Release Pipelines, App Store and Google Play
Staged Rollouts . . . . . . . . . . . . . . . . . . . . 382
12.28. Summary of Technical Effects Across Industries . . . . . 383
13. Detailed Relevance to IETF Working Groups, Standards and
Internet-Drafts . . . . . . . . . . . . . . . . . . . . . 384
13.1. OAuth: Structured Delegated Authorization and Current
Source Grants . . . . . . . . . . . . . . . . . . . . . 384
13.2. WIMSE: Workload Identity Across Administrative
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 385
13.3. RATS: Attestation and Trustworthiness of Verifiers or
Observers . . . . . . . . . . . . . . . . . . . . . . . 385
13.4. COSE/CBOR: Authenticated Machine-Readable Receipt
Objects . . . . . . . . . . . . . . . . . . . . . . . . 385
13.5. SCITT: Signed Statements and Transparent Technical
Evidence . . . . . . . . . . . . . . . . . . . . . . . . 386
13.6. ACE: Constrained Device Authorization . . . . . . . . . 386
13.7. HTTPBIS: Semantics, Conditional Requests and Asynchronous
Effects . . . . . . . . . . . . . . . . . . . . . . . . 387
13.8. SEC-DISPATCH and Security Area: Cross-Layer Technical
Problem Framing . . . . . . . . . . . . . . . . . . . . 387
13.9. Transactional and Data Consistency Semantics Across
Services . . . . . . . . . . . . . . . . . . . . . . . . 387
14. Relevance to the EU Artificial Intelligence Act . . . . . . . 388
15. Security and Privacy Considerations, Operational Availability
and Trust Boundaries . . . . . . . . . . . . . . . . . . 389
15.1. Authenticity versus causal truth . . . . . . . . . . . . 389
15.2. Finality and replay . . . . . . . . . . . . . . . . . . 389
15.3. Time, lease and revocation . . . . . . . . . . . . . . . 389
15.4. Asynchronous remote effects and uncertainty . . . . . . 390
15.5. Denial of service and bounded verification . . . . . . . 390
15.6. Device and platform permissions . . . . . . . . . . . . 390
15.7. Confidentiality of evidence and logs . . . . . . . . . . 390
15.8. Dependency and conflict composition . . . . . . . . . . 390
15.9. Failure handling and source novelty . . . . . . . . . . 390
16. Patent Examiner and Industry Discovery Index: Original Pages,
Figures and Supporting Source Boundaries . . . . . . . . 391
17. Explicit Foundational and Companion Cross-References . . . . 392
18. Informative References . . . . . . . . . . . . . . . . . . . 392
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 396
Das Expires 29 April 2027 [Page 8]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
1. Introduction: Causal Security Problem, Document Purpose and Twelve-
Part Series
In an autonomous system the completion of code, RPC return,
successful API authentication, message queuing, successful signature
verification, authorization to attempt an action, and the actual
externally consequential effect are different events. A later action
may depend on the last event rather than any of the others. An AI
agent can falsely infer success after a timeout, hallucinate an
acknowledgement, accept attacker-generated tool output or replay a
valid result that belongs to another operation. A dangerous
continuation arises if a later tool, resource server or physical
actuator treats that assertion as authority.
The specific source mechanisms addressed here are Common Workflow CW-
2, identity-bound protected Interim Effectuation Validation and
receipt-constituted continuation in Embodiment 2, the supplementary
technical disclosure for Embodiment 2, the source discussion of
relationships among causal and conflicting effects, and independently
qualified evidence of remote effects as described by Embodiment 4.
The principal CW-2 arrangement makes a later governed consequential
effect technically dependent upon a protected validation result
showing that a required earlier bounded real effect has been
appropriately established. The IEV, PER, VAER and CCC are not merely
decorative labels: the precise enforcement dependency matters.
The earlier real effect is not automatically a grant of unlimited
successor permission. Successor source authorization, effect scope,
current revocation, designated sink, actual resource and protected
consumption remain separate requirements. A receipt can be
cryptographically valid while supporting the wrong predecessor,
representing dispatch rather than actual effect, or being stale
relative to the current resource. When a mandatory receipt cannot be
qualified, the next covered effect remains non-effective.
Intended readers include patent examiners, Apple iOS/iPadOS and
Android application-security engineers, desktop and cloud API
architects, payment and transaction engineers, multi-agent platform
designers, operational technology engineers, and relevant IETF
security-area contributors. The main purpose is searchable public
technical disclosure and independent technical examination, not a
claim of standardized IETF behavior or mandatory implementation by
any vendor. The source texts reproduced below and the newly authored
engineering examples are kept distinguishable.
This is Part 6 of 12. Part 1 remains the authoritative shared
architecture and definitions for Candidate Act (CA), Non-Effective
State (NES), Protected Enforcement Domain (PED), protected evidence
Das Expires 29 April 2027 [Page 9]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
and Finality Sink (FS). Part 3 discusses validation evidence and
authority binding before independent finality; Part 4 details actual-
operation verification and anti-bypass; Part 8 governs separate
cross-domain outcomes, uncertainty and recovery. This Part 6
specializes the causal dependency between earlier qualified real
effects and later separately consequential operations.
1.1. Full Series Directory: What Each Part Contains and Proposed
Datatracker Address
The following names and future addresses are planned document
identifiers. A constructed Datatracker URL does not establish that
the corresponding Internet-Draft has been submitted, accepted, or
published. Each part has a distinct abstract, security problem and
primary set of original embodiment sections.
1.1.1. Part 1 of 12 — Foundational Definitions, Trust Model and Common
Workflows CW-1/CW-2/CW-3
Identifier: draft-das-interoperable-consequence-authority. Planned
address: https://datatracker.ietf.org/doc/draft-das-interoperable-
consequence-authority/ .
Foundational: authoritative common vocabulary, protected authority/
effect separation, trust models, CW-1, CW-2 and CW-3 and the baseline
security invariants.
1.1.2. Part 2 of 12 — Secure Apple iOS, Android and Cross-Platform AI
Tool Interoperability
Identifier: draft-das-cross-platform-ai-interoperability. Planned
address: https://datatracker.ietf.org/doc/draft-das-cross-platform-
ai-interoperability/ .
Companion part: covers the indicated mechanism under its own trust
model; a cross-reference does not make every optional mechanism
mandatory in this part.
1.1.3. Part 3 of 12 — Protected Authorization, Cross-Committed
Validation Evidence and Scoped Finality
Identifier: draft-das-protected-authority-evidence. Planned address:
https://datatracker.ietf.org/doc/draft-das-protected-authority-
evidence/ .
Companion part: covers the indicated mechanism under its own trust
model; a cross-reference does not make every optional mechanism
mandatory in this part.
Das Expires 29 April 2027 [Page 10]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
1.1.4. Part 4 of 12 — Finality Sink Enforcement, Actual-Operation
Reconstruction and Anti-Bypass Security
Identifier: draft-das-finality-sink-enforcement. Planned address:
https://datatracker.ietf.org/doc/draft-das-finality-sink-enforcement/
.
Companion part: covers the indicated mechanism under its own trust
model; a cross-reference does not make every optional mechanism
mandatory in this part.
1.1.5. Part 5 of 12 — Multi-Agent Security, Delegation, Conflict
Arbitration and Quorum Authority
Identifier: draft-das-multi-agent-authority-control. Planned
address: https://datatracker.ietf.org/doc/draft-das-multi-agent-
authority-control/ .
Companion part: covers the indicated mechanism under its own trust
model; a cross-reference does not make every optional mechanism
mandatory in this part.
1.1.6. Part 6 of 12 — Verified Real-Effect Receipts and Protected
Causal Continuation for AI Workflows
Identifier: draft-das-causal-effect-receipts. Planned address:
https://datatracker.ietf.org/doc/draft-das-causal-effect-receipts/ .
This part: validated real-effect receipt evidence; cryptographically
identifiable Interim Effectuation Validator; receipt-dependent
successor authority; phase lineage; sink-local enforcement; recovery
following uncertain predecessor outcomes.
1.1.7. Part 7 of 12 — AI Tool Security, Resource Identity and
Execution-Time Semantic Integrity
Identifier: draft-das-agent-tool-integrity. Planned address:
https://datatracker.ietf.org/doc/draft-das-agent-tool-integrity/ .
Companion part: covers the indicated mechanism under its own trust
model; a cross-reference does not make every optional mechanism
mandatory in this part.
Das Expires 29 April 2027 [Page 11]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
1.1.8. Part 8 of 12 — Distributed Autonomous Effects, Multi-Resource
Transactions and Recovery
Identifier: draft-das-distributed-effect-recovery. Planned address:
https://datatracker.ietf.org/doc/draft-das-distributed-effect-
recovery/ .
Companion part: covers the indicated mechanism under its own trust
model; a cross-reference does not make every optional mechanism
mandatory in this part.
1.1.9. Part 9 of 12 — Protected Agent Credential Custody, API
Authorization and Data Privacy
Identifier: draft-das-agent-credential-privacy. Planned address:
https://datatracker.ietf.org/doc/draft-das-agent-credential-privacy/
.
Companion part: covers the indicated mechanism under its own trust
model; a cross-reference does not make every optional mechanism
mandatory in this part.
1.1.10. Part 10 of 12 — Cross-Device Authority Continuity, Revocation
Fencing and Offline Authorization
Identifier: draft-das-cross-device-authority-revocation. Planned
address: https://datatracker.ietf.org/doc/draft-das-cross-device-
authority-revocation/ .
Companion part: covers the indicated mechanism under its own trust
model; a cross-reference does not make every optional mechanism
mandatory in this part.
1.1.11. Part 11 of 12 — Hardware-Assisted, Kernel and Sandbox Finality
Enforcement
Identifier: draft-das-hardware-execution-finality. Planned address:
https://datatracker.ietf.org/doc/draft-das-hardware-execution-
finality/ .
Companion part: covers the indicated mechanism under its own trust
model; a cross-reference does not make every optional mechanism
mandatory in this part.
Das Expires 29 April 2027 [Page 12]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
1.1.12. Part 12 of 12 — Autonomous Cloud, Telecom and Critical
Infrastructure Resource Security
Identifier: draft-das-autonomous-infrastructure-finality. Planned
address: https://datatracker.ietf.org/doc/draft-das-autonomous-
infrastructure-finality/ .
Companion part: covers the indicated mechanism under its own trust
model; a cross-reference does not make every optional mechanism
mandatory in this part.
2. Source Publication, Principal Patent-Pending PCT, Formal IETF IPR
Disclosure and Future GitHub Reference
The principal 8,598-page international technical disclosure
identified for this project is PCT/IB2026/055615, filed 4 June 2026
and published as WO 2026/150382 [PCT-055615]. The earlier PCT/
IB2025/058316 is a separate filing, not the 8,598-page June 2026
technical disclosure. Patent applications and publication dates must
not be conflated. No assertion of granted claims or of a particular
claim's priority is made here.
Underlying public 3,567-page technical specification: "iOS and
Android Interoperability for Secure Third Party AI Tools - Cross-
Platform Execution Finality, Hardware Security, and Interoperability
(3,567-Page Specification)", Sangam Kumar Das, [ZENODO]
(https://zenodo.org/records/23657985, DOI 10.5281/zenodo.23657985).
The page-indexed reproduced excerpts below come from the seven user-
supplied PDF segments constituting that separate specification. New
diagrams, new pseudocode, extra industry analysis and newly proposed
tests are separately authored content, and must not be presumed
disclosed on the earlier PCT filing date.
Detailed, verified IETF IPR disclosures identifying pertinent
applications, claims and any licensing declarations are intended for
separate submission or update through the formal IETF IPR disclosure
system. A planned later submission does not defer any applicable
timely obligation under BCP 79 [RFC8179] and this text does not
substitute for an actual IETF IPR disclosure.
A GitHub reference implementation, deterministic test vectors,
effect-receipt schemas, validator interfaces, Android/iOS cooperating
gateway examples and executable denial/rollback test harnesses are
planned for a subsequent revision. No specific repository URL,
successful run, implementation readiness or measurement is asserted
until available and independently inspectable.
Das Expires 29 April 2027 [Page 13]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
3. Keywords and Searchable Security and Industry Terminology
AI agent security; Apple iOS; iPadOS; macOS; Android automation;
Android intents; mobile AI assistants; secure third-party AI tools;
cross-platform interoperability; prompt injection; fabricated tool
success; hallucinated API acknowledgement; API response spoofing;
autonomous workflow security; causal ordering; effect receipt; real
effect versus request acceptance; Interim Effectuation Validator;
IEV; identity-authenticated validator; Protected Effect Receipt; PER;
Validator-Accepted Effect Receipt; VAER; Causal Continuation
Condition; CCC; receipt-constituted continuation authority;
consequence verification; successful dispatch versus completed
operation; distributed transaction; receipt-bound capability; non-
bearer finality; protected phase state; actual operation; Finality
Sink; Candidate Act; Non-Effective State; phase skipping; replayed
receipt; stale evidence; payment settlement; shipment verification;
secure cloud deployment; safe device actuation; robotics; industrial
control; cross-domain effect observation; recovery after timeout;
idempotency; exactly-once effects; authorization exhaustion; OAuth
Rich Authorization Requests; WIMSE; RATS; COSE; CBOR; SCITT; ACE;
HTTP 9110; source authority; sink-local state; patent examiner
discoverability; protected execution finality.
These keywords describe source mechanisms and their plausible
application/security context; commercial product mentions are not
assertions of deployment, sponsorship or equivalence.
4. Foundational Dependencies and Receipt-Specific Terminology
4.1. Candidate Act (CA)
A machine-verifiable proposed consequential operation under the
common Part 1 architecture. Preparation or simulation does not
independently make it effective.
4.2. Non-Effective State (NES)
A controlled state in which a proposed operation lacks a path to
produce the governed consequence until applicable protected
conditions pass.
4.3. Protected Enforcement Domain (PED)
An independently protected domain or other qualified enforcement
component responsible for source, evidence or effect validity under a
disclosed trust model.
Das Expires 29 April 2027 [Page 14]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
4.4. Finality Sink (FS)
An actual resource-side or equally authoritative enforcement
interface that obtains or reconstructs the material pending operation
and refuses release unless qualified evidence, scoped authority and
current protected sink state match.
4.5. Interim Effectuation Validator (IEV)
In the source CW-2/Embodiment 2, an authenticated validator that
independently checks evidence concerning the earlier bounded real
effect and qualifies causal continuation. Independence and
cryptographic identity have concrete deployment assumptions.
4.6. Protected Effect Receipt (PER)
Protected evidence associated with an earlier real-effect attempt or
outcome; its contents and evidentiary sufficiency depend on the
actual trusted observer, resource, effect predicate and security
model.
4.7. Validator-Accepted Effect Receipt (VAER)
A PER or equivalent accepted protected receipt state that a suitably
authorized, cryptographically identifiable IEV has validated for the
required causal progression.
4.8. Causal Continuation Condition (CCC)
A protected technical predicate needed for a later consequential
phase whose eligibility depends on appropriate VAER acceptance;
possibly realized by key material, a capability, latch, state, or
gateway release condition.
4.9. Receipt-Constituted Continuation Authority
Operation-specific finality-enabling condition constituted through
accepted evidence of an earlier real effect; not generic delegation
or an unbounded bearer token.
4.10. Effect predicate
Specified property of the actual predecessor consequence required for
successor eligibility, such as committed resource version, confirmed
inventory reservation, qualified remote actuation measurement or
bounded transaction outcome.
Das Expires 29 April 2027 [Page 15]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
4.11. Observed effect versus submitted request
A request receipt, queue acceptance or API return may not prove the
downstream resource state changed. Trustworthy observation must
match the asserted causal phase and operational context.
4.12. Source authority and continuation authority
Distinct checks: the principal/delegate must authorize the later
consequence; a verified predecessor may satisfy a necessary
dependency. Neither replaces the other.
4.13. Causal lineage and phase identity
Authenticated references to parent workflow, predecessor and
successor Candidate Acts, effect condition, resource and validation
generation, preventing substitution between workflow branches.
4.14. Outcome indeterminacy
A timeout or lost acknowledgement can leave actual effect uncertain.
Such states require protected reconciliation and do not automatically
reset consumed authority or permit an unsafe retry.
4.15. Non-bearer capability and consumption
A scoped reference is meaningful only under sink-side verification of
the specific operation, effect scope and protected single-use or
otherwise bounded usage state.
5. Mandatory Conceptual Security Invariants and Optional Realizations
5.1. Invariant 1
Generating a next-phase command is not authority to cause the later
consequence.
5.2. Invariant 2
A receipt that only proves dispatch or acceptance must not be treated
as proof of a completed earlier effect when completed effect is the
required dependency.
5.3. Invariant 3
An untrusted agent cannot be the sole authoritative source for a
required earlier real-effect predicate.
Das Expires 29 April 2027 [Page 16]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
5.4. Invariant 4
The protected evidence must bind the actual predecessor operation and
resource or correspond to them under an explicitly qualified
equivalence rule.
5.5. Invariant 5
An IEV signature or cryptographic identity authenticates the
validator, but does not by itself establish truth of an underlying
remote observation.
5.6. Invariant 6
A qualified VAER may establish necessary causal continuation
eligibility but cannot broaden the successor source grant.
5.7. Invariant 7
A successor Finality Sink must independently obtain or reconstruct
the actual pending successor operation under the selected trust
model.
5.8. Invariant 8
A successor cannot bypass an applicable receipt-dependent protected
continuation condition through an alternative effectuation interface.
5.9. Invariant 9
Accepted receipt and CCC must be bound to phase identity, designated
sink, applicable authority generations and bounded effect scope.
5.10. Invariant 10
A stale, mismatched, replayed, revoked, or insufficiently supported
predecessor effect must not satisfy a mandatory causal dependency.
5.11. Invariant 11
Current protected sink-local usage or consumption prevents reusing
single-use authority for additional effects.
5.12. Invariant 12
When multiple preceding effects are mandatory, all identified
dependencies must be independently qualified to the required
standard.
Das Expires 29 April 2027 [Page 17]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
5.13. Invariant 13
Partial failure, interrupted communication and uncertain external
outcomes must be explicitly represented; safe recovery cannot assume
the effect failed.
5.14. Invariant 14
A receipt-gated mechanism need not require blockchain, universal
distributed transactions, a specific cryptographic signature
algorithm, or any named vendor.
5.15. Invariant 15
Optional human approval, workflow management and task ordering do not
replace the chosen mandatory protected causal and sink checks.
5.16. Invariant 16
Exact enforcement guarantees must be stated with regard to the
actually covered resource boundaries, remote trust assumptions and
partition behavior.
6. Part 6 Reference Causal-Effect Architecture, Boundaries and Overall
Flow
The early controlled operation is validated and effectuated through
its own protected resource boundary. A qualified observer produces
protected evidence of an actual result. The Interim Effectuation
Validator (IEV) checks the correct earlier Candidate Act, expected
and observed predicate, authenticated provenance, time/freshness,
validator identity, revocation and phase lineage. Acceptance yields
a VAER and may constitute/enable a CCC at a separately controlled
component. The successor remains NES unless its own source grant,
exact intended effect, dependency condition, finality and replay
state are valid at its receiving Finality Sink. The diagrams are
newly authored interpretations of the corresponding source
relationships.
Das Expires 29 April 2027 [Page 18]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
[Source principal and bounded authorized workflow]
|
[Candidate Act phase i] -- [NES]
|
[Predecessor protected FS]
|
[Actual real effect]
|
[Qualified observer / outcome source]
|
[Protected PER]
|
[Identity-authenticated IEV]
[Effect predicate / provenance]
|
[Accepted VAER]
|
[Protected CCC constitution]
/ key / latch / capability / state
|
[Candidate Act phase i+1] -- [NES]
|
[Successor FS: re-observe actual operation]
[Current grant + receipt + scope + state]
/ \
[VERIFY / CONSUME] [WITHHOLD]
|
[Actual successor effect]
Figure 1: Part 6 — Trust-Domain Architecture: Predecessor, IEV
and Successor
Das Expires 29 April 2027 [Page 19]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
[Authorize and prepare predecessor CA]
|
[Effectuate bounded phase]
|
<Required real effect observed?>---NO--->[HOLD / RECONCILE]
| YES
[Create protected effect receipt]
|
<IEV identity/evidence valid?>-----NO--->[WITHHOLD]
| YES
<Effect predicate and phase match?>-NO--->[WITHHOLD]
| YES
[Accept VAER; constitute CCC]
|
<Successor source grant current?>--NO--->[WITHHOLD]
| YES
[Successor sink reconstructs actual act]
|
<CCC, scope, resource and sink state OK?>--NO-->[REFUSE]
| YES
[Protected consumption and actual effect]
|
[Qualified successor result, if needed]
Figure 2: Part 6 — Overall Receipt-Gated Decision Flow
7. PHOSITA Implementation With Existing Technologies, Current Platform
Capabilities and Explicit Limits
This newly authored, non-normative engineering implementation guide
maps the disclosed causal receipt controls to existing cryptographic
libraries, database transactions, cooperating resource gateways and
constrained device enforcement. It does not claim that ordinary iOS
or Android third-party applications possess privileged control over
all device effectuation paths. A minimum reference deployment can be
built from two cooperating API resource servers, an independent
evidence verifier, an authoritative transactional state store and an
agent that remains unable to directly bypass those servers.
7.1. Minimum cooperating-resource reference deployment
Run a proposing agent without direct write credentials; an effect-
capable Resource A; an independent IEV process with distinct
cryptographic keys; an authoritative receipt/continuation store; and
an effect-capable Resource B that refuses an effect without current
source grant, accepted predecessor evidence and a matching protected
CCC. Record actual resource state before and after each call.
Das Expires 29 April 2027 [Page 20]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
7.2. Protected source authority versus workflow scheduler
Store each original principal grant, delegation, eligible resource,
effect parameters and time/generation constraints outside lower-trust
agent memory. The orchestrator can schedule phases but is not
allowed to mint trusted effect observations, VAER or successor
release authority.
7.3. Canonicalization and effect description
Define deterministic type/serialization rules for source principal,
resource URI/ID, recipient, predecessor operation, intended actual
effect predicate, evidence provenance, successor scope, designated
sink, validity and phase identity. Disallow ambiguous aliases and
unqualified text-to-effect translation.
7.4. Existing HTTP resource primitives
Use HTTPS/mTLS for transport and appropriate receiver-side
conditional requests (e.g., If-Match, RFC 9110) for resource
versions. A 2xx/202 status or queued message does not necessarily
prove the required downstream effect; define the actual effect
predicate at the receiving resource or qualified observation
interface.
7.5. Credential proof and existing OAuth primitives
If deployment uses OAuth 2.0, consider RFC 9396 Rich Authorization
Requests for structured scope, RFC 8707 for resource indicators, RFC
8693 for exchange, RFC 9449 for sender constrained DPoP where
appropriate, and RFC 7009 for revocation semantics. None of these
alone guarantees that a specific prior real-world consequence
happened.
7.6. Validator identity and evidence authentication
Give the Interim Effectuation Validator a separately managed
protected signing or message-authentication identity. Verify issuer,
audience, receipt evidence provenance, original operation, required
observed result, current trust state, expiration and accepted format
before asserting VAER eligibility.
Das Expires 29 April 2027 [Page 21]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
7.7. Evidence storage and independent observation
Prefer qualified resource-committed transaction status, authentically
recorded receiving state, hardware sensor proofs or protected effect
journals over agent-generated text. For independent remote systems,
clearly disclose whether evidence is an assertion, a signed state
observation, or evidence of causation under the chosen trust model.
7.8. Authorization and receipt-state database
A serializable SQL transaction, compare-and-swap store or other
authoritative protected state service can prototype accepted receipt
IDs, validation generations, successor dependencies and consumption
transitions. Enforce uniqueness for predecessor receipt, successor
operation and designated sink under the selected single-use rules.
7.9. Protected CCC realization alternatives
A CCC can be a scoped non-bearer enablement, protected gate bit,
hardware interlock, missing key share, keystore-controlled operation,
distributed state transition or privileged gateway grant. Select a
realization only when the untrusted agent cannot independently bypass
or fabricate it within the relevant controlled boundary.
7.10. Receiving Finality Sink actual-operation validation
The protected Resource B/gateway obtains actual outbound method,
resource identity, recipient, payload digest and resource version
from its controlled effectuation interface. Check current successor
grant, accepted causal lineage, designated sink, CCC, revocation and
sink-local usage before allowing the particular effect.
7.11. Strong retry protection and indeterminate outcomes
Record `PENDING`, `EFFECT_OBSERVED`, `RECEIPT_ACCEPTED`, `CCC_READY`,
`SUCC_CONSUMED`, `EFFECT_CONFIRMED`, `INDETERMINATE` or equivalent
protected states. A timeout after remote dispatch cannot be used to
reissue the same consequential operation blindly; reconcile receiver
state or obtain a separately authorized recovery act.
7.12. Multiple predecessors and conditional branches
Express a dependency graph keyed by source-authorized predecessor
effect predicates; verify every required receipt. Where an alternate
branch is permitted, encode that choice in the original grant and
protected phase logic rather than letting an untrusted planner bypass
a failed predecessor.
Das Expires 29 April 2027 [Page 22]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
7.13. Apple iOS, iPadOS and macOS integration
Implement app-owned workflows through supported App Intents, app
extensions, Keychain-held credentials and cooperating remote API
servers. Secure Enclave/Keychain can contribute protection for
authorized key operations but do not prove actual third-party effect
completion. A normal iOS app cannot intercept arbitrary other-app or
kernel actions.
7.14. Android apps, Binder and Keystore integration
Use Android app components, permission-aware Binder identity checks,
Keystore-backed credential access, local protected app state and
cooperating remote services. Revalidate actual resource action at a
receiving resource/gateway; private platform security controls and
system-wide mediation require applicable OEM/system privileges.
7.15. Cloud, SaaS and cross-provider transactions
Bind accepted effect receipts to qualified remote resource identity
and operation-specific outcome. Service-mesh identity or workload
attestation may contribute actor assurance; final qualification of
business outcome must be provided by an appropriate resource-side
observation mechanism.
7.16. Payments, inventory and settlements
Distinguish authorization, reservation, capture, clearing,
settlement, shipment and fulfilment events. Choose the precisely
authorized predecessor predicate; a payment gateway acceptance is not
automatically evidence of settlement or customer receipt.
7.17. Industrial hardware, robotics and offline constraints
Implement a safety or command-release latch at a cooperating
industrial controller only if the predecessor effect sensor/observer
and validator provide adequate integrity, freshness and coverage.
Partitioned nodes require bounded leases or withholding under policy;
do not imply universally immediate revocation.
7.18. Implementation evidence and reproducibility
For a future GitHub project, publish source revision, schema
versions, trust roots for test keys only, fixture resources, expected
predicate, end-to-end observations, denial reason codes, timing
state, test invocation and results. Do not publish sensitive keys or
private resource records.
Das Expires 29 April 2027 [Page 23]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
7.19. Explicit limits and assumptions
Do not claim exact-once effects in arbitrary distributed systems,
accurate observation at nonparticipating resource providers, perfect
proof of remote causation or independent validator security where
every root of trust is compromised. Describe what resource
interfaces can actually refuse an effect and what evidence is merely
asserted.
8. Reference Interfaces, Receipt Data Structures, Phase-State Machines
and Illustrative Algorithms
All schemas, pseudocode and status names below are new, illustrative,
non-normative reference examples derived conceptually from the
supplied source; they are not asserted as exact original filing text,
registered IETF standards, or evidence of a completed implementation.
Choose cryptographic and serialization profiles according to the
selected deployment and standards.
8.1. Predecessor Candidate Act and Protected Effect Predicate
Illustrative engineering reference, NOT an executed test and not
verbatim earlier filing code. All protected predicates must be given
their own explicit operational definition in an implementation.
PredecessorCA = {
version, ca_id, workflow_id, phase_id,
source_grant_id, principal, origin_workload,
actual_resource_id, method, effect_parameters_hash,
expected_real_effect_predicate, output_version_rule,
designated_predecessor_sink, revocation_epoch,
expiration, protected_policy_id
}
require qualified grant; hold NES until effect boundary.
Figure 3: Predecessor Candidate Act and Protected Effect
Predicate — reference pseudocode
8.2. Protected Effect Receipt
Illustrative engineering reference, NOT an executed test and not
verbatim earlier filing code. All protected predicates must be given
their own explicit operational definition in an implementation.
Das Expires 29 April 2027 [Page 24]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
PER = {
receipt_id, predecessor_ca_digest,
workflow_id, predecessor_phase,
claimed_effect_predicate, observed_resource_id,
observer_id, observer_trust_context,
observed_result, result_state_version,
observation_timestamp, causal_event_id,
authenticator, receipt_generation
}
NOTE: request_accepted != actual_effect_verified.
Figure 4: Protected Effect Receipt — reference pseudocode
8.3. IEV Eligibility and Verification
Illustrative engineering reference, NOT an executed test and not
verbatim earlier filing code. All protected predicates must be given
their own explicit operational definition in an implementation.
verify_per(per, predecessor, policy):
require valid_iev_identity_and_role(policy.iev)
require verify_observer_authenticator(per)
require digest(predecessor) == per.predecessor_ca_digest
require per.workflow_id == predecessor.workflow_id
require qualifies(per.observed_result, policy.effect_predicate)
require fresh(per, current_trust_and_resource_state)
require current_grant_and_no_mandatory_revocation(predecessor)
require evidence_sufficiency(per, observer_trust_model)
return ACCEPT_PER_OR_WITHHOLD
Figure 5: IEV Eligibility and Verification — reference pseudocode
8.4. Validator-Accepted Effect Receipt
Illustrative engineering reference, NOT an executed test and not
verbatim earlier filing code. All protected predicates must be given
their own explicit operational definition in an implementation.
VAER = {
vaer_id, per_digest, validator_id,
accepted_predicate, authorized_successor_phase,
successor_effect_bound, workflow_id, source_epoch,
acceptance_epoch, expires_at, signed_acceptance
}
create only after IEV qualification and atomic acceptance;
record predecessor outcome and replay limits.
Figure 6: Validator-Accepted Effect Receipt — reference pseudocode
Das Expires 29 April 2027 [Page 25]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
8.5. Constitute Causal Continuation Condition
Illustrative engineering reference, NOT an executed test and not
verbatim earlier filing code. All protected predicates must be given
their own explicit operational definition in an implementation.
constitute_ccc(vaer, successor, state):
require accepted_and_current(vaer)
require dependency_edge(vaer, successor)
require successor.source_grant_current
require successor.effect subset_of authorized_scope
ccc = bind(vaer, successor.ca_id, sink_id,
resource_id, effect_parameters_hash,
source_epoch, expiry, consumption_id)
persist_protected(ccc)
return non_bearer_reference(ccc)
Figure 7: Constitute Causal Continuation Condition — reference
pseudocode
8.6. Successor Finality-Sink Verification
Illustrative engineering reference, NOT an executed test and not
verbatim earlier filing code. All protected predicates must be given
their own explicit operational definition in an implementation.
verify_successor_at_sink(actual, ccc_ref, evidence):
actual = reconstruct_from_protected_effect_interface()
require designated_sink(actual) == ccc_ref.sink
require current_source_authority(actual)
require valid_accepted_predecessor_evidence(evidence)
require match_actual_to_authorized_effect(actual, ccc_ref)
require current_versions_revocation_and_lease(actual)
require atomic_consume_once(ccc_ref, actual.op_id)
if all required predicates pass: release(actual)
else: refuse(actual)
Figure 8: Successor Finality-Sink Verification — reference pseudocode
8.7. Multi-Predecessor Dependency Graph
Illustrative engineering reference, NOT an executed test and not
verbatim earlier filing code. All protected predicates must be given
their own explicit operational definition in an implementation.
Das Expires 29 April 2027 [Page 26]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
authorize_phase(successor, graph):
dependencies = protected_required_predecessors(graph, successor)
for (p, predicate) in dependencies:
require VAER_for(p) with accepted(predicate)
require phase_lineage_current(p, successor)
require successor_grant_current()
require sink_current_and_covered()
proceed_to_new_sink_check_or_withhold
Figure 9: Multi-Predecessor Dependency Graph — reference pseudocode
8.8. Idempotent, Durable Consumption and Indeterminate State
Illustrative engineering reference, NOT an executed test and not
verbatim earlier filing code. All protected predicates must be given
their own explicit operational definition in an implementation.
BEGIN SERIALIZABLE TRANSACTION
require CCC.status == READY
require operation_descriptor_matches_actual()
update CCC.status = CONSUMED,
consumed_for = actual_op_id, sink_epoch = current_epoch
COMMIT
attempt_effect()
if result unconfirmed: set INDETERMINATE;
DO NOT reset authority on lost acknowledgment;
reconcile actual receiver effect before any retry.
Figure 10: Idempotent, Durable Consumption and Indeterminate
State — reference pseudocode
8.9. Remote Witness Qualification
Illustrative engineering reference, NOT an executed test and not
verbatim earlier filing code. All protected predicates must be given
their own explicit operational definition in an implementation.
qualify_remote_result(witness, expected):
require authenticate_witness_and_channel(witness)
require exact_resource_method_target(witness, expected)
require trusted_observation_of_required_state(witness)
require replay_proof_and_freshness(witness)
require consistency_with_conflicting_evidence(witness)
if only queued/accepted: INSUFFICIENT_EFFECT_EVIDENCE
if contradictory/unknown: INDETERMINATE
else: predicate_qualified_under_assumptions
Figure 11: Remote Witness Qualification — reference pseudocode
Das Expires 29 April 2027 [Page 27]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
8.10. Causal Successor Denial and Recovery
Illustrative engineering reference, NOT an executed test and not
verbatim earlier filing code. All protected predicates must be given
their own explicit operational definition in an implementation.
if any_required_per_missing_or_invalid:
keep_successor_NES(); record_diagnostic();
do_not_create_CCC()
if network_timeout_after_predecessor_dispatch:
query_qualified_receiver_or_witness()
if still uncertain: preserve_indeterminate_state()
if compensation required:
construct NEW recovery Candidate Act
require separate qualified source and sink authority
Figure 12: Causal Successor Denial and Recovery — reference
pseudocode
8.11. Effect Receipt and Finality Audit Event
Illustrative engineering reference, NOT an executed test and not
verbatim earlier filing code. All protected predicates must be given
their own explicit operational definition in an implementation.
AuditEvent = {
event_id, protected_time, workflow_id, phase_id,
predecessor_ca_digest, per_digest, vaer_digest,
validator_qualified_identity, ccc_consumption_id,
successor_ca_digest, receiver_observation_digest,
decision, refusal_reason, outcome_confidence
}
No audit event alone constitutes successor authority;
minimize personal data and protect log integrity.
Figure 13: Effect Receipt and Finality Audit Event — reference
pseudocode
9. Original Page-Indexed Source Technical Disclosures: CW-2, Embodiment
2 and Qualified Supporting Material
The following contains text retrieved from identifiable global pages
in the seven PDFs uploaded by the author. CW-2 and Embodiment 2 are
the principal disclosure units. CW-IMP1 and the joint discussion
provide cross-workflow context. The selected Embodiment 4 material
is supporting remote-effect evidence only: its primary full treatment
belongs to Part 8. Each page has an exact source anchor, and each
source unit has separately authored technical diagrams placed BEFORE
Das Expires 29 April 2027 [Page 28]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
its reproduced page text. Extracted PDF blocks may have typographic
ligature or line-break artifacts, so the full original source PDF
remains authoritative for exact filing comparison.
9.1. Common Workflow CW-2: Causally Ordered Real-Effect Execution and
Protected Validator-Accepted Receipts
Original global source page range: 63-119 inclusive, original
uploaded PDF segment: TECHNICAL SPECIFICATION -1-554.pdf. Primary in
this part: True. Page-extract fidelity limitations and independent
filing-priority analysis are stated in the source note.
9.1.1. Architecture and Protected Trust-Relationship Diagram
[Original authorized source + workflow]
|
[Predecessor CA / NES / PED]
|
[Predecessor Finality Sink]
|
[Qualified first REAL effect]
|
[Protected actual-effect observer]
|
[Protected Effect Receipt]
|
[Identity-authenticated IEV]
|
[Accepted VAER + CCC]
|
[Successor CA / NES]
|
[Successor FS: actual effect and state]
|
[Controlled successor effect]
Figure 14: Common Workflow CW-2: Causally Ordered Real-Effect
Execution and Protected Validator-Accepted Receipts —
architecture and protected dependencies
9.1.2. Operational Decision Flowchart and Refusal Conditions
Das Expires 29 April 2027 [Page 29]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
[Earlier bounded real effect]
|
<Required outcome actually qualified?>--NO-->[HOLD]
|YES
[PER collected under protected observer]
|
<Authenticated IEV acceptance?>--NO-->[WITHHOLD]
|YES
<Correct phase, outcome, freshness?>--NO-->[WITHHOLD]
|YES
[Constitute protected VAER/CCC]
|
<Current successor authority?>--NO-->[WITHHOLD]
|YES
<Sink actual-operation + consumption OK?>--NO-->[REFUSE]
|YES
[Consume and effect successor]
Figure 15: Common Workflow CW-2: Causally Ordered Real-Effect
Execution and Protected Validator-Accepted Receipts — decision
flowchart
9.1.3. Original Source Page-Indexed Technical Content
9.1.3.1. Source page 63 of the original specification
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 30]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.1.3.2. Source page 64 of the original specification
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 31]
Internet-Draft Execution-Finality Part 6: Receipts 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 32]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.1.3.3. Source page 65 of the original specification
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 33]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.1.3.4. Source page 66 of the original specification
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 34]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.1.3.5. Source page 67 of the original specification
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 35]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.1.3.6. Source page 68 of the original specification
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 36]
Internet-Draft Execution-Finality Part 6: Receipts 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 37]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The controlled effectuation interface must require the receipt-
dependent condition irrespective of which covered upstream software
path requests the effect.
9.1.3.7. Source page 69 of the original specification
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 38]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.1.3.8. Source page 70 of the original specification
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 39]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.1.3.9. Source page 71 of the original specification
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 40]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.1.3.10. Source page 72 of the original specification
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 41]
Internet-Draft Execution-Finality Part 6: Receipts 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 42]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.1.3.11. Source page 73 of the original specification
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 43]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.1.3.12. Source page 74 of the original specification
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 44]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.1.3.13. Source page 75 of the original specification
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 45]
Internet-Draft Execution-Finality Part 6: Receipts 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 46]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.1.3.14. Source page 76 of the original specification
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 47]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.1.3.15. Source page 77 of the original specification
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 48]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.1.3.16. Source page 78 of the original specification
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 49]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.1.3.17. Source page 79 of the original specification
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 50]
Internet-Draft Execution-Finality Part 6: Receipts 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 51]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.1.3.18. Source page 80 of the original specification
required_predecessor_outcome, required_validator_identity_or_role,
authorized_receipt_type, receipt_assurance_requirement,
required_continuation_condition, authority_epoch, revocation_epoch,
policy_epoch, phase_nonce, protected_consumption_reference,
canonicalization_profile } The descriptor may be represented through
deterministic binary encoding, canonicalized structured data, or an
equivalent machine-verifiable form.
The essential relationship is not the choice of encoding.
It is that the required predecessor evidence, accepting validator
identity, and successor effectuation authority are bound to the
correct phase and actual operation.
A protected phase dependency may be represented as:
DEPENDENCY[i+1] = REQUIRE_VALIDATED_EFFECT( Phase[i],
RequiredOutcome[i], AuthorizedIEV[i], SuccessorAct[i+1],
SuccessorSink[i+1] ) For the mandatory receipt-gated implementation,
the successor effect remains non-effective until this dependency is
satisfied.
CW-2.7 — IDENTITY-BOUND PROTECTED EFFECT RECEIPT
CW-2.7.1 — Purpose
A PER describes or references evidence concerning an earlier actual-
effect attempt.
A VAER represents the IEV's authorized acceptance of that evidence.
The VAER may become the direct allowing factor for a successor act or
the protected basis from which the required next-phase execution
condition is formed.
CW-2.7.2 — Representative Receipt Structure
VALIDATOR_ACCEPTED_EFFECT_RECEIPT = { receipt_version, workflow_id,
predecessor_phase_id, predecessor_candidate_act_digest,
Das Expires 29 April 2027 [Page 52]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.1.3.19. Source page 81 of the original specification
predecessor_finality_sink_id, predecessor_effectuation_attempt_id,
actual_effect_descriptor, qualified_observation_reference,
supported_outcome_predicate, validator_unique_identity,
validator_cryptographic_key_id, validator_authorization_profile,
validation_policy_reference, validator_acceptance_decision,
permitted_successor_phase_id, permitted_successor_candidate_digest,
designated_successor_sink_id, authority_epoch,
receipt_freshness_reference, receipt_consumption_reference,
protected_sequence_or_counter, cryptographic_validator_authentication
} A single receipt may omit fields that are immaterial to a
particular effect, provided the necessary causal and identity
bindings remain verifiable.
CW-2.7.3 — Receipt Is Not a Blockchain Object
The receipt may be a compact signed message.
It may be an authenticated controller event.
It may be stored in a protected register.
It may be a protected memory object.
It may be a cryptographically authenticated state transition.
It may be an operation-bound key-release authorization.
It may be a non-exportable protected receipt handle.
It may be an internal condition of a secure state machine.
No distributed ledger is necessary.
CW-2.7.4 — Receipt Acceptance
The IEV accepts a receipt only after the required outcome evidence
and authorization predicates pass.
Acceptance is bound to the validator's authenticated identity.
CW-2.7.5 — Receipt as Direct Authority
In one implementation, the VAER itself includes the scoped successor
authority accepted by the Finality Sink.
Das Expires 29 April 2027 [Page 53]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.1.3.20. Source page 82 of the original specification
The sink validates the receipt and actual successor operation before
effectuation.
CW-2.7.6 — Receipt as Key-Enabling Factor
In another implementation, the VAER is a necessary input to a
protected key service.
The key service releases or derives the cryptographic material
required for successor effectuation only after validating the VAER.
CW-2.7.7 — Receipt as State-Enabling Factor
In another implementation, receipt acceptance causes a protected
controller state transition enabling the next operation.
The sink verifies the authenticated receipt-linked state.
CW-2.7.8 — Receipt as Non-Bearer Authority
The receipt may be copied or transported without granting
unrestricted authority.
The designated sink verifies current authority, actual operation, and
applicable protected consumption state.
CW-2.7.9 — Receipt Consumption
A single-use VAER may be consumed through an atomic protected state
transition.
The same receipt cannot produce additional unauthorized effects by
being replayed.
CW-2.8 — CAUSAL ORDERING AND PROTECTED CONTINUATION
CW-2.8.1 — Formal Causal Relationship
Let E[i] denote an earlier bounded real effect.
Let R[i] denote qualified receipt evidence concerning E[i].
Let V[i] denote acceptance by an authorized IEV.
Let C[i+1] denote the required successor execution condition.
Das Expires 29 April 2027 [Page 54]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Let FS[i+1] denote the successor Finality Sink.
The required relationship is:
E[i] -> R[i] -> V[i] -> C[i+1] -> FS[i+1] -> E[i+1] The relation does
not require globally synchronized clocks.
It requires protected proof of the specified predecessor
dependencies.
CW-2.8.2 — Causal Receipt Acceptance
9.1.3.21. Source page 83 of the original specification
V[i] cannot be accepted for a required actual-effect predicate merely
because the requesting agent predicted E[i].
The accepted evidence must satisfy the applicable real-effect
observation requirement.
CW-2.8.3 — No Premature Continuation
C[i+1] remains invalid or unavailable before the accepted receipt
condition exists.
CW-2.8.4 — No Arbitrary Phase Skipping
Where sequential causal dependencies are mandatory, a later phase
cannot be executed without satisfying the required predecessor
transitions.
CW-2.8.5 — Branching
Different acceptable prior outcomes may enable different
preauthorized successor branches.
A failure or partial-effect receipt may enable a narrow recovery
branch rather than the originally intended broader effect.
CW-2.8.6 — Multiple Predecessors
A successor may require receipts from several earlier effects.
The protected continuation condition may require all designated
receipts or a specifically authorized threshold.
CW-2.8.7 — Parallel Effects
Das Expires 29 April 2027 [Page 55]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Independent non-conflicting phases may operate concurrently where the
applicable protected constraints permit.
A later phase requiring their joint results remains withheld until
the required accepted receipts are available.
CW-2.8.8 — Effect-Specific Finality
The evidence must establish the particular actual consequence
required by the successor operation.
A command-dispatch receipt does not automatically prove a remote
resource was modified.
A controller acknowledgement does not automatically prove that a
physical actuator reached the target position.
CW-2.9 — RECEIPT DELIVERY TO THE SUCCESSOR FINALITY SINK
CW-2.9.1 — Direct Delivery
The IEV may send the VAER directly to the successor Finality Sink
through an authenticated communication channel.
9.1.3.22. Source page 84 of the original specification
CW-2.9.2 — Protected Registry Retrieval
The sink may retrieve the VAER from an authoritative protected
registry.
CW-2.9.3 — Protected Internal State
Where the validator and sink are integrated, the IEV may commit an
identity-bound acceptance event to protected internal state.
The effectuation function verifies that state before release.
CW-2.9.4 — Controller Bus
A physically separate validator may transmit the accepted receipt
over an authenticated hardware or controller communication interface.
CW-2.9.5 — Secure Mailbox
A protected mailbox may convey the receipt from the IEV to the
effectuation controller.
Das Expires 29 April 2027 [Page 56]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
CW-2.9.6 — Receipt Reference
A compact reference may be supplied instead of a complete receipt
object.
The sink resolves the reference through the appropriate authoritative
source and verifies the underlying accepted receipt.
CW-2.9.7 — Required Sink Checks
The sink determines:
Whether the validator identity is authentic;
Whether the validator remains authorized;
Whether the correct prior effect is represented;
Whether the required outcome predicate is supported;
Whether the receipt belongs to the proposed successor;
Whether the successor's actual operation is within the permitted
scope;
Whether the receipt remains valid and unconsumed;
And whether current protected authority permits effectuation.
CW-2.9.8 — No Trust in Agent-Carried Assertions
An agent may transport a receipt but cannot independently modify its
protected authority or validator acceptance.
A message stating that the receipt was previously approved is not a
substitute for receipt authentication.
9.1.3.23. Source page 85 of the original specification
CW-2.10 — DETAILED MODE A OPERATIONAL WORKFLOW
Step A1 — Construct Candidate Act
An agent proposes a consequential operation.
Step A2 — Establish Non-Effective Hold
The operation is withheld at a controlled boundary.
Das Expires 29 April 2027 [Page 57]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Step A3 — Perform Initial Authorization
The PED verifies applicable scope, identity, and protected authority.
Step A4 — Prepare Actual Operation
A protected component constructs the operation that would be
executed.
Step A5 — Identify Required Validator
The protected controller determines which IEV identity or authorized
role must approve the operation.
Step A6 — Reconstruct Actual Pending Operation
The IEV obtains the actual operation through a protected interface.
Step A7 — Verify Current Predicates
The IEV checks the operation against relevant current authority and
protected state.
Step A8 — Authenticate Pre-Effect Result
If validation succeeds, the IEV authenticates a PEVR under its
verifiable identity.
Step A9 — Deliver Result to Final Sink
The PEVR is sent or made available through protected state.
Step A10 — Final Sink Verification
The sink authenticates the validator, verifies the actual command and
current authority, and prevents unauthorized replay.
Step A11 — Permit Consequence
Only then may the governed principal effect occur.
Mode A is an optional in-line protection.
It does not require an earlier actual-effect receipt.
Das Expires 29 April 2027 [Page 58]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.1.3.24. Source page 86 of the original specification
CW-2.11 — DETAILED MODE B OPERATIONAL WORKFLOW
Step B1 — Construct First Candidate Act
An agent proposes an initial bounded consequential operation.
Step B2 — Establish Protected Authorization
The PED validates the permitted first phase.
Step B3 — Verify First Actual Operation
The first Finality Sink reconstructs and verifies the actual pending
operation.
Step B4 — Release First Real Effect
The first effect is permitted within its authorized bounds.
Step B5 — Record Actual Attempt
The protected system associates the effect with an authenticated
attempt reference.
Step B6 — Obtain Actual-Effect Evidence
A qualified observer or controller obtains evidence concerning what
happened.
Step B7 — Construct Effect Receipt
A PER is formed from the supported observation evidence.
Step B8 — Authenticate Required Validator
The relevant IEV establishes its authorized identity and validation
role.
Step B9 — Independently Evaluate Receipt
The IEV checks the evidence, required effect, phase ordering,
operation identity, and current protected state.
Step B10 — Produce Validator-Accepted Receipt
The IEV creates or commits a VAER under its cryptographic identity.
Das Expires 29 April 2027 [Page 59]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Step B11 — Bind Successor Scope
The accepted receipt is associated with the permitted successor
Candidate Act and designated Finality Sink.
Step B12 — Deliver Receipt
The receipt is delivered to or made available to the successor
Finality Sink.
9.1.3.25. Source page 87 of the original specification
Step B13 — Establish Missing Execution Condition
The VAER directly constitutes, enables, releases, derives, or
activates the required continuation condition.
Step B14 — Reconstruct Successor Operation
The successor sink obtains the actual pending consequential
operation.
Step B15 — Verify Validator Identity
The sink authenticates the accepting IEV and checks its authorization
profile.
Step B16 — Verify Causal Receipt
The sink checks the required predecessor evidence, phase lineage,
current authority, and replay state.
Step B17 — Consume Authority
Where required, the sink atomically consumes the applicable single-
use continuation condition.
Step B18 — Release Next Real Effect
The next consequential operation becomes effective only after its
receipt-dependent conditions are satisfied.
Step B19 — Observe Next Outcome
Where another phase depends upon the current effect, the process
produces the next effect receipt and repeats the protected causal
sequence.
Das Expires 29 April 2027 [Page 60]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
CW-2.12 — COMBINED AND NESTED PHASES
A larger authorized task may contain nested phases.
A parent authorization may establish the maximum permitted resource,
destination, privilege, monetary amount, or other effect scope.
Individual phases remain subject to their applicable causal
dependencies.
A successor phase may require both the VAER from its predecessor and
a new in-line PEVR verifying the current actual operation.
A protected parent task cannot automatically override a missing
mandatory phase receipt.
A nested workflow may contain local preparation, bounded
effectuation, observation, receipt acceptance, and subsequent
effectuation steps.
The physical components responsible for those steps may be integrated
or distributed.
9.1.3.26. Source page 88 of the original specification
CW-2.13 — PROTECTED CAUSAL STATE MACHINE
A representative state machine may include:
CREATED: The phase exists but lacks authority to produce the governed
effect.
HELD: The phase remains non-effective.
AUTHORIZED_PREPARATION: Preliminary preparation is permitted.
INLINE_VALIDATION_PENDING: An optional IEV result is required.
INLINE_VALIDATED: The authorized IEV accepted the actual pending
operation.
FINALITY_READY: Required initial finality conditions are satisfied.
EFFECT_ATTEMPTED: The first consequential operation was initiated.
EFFECT_CONFIRMED: Qualified evidence supports the required actual
result.
Das Expires 29 April 2027 [Page 61]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
PARTIAL_EFFECT: Only a defined part of the result is established.
EFFECT_MISMATCH: The observed consequence differs materially from the
authorized effect.
NO_EFFECT_CONFIRMED: Suitable evidence establishes absence of the
relevant effect.
OUTCOME_UNKNOWN: Required outcome evidence is insufficient.
RECEIPT_CONSTRUCTED: A PER has been formed.
IEV_ACCEPTANCE_PENDING: The receipt has not yet passed required
validator checks.
VALIDATOR_ACCEPTED: The authorized IEV has authenticated acceptance.
RECEIPT_AVAILABLE_TO_SINK: The successor sink can verify the accepted
receipt.
CONTINUATION_CONDITION_ESTABLISHED: The required CCC exists or is
active.
SUCCESSOR_FINALITY_PENDING: The actual successor operation awaits
sink verification.
SUCCESSOR_EFFECT_ATTEMPTED: The next consequential operation has been
initiated.
RECOVERY_PENDING: A separately governed recovery operation is
required.
TERMINATED: The applicable phase or task has concluded.
A transition to CONTINUATION_CONDITION_ESTABLISHED shall not be
triggered by an untrusted completion flag alone.
It requires the appropriate accepted receipt or protected equivalent.
CW-2.14 — CRYPTOGRAPHIC CAUSAL ENFORCEMENT
CW-2.14.1 — Receipt-Dependent Key Release
9.1.3.27. Source page 89 of the original specification
A protected key service may withhold the material necessary for the
next consequential operation.
Das Expires 29 April 2027 [Page 62]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Successful VAER verification enables release of the appropriate
scoped material.
CW-2.14.2 — Receipt-Dependent Key Derivation
A non-limiting construction may use:
K_NEXT = KDF( ProtectedRootSecret, H(ValidatorAcceptedReceipt),
SuccessorCandidateDigest, FinalitySinkIdentity, AuthorityEpoch,
ProtectedPhaseCounter ) The protected root secret remains unavailable
to the untrusted agent.
The service enforces validation before deriving or releasing usable
execution material.
CW-2.14.3 — Split-Key Authorization
The next effect may require a cryptographic key assembled from
separate protected components.
A required component is released only after receipt validation.
CW-2.14.4 — Threshold Signature
The successor operation may require a threshold signature containing
at least one validator-controlled authorized contribution.
CW-2.14.5 — Cryptographic Command Authorization
A controller may require an authenticated command whose validity
depends upon the VAER.
CW-2.14.6 — Protected Data Release
A subsequent information object may remain encrypted until receipt-
dependent cryptographic material becomes available.
CW-2.14.7 — Cryptographic Identity Versus Cryptographic Gate
The validator identity is cryptographically authenticated.
The continuation gate may separately use cryptography or non-
cryptographic protected state.
These are distinct implementation choices.
CW-2.14.8 — Cryptographic Limitation
Das Expires 29 April 2027 [Page 63]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Cryptographic material is not a substitute for mandatory
effectuation-path coverage.
9.1.3.28. Source page 90 of the original specification
If the same consequence can be produced without the required
cryptographic procedure, that alternate path must be separately
controlled before non-bypassability can be claimed for it.
CW-2.15 — NON-CRYPTOGRAPHIC CAUSAL ENFORCEMENT
CW-2.15.1 — Protected Hardware Latch
A hardware controller may maintain a latch disabling a successor
effect.
A validator-authenticated receipt causes the permitted latch
transition.
CW-2.15.2 — Protected State Register
A protected register may contain the current phase and continuation
status.
The agent cannot independently modify it.
CW-2.15.3 — Atomic State-Machine Transition
The receipt acceptance procedure may atomically consume a predecessor
receipt and enable the designated successor.
CW-2.15.4 — Secure Command Queue
A command queue may refuse a successor command until protected
receipt-dependent state permits dispatch.
CW-2.15.5 — Storage Controller Gate
A protected storage controller may withhold a consequential commit
until a VAER-derived condition exists.
CW-2.15.6 — Network Controller Gate
A protected network controller may withhold a later transmission
pending accepted evidence from an earlier bounded real network
effect.
CW-2.15.7 — Actuator Controller Gate
Das Expires 29 April 2027 [Page 64]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A physical actuator controller may require a protected phase state
enabled through actual-effect receipt validation.
CW-2.15.8 — Transaction Controller Gate
A transactional system may refuse a successor commit unless the
correct accepted predecessor receipt is present in authoritative
protected state.
CW-2.15.9 — Single Protected Component
The receipt may be accepted and consumed entirely within one
protected controller without a separately exported token.
9.1.3.29. Source page 91 of the original specification
CW-2.15.10 — Required Security Property
The effectuation component must actually enforce the protected state.
A state variable modifiable by an untrusted agent is insufficient to
establish non-bypassable receipt-gated authority.
CW-2.16 — GENERALIZED CONTINUATION PREDICATE
A principal continuation predicate may be expressed as:
CONTINUE[i+1] = VALID_PREDECESSOR_EFFECT[i] AND VALID_IEV_IDENTITY[i]
AND VALID_IEV_ACCEPTED_RECEIPT[i] AND VALID_PHASE_LINEAGE[i+1] AND
VALID_SUCCESSOR_SCOPE[i+1] AND VALID_CURRENT_AUTHORITY[i+1] AND
VALID_SINK_BINDING[i+1] AND VALID_CONSUMPTION_STATE[i+1] The receipt
must not merely be present as data.
It must satisfy the actual sink's protected causal release protocol.
Where any mandatory predicate is absent, invalid, or unsupported, the
successor effect remains withheld.
CW-2.17 — IMPLEMENTABLE REFERENCE PSEUDOCODE
CW-2.17.1 — Validator Enrollment
FUNCTION ENROLL_VALIDATOR( validator_instance, authorized_role,
protected_identity_authority ):
REQUIRE VERIFY_VALIDATOR_BOUNDARY( validator_instance )
Das Expires 29 April 2027 [Page 65]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
credentials = PROVISION_PROTECTED_CRYPTOGRAPHIC_IDENTITY(
validator_instance )
REQUIRE VERIFY_KEY_POSSESSION( validator_instance, credentials )
9.1.3.30. Source page 92 of the original specification
identity = protected_identity_authority.REGISTER({
unique_validator_id: NEW_ENROLLED_IDENTIFIER(),
verification_key: credentials.public_verification_key,
authorized_role: authorized_role,
authority_epoch: CURRENT_AUTHORITY_EPOCH(),
credential_generation: CURRENT_KEY_GENERATION() })
REQUIRE identity == COMMITTED
RETURN identity CW-2.17.2 — Initial Phase Admission
FUNCTION ADMIT_PHASE( candidate_act, phase_descriptor,
protected_policy ):
REQUIRE PED.VERIFY_INITIAL_AUTHORITY( candidate_act, protected_policy
)
REQUIRE PED.VERIFY_PHASE_SCOPE( phase_descriptor )
hold = ESTABLISH_REQUIRED_NON_EFFECTIVE_HOLD( candidate_act )
IF hold != VERIFIED: RETURN DENY
RETURN PED.COMMIT_PHASE_ADMISSION({ candidate_act:
HASH(candidate_act),
phase: HASH(phase_descriptor),
9.1.3.31. Source page 93 of the original specification
state: HELD,
protected_attempt_reference: NEW_PROTECTED_REFERENCE() }) CW-2.17.3 —
First Real Effect
FUNCTION EXECUTE_FIRST_EFFECT( candidate_act, first_sink ):
Das Expires 29 April 2027 [Page 66]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
actual_operation = first_sink.RECONSTRUCT_ACTUAL_PENDING_OPERATION()
REQUIRE first_sink.VERIFY_SCOPED_AUTHORITY( candidate_act,
actual_operation )
consumption = first_sink.ATOMIC_CONSUME_REQUIRED_AUTHORITY()
IF consumption != SUCCESS: RETURN DENY
attempt = first_sink.EFFECTUATE(actual_operation)
RECORD_PROTECTED_ATTEMPT(attempt)
RETURN attempt CW-2.17.4 — Actual-Effect Receipt Formation
FUNCTION FORM_EFFECT_RECEIPT( predecessor_phase, effect_attempt,
observation ):
witness = QUALIFY_EFFECT_WITNESS( observation.source )
IF witness IS INVALID: RETURN OUTCOME_UNKNOWN
outcome = CLASSIFY_SUPPORTED_ACTUAL_EFFECT( observation,
9.1.3.32. Source page 94 of the original specification
predecessor_phase.required_outcome )
receipt = PROTECTED_COMMIT({ predecessor: HASH(predecessor_phase),
attempt: HASH(effect_attempt),
witness_identity: witness.identifier,
outcome: outcome,
observation: HASH(observation),
protected_sequence: NEXT_PROTECTED_SEQUENCE() })
RETURN receipt CW-2.17.5 — Authorized IEV Receipt Acceptance
FUNCTION IEV_ACCEPT_RECEIPT( validator_identity, effect_receipt,
predecessor_phase, successor_phase ):
REQUIRE VERIFY_ENROLLED_IEV_IDENTITY( validator_identity )
Das Expires 29 April 2027 [Page 67]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
REQUIRE VERIFY_IEV_AUTHORIZED_ROLE( validator_identity,
predecessor_phase, successor_phase )
REQUIRE VERIFY_EFFECT_RECEIPT_AUTHENTICITY( effect_receipt )
REQUIRE VERIFY_PREDECESSOR_BINDING( effect_receipt, predecessor_phase
)
9.1.3.33. Source page 95 of the original specification
REQUIRE VERIFY_REQUIRED_REAL_EFFECT( effect_receipt,
successor_phase.required_predecessor_outcome )
REQUIRE VERIFY_SUCCESSOR_SCOPE( successor_phase )
REQUIRE VERIFY_CURRENT_POLICY_AND_REVOCATION()
accepted_state = IEV.ATOMIC_COMMIT({ accepted_receipt:
HASH(effect_receipt),
validator_identity: validator_identity.identifier,
successor: HASH(successor_phase),
successor_sink: successor_phase.sink_id,
decision: ACCEPT,
consumption_reference: NEW_PROTECTED_REFERENCE(),
phase_counter: NEXT_PROTECTED_COUNTER() })
IF accepted_state != COMMITTED: RETURN DENY
RETURN AUTHENTICATE_AS_IEV( validator_identity, accepted_state ) CW-
2.17.6 — Protected Receipt Delivery
FUNCTION PROVIDE_RECEIPT_TO_SINK( validator_accepted_receipt,
successor_sink ):
REQUIRE VERIFY_VALIDATED_RECEIPT_AUTHENTICATION(
validator_accepted_receipt )
9.1.3.34. Source page 96 of the original specification
delivery = AUTHENTICATED_DELIVER_OR_REGISTER(
validator_accepted_receipt, successor_sink.identifier )
Das Expires 29 April 2027 [Page 68]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
IF delivery != SUCCESS: RETURN RECEIPT_UNAVAILABLE
RETURN delivery.authoritative_receipt_reference CW-2.17.7 — Next
Finality Sink Enforcement
FUNCTION EFFECTUATE_SUCCESSOR( successor_candidate_act,
accepted_receipt_reference, successor_sink ):
actual_operation = successor_sink.RECONSTRUCT_PENDING_OPERATION()
IF actual_operation IS NULL: RETURN DENY
vaer = successor_sink.RESOLVE_AUTHORITATIVE_RECEIPT(
accepted_receipt_reference )
REQUIRE successor_sink.VERIFY_IEV_IDENTITY( vaer.validator_identity )
REQUIRE successor_sink.VERIFY_IEV_CRYPTOGRAPHIC_AUTH( vaer )
REQUIRE successor_sink.VERIFY_IEV_ROLE_AUTHORIZATION( vaer,
actual_operation )
REQUIRE successor_sink.VERIFY_CAUSAL_PREDECESSOR( vaer,
successor_candidate_act )
REQUIRE successor_sink.VERIFY_SUCCESSOR_BINDING( vaer,
actual_operation )
REQUIRE successor_sink.VERIFY_CURRENT_AUTHORITY()
9.1.3.35. Source page 97 of the original specification
REQUIRE successor_sink.VERIFY_CCC( vaer, actual_operation )
consumption = successor_sink.ATOMIC_CONSUME( vaer, actual_operation )
IF consumption != SUCCESS: RETURN DENY
RETURN successor_sink.EFFECTUATE( actual_operation, consumption ) CW-
2.17.8 — Cryptographic Continuation Enablement
FUNCTION RELEASE_CRYPTOGRAPHIC_ENABLEMENT( vaer, successor_act,
protected_key_service ):
REQUIRE VERIFY_AUTHORIZED_VALIDATOR_RECEIPT(vaer)
REQUIRE VERIFY_SUCCESSOR_SCOPE( vaer, successor_act )
Das Expires 29 April 2027 [Page 69]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
REQUIRE VERIFY_CURRENT_PROTECTED_STATE()
result = protected_key_service.DERIVE_OR_RELEASE({ accepted_receipt:
HASH(vaer),
successor: HASH(successor_act),
sink: successor_act.sink_id,
epoch: CURRENT_AUTHORITY_EPOCH(),
protected_counter: CURRENT_PHASE_COUNTER() })
9.1.3.36. Source page 98 of the original specification
RETURN result The key service must maintain any necessary secret or
protected authority material inaccessible to the untrusted agent.
CW-2.17.9 — Non-Cryptographic Continuation Enablement
FUNCTION ACTIVATE_PROTECTED_CONTINUATION( vaer, protected_controller
):
REQUIRE VERIFY_AUTHORIZED_VALIDATOR_RECEIPT(vaer)
REQUIRE protected_controller.VERIFY_PHASE_LINEAGE()
REQUIRE protected_controller.VERIFY_RECEIPT_UNUSED()
REQUIRE protected_controller.VERIFY_CURRENT_AUTHORITY()
transition = protected_controller.ATOMIC_TRANSITION({ expected:
NEXT_PHASE_DISABLED,
required_receipt: HASH(vaer),
successor: vaer.authorized_successor,
new_state: NEXT_PHASE_ENABLED })
RETURN transition CW-2.17.10 — Failure Behavior
If any required verification fails, the successor effect remains
disabled.
An untrusted scheduler cannot replace the failed step with an
arbitrary success assertion.
Das Expires 29 April 2027 [Page 70]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
CW-2.18 — GENERALIZED MULTI-PHASE CAUSAL ALGORITHM
In a non-limiting implementation, a parent workflow comprises
multiple controlled consequential phases.
The initial phase is authorized separately.
For each subsequent phase, the protected controller identifies the
required predecessor effects.
The controller obtains the applicable validated receipts.
9.1.3.37. Source page 99 of the original specification
The successor phase is not effectually enabled unless all mandatory
receipt-dependent conditions are satisfied.
A generalized sequence is:
FOR EACH successor_phase:
REQUIRE valid original or delegated authority
REQUIRE required predecessor receipts
REQUIRE authorized IEV acceptance
REQUIRE authentic validator identities
REQUIRE protected causal lineage
REQUIRE successor-specific scope
REQUIRE current finality state
REQUIRE actual sink operation correspondence
ATOMICALLY consume required continuation authority
EFFECTUATE successor phase
OBSERVE actual effect where required
PRODUCE next receipt
REPEAT A parent task may contain conditional branches, parallel
operations, nested phases, or distributed control.
Das Expires 29 April 2027 [Page 71]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The protected causal dependency applies to each operation for which
the corresponding receipt-gated condition is mandatory.
CW-2.19 — PRINCIPAL PROTECTED INVARIANTS
Invariant C1 — Real Predecessor Effect: Where the required
predecessor predicate concerns an actual external effect, an
unsupported agent prediction cannot satisfy the predicate.
Invariant C2 — Authorized Validator: The required acceptance must
originate from an IEV possessing a valid cryptographically
authenticated identity and appropriate role.
Invariant C3 — Receipt Dependency: The successor phase cannot obtain
or exercise valid effectuation enablement independently of the
required accepted receipt.
Invariant C4 — Mandatory Sink Enforcement: The successor Finality
Sink verifies the receipt-derived condition before effectuation.
9.1.3.38. Source page 100 of the original specification
Invariant C5 — Physical-Placement Neutrality: The same causal
requirement applies whether the IEV is physically separate,
integrated, or distributed.
Invariant C6 — No Validator Impersonation: A copied VUID without
valid cryptographic authentication is insufficient.
Invariant C7 — No Unauthorized Substitution: A receipt from an
unrelated validator, predecessor, or successor does not satisfy the
required condition.
Invariant C8 — Operation Binding: The actual pending successor
operation must match the scope covered by the receipt-dependent
authority.
Invariant C9 — Replay Control: A receipt cannot be reused beyond its
authorized consumption rules.
Invariant C10 — Phase Ordering: Required predecessor dependencies
cannot be skipped.
Invariant C11 — Non-Bearer Scope: Possession of a raw or copied
receipt does not authorize arbitrary operations.
Invariant C12 — Outcome Honesty: Unknown remote outcomes are not
treated as confirmed success or failure without adequate evidence.
Das Expires 29 April 2027 [Page 72]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Invariant C13 — Protected State Integrity: Required continuation
state cannot be directly rewritten by the untrusted requesting
entity.
Invariant C14 — Controlled Effectuation Coverage: Every effectuation
route claimed to be non-bypassable must enforce the required causal
condition or be constrained by an equivalent authoritative mechanism.
Invariant C15 — Validator Revocation: A validator whose credentials
or authority are invalid cannot issue newly acceptable continuation
receipts under the applicable current trust policy.
Invariant C16 — Recovery Separation: Corrective actions remain
separately authorized where they produce new consequences.
Invariant C17 — No Retroactive Erasure: A completed real effect is
not made non-effective merely because a later receipt validation
fails.
Invariant C18 — No Blockchain Dependence: The receipt-gating
mechanism does not require a ledger or append-only blockchain.
CW-2.20 — CRASH, REPLAY, AND REVOCATION HANDLING
CW-2.20.1 — Crash Before First Effect
The first consequential operation remains non-effective where
required authorization was not completed.
CW-2.20.2 — Crash After First Effect
The system preserves the effectuation attempt reference.
9.1.3.39. Source page 101 of the original specification
A local crash does not imply that the external consequence failed.
CW-2.20.3 — Crash Before Receipt Formation
The outcome remains unresolved until suitable evidence can be
obtained.
CW-2.20.4 — Crash During IEV Acceptance
An incomplete validation procedure does not automatically establish
next-phase authority.
CW-2.20.5 — Crash After Accepted Receipt
Das Expires 29 April 2027 [Page 73]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The system may recover the VAER and its protected consumption state.
CW-2.20.6 — Crash During Receipt Delivery
The successor sink may retrieve the receipt again from an
authoritative source.
Repeated receipt transport does not independently authorize repeated
effects.
CW-2.20.7 — Crash After Authority Consumption
The system does not automatically restore consumed authority.
The actual successor attempt is reconciled before potentially
duplicative retry.
CW-2.20.8 — Validator Unavailability
Where a required IEV is unavailable, the dependent successor phase
remains withheld unless an expressly authorized alternate validator
satisfies the same protected requirements.
CW-2.20.9 — Validator Revocation
Revocation state is checked according to the applicable protected
policy and relevant effectuation time.
CW-2.20.10 — Protected-State Rollback
Protected epochs, counters, secure storage, or equivalent techniques
prevent unauthorized restoration of previously consumed continuation
authority.
CW-2.20.11 — Unknown Outcome
An unresolved earlier effect is represented honestly as uncertain.
Any dependent successor requiring confirmed completion remains
disabled.
CW-2.20.12 — Remote Reconciliation
Where supported, the system may obtain authenticated remote state,
controller evidence, or another qualified observation to resolve the
attempt.
Das Expires 29 April 2027 [Page 74]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.1.3.40. Source page 102 of the original specification
CW-2.21 — RECOVERY AND COMPENSATING EFFECTS
A recovery operation may be required after partial, mismatched, or
uncertain effectuation.
The recovery operation is represented as a separate Candidate Act
when it produces another consequential effect.
The recovery operation may have its own protected authority, required
effect observation, IEV validation, and finality conditions.
A valid receipt establishing an adverse effect may enable a narrowly
authorized recovery branch.
The receipt does not automatically confer unrestricted corrective
authority.
A compensating financial transaction does not necessarily erase the
first transaction.
A corrective message does not necessarily retract previously
disclosed information.
A physical recovery movement does not necessarily reverse all earlier
physical consequences.
The architecture records the actual resulting state and applies new
protected causal dependencies where required.
CW-2.22 — BASIC UNDERSTANDABLE EXAMPLE: ONE REAL DEVICE EFFECT
ENABLES THE NEXT
A user authorizes an autonomous controller to update a group of
devices.
The protected task policy requires a bounded real update on one
designated device before broader deployment.
The first Finality Sink permits the authorized update to the test
device.
The device actually applies the update.
A qualified controller produces authenticated evidence of the
resulting software state.
Das Expires 29 April 2027 [Page 75]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
An authorized IEV, identified by its enrolled cryptographic identity,
verifies the evidence.
The IEV produces a VAER bound to the update operation, result,
approved next deployment population, and designated successor
Finality Sink.
The broader deployment authority remains unavailable before this
receipt acceptance.
The successor deployment sink verifies the IEV identity and VAER.
It also checks the actual update package and destination devices.
Only then does it permit the broader effect.
If the test-device receipt is missing, stale, forged, or generated by
an unauthorized validator, the broader deployment cannot proceed
through the protected controller.
9.1.3.41. Source page 103 of the original specification
The receipt does not merely inform the agent that testing passed.
The accepted receipt is the necessary enabling factor for the next
real deployment.
CW-2.23 — EXAMPLE: PHYSICALLY ADDED VALIDATOR BETWEEN CONTROLLERS
An autonomous system operates through a protected network or hardware
command interface.
A separate IEV appliance is installed between the initial-effect
observation source and the downstream effectuation controller.
The appliance has a VUID and cryptographic credentials enrolled with
the downstream Finality Sink.
The first bounded operation produces actual-effect evidence.
The appliance validates that evidence.
It authenticates a successor-bound receipt.
The receipt is transmitted to the downstream controller.
The controller verifies the validator identity and receipt.
Das Expires 29 April 2027 [Page 76]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The protected controller refuses the next effect if the receipt is
unavailable or invalid.
The system may be configured so that every claimed protected path to
the effectuation resource terminates at a controller enforcing the
same receipt requirement.
The security property arises from mandatory downstream verification,
not solely from the appliance's physical presence.
CW-2.24 — EXAMPLE: SINGLE CHIP WITH INTEGRATED VALIDATOR
A protected chip contains both the IEV and the effectuation
controller.
The IEV is implemented as a logically distinguishable protected
function with an enrolled cryptographic identity.
The chip performs an initial bounded real effect.
A protected observation function records the actual result.
The IEV validates the observation.
A validator-identity-bound acceptance event is committed to protected
chip state.
The effectuation controller verifies the corresponding accepted
state.
The next command remains disabled until that state exists.
9.1.3.42. Source page 104 of the original specification
The internal communication may occur through protected registers or
memory rather than an external signed message.
The validator's enrolled cryptographic identity remains part of the
protected trust relationship.
The arrangement demonstrates that separate physical devices are not
necessary to implement receipt-dependent causal authority.
CW-2.25 — EXAMPLE: CLOUD, REMOTE SERVICE, AND CROSS-DOMAIN VALIDATOR
An autonomous agent requests a bounded real cloud-resource operation.
Das Expires 29 April 2027 [Page 77]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The controlled first operation produces an authenticated resource-
state record.
A remotely located IEV validates the record.
The IEV possesses a registered cryptographic identity authorized for
the relevant effect class.
It authenticates a receipt identifying the verified resource, actual
state, and permitted next operation.
A successor Finality Sink located in another computing domain
retrieves the receipt through a protected service.
The sink verifies the IEV identity, predecessor outcome, operation
binding, and current authority.
Only then does the next cloud operation become effective.
The arrangement may span multiple devices or administrative domains
without requiring one central physical security appliance.
CW-2.26 — EXAMPLE: ROBOTIC CAUSAL PHASE CONTROL
A robotic actuator is authorized to move through successive bounded
positions.
The first actuator controller permits an initial real movement.
A protected position sensor measures the resulting state.
An IEV validates the measured position under the applicable tolerance
predicate.
The validator produces an authenticated accepted receipt.
The protected actuator controller receives the receipt or
corresponding protected state.
A hardware latch for the next movement remains disabled until the
receipt-dependent condition is satisfied.
The next command is independently checked against actual current
actuator state.
If the first movement did not reach the required position, the next
movement remains unavailable.
Das Expires 29 April 2027 [Page 78]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.1.3.43. Source page 105 of the original specification
The receipt therefore directly participates in enabling the later
physical consequence.
CW-2.27 — ADVERSARIAL AND DESIGN-AROUND-RESISTANCE VARIATIONS
The following examples illustrate different attempts to avoid the
required causal enforcement mechanism and the corresponding protected
implementation alternatives.
Variation 1 — Replace Separate Validator with Integrated Software
A system may combine validation and effectuation within one protected
service.
The causal property remains implemented where the effectuation
function requires authenticated validator-accepted state inaccessible
to the untrusted agent.
Variation 2 — Replace Cryptographic Key Release with Hardware State
The next operation may be enabled through a protected hardware
register instead of a newly derived key.
The relevant continuation still depends upon receipt acceptance.
Variation 3 — Replace Transferable Receipt with Internal State
A system may avoid exporting a receipt object.
A protected internal acceptance event may nevertheless constitute the
required receipt when it is authenticated to the validator identity
and enforced by the successor sink.
Variation 4 — Move the Validator to the Destination
The IEV may reside in the remote recipient or device.
The destination-side Finality Sink requires its validated receipt
before completing the successor consequence.
Variation 5 — Use Multiple Validators
A protected threshold of authorized validators may jointly establish
the receipt acceptance condition.
Variation 6 — Use a Distributed Validator Service
Das Expires 29 April 2027 [Page 79]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Validation may be performed across several protected servers.
The successor sink authenticates the accepted result according to the
authorized validator group and current trust policy.
Variation 7 — Use a Hardware Interlock
A receipt may activate a protected interlock.
The physical effectuation path remains dependent upon accepted prior-
effect evidence.
9.1.3.44. Source page 106 of the original specification
Variation 8 — Use a Secure Command Queue
A subsequent command may remain in a protected non-effective queue
until the receipt-dependent state permits release.
Variation 9 — Use a Transaction Controller
A database or transactional resource controller may require the
validated predecessor receipt before committing a successor state
change.
Variation 10 — Use a Cryptographic Threshold Share
An IEV-controlled share may be necessary to authenticate the next
operation.
Variation 11 — Use a Credential Activation Mechanism
The relevant credential may remain unusable for the successor effect
until the accepted receipt condition exists.
Variation 12 — Use a Protected Capability
The VAER may directly enable a scoped non-bearer execution handle.
Variation 13 — Use an Internal Device Security System
A phone, computer, or embedded device may provide an internal
protected validator with enrolled cryptographic identity.
The relevant effectuation controller verifies the receipt-dependent
continuation state.
Variation 14 — Use an External Security Module
Das Expires 29 April 2027 [Page 80]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A dedicated appliance or hardware module may validate effects and
transmit authenticated receipts to a downstream sink.
Variation 15 — Use a Remote Witness
The effect evidence may originate from a remote authenticated source,
provided its observation capability satisfies the required predicate.
Variation 16 — Use a Signed Event Instead of a Receipt File
An authenticated event may represent the accepted receipt without
being called a receipt by the implementation.
Its technical role remains the establishment of the required causal
continuation condition.
Variation 17 — Use Protected Memory Instead of a Token
A protected memory state may embody the validator acceptance.
The successor effectuation function requires that state.
9.1.3.45. Source page 107 of the original specification
Variation 18 — Use a Counter Instead of a Stored Receipt Chain
A protected phase counter may advance only after authenticated
receipt acceptance.
The next effect requires the correct counter and operation binding.
Variation 19 — Use a Direct IEV-to-Sink Interface
The validator may communicate directly with the final controller
without an intermediary capability issuer.
Variation 20 — Use a Separate Authority Issuer
The IEV may authenticate receipt acceptance to a protected authority
issuer, which generates the required next-phase capability.
The capability remains causally dependent upon the accepted receipt.
Variation 21 — Use One Component for IEV and Authority Issuance
The IEV may directly issue the next scoped authority upon successful
receipt acceptance.
Das Expires 29 April 2027 [Page 81]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Variation 22 — Use One Component for All Functions
The entire protocol may be implemented inside one protected
controller with distinguishable authority and state transitions.
Variation 23 — Replace an Agent with Another Autonomous Workload
The requesting entity may be an operating-system service,
application, autonomous controller, robotic process, or other effect-
capable computational entity.
The same protected causal condition may apply.
Variation 24 — Different Physical Finality Sink
The first and second consequential effects may be enforced by
different kinds of sinks, including a storage controller followed by
a network gateway.
Variation 25 — Same Finality Sink Across Phases
One sink may execute several causally ordered phases, enforcing a
distinct receipt-dependent authorization for each.
Variation 26 — Human-Approved Branch
An authorized user may approve a particular next operation under CW-
3.
Where prior actual-effect evidence is mandatory, the receipt
requirement remains enforced.
Variation 27 — Automated Remediation Branch
A protected policy may authorize a narrow recovery operation after a
validated failure receipt.
9.1.3.46. Source page 108 of the original specification
Variation 28 — No Public Ledger
The causal receipt may be transient and locally protected, without
any blockchain or distributed ledger.
Das Expires 29 April 2027 [Page 82]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
These variations describe technical alternatives. Their inclusion
does not by itself establish that every conceivable implementation
falls within a particular patent claim. Claim coverage depends upon
the operative limitations, original disclosure support, and
applicable patent law.
CW-2.28 — NON-LIMITING FEASIBILITY EXPERIMENTS
The following experiments are proposed and are not represented as
having been performed.
Experiment 1 — No Receipt: Attempt a successor effect before
generating the required predecessor receipt. Verify rejection.
Experiment 2 — No Validator Acceptance: Provide a raw effect receipt
without IEV acceptance. Verify rejection.
Experiment 3 — Valid Accepted Receipt: Provide the correct VAER and
verify permitted scoped continuation.
Experiment 4 — Wrong Validator: Submit a receipt authenticated by a
different unauthorized validator. Verify rejection.
Experiment 5 — Copied Validator Identifier: Copy the correct VUID but
use unrelated cryptographic credentials. Verify rejection.
Experiment 6 — Revoked Validator: Revoke an IEV and verify
enforcement of current revocation policy.
Experiment 7 — Wrong Predecessor: Use a genuine receipt from another
earlier operation. Verify rejection.
Experiment 8 — Wrong Successor: Reuse an accepted receipt for a
different next-phase Candidate Act. Verify rejection.
Experiment 9 — Wrong Sink: Deliver the receipt to an unauthorized
Finality Sink. Verify rejection where sink binding is required.
Experiment 10 — Receipt Replay: Reuse a single-use accepted receipt.
Verify protected consumption.
Experiment 11 — Phase Skipping: Attempt Phase 3 without the required
Phase 2 receipt. Verify refusal.
Experiment 12 — Hardware Latch: Verify that the next actuator latch
remains disabled before receipt acceptance.
Das Expires 29 April 2027 [Page 83]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Experiment 13 — Cryptographic Key Release: Verify that the required
next-phase key material is unavailable before accepted receipt
validation.
9.1.3.47. Source page 109 of the original specification
Experiment 14 — Protected State Transition: Verify that an agent
cannot directly activate the receipt-dependent continuation state.
Experiment 15 — Physically Separate IEV: Install a validator as a
separate appliance and verify authenticated receipt-to-sink control.
Experiment 16 — Integrated IEV: Combine validator and sink in a
protected controller while preserving the required causal conditions.
Experiment 17 — Distributed IEV: Perform receipt validation remotely
and verify cross-domain identity authentication.
Experiment 18 — Multiple Validators: Require a protected threshold of
distinct validator identities.
Experiment 19 — Remove Application Receipt Check: Bypass the ordinary
workflow-level receipt check and confirm that protected sink
enforcement still prevents unauthorized effectuation.
Experiment 20 — Alternate API: Attempt a covered effect through
another software interface and verify enforcement of the same receipt
condition.
Experiment 21 — Alternate Hardware Path: Test whether direct hardware
access bypasses the asserted protected controller and identify any
uncovered paths.
Experiment 22 — False Outcome Evidence: Supply evidence proving only
dispatch where the successor requires actual external completion.
Verify rejection.
Experiment 23 — Partial Effect: Produce a bounded partial effect and
verify the specified limited continuation behavior.
Experiment 24 — Unknown Outcome: Lose an acknowledgement after a real
external effect and verify safe uncertainty handling.
Experiment 25 — Crash After Accepted Receipt: Recover receipt state
without duplicating continuation authority.
Experiment 26 — Concurrent Receipt Use: Attempt simultaneous reuse of
one single-use VAER and verify atomic consumption.
Das Expires 29 April 2027 [Page 84]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Experiment 27 — Validator Key Rotation: Rotate the IEV's credentials
and verify current trust-state enforcement.
Experiment 28 — Validator Replacement: Replace a failed validator
only through authorized enrollment.
Experiment 29 — Multi-Phase Real Execution: Execute multiple phases,
each enabled by the required preceding accepted receipt.
Experiment 30 — No Blockchain: Demonstrate the complete causal
protocol using a protected local receipt and sink, without a ledger.
CW-2.29 — PHOSITA REFERENCE IMPLEMENTATION
9.1.3.48. Source page 110 of the original specification
A reference implementation may comprise a controlled autonomous
workload, a first effectuation gateway, a protected actual-effect
observer, a cryptographically identified IEV, an authenticated
receipt service, and a successor Finality Sink.
A protected validator identity may be established through an enrolled
asymmetric signing key and an authorized role record.
The effect observer may generate an authenticated transaction or
controller-completion record.
The IEV may validate the record against the authorized phase
descriptor.
The accepted result may be authenticated using the IEV's protected
key.
The successor sink may verify the signature, enrolled validator role,
predecessor phase, successor operation, and current protected
consumption state.
A transactional database or protected controller may maintain
receipt-consumption and phase-transition state.
The successor effectuation interface must deny commands that lack the
required valid receipt-dependent authorization.
A software prototype may initially demonstrate the protocol under an
expressly defined software trust model.
A hardware implementation may additionally provide protected keys,
non-bypassable command routing, secured registers, or isolated state.
Das Expires 29 April 2027 [Page 85]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
No blockchain infrastructure is necessary for this reference
implementation.
CW-2.30 — TECHNICAL EFFECTS
CW-2.30.1 — Enforced Causal Progression
The next real effect cannot proceed through the protected
effectuation path without accepted evidence of the required prior
effect.
CW-2.30.2 — Validator Provenance
The sink can determine which authorized validator accepted the
receipt.
CW-2.30.3 — Protection Against Validator Impersonation
A copied identifier or forged success message does not satisfy
required cryptographic authentication.
CW-2.30.4 — Protection Against Receipt Replay
Protected phase and consumption state may prevent unauthorized
repeated effects.
CW-2.30.5 — Protection Against Operation Substitution
9.1.3.49. Source page 111 of the original specification
The receipt is bound to the permitted successor operation and actual
sink verification.
CW-2.30.6 — Physical-Topology Independence
The required causal relationship can be enforced through integrated
or distributed protected components.
CW-2.30.7 — Reduced Advisory-Check Bypass
The effectuation authority is controlled by the sink rather than
merely by a workflow-level decision.
CW-2.30.8 — Protected Recovery
Uncertain or partial effects can be contained without automatically
repeating the same consequence.
Das Expires 29 April 2027 [Page 86]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
CW-2.30.9 — Controlled Autonomous Progression
The system may permit automatic phase advancement when authenticated
actual-effect evidence satisfies the applicable protected predicates.
CW-2.31 — DISTINCTION FROM CONVENTIONAL TECHNIQUES AND INVENTIVE-STEP
FOCUS
CW-2.31.1 — Conventional Workflow Scheduler
A scheduler may start the next job after the prior job reports
completion.
The proposed stronger arrangement requires an accepted real-effect
receipt to establish the next operation's technical execution
condition.
CW-2.31.2 — Conventional Receipt Checking
An application may inspect a receipt and decide to proceed.
Such a check may remain bypassable if the application retains
independent access to the effectuation primitive.
The present implementation requires the actual Finality Sink to
enforce the receipt-dependent condition.
CW-2.31.3 — Conventional Audit Logging
An audit record may describe past activity.
The VAER in the principal implementation contributes directly to
enabling a future protected effect.
The receipt need not be persisted as an audit log at all.
CW-2.31.4 — Conventional Blockchain Receipt
A blockchain receipt may provide evidence of inclusion or a
transaction state within a ledger system.
9.1.3.50. Source page 112 of the original specification
CW-2 does not depend upon blockchain inclusion.
The relevant receipt authenticates validator acceptance and supplies
a necessary causal condition for subsequent controlled effectuation.
Das Expires 29 April 2027 [Page 87]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
CW-2.31.5 — Conventional Digital Signature
A signature authenticates a statement or authorization under its
trust assumptions.
CW-2 additionally binds the validator's authorized identity, required
prior actual-effect evidence, successor scope, and mandatory final
enforcement relationship.
Digital signatures themselves are not claimed as new.
CW-2.31.6 — Conventional Hardware Interlock
Hardware interlocks are established techniques.
The potentially distinctive combination is a protected effectuation
interlock whose permitted transition depends upon receipt acceptance
by an authorized cryptographically identified IEV concerning a
specific prior real effect.
CW-2.31.7 — Conventional Distributed Transaction
A distributed transaction protocol may coordinate participating
transactional operations.
CW-2 may govern causally ordered real effects across systems that
cannot participate in one atomic transaction.
CW-2.31.8 — Conventional Canary Testing
A canary deployment may evaluate an initial rollout before broader
release.
The proposed stronger embodiment requires the actual broader
deployment authority to depend upon accepted effect evidence from the
earlier bounded rollout.
CW-2.31.9 — Candidate Objective Technical Problem
An illustrative objective technical problem is:
How to enforce a protected, non-bypassable causal dependency between
a bounded earlier real consequential effect and a subsequent
consequential effect, such that the subsequent effectuation authority
cannot become usable without an accepted prior-effect receipt
authenticated to an authorized identifiable validator and verified at
the actual successor Finality Sink, across integrated, physically
separated, and distributed computing arrangements.
Das Expires 29 April 2027 [Page 88]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
CW-2.31.10 — Candidate Inventive Technical Kernel
A potentially significant technical combination comprises:
An earlier bounded authorized real effect;
9.1.3.51. Source page 113 of the original specification
A qualified observation of that effect;
An IEV having a cryptographically verifiable authorized identity;
A validator-accepted receipt bound to the earlier effect and
permitted successor;
A protected causal condition whose establishment depends upon that
receipt;
And a successor Finality Sink that independently verifies and
enforces the receipt-dependent condition before permitting the actual
next effect.
The strength of a particular patent claim depends upon which of these
features are essential and how they differ from relevant prior art.
The arrangement is not established as novel merely by employing new
terminology for receipt checking, protected keys, staged execution,
or hardware interlocks.
CW-2.32 — ADDITIONAL IMPLEMENTATION VARIANTS
Variant A — Validator Physically Before the Finality Sink: The IEV
authenticates the result to a downstream sink.
Variant B — Validator Physically After the Earlier Sink: The IEV
validates actual-effect evidence from the preceding sink or affected
resource.
Variant C — Validator Integrated with Successor Sink: An internal
protected validation function establishes receipt state.
Variant D — Validator Integrated with Earlier Sink: The preceding
controller hosts the IEV, while the next sink independently verifies
its authenticated receipt.
Variant E — Remote Validator: A separate domain hosts the IEV.
Das Expires 29 April 2027 [Page 89]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Variant F — Multiple Validators: Several authorized identities
contribute to receipt acceptance.
Variant G — Validator Threshold: A configured threshold must be
satisfied.
Variant H — Cryptographic Key Release: The accepted receipt unlocks
missing execution material.
Variant I — Protected State Transition: The accepted receipt advances
a required controller state.
Variant J — Hardware Latch: The accepted receipt enables a bounded
actuator operation.
Variant K — Direct Receipt Capability: The VAER directly carries
scoped successor authority.
Variant L — Split Receipt and Capability: The VAER enables separate
scoped authority.
Variant M — Protected Receipt Reference: The sink retrieves a
protected state reference.
Variant N — Non-Exportable Receipt: Acceptance remains inside
protected hardware or memory.
Variant O — Cross-Device Receipt: The validated receipt travels
between devices.
9.1.3.52. Source page 114 of the original specification
Variant P — Cross-Domain Receipt: The receipt crosses administrative
domains through authenticated interfaces.
Variant Q — Receipt-Dependent Credential Release: Protected
credentials are released or activated only for the permitted
successor.
Variant R — Receipt-Dependent Storage Commit: A later write or
publication requires validated prior-effect evidence.
Variant S — Receipt-Dependent Network Transmission: A later
transmission depends upon the validated receipt.
Variant T — Receipt-Dependent Physical Actuation: A later physical
command requires the accepted receipt.
Das Expires 29 April 2027 [Page 90]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Variant U — Conditional Branching: Distinct verified outcomes enable
distinct preauthorized next effects.
Variant V — Partial-Effect Recovery: A limited actual result enables
only a specifically authorized recovery branch.
Variant W — Identity Rotation: Validator signing credentials may be
updated through protected enrollment.
Variant X — Validator Failover: A replacement validator may be
accepted under current protected trust rules.
Variant Y — Single-Use Receipt: The receipt enables one bounded
successor act.
Variant Z — Bounded Multi-Use Receipt: The receipt permits an
explicitly controlled successor set with protected consumption
limits.
Variant AA — In-Line Validation: A cryptographically identified IEV
validates a pending operation before its first actual effect.
Variant AB — Inter-Phase Validation: An IEV accepts real-effect
evidence to enable the next phase.
Variant AC — Combined Validation: Both modes operate within the same
controlled workflow.
Variant AD — Local Controller-Only Implementation: All causal state
is maintained within one protected device.
Variant AE — Distributed State Implementation: Authoritative
protected continuation state is coordinated across several domains.
Variant AF — No Ledger Implementation: No blockchain or distributed
ledger is used.
Variant AG — Hardware-Only Effect Gate: The next effect is enabled by
protected hardware state after cryptographically authenticated IEV
acceptance.
Variant AH — Software-Mediated Effect Gate: An isolated protected
service enforces the receipt dependency under the defined software
trust model.
Das Expires 29 April 2027 [Page 91]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.1.3.53. Source page 115 of the original specification
Variant AI — Hybrid Effect Gate: Cryptographic identity, protected
state, and hardware final enforcement are combined.
These implementations are non-limiting.
CW-2.33 — RELATIONSHIP TO EMBODIMENTS 1–40
CW-2 provides a common reference mechanism for specialized
embodiments requiring protected validation between consequential
phases.
Embodiment 1 may use actual-effect receipts to advance protected
cross-agent effect reservations.
Embodiment 2 may provide further specific implementation of identity-
authenticated receipt-constituted continuation.
Embodiment 3 may use protected semantic and referent correspondence
to ensure that the actual effect concerns the authorized user-
referenced object.
Embodiment 4 may provide cross-domain actual-consequence witnessing
to strengthen the evidence underlying a receipt.
Other embodiments may introduce additional protected technical
predicates concerning privacy, resource allocation, delegated
authority, device migration, command integrity, recovery, or physical
actuation.
Such additional predicates do not automatically replace the required
receipt-dependent causal condition where that condition is mandatory.
CW-2.34 — SUPPORT FOR POTENTIAL CLAIM LIMITATIONS
The present disclosure provides technical support for considering
claim limitations concerning:
A protected causal sequence of bounded real consequential operations.
An IEV possessing an enrolled cryptographically verifiable identity.
A validator identity uniquely distinguishable within an authenticated
trust namespace.
A protected validator authorization profile.
Das Expires 29 April 2027 [Page 92]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A receipt generated from qualified evidence of an earlier actual
effect.
A validator-accepted receipt authenticated to the authorized IEV.
A successor Finality Sink required to verify the receipt.
Receipt delivery by direct communication, protected state, or
authenticated reference.
An indispensable receipt-dependent next-phase execution condition.
Direct receipt-constituted scoped finality authority.
9.1.3.54. Source page 116 of the original specification
Receipt-dependent key derivation or release.
Receipt-dependent hardware latch activation.
Receipt-dependent protected transaction state.
Protected phase ordering and anti-replay consumption.
Mandatory actual-operation verification at the successor Finality
Sink.
Physically separate validator implementations.
Integrated single-component validator implementations.
Distributed and cross-domain validator implementations.
Multiple validator identities and threshold acceptance.
Validator replacement, rotation, revocation, and protected
enrollment.
Unknown-outcome reconciliation.
Separately authorized recovery.
No requirement for blockchain or ledger storage.
The exact claim structure must be selected with reference to
disclosure support and prior-art examination.
CW-2.35 — INDUSTRIAL APPLICABILITY AND PHOSITA IMPLEMENTATION
Das Expires 29 April 2027 [Page 93]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The disclosed causal receipt-gated architecture may be industrially
implemented wherever a later consequential operation must depend upon
accepted evidence of an earlier real effect.
In cloud infrastructure, a bounded deployment may generate the
receipt required for a broader deployment.
In autonomous device management, a verified initial configuration
change may enable subsequent activation.
In telecommunications, accepted evidence of a protected limited
network-state transition may become necessary for further control-
plane changes.
In financial systems, a qualified prior transaction-state receipt may
enable a separately authorized subsequent accounting or payment-
related consequence.
In industrial robotics, actual position evidence accepted by an
identified IEV may activate the next bounded movement.
In protected storage, a verified initial commit may create the
necessary condition for publication or external export.
9.1.3.55. Source page 117 of the original specification
In secure communications, a bounded recipient-side actual-effect
receipt may enable subsequent protected data release.
In enterprise AI workflows, an authenticated earlier operation result
may provide the causal authority required for a dependent external
act.
A PHOSITA may implement the architecture using authenticated
identities, protected state machines, cryptographic keys, controlled
effectuation interfaces, transactional state, hardware registers,
protected message delivery, or equivalent techniques.
The technical implementation must identify the authoritative
validator identity, actual-effect evidence source, receipt acceptance
rule, successor enabling mechanism, and final enforcement boundary.
The system may be constructed entirely within one protected component
or across multiple connected protected components.
The essential technical relationship is the same.
CW-2.36 — FINAL NON-LIMITING TECHNICAL SUMMARY
Das Expires 29 April 2027 [Page 94]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Common Workflow CW-2 discloses a protected causal-ordered
effectuation system in which the valid ability to perform a later
consequential operation depends upon independently accepted evidence
from an earlier actual consequential phase.
An authorized bounded first effect is performed through a designated
Finality Sink.
A qualified source obtains evidence concerning the actual result.
An Interim Effectuation Validator having a cryptographically
verifiable identity independently evaluates that evidence.
Successful acceptance is authenticated to the validator identity and
results in a Validator-Accepted Effect Receipt or equivalent
protected receipt state.
The accepted receipt is supplied to, retrieved by, or represented
within protected state verified by the designated successor Finality
Sink.
The successor sink authenticates the validator identity, prior-effect
evidence relationship, phase lineage, current authority, authorized
successor scope, and protected consumption state.
The required accepted receipt directly constitutes, enables,
releases, activates, or supplies the indispensable causal condition
for subsequent effectuation.
The next consequential phase cannot validly occur through the
protected effectuation architecture before that receipt-dependent
condition exists.
The architecture may be implemented cryptographically through keys,
signatures, authentication shares, or protected capabilities.
It may implement actual effectuation gating through non-cryptographic
protected state, hardware latches, command registers, transactional
control, or secure controller transitions while retaining
cryptographic validator identity authentication.
9.1.3.56. Source page 118 of the original specification
The validator may be physically added as a separate protected device.
It may reside in an operating-system security component.
It may operate within protected firmware.
Das Expires 29 April 2027 [Page 95]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
It may be integrated into the Finality Sink.
It may be hosted remotely.
It may be implemented through multiple distributed validators.
All functions may reside within one protected processor or
controller.
The number and physical arrangement of components do not define the
essential causal security property.
The defining requirement is that the accepted evidence from an
authorized cryptographically identifiable validator is a necessary
technical condition for the next protected consequential effect.
A generic software success flag is not sufficient.
An ordinary agent self-report is not sufficient.
A raw unvalidated receipt is not sufficient.
A copied validator identity is not sufficient.
An unrelated valid receipt is not sufficient.
A validator-authenticated receipt without the required successor
operation binding is not sufficient.
A correct receipt cannot authorize an effect outside its protected
scope.
Where the mandatory receipt is absent, invalid, stale, mismatched,
unsupported, or unconsumed state cannot be established, the dependent
effect remains withheld or enters the applicable protected recovery
procedure.
The system does not require blockchain technology or a persistent
distributed receipt ledger.
The receipt's essential function is operational and causal, not
merely historical.
Das Expires 29 April 2027 [Page 96]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The principal proposed technical contribution of CW-2 is the creation
of an enforceable, validator-identity-authenticated causal
relationship in which an earlier bounded real effect produces
qualified evidence, an authorized IEV accepts that evidence, and the
resulting accepted receipt constitutes the indispensable enabling
factor for the next consequential effect at its actual Finality Sink.
This common technical relationship may be implemented through
integrated, physically separated, hardware-based, software-protected,
or distributed architectures, provided the claimed non-bypassable
causal enforcement property is actually achieved under the defined
trust and effectuation boundaries.
9.1.3.57. Source page 119 of the original specification
The novelty and inventive step of particular claim combinations
remain subject to the relevant prior-art examination, and any
asserted filing priority remains limited to subject matter supported
by the relevant application as filed.
END OF COMMON WORKFLOW CW-2 — COMPLETE DISCLOSURE.
COMMON WORKFLOW CW-3
OPTIONAL PROTECTED AUTONOMOUS-AGENT SCOPE-DEVIATION DETECTION,
INDEPENDENT SECURITY-SIGNAL CORRELATION, RISK-ADAPTIVE SUSPENSION,
AUTOMATED REVALIDATION, SECURE HUMAN REAUTHORIZATION, AND FINALITY-
SINK-BOUND EXECUTION CONTROL
CW-3.0 — GENERAL DESCRIPTION AND TECHNICAL PURPOSE
The present disclosure provides a Common Workflow, designated CW-3,
for detecting, evaluating, containing, and resolving potential
deviations by autonomous computational entities from an originally
authorized task, operation, purpose, resource scope, destination,
delegation boundary, or other protected authority condition.
The workflow applies to autonomous artificial-intelligence agents,
on-device assistants, operating-system services, application agents,
distributed orchestration frameworks, remote computational agents,
delegated tools, robotic controllers, enterprise automation systems,
and other entities capable of proposing or producing consequential
effects.
In one non-limiting implementation, an autonomous agent receives
authority to perform a task without requiring repeated human
confirmation for every permitted operation.
Das Expires 29 April 2027 [Page 97]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The agent may thereafter perform authorized computation, planning,
tool use, and consequential operations according to the applicable
execution-finality architecture.
During operation, one or more independently operated monitoring,
validation, or security components observe relevant execution
behavior, requested operations, application-state changes,
information flows, and protected effectuation events.
Where an observed operation appears inconsistent with the originally
authorized scope, a protected deviation-detection mechanism generates
an authenticated deviation indication.
The system then determines whether the indication represents:
1. An operation that remains within the original authorization;
2. A suspected deviation that can be resolved through independent
automated verification;
3. A proposed change that may be permitted following fresh user
authorization;
4. An operation requiring authorization from an additional
principal;
5. A mandatory security violation that must remain denied;
9.2. Common Workflow Implementation Clarification: Optional Causal
Controls and Correct Relationship to CW-1 and CW-3
Original global source page range: 179-196 inclusive, original
uploaded PDF segment: TECHNICAL SPECIFICATION -1-554.pdf. Primary in
this part: False. Page-extract fidelity limitations and independent
filing-priority analysis are stated in the source note.
9.2.1. Architecture and Protected Trust-Relationship Diagram
Das Expires 29 April 2027 [Page 98]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
[CW-1 common protected effectuation]
|
[Optional causal dependency required?]
|YES |NO
[CW-2 IEV] [Ordinary CW-1]
|
[Qualified prior-effect PER]
|
[VAER / CCC]
|
[New CA + protected FS]
Figure 16: Common Workflow Implementation Clarification: Optional
Causal Controls and Correct Relationship to CW-1 and CW-3 —
architecture and protected dependencies
9.2.2. Operational Decision Flowchart and Refusal Conditions
[Select required workflow conditions]
|
<Mandatory predecessor dependency?>--NO-->[CW-1 only]
|YES
[Observe real effect + qualify evidence]
|
<Accepted VAER current?>--NO-->[WITHHOLD]
|YES
[Check successor source and scope]
|
<Finality Sink actual operation valid?>--NO-->[REFUSE]
|YES
[Consume and effect]
Figure 17: Common Workflow Implementation Clarification: Optional
Causal Controls and Correct Relationship to CW-1 and CW-3 —
decision flowchart
9.2.3. Original Source Page-Indexed Technical Content
9.2.3.1. Source page 179 of the original specification
These workflows may be implemented independently where technically
sufficient.
They may also be combined.
A combination does not automatically make optional mechanisms of one
workflow mandatory in another.
Das Expires 29 April 2027 [Page 99]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
CW-IMP-1.0.2 — Preservation of the Original CW-1 Disclosure
CW-1 remains the common foundational architecture.
Its defining relationship comprises:
• Candidate Act construction.
• Maintenance of Non-Effective State.
• Protected Enforcement Domain verification.
• Operation-specific protected evidence.
• Scoped finality authority.
• Independent actual-operation reconstruction.
• Finality Sink verification.
• Protected effectuation-state consumption.
• Controlled consequential release.
The implementation examples below explain how those relationships may
be realized using existing computing primitives.
CW-IMP-1.0.3 — Preservation of the Original CW-2 Disclosure
CW-2 retains its three disclosed operational modes.
Mode A: An authenticated Interim Effectuation Validator performs
required in-line pre-effect validation of a prepared actual
operation.
Mode B: An earlier bounded actual effect produces qualified
observation evidence, an authorized cryptographically identifiable
IEV accepts the evidence, and the accepted receipt is a necessary
enabling factor for the next consequential phase.
Mode C: A combined arrangement requires both applicable prior-effect
receipt acceptance and current in-line validation of the successor
operation.
The principal inter-phase implementation is Mode B.
Das Expires 29 April 2027 [Page 100]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The prior real-effect receipt must not be reduced to a mere
scheduler-completion flag, audit log, or optional informational
record.
CW-IMP-1.0.4 — Preservation of the Original CW-3 Disclosure
9.2.3.2. Source page 180 of the original specification
CW-3 retains the Original Authorized Scope Envelope, Protected Scope-
State Accumulator, Scope-Deviation Observation, Scope-Deviation
Evidence Bundle, Protected Deviation Latch, Independent Scope
Adjudicator, Automated Scope Revalidation, Protected Scope Delta,
Trusted Approval Presentation Record, Protected Reauthorization
Decision, Scope-Delta Authorization, Protected Scope-Version Chain,
Non-Overridable Security Constraint, and Scope-Deviation Resolution
Record.
It further retains the distinction between:
An operation already within valid original authority;
An apparent deviation that can be conclusively resolved through
protected automated verification;
A genuinely new consequential scope requiring appropriate additional
authorization;
And a non-overridable technical security failure.
A new human approval does not override a mandatory failed security
predicate.
CW-IMP-1.0.5 — Fundamental Technical Relationship
The common principle is:
Computation is not authority to act.
More specifically:
An authenticated computational requester does not necessarily have
the right to produce every resource effect it can technically
request.
An authentic historical receipt does not necessarily constitute
current unrestricted permission.
Das Expires 29 April 2027 [Page 101]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A valid human approval for a particular change does not independently
permit an unrelated or technically prohibited operation.
The actual consequential operation remains subject to independent
protected effectuation-boundary control.
CW-IMP-1.0.6 — Implementation-Neutral Technical Characteristics
A selected implementation may use:
A protected software service;
A transactional database;
An operating-system security component;
A hardware security module;
A secure element;
A protected microcontroller;
A trusted execution environment;
9.2.3.3. Source page 181 of the original specification
A cryptographically authenticated remote service;
A resource-specific API gateway;
A controlled database commit path;
A protected device command interface;
Or a combination of these mechanisms.
The particular choice of physical or software substrate does not
independently define the claimed technical contribution.
The relevant distinction lies in the protected ordering, dependency,
operation correspondence, and mandatory enforcement relationships
established by the selected implementation.
PART I — PHOSITA IMPLEMENTATION OF CW-1
CW-IMP-1.1 — IMPLEMENTATION OBJECTIVE FOR CW-1
Das Expires 29 April 2027 [Page 102]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The technical objective is to prevent an autonomous computational
requester from directly producing a covered consequential effect
unless a protected authority controller has established operation-
specific authorization and the actual Finality Sink has verified that
authorization against the operation really presented for
effectuation.
A PHOSITA may build a minimum implementation using three separately
controlled logical components:
Component A — Autonomous Requester: Generates proposed actions but
lacks direct authority over the protected resource.
Component B — Protected Enforcement Domain: Maintains current
permission, evidence, policy, and finality-authority state.
Component C — Finality Sink: Controls the actual resource mutation,
data release, payment instruction, or device command.
The critical implementation requirement is that Component A cannot
avoid Components B and C when causing the covered consequence.
The components may reside on separate machines or within one suitably
protected machine.
CW-IMP-1.2 — EXISTING TECHNOLOGY: AUTHORIZATION SERVER
A PHOSITA may use an established authorization service to identify
the original principal and permitted operation scope.
Possible mechanisms include:
OAuth-compatible authorization;
Structured authorization-detail records;
9.2.3.4. Source page 182 of the original specification
Enterprise identity and access-management services;
Role-based access control;
Attribute-based access control;
Resource-specific access-control lists;
Authenticated policy engines;
Das Expires 29 April 2027 [Page 103]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
And protected application permission registries.
CW-IMP-1.2.1 — Technical Use
The authorization mechanism supplies evidence concerning the original
permission.
For example, the originating principal may authorize an automated
system to upload Document X to Recipient Y.
The authorization evidence may specify:
AUTHORIZATION_EVIDENCE = { principal_id, permitted_operation:
"DOCUMENT_UPLOAD", permitted_document: "DOCUMENT_X",
permitted_recipient: "RECIPIENT_Y", permitted_effect_count: 1,
permission_generation: 17, revocation_state: "ACTIVE" } The protected
architecture does not interpret a general permission to invoke the
upload service as authority to upload arbitrary documents to
arbitrary recipients.
CW-IMP-1.2.2 — Candidate Technical Interaction
The source authorization is converted into a protected constraint on
the actual resource operation.
The relationship may be expressed as:
PERMISSION_EVIDENCE | v PROTECTED EFFECT-SCOPE RESOLUTION | v
CANDIDATE ACT BINDING | v SEPARATE FINALITY ELIGIBILITY | v ACTUAL
RESOURCE-SIDE VERIFICATION The protected effect-scope resolution must
preserve the original authorization boundaries.
9.2.3.5. Source page 183 of the original specification
It must not expand permission merely because the requester's
application interface accepts broader parameters.
CW-IMP-1.3 — EXISTING TECHNOLOGY: CANDIDATE ACT CONSTRUCTION
A PHOSITA may use an existing structured-data parser and typed
application schema to construct a Candidate Act.
A representative structure comprises:
Das Expires 29 April 2027 [Page 104]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
CANDIDATE_ACT = { ca_id, original_principal, requesting_agent,
original_grant_id, operation_class, actual_resource_identifier,
destination_identifier, operation_parameters,
permitted_effect_envelope, current_authority_generation,
designated_finality_sink, schema_version, protected_context_reference
} The fields may be encoded through:
Typed application structures;
Deterministic CBOR;
Canonical JSON;
Protocol Buffers with an expressly specified deterministic identity
representation;
Or another suitably defined encoding.
CW-IMP-1.3.1 — Why Canonicalization Is Technically Important
Two components may interpret the same serialized operation
differently.
Examples include:
Different Unicode representations of resource names;
Different numerical representations of payment amounts;
Ambiguous path normalization;
Duplicate structured-data keys;
Different query-parameter handling;
Resource aliases;
9.2.3.6. Source page 184 of the original specification
And different operation-schema versions.
A cryptographic hash of ambiguous input does not establish a correct
shared understanding of the operation.
Accordingly, a principal implementation may define one protected
canonical effect representation.
CW-IMP-1.3.2 — Payment Amount Example
Das Expires 29 April 2027 [Page 105]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Payment values may be represented using exact integer minor units and
an explicit currency identifier.
An operation authorizing 100 units of one currency must not become
authorization for another currency merely because the serialized
number is identical.
The authorized descriptor may also identify the payment recipient,
source account, and resource-generation conditions.
CW-IMP-1.3.3 — Candidate Technical Distinction
The relevant technical feature is not the use of JSON, CBOR, or
hashing alone.
It is that the protected canonical operation descriptor becomes a
mandatory comparison object at the actual Finality Sink.
CW-IMP-1.4 — EXISTING TECHNOLOGY: NON-EFFECTIVE HOLD
A PHOSITA may implement the Non-Effective State using an existing
resource-control primitive.
Possible examples include:
A request queue that cannot dispatch externally without protected
release;
An uncommitted database mutation;
A withheld application-service invocation;
A credential broker that does not expose the required secret;
A storage command held behind a protected gate;
A network egress rule preventing direct transmission;
A device command buffer whose enablement is controlled by protected
hardware;
Or a resource transaction held pending finality authorization.
CW-IMP-1.4.1 — Essential Requirement
The hold must actually prevent the covered consequence.
Merely recording an intention not to execute is insufficient.
Das Expires 29 April 2027 [Page 106]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.2.3.7. Source page 185 of the original specification
CW-IMP-1.4.2 — Database Variation
A protected service may maintain a pending mutation descriptor
outside the live resource transaction.
Before actual commit, the database resource controller reconstructs
and verifies the mutation.
Where an uncommitted transaction is used as the hold, the
implementation must account for transaction lifetime, locks, resource
changes, and timeouts.
CW-IMP-1.4.3 — Network Variation
A controlled outbound gateway may hold an HTTP request until
validation.
The agent must lack another permitted uncontrolled route to perform
the covered operation.
CW-IMP-1.4.4 — Hardware Variation
A device may hold an actuation command in a protected queue.
The final hardware command interface refuses activation until the
required authority state is valid.
CW-IMP-1.4.5 — Candidate Technical Interaction
The Non-Effective State is connected to protected authority formation
and actual resource-side release.
The distinction is between an advisory approval procedure and an
enforceable transition that cannot be bypassed within the claimed
effectuation coverage domain.
CW-IMP-1.5 — EXISTING TECHNOLOGY: PROTECTED ENFORCEMENT DOMAIN
A PHOSITA may use an existing isolated service or suitable protected
computing environment to implement the PED.
The PED may maintain:
Current source-authority state;
Revocation generations;
Das Expires 29 April 2027 [Page 107]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Evidence commitments;
Required verification-module results;
Operation-specific finality eligibility;
Protected consumption references;
And current effectuation-path state.
The PED may be implemented as:
9.2.3.8. Source page 186 of the original specification
A privileged operating-system service with controlled IPC;
A hardened remote authorization service;
A suitably isolated virtual machine;
A hardware-backed trusted execution component;
Or a protected microcontroller.
CW-IMP-1.5.1 — Software Trust Model
A separate software service can prevent an ordinary agent process
from modifying protected state when operating-system isolation
remains trustworthy.
It does not automatically resist complete compromise of the same
privileged kernel.
CW-IMP-1.5.2 — Hardware Trust Model
Protected hardware may provide stronger isolation of selected keys or
state.
However, hardware protection does not automatically establish correct
operation semantics or actual resource authorization.
CW-IMP-1.5.3 — Candidate Technical Relationship
The PED establishes operation-specific authority while the Finality
Sink retains responsibility for independently verifying the actual
pending consequence.
Das Expires 29 April 2027 [Page 108]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A protected authorization response is not merely a reusable
credential giving the agent unrestricted access.
CW-IMP-1.6 — EXISTING TECHNOLOGY: PROTECTED EVIDENCE
A PHOSITA may use:
Message authentication codes;
Digital signatures;
Authenticated protected service responses;
Protected transaction records;
Resource-version evidence;
Secure device observations;
And protected application-state interfaces.
A representative validation record may comprise:
PROTECTED_VALIDATION_EVIDENCE = {
9.2.3.9. Source page 187 of the original specification
candidate_act_digest, source_grant_reference,
evaluated_effect_envelope, current_resource_reference,
required_module_set, actual_module_results, authority_generation,
policy_generation, validation_instance_identity, evidence_commitment
} The record should identify what was actually verified.
A signature authenticates the signed data under the applicable key
assumptions.
It does not independently prove the correctness of untrusted data
signed by a compromised or insufficiently qualified source.
CW-IMP-1.7 — EXISTING TECHNOLOGY: MANDATORY MODULE SELECTION
A PHOSITA may use a policy engine and typed verification-module
registry.
The applicable module set may be derived from:
The actual operation class;
Das Expires 29 April 2027 [Page 109]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The protected resource class;
The source-authority envelope;
The current policy generation;
And the current enforcement-path requirements.
The requesting agent may propose an operation classification.
However, the protected controller independently determines the
mandatory verification modules.
For example:
REQUIRED_MODULES("FILE_EXPORT") = { RESOURCE_IDENTITY,
DESTINATION_PERMISSION, CURRENT_REVOCATION, EFFECTUATION_COVERAGE } A
protected privacy policy may additionally require cumulative
information-exposure verification.
A financial transfer may require a resource-version or spending-limit
module.
A hardware actuation may require current device ownership and
physical safety conditions.
CW-IMP-1.7.1 — Technical Interaction
9.2.3.10. Source page 188 of the original specification
A mandatory verification predicate cannot be bypassed merely because
the agent omits it from a request.
An authenticated result from a different verification module does not
replace the required predicate.
CW-IMP-1.8 — EXISTING TECHNOLOGY: NON-BEARER FINALITY AUTHORITY
A PHOSITA may implement operation-specific non-bearer finality
authority using a protected database row, server-side capability
registry, hardware-controlled authorization slot, or suitable secure
command controller.
A representative protected authority record may comprise:
FINALITY_AUTHORITY = { authority_id, candidate_act_digest,
designated_finality_sink, authorized_actual_effect_digest,
source_authority_generation, required_validation_commitment,
Das Expires 29 April 2027 [Page 110]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
policy_generation, resource_generation, permitted_use_count: 1,
consumed_use_count: 0, status: "PREPARED" } The agent may receive a
reference to the protected authority.
The reference does not itself provide sufficient authority to release
the real resource operation.
The designated Finality Sink must retrieve or verify the
corresponding current protected state.
CW-IMP-1.8.1 — Why an Ordinary Token Is Not Necessarily Equivalent
A conventional API credential may be reusable across several resource
requests.
The selected finality authority is bound to a specified actual
operation or bounded effect class.
Its valid exercise depends upon the current designated sink, relevant
source authorization, and protected consumption conditions.
CW-IMP-1.8.2 — Alternative Cryptographic Realization
A signed operation-specific authorization may be used.
However, a signature alone does not establish single-use consumption.
The sink must also maintain authoritative replay or usage state when
that property is required.
CW-IMP-1.8.3 — Candidate Technical Interaction
9.2.3.11. Source page 189 of the original specification
Protected finality authority is constituted from accepted validation
evidence but is not identical to the original permission or
historical validation record.
CW-IMP-1.9 — EXISTING TECHNOLOGY: ACTUAL FINALITY SINK
The critical PHOSITA implementation step is the construction of a
resource-side gate that controls the actual consequential primitive.
A selected Finality Sink may be:
A database commit service;
An authenticated remote API resource server;
Das Expires 29 April 2027 [Page 111]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A file-system mutation controller;
A credential broker;
A network data-release gateway;
A payment dispatcher;
A hardware command interface;
Or another effect-capable resource boundary.
CW-IMP-1.9.1 — Independent Operation Reconstruction
The sink obtains the actual pending operation from its controlled
resource interface.
For example, a database sink may inspect:
The target record;
The mutation type;
The actual new values;
The transaction identifier;
The expected resource version;
And the effective principal.
A network sink may inspect the actual destination, method, path,
body, and application-level operation fields visible within its
qualified enforcement boundary.
A hardware sink may inspect the actual command buffer and target
device identity.
CW-IMP-1.9.2 — Actual Equality Predicate
The protected sink verifies that the actual operation lies within the
authorized effect envelope.
A representative relation is:
Das Expires 29 April 2027 [Page 112]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.2.3.12. Source page 190 of the original specification
[ \operatorname{ActualEffect}(O) \in
\operatorname{AuthorizedEnvelope}(CA) ]
The relation may comprise exact equality, bounded membership, or
another expressly defined technical correspondence predicate.
CW-IMP-1.9.3 — Current Authority Predicate
The sink verifies the applicable current source-authority state.
CW-IMP-1.9.4 — Current Resource Predicate
The sink verifies resource version, ownership, reservation, or other
mandatory technical conditions.
CW-IMP-1.9.5 — Consumption Predicate
The sink verifies that the authority has not already been exhausted
or invalidated.
CW-IMP-1.9.6 — Protected Release
Only after the required checks pass does the sink perform the
protected release transition.
CW-IMP-1.10 — DATABASE IMPLEMENTATION WITH TRANSACTIONAL STATE
A PHOSITA may implement a strong single-resource variant using a
transactional database.
The following conceptual tables may be maintained:
SOURCE_GRANTS grant_id principal_id resource_scope operation_scope
authority_generation revocation_state
CANDIDATE_ACTS ca_id grant_id canonical_effect_digest designated_sink
status
VALIDATION_EVIDENCE evidence_id ca_id verified_effect_digest
policy_generation authority_generation
9.2.3.13. Source page 191 of the original specification
FINALITY_AUTHORITY finality_id ca_id effect_digest designated_sink
remaining_uses status
Das Expires 29 April 2027 [Page 113]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
FINALITY_ATTEMPTS logical_operation_id finality_id operation_digest
dispatch_state outcome_state CW-IMP-1.10.1 — Strong Local Transaction
Where the actual resource mutation and the protected finality state
are within the same supported transaction scope, the sink may:
Begin a transaction;
Read current source authority;
Read the current resource;
Reconstruct the pending mutation;
Verify the protected effect descriptor;
Verify current finality eligibility;
Conditionally consume the permitted authority;
Perform the authorized resource mutation;
And commit both state transitions in one transaction.
The transaction must provide suitable isolation or conditional-update
semantics for the claimed concurrency guarantee.
CW-IMP-1.10.2 — External Effect Boundary
Where the final effect is a remote payment, network transmission, or
physical command, the local database transaction cannot automatically
make the remote effect atomic with local consumption.
The implementation may instead commit a durable effect attempt and
use controlled dispatch, receiver-side operation identity, and
qualified outcome reconciliation.
CW-IMP-1.10.3 — Technical Effect
9.2.3.14. Source page 192 of the original specification
In the supported local-transaction variant, protected finality
consumption and the actual resource mutation are coherently enforced.
In the remote variant, the implementation avoids pretending that
locally consumed authorization proves remote completion.
CW-IMP-1.11 — REFERENCE ALGORITHM: CW-1
Das Expires 29 April 2027 [Page 114]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
FUNCTION CW1_PROTECTED_EFFECTUATION( proposed_operation,
requester_identity, designated_sink ):
ca = BUILD_TYPED_CANDIDATE_ACT( proposed_operation,
requester_identity )
REQUIRE VERIFY_CANDIDATE_ACT(ca)
REQUIRE ESTABLISH_ACTUAL_NON_EFFECTIVE_HOLD( ca, designated_sink )
source_authority = PED.LOAD_CURRENT_SOURCE_AUTHORITY(ca)
REQUIRE VERIFY_AUTHORITY_SCOPE( source_authority, ca )
required_modules = PED.RESOLVE_MANDATORY_MODULE_SET(ca)
evidence = PED.COLLECT_QUALIFIED_EVIDENCE(ca)
FOR EACH module IN required_modules: REQUIRE module.VERIFY( ca,
evidence, CURRENT_PROTECTED_STATE() )
REQUIRE VERIFY_EFFECTUATION_COVERAGE( ca, designated_sink )
9.2.3.15. Source page 193 of the original specification
validation_commitment = PED.COMMIT_VALIDATION_EVIDENCE( ca, evidence
)
finality = PED.PREPARE_NON_BEARER_FINALITY({ candidate_act: ca,
validation: validation_commitment, designated_sink: designated_sink,
current_authority: source_authority, permitted_uses: 1 })
actual = designated_sink.RECONSTRUCT_ACTUAL_OPERATION()
REQUIRE designated_sink.VERIFY( actual, ca, finality,
CURRENT_SOURCE_AUTHORITY(), CURRENT_RESOURCE_STATE(),
CURRENT_CONSUMPTION_STATE() )
committed = designated_sink.COMMIT_PROTECTED_FINALITY( actual,
finality )
IF committed != SUCCESS: RETURN DENY
result = designated_sink.RELEASE_ACTUAL_EFFECT(actual)
RECORD_QUALIFIED_ATTEMPT_STATE(result)
Das Expires 29 April 2027 [Page 115]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
RETURN CLASSIFY_SUPPORTED_OUTCOME(result) Where the actual effect is
external to the protected consumption transaction, the implementation
must use an appropriate dispatch, receiver-side, and outcome-
reconciliation arrangement rather than infer that remote completion
occurred atomically.
CW-IMP-1.12 — CW-1 IMPLEMENTATION VARIATIONS
Variation A — Authorization Server Plus Protected API Gateway
9.2.3.16. Source page 194 of the original specification
A conventional authorization server establishes principal permission.
A protected controller creates operation-specific finality state.
A receiving API gateway reconstructs the actual outgoing request and
verifies finality before contacting the protected resource.
Variation B — Database-Local Finality
A database transaction checks current authority and the actual
pending mutation while consuming finality state.
Variation C — Credential-Broker Finality
The agent never receives the reusable credential.
A broker exercises the credential only after verifying the actual
resource operation and protected authority.
Variation D — Operating-System Resource Gate
A suitably privileged protected service mediates covered file,
process, or device effects.
A monitoring-only hook cannot substitute for mandatory blocking
enforcement.
Variation E — Hardware Command Finality
A protected command register or device controller refuses unqualified
actual commands.
Variation F — Cross-Domain Finality
The PED and receiving sink reside in separate administrative domains.
Das Expires 29 April 2027 [Page 116]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Authenticated evidence is transported, but the destination retains
actual operation-side authority verification.
Variation G — Canonical Semantic Binding
The implementation verifies normalized operation parameters and
current resource identity rather than relying upon the agent's
unverified description.
Variation H — Dynamic Coverage Revalidation
A material change in tool, service, driver, network path, or resource
controller invalidates relevant finality eligibility until the
corresponding mandatory enforcement coverage is reestablished.
CW-IMP-1.13 — CW-1 COMPARATIVE TECHNICAL TESTS
Test CW1-A — Active Credential, Different Operation
Provide the agent with a valid resource credential and permission for
one effect.
Attempt a different target or operation.
9.2.3.17. Source page 195 of the original specification
Expected result: the actual sink refuses the unmatched effect.
Test CW1-B — Signed Approval Without Current Authority
Prepare valid earlier validation evidence.
Revoke the originating permission.
Expected result: the sink rejects the operation under current
protected authority state.
Test CW1-C — Replayed Finality Reference
Execute one permitted protected mutation.
Reuse the finality reference.
Expected result: the second attempt cannot validly consume already
exhausted authority.
Test CW1-D — Modified Actual Request
Das Expires 29 April 2027 [Page 117]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Authorize one canonical operation.
Change the operation after protected preparation.
Expected result: independent actual-operation reconstruction detects
the material mismatch.
Test CW1-E — Missing Mandatory Module
Omit a required technical verification module from the agent's
request.
Expected result: the protected module registry still requires the
missing predicate.
Test CW1-F — Alternate Effectuation Path
Attempt the same resource effect through another API.
Expected result: within the asserted coverage domain, the alternate
path remains blocked or subject to equivalent finality enforcement.
Test CW1-G — External Outcome Unknown
Release an authorized external command and suppress its
acknowledgement.
Expected result: the protected system records uncertainty instead of
treating the command as definitely unperformed.
CW-IMP-1.13.1 — Proposed Comparative Ablation
A prototype may be configured with and without the actual Finality-
Sink reconstruction requirement.
The comparison may examine whether upstream authorization alone
accepts a request whose final resource target or material parameters
have changed.
9.2.3.18. Source page 196 of the original specification
The resulting evidence may support a technically specific argument
about the contribution of operation-specific sink correspondence.
No experimental outcome is asserted here as already established.
CW-IMP-1.14 — CW-1 CANDIDATE TECHNICAL CONTRIBUTION
Das Expires 29 April 2027 [Page 118]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The proposed inventive relationship is not merely the presence of:
A policy engine;
Cryptographic signatures;
A transactional database;
Or a gateway.
The stronger candidate combination requires:
An actual enforceable Non-Effective State, protected operation-
specific evidence, a distinct scoped finality enablement, and
mandatory independent verification of the actual pending operation
against current authority and protected consumption state at the
resource's effectuation boundary.
This relationship may be described as an authority-to-effect
continuity mechanism.
The protected decision must remain applicable to the same actual
consequential operation through final release.
A narrower fallback may additionally require authenticated
effectuation-path coverage and invalidation following material path
changes.
PART II — PHOSITA IMPLEMENTATION OF CW-2
CW-IMP-2.1 — IMPLEMENTATION OBJECTIVE FOR CW-2
CW-2 concerns protected causal ordering among consequential
operations.
In the principal Mode B implementation, the technical goal is not
simply to schedule Operation B after Operation A.
The goal is to make the required authority or execution-enabling
condition for Operation B depend upon acceptance of qualified
evidence that the specified real effect of Operation A occurred.
A PHOSITA may implement this arrangement using:
Two actual Finality Sinks;
An authenticated actual-effect observation source;
Das Expires 29 April 2027 [Page 119]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.3. Embodiment 2: Identity-Bound Interim Effectuation Validator and
Non-Bypassable Receipt-Constituted Authority
Original global source page range: 295-363 inclusive, original
uploaded PDF segment: TECHNICAL SPECIFICATION -1-554.pdf. Primary in
this part: True. Page-extract fidelity limitations and independent
filing-priority analysis are stated in the source note.
9.3.1. Architecture and Protected Trust-Relationship Diagram
[Bounded predecessor grant]
|
[Protected predecessor effect]
|
[Authenticated consequence witness]
|
[Protected PER + validator identity]
|
[Independent IEV: compare actual effect]
|
[VAER -> technical CCC condition]
/ | \
[Key share] [Latch] [Scoped capability]
\ | /
[Successor actual-operation Finality Sink]
|
[Protected consumption + successor effect]
Figure 18: Embodiment 2: Identity-Bound Interim Effectuation
Validator and Non- Bypassable Receipt-Constituted Authority —
architecture and protected dependencies
9.3.2. Operational Decision Flowchart and Refusal Conditions
Das Expires 29 April 2027 [Page 120]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
[Observe predecessor REAL effect]
|
<Authenticated witness/proof?>--NO-->[WITHHOLD]
|YES
<IEV validates effect predicate?>--NO-->[WITHHOLD]
|YES
[Accept VAER under protected identity]
|
[Constitute necessary continuation condition]
|
<Can agent bypass CCC?>--YES-->[UNSAFE DESIGN]
|NO
<Successor actual effect matches authority?>--NO-->[REFUSE]
|YES
[Atomic consume + release]
Figure 19: Embodiment 2: Identity-Bound Interim Effectuation
Validator and Non- Bypassable Receipt-Constituted Authority —
decision flowchart
9.3.3. Original Source Page-Indexed Technical Content
9.3.3.1. Source page 295 of the original specification
Protected arbitration state is subsequently advanced or retained
according to sufficiently trustworthy evidence of the actual outcome.
A stale reservation, incompatible operation, unverified alternate
resource, replayed authority, or unresolved mandatory conflict causes
withholding of the affected operation.
The architecture may operate across applications, devices, services,
and protected administrative domains where the necessary
authenticated resource identification, protected coordination, and
enforcement interfaces are implemented.
An optional Interim Effectuation Validator may provide additional
phase-specific validation but is not mandatory for ordinary protected
conflict arbitration.
The embodiment thereby proposes a technical arrangement separating
individual operation authorization from protected authorization of an
operation's permissible relationship to other consequential
operations.
End of Embodiment 1.
EMBODIMENT 2
Das Expires 29 April 2027 [Page 121]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
IDENTITY-BOUND INDEPENDENT INTERIM EFFECTUATION VALIDATION WITH
CAUSALLY ORDERED REAL-EFFECT RECEIPTS, NON-BYPASSABLE RECEIPT-
CONSTITUTED CONTINUATION AUTHORITY, AND CRYPTOGRAPHIC OR NON-
CRYPTOGRAPHIC FINALITY-SINK ENFORCEMENT
2.0 — COMPLETE TECHNICAL TITLE
Systems and Methods for Protected Causally Ordered Autonomous
Effectuation Using Cryptographically Identifiable Interim
Effectuation Validators, Authenticated Actual-Effect Receipts,
Receipt-Dependent Execution Enablement, Physically Integrated or
Distributed Validation Components, Sink-Bound Continuation Authority,
and Fail-Closed Consequence-State Recovery
2.0.1 — General Characterization
The present embodiment discloses systems, methods, apparatus,
protected computing components, hardware and software enforcement
arrangements, authenticated validation identities, protected evidence
structures, cryptographic protocols, non-cryptographic state-
transition mechanisms, and machine-verifiable causal execution
procedures for governing one or more consequential operations
performed by autonomous computational entities.
The disclosed architecture establishes a protected relationship
between an earlier bounded real effect and a subsequent consequential
operation.
In a principal implementation, an earlier authorized consequential
phase produces an actual effect within a specified resource, device,
application, system, network, transaction, storage, or physical
domain.
A qualified observation component obtains evidence concerning that
effect.
9.3.3.2. Source page 296 of the original specification
An Interim Effectuation Validator, hereinafter IEV, validates the
evidence according to an applicable protected authorization,
operation identity, expected outcome, observed result, phase
relationship, and current protected state.
The IEV possesses a cryptographically verifiable validator identity
established within an applicable trusted authorization domain.
Das Expires 29 April 2027 [Page 122]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The IEV generates, authenticates, countersigns, activates, commits,
or otherwise establishes a validated effect receipt whose
authenticated provenance identifies the validator responsible for
accepting the prior-effect evidence.
The validated receipt is conveyed to, made retrievable by, or
represented within protected state accessible to the designated
successor Finality Sink.
The successor Finality Sink independently verifies the validator
identity, receipt authenticity, receipt authorization, prior-phase
correspondence, successor operation binding, and applicable current
protected state.
The validated receipt constitutes a necessary enabling factor for the
next consequential phase.
The subsequent effect cannot become validly effective through the
controlled effectuation architecture without satisfaction of the
receipt-dependent condition.
The required dependency may be enforced through cryptographic
material, hardware-controlled state, transactional control, protected
memory, secure command dispatch, scoped capability formation, or
other appropriate mechanisms.
The IEV may be implemented as a physically separate device, a
hardware subsystem, an operating-system security component, a trusted
process, an isolated service, a remote protected validator, or an
integrated logical validation function within a larger protected
component.
The IEV, receipt issuer, protected state controller, and Finality
Sink may be physically distinct, logically distinct, integrated into
one device, or distributed across several administrative and
computing domains.
The invention is not limited to any particular physical placement or
number of components.
The required technical property is that the governed successor
effectuation path cannot bypass the authenticated receipt-dependent
continuation condition.
2.0.2 — Fundamental Causal Principle
The central principle of the embodiment is:
Das Expires 29 April 2027 [Page 123]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A required next consequential phase shall not obtain or exercise
valid finality authority until a cryptographically identifiable
authorized validator has accepted evidence of the required earlier
real effect, and the resulting authenticated receipt or authoritative
protected receipt state has satisfied the next Finality Sink's
mandatory continuation condition.
This arrangement distinguishes:
1. Authority to perform an earlier bounded real effect;
2. The actual occurrence of that effect;
9.3.3.3. Source page 297 of the original specification
3. Evidence concerning the observed effect;
4. Authentication and qualification of the evidence source;
5. Independent acceptance of the evidence by an identifiable
validator;
6. Formation of the validated receipt-dependent continuation
condition;
7. Independent successor Finality Sink verification;
8. Actual release of the next consequential effect.
These stages may be implemented through separate components or as
logically protected state transitions within one component.
Their physical separation is not universally required.
Their required logical, evidentiary, and enforcement relationships
remain applicable.
2.0.3 — Receipt as an Execution-Enabling Factor
The validated effect receipt is not merely a historical statement
that the earlier phase succeeded.
It is not merely an audit record, informational message, workflow-
completion flag, or advisory security result.
Das Expires 29 April 2027 [Page 124]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
In the principal receipt-gated implementation, the accepted receipt
is a constitutive input to the creation, activation, derivation,
release, or validation of the authority necessary for the next
consequential operation.
A system may enforce this property by preventing the next Finality
Sink from completing its controlled effectuation function until it
has verified the appropriate receipt-dependent condition.
The receipt may be transmitted as an authenticated object, supplied
through a protected internal interface, fetched from an authoritative
receipt registry, or represented by a sealed protected state
reference.
A separately transmitted receipt file is not essential where the same
protected component contains the validator and sink.
Nevertheless, the protected system maintains a distinguishable
receipt acceptance event and binds that event to the required
continuation state.
2.0.4 — Validator Identity Requirement
Every IEV authorized to produce a receipt accepted for protected
causal continuation has a verifiable identity within the applicable
authorization domain.
The identity may comprise a unique enrolled validator identifier
together with an associated cryptographic public key, certificate,
protected signing key, or equivalent cryptographic authentication
mechanism.
The validator identifier distinguishes the authorized validator
instance or expressly authorized validator role within its trust
namespace.
9.3.3.4. Source page 298 of the original specification
Cryptographic proof establishes that the validation result originated
from an entity possessing the corresponding authorized cryptographic
credentials.
An arbitrary identifier string, serial number, UUID, software process
name, or device label is insufficient, by itself, to authenticate the
validator.
Das Expires 29 April 2027 [Page 125]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The applicable Finality Sink verifies that the identified validator
is enrolled, authorized for the relevant validation function, and
valid under current protected trust and revocation state.
A validator identity may remain stable while its cryptographic keys
are rotated, provided a protected binding between the identity and
authorized replacement keys is maintained.
2.0.5 — Physical and Logical Deployment Neutrality
The IEV may be physically installed between an autonomous agent and
an effectuation controller.
For example, a validator may be implemented in a separate protected
network appliance positioned on a mandatory communication path.
In another implementation, the IEV may be installed as a protected
hardware module connected to a storage, network, or actuator
controller.
In another implementation, a processor may contain an isolated
validator function and a separate effectuation-control function.
In another implementation, the entire validation, receipt, authority,
and Finality Sink procedure may execute within a single protected
processor or controller.
In another implementation, the validator may operate remotely and
send authenticated validated receipts to a successor Finality Sink in
another domain.
The physical architecture does not determine whether the causal
security property exists.
The decisive requirement is that the authorized validator's result is
authenticated and the required next-phase effect cannot bypass the
receipt-dependent finality condition.
2.0.6 — No Unrestricted Bearer Authority
A validated receipt need not function as a transferable bearer
credential.
The receipt may bind a specific predecessor effect, successor
Candidate Act, authorized resource, destination, operation class,
designated Finality Sink, validator identity, protected epoch, and
consumption reference.
Das Expires 29 April 2027 [Page 126]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Possession of a copy of the receipt by an untrusted agent does not
authorize unrelated operations.
A validator-signed receipt accepted for one successor phase does not
automatically authorize a different phase or an unrestricted session.
2.0.7 — Optional In-Line Validation
The embodiment additionally includes an optional pre-effect IEV mode.
9.3.3.5. Source page 299 of the original specification
In this mode, a cryptographically identified validator independently
verifies the actual pending operation immediately before its
principal consequence.
Its authenticated validation result becomes a necessary condition for
final release of the corresponding operation.
This mode may operate without an earlier real-effect receipt.
The principal inter-phase receipt-gated implementation remains
distinguished by the mandatory causal dependency upon evidence from a
preceding actual bounded consequence.
2.1 — TECHNICAL FIELD
The present embodiment relates to protected autonomous execution,
artificial-intelligence agent security, secure operating systems,
cryptographically authenticated machine identities, distributed
authorization, hardware and firmware enforcement, protected state
machines, trusted execution environments, effectuation-boundary
verification, causal execution protocols, secure networking,
transactional systems, robotics, and consequential workflow control.
More particularly, the embodiment relates to the use of a
cryptographically identifiable validation authority to establish a
causal relationship between an earlier actual consequential effect
and the authority required for a later consequential effect.
The architecture may apply to AI assistants, autonomous agents,
embedded controllers, industrial equipment, enterprise workflow
systems, financial services, cloud infrastructure, telecommunications
networks, secure storage systems, cross-device services, and remote
effectuation platforms.
Das Expires 29 April 2027 [Page 127]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The IEV may be implemented through hardware, firmware, isolated
software, an authenticated distributed service, or combinations
thereof.
No particular processor, operating system, cryptographic algorithm,
network protocol, programming language, vendor-specific device, or
commercial AI platform is essential.
2.2 — SPECIFIC TECHNICAL PROBLEMS
2.2.1 — The Authorization-to-Actual-Effect Gap
An agent may obtain valid authorization for a proposed operation.
However, the actual operation reaching an effectuation boundary may
differ from the authorized proposal because of resource substitution,
application changes, intermediary compromise, asynchronous execution,
command-buffer mutation, or time-of-check/time-of-use conditions.
An earlier approval therefore does not necessarily establish that the
actual pending command is valid.
The optional in-line IEV addresses this gap through independent
actual-operation verification and authenticated validator-bound
release evidence.
2.2.2 — The Actual-Effect-to-Evidence Gap
9.3.3.6. Source page 300 of the original specification
A validly authorized operation may be transmitted or initiated
without producing its intended external result.
An acknowledgement may establish request receipt but not completion.
A local command may succeed while an external service fails.
A physical actuator may accept a command without reaching the
expected position.
A valid receipt requires evidence capable of establishing the
particular outcome being asserted.
2.2.3 — The Evidence-to-Causal-Authority Gap
A conventional system may examine a success flag or receipt before
scheduling another task.
Das Expires 29 April 2027 [Page 128]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
However, the subsequent operation may remain technically executable
through an unrestricted API, credential, controller, or alternate
interface.
This creates a gap between receipt verification as a software
decision and receipt verification as an enforceable execution
prerequisite.
The principal embodiment closes this gap by withholding the required
next-phase authority or execution-enabling condition until receipt
acceptance.
2.2.4 — The Validator-Identity Gap
A system may receive a message stating:
"Validation successful."
Without a verifiable validator identity, the Finality Sink may be
unable to determine whether the result came from the designated
security component, an unauthorized process, a compromised
intermediary, or the requesting agent.
Even an authenticated message is insufficient where its issuer is not
authorized for the particular validation function.
Accordingly, the successor Finality Sink must establish not merely
that a validation result exists, but that the result originated from
an appropriately enrolled validator with valid cryptographic
credentials and the required authority.
2.2.5 — The Validator-Substitution Problem
An attacker may attempt to replace the designated validator with
another program or device that always produces successful results.
If the sink accepts any correctly formatted receipt, the security
condition becomes bypassable.
The architecture therefore binds accepted receipts to approved
validator identities or expressly permitted validator groups.
A replacement validator must satisfy a protected enrollment or
substitution procedure before its receipts become acceptable.
Das Expires 29 April 2027 [Page 129]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.3.3.7. Source page 301 of the original specification
2.2.6 — The Physical-Bypass Problem
A physically separate validator may inspect traffic or commands.
However, if the agent can use another path to reach the effectuation
controller, the physical validator can be bypassed.
For example, an agent may use a second network interface, alternate
API endpoint, direct device connection, or privileged local service.
A physically separate validator therefore does not automatically
provide non-bypassability.
The required finality condition must be enforced by the actual
controlled sink or by an equivalent mandatory path arrangement
covering the relevant effect.
2.2.7 — The Integrated-Component Problem
Conversely, placing the IEV and Finality Sink within one component
does not automatically eliminate independence.
A protected component may contain separately authorized validation
and effectuation functions with distinct protected state and
authenticated roles.
The relevant concern is whether the requesting agent can manipulate
the validator result or bypass the mandatory release condition.
Physical separation is one possible implementation of protection, but
not a universal requirement.
2.2.8 — The Receipt-Replay Problem
An attacker may copy a valid receipt and attempt to reuse it for
another operation.
A receipt may be authentic yet stale, consumed, associated with
another phase, or invalid for the current successor.
The sink must therefore verify operation-specific binding, protected
phase lineage, applicable freshness, current authority, and
consumption state.
2.2.9 — The Unknown-Outcome Problem
Das Expires 29 April 2027 [Page 130]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
An earlier effect may occur without a trustworthy acknowledgement.
A crash or network partition may leave the system uncertain whether
the effect happened.
A missing receipt is not proof that the effect failed.
Where the later phase requires confirmed prior completion, the
necessary continuation condition remains unavailable until suitable
evidence is obtained.
2.2.10 — The Fundamental Objective
The objective is to establish a protected causal execution
architecture in which the ability to perform a later consequential
operation depends on an accepted, authenticated, validator-identified
receipt arising from the required preceding real effect.
9.3.3.8. Source page 302 of the original specification
The mechanism may be distributed or integrated, cryptographic or non-
cryptographic in its actual effectuation control, and implemented
across heterogeneous execution domains.
2.3 — INCORPORATION OF COMMON WORKFLOWS
The embodiment may incorporate Candidate Acts, Non-Effective State
holding, Protected Enforcement Domains, scoped non-bearer finality
authority, actual-operation reconstruction, Finality Sinks, and
protected effectuation-state management disclosed in CW-1.
It may incorporate phase descriptors, bounded effectuation, protected
receipts, Interim Effectuation Validators, continuation authority,
and outcome reconciliation disclosed in CW-2.
It may optionally invoke CW-3 where the operation or resulting effect
departs from originally authorized task scope.
The present embodiment develops the following additional technical
features:
First, cryptographically verifiable IEV identity.
Second, protected validator enrollment and role authorization.
Third, validator-identity-bound receipt formation.
Das Expires 29 April 2027 [Page 131]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Fourth, authenticated delivery or authoritative availability of
validated receipts to successor Finality Sinks.
Fifth, receipt-constituted execution enablement.
Sixth, mandatory sink-side verification of validator identity and
receipt correspondence.
Seventh, physical, integrated, and distributed implementations
preserving the same causal enforcement property.
Eighth, cryptographic and non-cryptographic mechanisms for preventing
execution before receipt acceptance.
Ninth, validator substitution, revocation, key rotation, and replay
protection.
Tenth, protected unknown-outcome and recovery procedures.
These mechanisms may be used independently or in technically
compatible combinations, subject to the selected claim limitations.
2.4 — BROAD TECHNICAL DEFINITIONS
2.4.1 — Interim Effectuation Validator
An Interim Effectuation Validator, or IEV, means a logically
identifiable validation function, component, service, processor,
hardware circuit, firmware controller, protected process, security
module, authenticated distributed service, or combination thereof
that independently evaluates a
9.3.3.9. Source page 303 of the original specification
specified actual pending operation or prior real-effect evidence and
produces or establishes an authenticated validation result required
by an applicable effectuation controller.
The term IEV does not require a physically separate device.
An IEV may be integrated with the requesting execution environment
only where the applicable protection prevents the untrusted
requesting entity from forging, replacing, or bypassing the required
validation result.
An IEV may be separate from the Finality Sink or implemented as a
logically protected validation function within the same security
component as the Finality Sink.
Das Expires 29 April 2027 [Page 132]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
2.4.2 — Cryptographically Verifiable Validator Identity
A Cryptographically Verifiable Validator Identity, or CVVI, is an
authenticated identity binding an IEV to one or more cryptographic
verification credentials and applicable protected authorization
attributes.
The identity may comprise:
A validator identifier unique within an enrolled trust namespace;
A cryptographic key identifier;
A public key or verification-key commitment;
A certificate or authenticated enrollment record;
A protected role or permitted validation class;
An authority or security-domain identifier;
Applicable validity and revocation conditions;
And optional device, firmware, software measurement, or hardware
trust evidence.
The identity is not limited to a particular certificate format.
2.4.3 — Validator Unique Identity
A Validator Unique Identity, or VUID, distinguishes a particular
enrolled validator instance or authorized validator role within the
relevant protected authorization domain.
A VUID may be generated from a protected enrollment transaction,
randomly assigned identifier, issuer-qualified serial, public-key
fingerprint, or equivalent authenticated namespace.
Uniqueness is enforced within the applicable enrollment and
authorization system.
The invention does not require an unverified assertion of universal
uniqueness across every computing system.
Where multiple validators share a role, each validator may have an
individual identity and the role may possess a separately
authenticated group identity.
Das Expires 29 April 2027 [Page 133]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.3.3.10. Source page 304 of the original specification
2.4.4 — Validator Identity Registry
A Validator Identity Registry, or VIR, is a protected registry
identifying IEVs authorized to issue validation results accepted by
one or more Finality Sinks.
The registry may contain validator identities, keys, certificate
references, roles, permitted effect classes, sink associations,
validity periods, revocation state, and trust-domain information.
2.4.5 — Validator Authorization Profile
A Validator Authorization Profile, or VAP, defines which operations,
phases, resources, outcome predicates, receipt classes, and successor
Finality Sinks a given IEV is authorized to validate.
A validator possessing a valid identity is not automatically
authorized to approve every consequential operation.
2.4.6 — Validator Identity Proof
A Validator Identity Proof, or VIP, is cryptographic evidence
establishing possession or controlled use of the credentials
associated with a claimed validator identity.
A VIP may comprise a signature, authenticated challenge response,
protected message authentication, or an equivalent authenticated
protocol.
2.4.7 — Qualified Effect Witness
A Qualified Effect Witness is a component capable of providing
evidence concerning a specified actual effect under an identified
observation and trust model.
The witness may be distinct from or integrated with the IEV.
A witness's cryptographic identity establishes its provenance, but
its qualification additionally depends upon its ability to observe
the required consequence.
2.4.8 — Protected Effect Receipt
A Protected Effect Receipt, or PER, is a machine-verifiable
representation of evidence concerning an actual effectuation attempt
or observed consequential result.
Das Expires 29 April 2027 [Page 134]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A PER may identify a prior Candidate Act, phase, actual operation,
effectuation attempt, observed state, outcome assurance, qualified
witness, and protected sequence.
A raw PER does not automatically confer successor authority.
2.4.9 — Validator-Accepted Effect Receipt
A Validator-Accepted Effect Receipt, or VAER, is a PER or equivalent
protected receipt state that has been independently evaluated and
accepted by an authorized IEV.
The VAER includes or is bound to the cryptographically verifiable
identity of the validating IEV.
The VAER constitutes a required causal input to the relevant
successor effectuation condition.
9.3.3.11. Source page 305 of the original specification
A separate VAER object need not be created where the IEV
authenticates the original PER in place or commits the accepted
receipt state within an authoritative protected controller.
2.4.10 — Receipt-Origin Authentication
Receipt-Origin Authentication is the verification that an effect
receipt or observation originated from the claimed witness,
controller, or protected source.
It is distinct from authentication of the IEV's subsequent acceptance
decision.
2.4.11 — Validator Acceptance Authentication
Validator Acceptance Authentication is the verification that an
authorized IEV accepted the specific prior-effect evidence under the
applicable validation policy.
The successor Finality Sink may require both receipt-origin
authentication and validator acceptance authentication.
2.4.12 — Causal Continuation Condition
A Causal Continuation Condition, or CCC, is a protected execution
prerequisite whose valid establishment depends upon acceptance of the
required prior-effect receipt.
Das Expires 29 April 2027 [Page 135]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The CCC may take the form of cryptographic material, protected state,
a controller register, a hardware latch, a command authorization, a
transaction-state condition, a secure mailbox entry, or an equivalent
enforceable mechanism.
2.4.13 — Receipt-Constituted Continuation Authority
Receipt-Constituted Continuation Authority means the specific
authority or necessary execution-enabling condition established as a
consequence of acceptance of required prior-effect evidence by the
authorized IEV.
The term does not imply that a raw receipt is an unrestricted bearer
credential.
2.4.14 — Successor Finality Sink
A Successor Finality Sink is the controlled effectuation boundary
governing a subsequent consequential operation whose release depends
upon the applicable receipt-derived continuation authority.
2.4.15 — Protected Receipt Delivery Path
A Protected Receipt Delivery Path, or PRDP, is an authenticated
method by which a VAER or authoritative receipt-state reference is
supplied to, retrieved by, or made verifiably accessible to a
designated successor Finality Sink.
The PRDP may comprise a network channel, secure internal message,
protected shared memory, controller bus, authenticated storage
lookup, secure mailbox, or equivalent mechanism.
2.4.16 — Receipt-to-Sink Binding
9.3.3.12. Source page 306 of the original specification
Receipt-to-Sink Binding is the protected association of a validated
receipt with the successor Finality Sink and permitted successor
operation.
The binding may include the sink identity, successor Candidate Act
digest, operation class, resource, destination, phase number,
protected epoch, and consumption reference.
2.4.17 — Non-Bypassable Causal Effectuation
Das Expires 29 April 2027 [Page 136]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Non-Bypassable Causal Effectuation means that, within the specified
protected enforcement coverage and threat model, the governed
successor consequence cannot be produced through an accepted
effectuation path without satisfying the required authenticated
receipt-derived continuation condition.
This property requires actual enforcement coverage, not merely a
policy statement or advisory validation result.
2.4.18 — Protected Validator Replacement
Protected Validator Replacement is an authenticated procedure for
replacing, rotating, revoking, or delegating a validator identity or
validation role.
A replacement validator becomes acceptable only after satisfaction of
the relevant enrollment and authority conditions.
2.4.19 — Protected Phase-Binding Commitment
A Protected Phase-Binding Commitment, or PPBC, authenticates the
relationship between the original Candidate Act, applicable Phase
Descriptor, authority state, designated Finality Sink, and permitted
phase operation.
2.4.20 — Protected Phase Outcome Commitment
A Protected Phase Outcome Commitment, or PPOC, authenticates the
relationship between a particular effectuation attempt and the
supported actual outcome.
It may form part of the PER or VAER.
2.4.21 — Protected Phase Lineage Commitment
A Protected Phase Lineage Commitment, or PPLC, binds the predecessor
phase, accepted receipt, validating IEV identity, successor phase,
and applicable authority state.
2.4.22 — Continuation Authority Record
A Continuation Authority Record, or CAR, represents or references the
operation-specific protected continuation authority derived from the
accepted receipt.
The CAR may contain or reference the VAER, CCC, successor Candidate
Act, designated sink, and consumption conditions.
Das Expires 29 April 2027 [Page 137]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A physically separate CAR record is not mandatory where the protected
receipt itself performs the required scope-bound enabling function.
9.3.3.13. Source page 307 of the original specification
2.4.23 — Continuation Consumption Identifier
A Continuation Consumption Identifier, or CCI, identifies a single-
use or otherwise bounded continuation authorization.
A CCI may be maintained by the sink, PED, protected registry, or
another authoritative state component.
2.4.24 — Outcome Reconciliation Fence
An Outcome Reconciliation Fence, or ORF, is protected state that
withholds unsafe continuation, retry, reservation release, or other
dependent effects while the earlier real-effect outcome remains
unresolved.
2.4.25 — Recovery Candidate Act
A Recovery Candidate Act is a separately governed operation proposed
to correct, compensate for, or contain an earlier actual or uncertain
consequential effect.
Its authority is independently established.
2.4.26 — Protected Identity-Bound Receipt Chain
A Protected Identity-Bound Receipt Chain is a sequence of receipt and
authority commitments in which each accepted receipt is associated
with the cryptographic identity of its validating IEV and the
specific causal predecessor and successor conditions.
The chain may exist as transferable authenticated records or as
protected state transitions within one or more components.
2.4.27 — Protected Phase Admission Controller
A Protected Phase Admission Controller, or PPAC, determines whether a
proposed phase may enter protected preparation or the next permitted
execution state.
Admission does not necessarily authorize immediate consequential
release.
2.4.28 — Actual Operation Reconstruction Interface
Das Expires 29 April 2027 [Page 138]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
An Actual Operation Reconstruction Interface, or AORI, supplies the
IEV or Finality Sink with authenticated or appropriately protected
information identifying the actual pending operation.
The AORI may be implemented through controller-owned buffers,
protected dispatchers, authenticated transaction interfaces, or
equivalent technical paths.
2.5 — DETAILED SYSTEM ARCHITECTURE
2.5.1 — Requesting Computational Entity
An AI agent or other autonomous component proposes one or more
consequential operations.
The entity may prepare plans, select tools, and request execution.
9.3.3.14. Source page 308 of the original specification
The entity does not independently possess authority to create an
acceptable IEV identity, forge validator acceptance, or bypass a
required CCC.
2.5.2 — Protected Phase Admission Controller
The PPAC verifies the proposed phase identity, task lineage,
authorized scope, predecessor requirements, current policy, and
applicable enforcement path.
It establishes an initial non-effective hold where required.
2.5.3 — Protected Non-Effective Phase Buffer
A proposed operation may be prepared in a protected buffer.
The buffer may contain the actual command, resource identity,
destination, operation arguments, applicable authority, and protected
command generation.
The buffer may be implemented in memory, secure storage, firmware, a
controlled queue, or controller-owned hardware.
2.5.4 — Actual Operation Reconstruction Interface
The AORI supplies the relevant actual pending operation to the IEV or
Finality Sink.
Das Expires 29 April 2027 [Page 139]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Where required, it obtains data from a protected source rather than
copying the requesting agent's declared intent.
2.5.5 — Cryptographically Identified Interim Effectuation Validator
The IEV possesses an enrolled cryptographic identity.
The IEV may have a protected signing key, authenticated service
credential, or equivalent cryptographic authentication capability.
The IEV applies its authorized validation policy and produces an
authenticated acceptance decision.
The relevant receipt or acceptance record identifies the validating
IEV.
The IEV may be physically separate, remotely located, or integrated
within a protected execution controller.
Its logical authority is distinct from the untrusted agent's ability
to propose or request operations.
2.5.6 — Validator Identity and Authorization Service
A protected identity service enrolls the IEV.
The service may establish a VUID, permitted validation role,
associated cryptographic keys, trust anchor, scope, and current
validity state.
The identity service may be implemented within the PED, a protected
device security controller, a hardware-backed key service, or a
remote authenticated authority.
2.5.7 — Witness Qualification Component
9.3.3.15. Source page 309 of the original specification
The system identifies which sources are capable of supporting the
required actual-effect predicate.
A local send controller may establish dispatch.
A protected storage controller may establish a committed storage
state.
A recipient-side component may establish a defined receipt or
delivery state.
Das Expires 29 April 2027 [Page 140]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A physical sensor may establish a measured physical condition.
The witness's observation capability is evaluated separately from the
existence of a valid cryptographic signature.
2.5.8 — Protected Receipt Formation Component
The receipt component receives actual-effect evidence and constructs
or commits a PER.
It binds the evidence to the prior Candidate Act, actual effectuation
attempt, phase identity, required effect, witness identity, and
protected sequence.
The IEV validates the PER and produces a VAER or equivalent accepted
protected receipt state.
2.5.9 — Protected Causal Continuation Controller
The continuation controller establishes the missing next-phase
execution condition only after receipt acceptance.
It may control cryptographic material, state transitions, hardware
enablement, a protected command queue, or a scoped capability.
The requesting agent cannot independently invoke an unrestricted
release primitive in the asserted protected implementation.
2.5.10 — Protected Receipt Delivery Component
The PRDP ensures that the applicable successor sink receives or can
verify the VAER.
A receipt may be directly sent to the successor sink.
Alternatively, the sink may retrieve the receipt through an
authenticated protected registry.
Where the IEV and sink reside in one protected component, an internal
authenticated or integrity-protected state transition may convey the
receipt.
Regardless of representation, the designated successor sink verifies
the accepted receipt state rather than trusting a generic workflow-
success flag.
2.5.11 — Successor Finality Sink
Das Expires 29 April 2027 [Page 141]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The successor Finality Sink obtains or reconstructs the actual
pending successor operation.
It authenticates the IEV identity and validation result.
9.3.3.16. Source page 310 of the original specification
It verifies the accepted receipt's relation to the earlier real
effect and the permitted successor operation.
It verifies the CCC, current protected state, and applicable
consumption conditions.
Only when all mandatory predicates pass does the sink permit the next
effect.
2.5.12 — Outcome Reconciliation Controller
The reconciliation controller manages uncertain, partial, mismatched,
or failed consequential phases.
It preserves protected attempt state and prevents unsafe continuation
or retry.
It may obtain additional evidence, apply valid idempotency
mechanisms, or propose independently authorized recovery operations.
2.6 — VALIDATOR IDENTITY ENROLLMENT AND TRUST ESTABLISHMENT
2.6.1 — General Requirement
An IEV capable of producing an accepted receipt must be recognized as
an authorized validation authority by the relevant successor Finality
Sink.
A receipt from an arbitrary untrusted service is insufficient.
The sink must know which validator identities or validator roles it
is authorized to trust.
2.6.2 — Validator Identity Enrollment
A non-limiting enrollment procedure may comprise:
First, establishing a protected validator instance or role.
Second, generating or provisioning a cryptographic key pair or
equivalent authentication secret.
Das Expires 29 April 2027 [Page 142]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Third, assigning a VUID within the applicable trust namespace.
Fourth, registering the validator's public verification material or
authenticated key reference.
Fifth, specifying the validator's permitted effect, phase, and
receipt-validation scope.
Sixth, identifying the Finality Sinks authorized to accept its
results.
Seventh, committing applicable validity, revocation, and rotation
information.
Eighth, binding the enrollment record to protected authority state.
2.6.3 — Validator Identity Record
A representative structure is:
VALIDATOR_IDENTITY_RECORD = {
9.3.3.17. Source page 311 of the original specification
protocol_version, trust_domain_id, validator_unique_id,
validator_role_id, cryptographic_key_id,
validator_public_key_or_verification_reference,
certificate_or_enrollment_commitment,
authorized_validation_classes[], permitted_effect_domains[],
permitted_successor_sinks[], validator_authority_epoch,
validator_identity_generation, permitted_receipt_types[],
applicable_assurance_profile, validity_conditions,
revocation_state_reference, optional_hardware_measurement,
protected_authentication } This structure is non-limiting.
A protected registry may contain equivalent authenticated information
without using these exact field names.
2.6.4 — Cryptographic Proof of Validator Possession
The validator may authenticate an issuance request or validation
result using a protected signing key.
In another implementation, it may complete a challenge-response
protocol.
The protected sink verifies that the result corresponds to an
authorized enrolled validator identity.
Das Expires 29 April 2027 [Page 143]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
An untrusted agent cannot impersonate the validator merely by copying
the validator's public identity fields.
2.6.5 — Validator Identity Binding to Receipt
A validator acceptance record may bind:
VALIDATOR_ACCEPTANCE_RECORD = { validator_unique_id,
validator_key_id, accepted_effect_receipt_digest,
predecessor_candidate_act_digest, predecessor_phase_id,
predecessor_attempt_id, supported_outcome_predicate,
authorized_successor_candidate_digest, authorized_successor_sink_id,
authority_epoch, validation_policy_version,
9.3.3.18. Source page 312 of the original specification
protected_validation_sequence, continuation_consumption_reference,
validation_decision, cryptographic_validator_authentication } The
record may be included in the VAER or maintained as an authenticated
companion object.
2.6.6 — Sink Trust Verification
The successor Finality Sink verifies:
1. The claimed validator identity exists in the authorized trust
registry.
2. The cryptographic authentication corresponds to that identity.
3. The validator possesses the required validation role.
4. The role covers the relevant effect predicate and successor sink.
5. The validator's key and authority have not been revoked or
superseded.
6. The receipt identifies the correct predecessor and successor
relationship.
7. The applicable protected state remains current.
A cryptographically valid signature from an unauthorized validator is
rejected.
2.6.7 — Identity Rotation
An authorized validator may rotate its signing key.
Das Expires 29 April 2027 [Page 144]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The protected identity registry associates the new key with the
existing validator identity or establishes a new identity generation.
A successor sink checks the applicable key generation and
authorization epoch.
An obsolete or revoked key is not silently treated as valid merely
because an old receipt contains a recognized validator name.
2.6.8 — Validator Replacement
A replacement IEV may be installed when an earlier validator fails or
is removed.
The replacement undergoes a protected enrollment or authorized
substitution process.
The system may preserve, revalidate, or invalidate pending receipts
according to the applicable replacement policy.
A newly installed program or device cannot become an authorized IEV
merely by adopting the same display name, network address, or
software identifier.
2.6.9 — Integrated Validator Identity
9.3.3.19. Source page 313 of the original specification
Where the IEV and Finality Sink reside in the same hardware
controller, the IEV may possess a cryptographically enrolled logical
validator identity associated with that controller.
The protected validation function may authenticate its receipt or
commit an identity-bound acceptance into controller-protected state.
The receiving effectuation function verifies the corresponding
protected validator identity and state.
A separate physical certificate exchange over a network is not
required where the protected internal trust boundary already
establishes the necessary authentication.
2.6.10 — Multi-Validator Identity
An implementation may require acceptance by more than one IEV.
Each validator may have its own VUID and cryptographic credentials.
Das Expires 29 April 2027 [Page 145]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A protected aggregation component may create a combined receipt whose
validity depends upon a defined set or threshold of authorized
validator identities.
A group identifier does not eliminate the need to establish which
validator instances actually participated where that fact matters.
2.7 — PROTECTED CAUSAL RECEIPT CHAIN
2.7.1 — Chain Construction
A principal embodiment employs the sequence:
AUTHORIZED PHASE P[i] | v ACTUAL REAL EFFECT E[i] | v QUALIFIED
OBSERVATION O[i] | v PROTECTED EFFECT RECEIPT R[i] | v IDENTIFIED IEV
VALIDATES R[i] | v VALIDATOR-AUTHENTICATED RECEIPT VAER[i] | v
VAER[i] REACHES OR IS VERIFIED BY FS[i+1] | v MISSING EXECUTION
CONDITION CCC[i+1] SATISFIED |
9.3.3.20. Source page 314 of the original specification
v SUCCESSOR REAL EFFECT E[i+1] 2.7.2 — First Causal Anchor
The first anchor binds the original Candidate Act, phase descriptor,
protected authority, and designated first Finality Sink.
2.7.3 — Second Causal Anchor
The second anchor binds the actual first-phase operation and
supported real-effect evidence.
2.7.4 — Third Causal Anchor
The third anchor binds the effect receipt to the cryptographic
identity of the IEV that independently accepts it.
2.7.5 — Fourth Causal Anchor
The fourth anchor binds the validator-accepted receipt to the
successor Candidate Act, designated successor Finality Sink, and
protected continuation state.
2.7.6 — Fifth Causal Anchor
The fifth anchor records the actual successor effectuation attempt
and corresponding protected authority consumption.
2.7.7 — Representative Commitments
Das Expires 29 April 2027 [Page 146]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A non-limiting construction may use:
A[i] = AUTH_PROTECT( H("PHASE-AUTH" || CANONICAL(CAD[i]) ||
PHASE[i] || SINK[i] || AUTHORITY_EPOCH[i]) )
B[i] = AUTH_PROTECT( H("ACTUAL-EFFECT" || A[i] ||
ACTUAL_OPERATION[i] || ATTEMPT[i] || QUALIFIED_OBSERVATION[i]) )
V[i] = SIGN_VALIDATOR_IDENTITY( H("IEV-ACCEPTED-RECEIPT" || B[i] ||
VALIDATOR_UNIQUE_ID || VALIDATION_POLICY || SUCCESSOR_CAD[i+1] ||
9.3.3.21. Source page 315 of the original specification
SUCCESSOR_SINK[i+1] || CONTINUATION_COUNTER[i+1]) )
C[i+1] = PROTECTED_ENABLEMENT( V[i], CURRENT_AUTHORITY,
CURRENT_PHASE_STATE, SUCCESSOR_OPERATION[i+1] ) These constructions
are illustrative.
Authentication may be realized through signatures, message-
authentication mechanisms, authenticated state transitions, or
protected equivalent representations.
For the principal implementation, an identifiable validator remains
cryptographically authenticated.
2.7.8 — Receipt as the Necessary Causal Factor
A valid V[i] is required to establish or verify C[i+1].
Without an accepted validator-authenticated receipt, the next phase
lacks a required execution-enabling condition.
The agent cannot fabricate C[i+1] merely by producing a software
success flag.
2.7.9 — Multiple Predecessors
A successor operation may depend upon several earlier real effects.
The protected receipt chain may require multiple VAERs.
For example:
CCC[3] = REQUIRE_ALL( VAER[0], VAER[1], VAER[2], CURRENT_AUTHORITY )
Alternatively, protected policy may expressly permit a threshold or
one of several defined predecessor conditions.
Das Expires 29 April 2027 [Page 147]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The applicable condition is established before effectuation and not
arbitrarily changed by the requesting agent.
2.8 — PHYSICAL, INTEGRATED, AND DISTRIBUTED VALIDATOR ARRANGEMENTS
2.8.1 — Separate Physical Validator
In one implementation, an IEV is implemented as a separate physical
computing device.
9.3.3.22. Source page 316 of the original specification
The device may be placed on a mandatory command or communication path
between an autonomous execution system and a protected effectuation
controller.
The physical validator possesses a cryptographic identity enrolled
with the designated Finality Sink.
It obtains actual operation or effect evidence, validates the
required predicates, and issues an authenticated receipt.
The Finality Sink refuses the governed successor operation unless the
appropriate identity-bound receipt is verified.
2.8.2 — Physically Added Network Validator
A protected network-validation appliance may be added between an
agent-host system and a controlled destination network.
The appliance may observe or mediate specific outgoing operations.
Where an earlier bounded real effect is required, an authenticated
recipient or controller provides suitable completion evidence.
The appliance's IEV validates the evidence and authenticates the
accepted receipt.
The next network Finality Sink requires the validated receipt before
releasing the next transmission.
The implementation must ensure that the governed transmissions cannot
bypass the required gateway through an alternative interface or
unmediated network path.
2.8.3 — Physically Added Hardware Controller
Das Expires 29 April 2027 [Page 148]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A hardware validator may be connected to an actuator controller,
device bus, protected storage controller, or peripheral interface.
The module may possess protected cryptographic credentials.
An initial bounded real command produces a qualified receipt.
The module validates the receipt and authenticates the continuation
state.
The final controller requires the resulting identity-bound condition
before accepting the next command.
2.8.4 — Hardware Module on an Internal Bus
An IEV may be implemented using a protected expansion module or
internal hardware subsystem.
The module may inspect controller-owned command descriptors and
authenticate its decisions.
A successor Finality Sink may require a response authenticated by the
module's enrolled validator identity.
An expansion card or hardware module alone does not guarantee
security if the agent can address the effectuation resource through
an alternate unprotected channel.
9.3.3.23. Source page 317 of the original specification
2.8.5 — Validator Integrated Within a Processor
An IEV may execute within an isolated region of a processor.
The processor may also contain the PED or Finality Sink.
The IEV may use an internally protected cryptographic identity and
state partition.
The untrusted agent cannot directly write the protected IEV decision
state.
The effectuation function verifies receipt acceptance and current
authority before release.
2.8.6 — Validator Integrated Within the Finality Sink
A Finality Sink may include an IEV subfunction.
Das Expires 29 April 2027 [Page 149]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The IEV receives actual-effect evidence, verifies it, and commits a
validator-identity-bound acceptance record.
A separate protected effectuation subfunction checks the accepted
receipt state and current authority.
Both functions may reside in one physical device.
The architecture may use a common hardware root of trust while
maintaining distinct logical validation and execution-state
transitions.
2.8.7 — Remote Validator
An IEV may operate in a remote protected service.
The service authenticates itself through its enrolled cryptographic
identity.
It may obtain predecessor-effect evidence and issue a successor-bound
VAER.
The receipt is transmitted through an authenticated channel or stored
in an authoritative protected registry.
The successor Finality Sink verifies the validator's identity and
authorization before using the receipt.
2.8.8 — Cross-Device Validator
A first device may perform the initial real effect.
A second device may host the IEV.
A third device may contain the successor Finality Sink.
The validated receipt may cross device boundaries.
Its authentication and operation-specific binding prevent the mere
transport of the receipt from becoming unrestricted authority.
9.3.3.24. Source page 318 of the original specification
2.8.9 — Distributed Validator Group
Several validators may jointly establish the required continuation
decision.
Das Expires 29 April 2027 [Page 150]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
They may possess individually enrolled identities and cryptographic
keys.
A protected policy may require a specific subset or threshold of
signatures or authenticated approvals.
The next sink verifies the required validator participation and
current identity validity.
2.8.10 — Single Protected Component
In another implementation, the agent-facing admission, IEV, receipt
commitment, continuation controller, and Finality Sink functions may
be contained within one protected device.
The same component may perform all relevant actions while enforcing
distinct protected state transitions.
The validator possesses a verifiable logical identity.
The receipt may be represented by protected internal state rather
than transmitted over an external network.
The successor effectuation interface checks that state before
release.
2.8.11 — Common Enforcement Property
Across the physical and distributed variants, the common required
relationship is:
No valid authenticated predecessor receipt accepted by the authorized
IEV means no required receipt-derived continuation condition; no
valid continuation condition means no release of the governed
successor effect through the designated Finality Sink.
2.9 — NON-BYPASSABLE CAUSAL ENFORCEMENT
2.9.1 — Mandatory Finality Sink Verification
The successor Finality Sink shall verify the required accepted
receipt or authoritative protected receipt state.
It shall not rely solely upon an untrusted agent's statement that
validation occurred.
2.9.2 — Validator Identity Verification
Das Expires 29 April 2027 [Page 151]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The sink verifies that the receipt was accepted by an authorized
validator possessing valid cryptographic credentials.
2.9.3 — Receipt-to-Operation Matching
The sink verifies that the accepted receipt corresponds to the
correct predecessor and authorized successor.
9.3.3.25. Source page 319 of the original specification
2.9.4 — Protected Phase Ordering
The sink verifies that required predecessor phases have completed
their applicable receipt-dependent transitions.
2.9.5 — Protected Consumption
Where continuation is single-use, the applicable authority is
atomically consumed or reserved under protected state.
2.9.6 — Alternate Path Coverage
The system identifies effectuation paths through which the governed
operation could occur.
Where necessary, those paths are mediated by the same protected
causal condition or an equivalent authoritative controller.
A path outside the protected enforcement coverage is treated as an
implementation limitation.
2.9.7 — Validator Absence
Where the IEV is mandatory but unavailable, the next phase remains
withheld.
The system does not substitute automatic success.
2.9.8 — Validator Failure
A failed validator may be replaced through protected enrollment.
The failure does not authorize bypass of the receipt requirement.
2.9.9 — Validator Compromise
Das Expires 29 April 2027 [Page 152]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Where the protected system determines that a validator's credentials
or trust assumptions are compromised, applicable identity revocation,
authority-epoch advancement, receipt invalidation, or revalidation
procedures may be invoked.
Cryptographic identity is not a guarantee against a compromised
authorized validator.
2.9.10 — Non-Bypassability Qualification
Non-bypassability is established for the protected controlled
effectuation paths under the stated threat model.
It is not established merely by placing a validator next to an
unrestricted resource.
2.10 — MODE A: IDENTIFIED IN-LINE PRE-EFFECT VALIDATION
2.10.1 — Initial Authorization
A Candidate Act is constructed under applicable CW-1 protected
authority.
9.3.3.26. Source page 320 of the original specification
The actual principal effect remains non-effective.
2.10.2 — Command Preparation
A preliminary component prepares the actual command.
The command may be stored in a protected buffer or controller-owned
queue.
2.10.3 — IEV Identity Authentication
The Finality Sink or protected controller establishes which
authorized IEV is required to validate the operation.
2.10.4 — Actual-Operation Reconstruction
The IEV obtains the actual pending operation through the AORI.
2.10.5 — Independent Validation
The IEV evaluates operation parameters, resource identity,
destination, current policy, and relevant protected state.
Das Expires 29 April 2027 [Page 153]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
2.10.6 — Authenticated Validation Record
If validation passes, the IEV authenticates a Pre-Effect Validation
Record using its enrolled cryptographic identity.
The record is bound to the actual operation and designated sink.
2.10.7 — Finality Sink Verification
The Finality Sink verifies the validator identity, validation record,
current command, and scoped finality authority.
2.10.8 — Protected Release
The command is permitted only after all required predicates pass.
2.10.9 — Post-Validation Substitution Protection
A protected immutable command buffer, generation counter, atomic
release, or equivalent mechanism prevents unauthorized substitution
after validation.
2.10.10 — Distinction from Inter-Phase Receipt Gating
Mode A may operate without an earlier real effect.
Its authenticated validation result is a required pre-effect
condition.
The principal Mode B implementation, by contrast, derives the next-
phase condition from accepted evidence of an earlier real effect.
9.3.3.27. Source page 321 of the original specification
2.11 — MODE B: RECEIPT-CONSTITUTED INTER-PHASE EFFECTUATION
2.11.1 — First Bounded Real Effect
A first Candidate Act receives valid authority.
The first Finality Sink verifies the actual operation and permits its
bounded real effect.
2.11.2 — Actual Effect Observation
A qualified source obtains evidence of the effect.
Das Expires 29 April 2027 [Page 154]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The observed outcome may be success, partial effect, mismatch,
confirmed absence of effect, or unknown.
2.11.3 — Protected Receipt Construction
The receipt component constructs a PER bound to the actual
effectuation attempt.
2.11.4 — Independent Validator Authentication
The IEV possesses an enrolled cryptographic identity.
The protected system authenticates the IEV's validation result.
2.11.5 — Receipt Validation
The IEV verifies:
• Predecessor Candidate Act identity;
• Actual prior operation;
• Effectuation-attempt identity;
• Required effect predicate;
• Witness authenticity and qualification;
• Actual observed outcome;
• Phase lineage;
• Receipt freshness;
• Protected authority state;
• Revocation state;
• Permitted successor scope.
2.11.6 — Validator-Accepted Receipt
Successful validation produces or commits a VAER.
9.3.3.28. Source page 322 of the original specification
The VAER is authenticated under the authorized IEV identity.
Das Expires 29 April 2027 [Page 155]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
2.11.7 — Receipt Delivery to Next Sink
The VAER is delivered to the successor Finality Sink or made
available through an authoritative protected lookup.
The sink verifies the receipt's authenticated provenance and
successor binding.
2.11.8 — Receipt-Dependent Enablement
The VAER establishes or satisfies the required CCC.
In a cryptographic implementation, the CCC may release or activate
missing key material.
In a non-cryptographic implementation, it may activate a protected
continuation state or hardware latch.
2.11.9 — Actual Successor Verification
The successor Finality Sink reconstructs the actual pending
operation.
It verifies that the operation corresponds to the permitted
successor.
2.11.10 — Next Real Effect
Only after the required receipt-dependent conditions and ordinary
finality authority pass may the next real effect occur.
2.11.11 — Repeated Causal Chain
The next phase may produce its own real-effect receipt.
A further IEV validation may establish authority for another phase.
The causal chain may continue for a permitted number of phases or
until a protected termination condition is reached.
2.12 — CRYPTOGRAPHIC EXECUTION-DEPENDENCY IMPLEMENTATIONS
2.12.1 — Receipt-Dependent Key Release
A protected key service withholds a key required for the next
consequential operation.
Das Expires 29 April 2027 [Page 156]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
After IEV acceptance, the key service verifies the VAER and makes the
operation-specific key material available through a protected
interface.
2.12.2 — Receipt-Dependent Key Derivation
A protected secret and accepted receipt commitment may be used to
derive successor-specific key material.
9.3.3.29. Source page 323 of the original specification
The key material may be bound to the successor sink, Candidate Act,
phase, and authority epoch.
2.12.3 — Split-Key Implementation
A Finality Sink may possess one key component while the IEV or
protected continuation service controls another.
Successful receipt validation permits access to the required missing
share.
2.12.4 — Threshold Authorization
A protected threshold signing mechanism may require one or more IEV-
controlled shares.
The successor command cannot obtain the necessary authenticated
authorization without the required validator participation.
2.12.5 — Signed Receipt as Required Input
The successor sink may require a cryptographically valid VAER before
accepting the next operation.
The receipt may be directly supplied to the sink or retrieved from
the authoritative registry.
2.12.6 — Encryption-Based Effect Withholding
A protected information object may remain encrypted until the
required validated receipt exists.
The downstream release or use of the object may be controlled by
receipt-dependent key availability.
2.12.7 — Credential Activation
Das Expires 29 April 2027 [Page 157]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A protected credential may remain unavailable or unusable for the
successor operation until the IEV's receipt-dependent condition is
satisfied.
2.12.8 — Authenticated Command Formation
The IEV may authenticate an accepted receipt whose commitment is
required for formation of a valid successor command authenticator.
2.12.9 — Security Condition
The protected cryptographic operation must be genuinely required for
the governed consequence.
A receipt-derived key provides no non-bypassability if the agent can
cause the same effect through an unrestricted alternate path.
2.13 — NON-CRYPTOGRAPHIC EFFECTUATION-GATING IMPLEMENTATIONS
The IEV retains a cryptographically verifiable identity, but the
actual next-phase gate need not depend upon cryptographic key
derivation.
9.3.3.30. Source page 324 of the original specification
2.13.1 — Protected State-Machine Transition
An IEV-accepted receipt may cause an atomic transition from
NEXT_PHASE_DISABLED to NEXT_PHASE_ENABLED.
2.13.2 — Hardware Latch
A controller-owned latch may remain disabled until the validated
receipt satisfies the required phase condition.
2.13.3 — Protected Register
A protected phase counter or authorization register may be advanced
only by the approved receipt-acceptance procedure.
2.13.4 — Secure Command Queue
A controlled command queue may refuse successor commands unless a
valid receipt-dependent state reference exists.
2.13.5 — Transaction-State Dependency
Das Expires 29 April 2027 [Page 158]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A protected transaction engine may require an authenticated
predecessor commit record accepted by the IEV before permitting a
successor transaction.
2.13.6 — Network Release State
A protected network controller may require a receipt-authorized
continuation entry before transmitting a specified next-phase
payload.
2.13.7 — Storage Commit State
A storage controller may require a valid receipt-dependent
authorization state before committing the next protected write.
2.13.8 — Firmware-Controlled Phase Advancement
Protected firmware may accept a validator-authenticated receipt and
advance a phase state governing future commands.
2.13.9 — Integrated Protected Controller
A single protected controller may maintain all receipt and phase
state internally.
The identified validator subfunction commits the accepted receipt.
The effectuation subfunction verifies the protected acceptance state
before release.
2.13.10 — Enforcement Requirement
The requesting agent must not be able to write the protected state,
force the latch, bypass the command gate, or generate an equivalent
unauthorized release condition.
9.3.3.31. Source page 325 of the original specification
2.14 — CROSS-COMMITTED RECEIPT AND AUTHORITY STRUCTURES
2.14.1 — Protected Phase Authorization Record
A phase authorization record binds the Candidate Act, Phase
Descriptor, designated Finality Sink, authorized effect envelope, and
applicable authority epoch.
2.14.2 — Actual Effectuation Attempt Record
Das Expires 29 April 2027 [Page 159]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
An attempt record identifies the actual operation, sink, attempt
identifier, and protected execution state.
2.14.3 — Qualified Outcome Evidence Record
An outcome evidence record identifies the observation source,
supported effect, observation sequence, and relevant trust
properties.
2.14.4 — Validator-Authenticated Receipt
A VAER binds the outcome evidence to the authorized IEV identity and
validation decision.
2.14.5 — Successor Continuation Record
A CAR or equivalent protected state binds the accepted receipt to the
permitted successor Candidate Act, designated sink, and CCC.
2.14.6 — Receipt Cross-Commitment
A representative commitment may be expressed as:
VAER_COMMITMENT = SIGN_IEV( DOMAIN_SEPARATOR ||
VALIDATOR_UNIQUE_ID || H(PREDECESSOR_CAD) ||
H(ACTUAL_PREDECESSOR_EFFECT) || H(QUALIFIED_OUTCOME_EVIDENCE) ||
H(SUCCESSOR_CAD) || SUCCESSOR_SINK_ID || POLICY_EPOCH ||
CONTINUATION_COUNTER ) The exact encoding and algorithm are non-
limiting.
A secure implementation requires canonical encoding and appropriate
key protection.
2.14.7 — Protected Receipt-Authority Separation
The system may maintain a separate scoped finality authority in
addition to the VAER.
Alternatively, a combined protected object may represent both receipt
acceptance and successor-specific finality authority.
9.3.3.32. Source page 326 of the original specification
In either arrangement, the receipt is the necessary causal factor for
the later authority.
A raw effect receipt that has not passed IEV validation cannot
independently cause the successor effect.
Das Expires 29 April 2027 [Page 160]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
2.15 — PROTECTED STATE MACHINE
The following states may be implemented through cryptographic or non-
cryptographic protected state.
CREATED: Phase descriptor constructed.
HELD_NON_EFFECTIVE: Governed consequence withheld.
PREPARED: Operation prepared under applicable preliminary authority.
INLINE_IEV_PENDING: Actual pending operation requires in-line
validation.
INLINE_VALIDATED: Authorized identified IEV accepted the pending
operation.
FINALITY_READY: Applicable first-phase finality conditions satisfied.
AUTHORITY_CONSUMED: Single-use or bounded authority committed or
reserved.
EFFECT_ATTEMPTED: Real consequential operation initiated.
EFFECT_CONFIRMED: Qualified evidence establishes the required
observed effect.
PARTIAL_EFFECT_CONFIRMED: A defined subset of the expected
consequence is supported.
NO_EFFECT_CONFIRMED: Adequate evidence supports absence of the
governed effect.
OUTCOME_UNKNOWN: Evidence insufficient to establish the relevant
result.
EFFECT_MISMATCH: Observed effect differs materially from the
permitted result.
RECEIPT_GENERATED: PER created from appropriate observation evidence.
IEV_RECEIPT_VALIDATION_PENDING: Receipt awaiting validation by the
authorized identified IEV.
VALIDATOR_ACCEPTED_RECEIPT: VAER authenticated and committed.
RECEIPT_DELIVERY_PENDING: Successor sink has not yet established
access to the required authenticated receipt.
Das Expires 29 April 2027 [Page 161]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
SUCCESSOR_SINK_RECEIPT_VERIFIED: Successor sink has authenticated the
required validator identity and receipt binding.
CONTINUATION_ENABLED: Required CCC established.
SUCCESSOR_EFFECT_PENDING: Next operation awaits actual sink
verification.
SUCCESSOR_EFFECT_ATTEMPTED: Next controlled consequential operation
initiated.
9.3.3.33. Source page 327 of the original specification
RECOVERY_PENDING: Corrective operation requires separate authority.
TERMINATED: Relevant workflow or phase concluded according to
protected state.
A transition to CONTINUATION_ENABLED is not permitted solely because
an untrusted agent reports success.
The transition requires accepted receipt evidence under the
applicable validator identity and policy.
2.16 — COMPLETE CAUSAL OPERATIONAL WORKFLOW
Step 1 — Establish Validator Identity
The IEV is enrolled with an authenticated identity, cryptographic
credentials, authorized role, and current trust state.
Step 2 — Establish Successor Sink Trust
The designated Finality Sink recognizes the permitted validator
identity or authorized validator group.
Step 3 — Construct Original Candidate Act
The agent proposes the initial bounded operation.
Step 4 — Commit Protected Phase Authorization
The PED validates the original operation and commits the applicable
authorization.
Step 5 — Prepare Actual Command
The controlled system prepares the operation.
Das Expires 29 April 2027 [Page 162]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Step 6 — Optional In-Line IEV Validation
Where required, an identified IEV verifies the actual pending command
and authenticates its result.
Step 7 — First Finality Sink Verification
The sink verifies the actual operation and permitted authority.
Step 8 — Perform First Real Effect
The bounded consequential operation is released.
Step 9 — Obtain Qualified Actual-Effect Evidence
A capable observation source supplies the relevant evidence.
Step 10 — Construct Protected Effect Receipt
The receipt component binds the actual effect evidence to the
protected predecessor operation.
9.3.3.34. Source page 328 of the original specification
Step 11 — Identify and Authenticate the IEV
The validator acceptance procedure uses the authorized IEV identity
and cryptographic credentials.
Step 12 — Independently Validate the Receipt
The IEV verifies operation correspondence, outcome evidence, phase
lineage, freshness, and current authority.
Step 13 — Produce Validator-Accepted Receipt
The IEV authenticates the VAER or commits equivalent identity-bound
protected receipt state.
Step 14 — Deliver Receipt to Successor Sink
The VAER is transmitted, retrieved, or made available through
protected shared state.
Step 15 — Verify Validator Identity at Sink
The successor Finality Sink verifies the identity and authorization
of the validator that accepted the receipt.
Das Expires 29 April 2027 [Page 163]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Step 16 — Verify Receipt-to-Successor Binding
The sink confirms that the receipt concerns the correct predecessor
and permits the specified successor.
Step 17 — Establish Causal Continuation Condition
The required CCC is generated, released, activated, derived, or
verified.
Step 18 — Reconstruct Actual Successor Operation
The sink obtains the actual pending next operation.
Step 19 — Verify Current Authority and Consumption
The sink verifies current protected policy, revocation, scope, and
replay-prevention state.
Step 20 — Effectuate Next Real Phase
The successor operation is permitted only after all mandatory causal
and finality predicates pass.
Step 21 — Record Next Attempt
The system commits the successor effectuation attempt.
Step 22 — Continue Causal Chain
Where further phases are authorized, the next real effect produces
evidence for another receipt-dependent transition.
9.3.3.35. Source page 329 of the original specification
2.17 — REFERENCE PSEUDOCODE: VALIDATOR ENROLLMENT
FUNCTION ENROLL_IEV( validator_instance, proposed_role,
authorized_sinks, protected_identity_authority ):
REQUIRE VERIFY_VALIDATOR_SECURITY_BOUNDARY( validator_instance )
key_material = CREATE_OR_PROVISION_PROTECTED_KEY( validator_instance
)
validator_id = ALLOCATE_UNIQUE_ENROLLED_ID(
protected_identity_authority )
Das Expires 29 April 2027 [Page 164]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
identity = { validator_unique_id: validator_id, validator_key_id:
key_material.key_id, validator_public_key: key_material.public_key,
authorized_role: proposed_role, permitted_sinks: authorized_sinks,
authority_epoch: protected_identity_authority.current_epoch }
REQUIRE VERIFY_PROOF_OF_KEY_POSSESSION( validator_instance,
key_material )
committed = protected_identity_authority
.ATOMIC_COMMIT_VALIDATOR(identity)
IF committed != SUCCESS: RETURN DENY
RETURN committed.validator_identity_reference The reference algorithm
establishes both identity and protected role authorization.
The identifier alone is not a trusted security credential.
2.18 — REFERENCE PSEUDOCODE: PROTECTED EFFECT RECEIPT
FUNCTION CONSTRUCT_EFFECT_RECEIPT( predecessor_phase,
9.3.3.36. Source page 330 of the original specification
actual_effectuation_attempt, observation_evidence ):
REQUIRE VERIFY_PREDECESSOR_AUTHORIZATION( predecessor_phase )
REQUIRE VERIFY_ACTUAL_ATTEMPT( actual_effectuation_attempt )
witness = LOOKUP_QUALIFIED_WITNESS( observation_evidence.source_id )
REQUIRE VERIFY_WITNESS_IDENTITY(witness)
REQUIRE VERIFY_WITNESS_CAPABILITY( witness,
predecessor_phase.required_outcome )
REQUIRE VERIFY_OBSERVATION_CORRESPONDENCE( observation_evidence,
actual_effectuation_attempt )
observed_outcome = CLASSIFY_ACTUAL_EFFECT( observation_evidence )
receipt = PROTECTED_COMMIT({ predecessor_phase:
HASH(predecessor_phase),
actual_attempt: HASH(actual_effectuation_attempt),
witness_identity: witness.identity,
Das Expires 29 April 2027 [Page 165]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
observed_effect: observed_outcome,
evidence_digest: HASH(observation_evidence),
protected_sequence: NEXT_PROTECTED_SEQUENCE() })
9.3.3.37. Source page 331 of the original specification
RETURN receipt This produces an effect receipt.
It does not automatically produce successor execution authority.
2.19 — REFERENCE PSEUDOCODE: IDENTITY-BOUND IEV RECEIPT ACCEPTANCE
FUNCTION IEV_ACCEPT_EFFECT_RECEIPT( iev_identity, effect_receipt,
predecessor_phase, successor_phase ):
REQUIRE VERIFY_ENROLLED_VALIDATOR_IDENTITY( iev_identity )
REQUIRE VERIFY_VALIDATOR_ROLE_AUTHORIZATION( iev_identity,
predecessor_phase, successor_phase )
REQUIRE VERIFY_VALIDATOR_CURRENT_STATUS( iev_identity )
REQUIRE VERIFY_RECEIPT_AUTHENTICITY( effect_receipt )
REQUIRE VERIFY_PREDECESSOR_BINDING( effect_receipt, predecessor_phase
)
REQUIRE VERIFY_REQUIRED_ACTUAL_EFFECT( effect_receipt,
successor_phase.required_predecessor_outcome )
REQUIRE VERIFY_PHASE_LINEAGE( predecessor_phase, successor_phase )
REQUIRE VERIFY_SUCCESSOR_AUTHORITY( successor_phase )
9.3.3.38. Source page 332 of the original specification
REQUIRE VERIFY_RECEIPT_NOT_CONSUMED( effect_receipt )
REQUIRE VERIFY_CURRENT_POLICY_AND_REVOCATION()
accepted = IEV_PROTECTED_ATOMIC_COMMIT({ validator_unique_id:
iev_identity.validator_unique_id,
receipt_digest: HASH(effect_receipt),
predecessor_digest: HASH(predecessor_phase),
Das Expires 29 April 2027 [Page 166]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
successor_digest: HASH(successor_phase),
successor_sink_id: successor_phase.sink_id,
validation_decision: PASS,
continuation_counter: NEXT_PROTECTED_COUNTER(),
receipt_consumption_reference: NEW_PROTECTED_REFERENCE() })
IF accepted != COMMITTED: RETURN DENY
vaer = AUTHENTICATE_WITH_IEV_IDENTITY( iev_identity, accepted )
RETURN vaer The result is an identity-bound accepted receipt.
The IEV is not merely returning a boolean flag.
The accepted receipt is the required input to establishment of the
next protected execution condition.
2.20 — REFERENCE PSEUDOCODE: SUCCESSOR FINALITY SINK
FUNCTION EFFECTUATE_NEXT_PHASE(
9.3.3.39. Source page 333 of the original specification
successor_candidate_act, validator_accepted_receipt,
successor_finality_sink ):
actual_operation = successor_finality_sink.RECONSTRUCT_PENDING_ACT()
IF actual_operation IS NULL: RETURN DENY
identity = EXTRACT_VALIDATOR_IDENTITY( validator_accepted_receipt )
REQUIRE successor_finality_sink
.VERIFY_AUTHORIZED_VALIDATOR(identity)
REQUIRE successor_finality_sink
.VERIFY_VALIDATOR_CRYPTOGRAPHIC_AUTHENTICATION(
validator_accepted_receipt, identity )
REQUIRE successor_finality_sink .VERIFY_RECEIPT_BINDING(
validator_accepted_receipt, successor_candidate_act, actual_operation
)
Das Expires 29 April 2027 [Page 167]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
REQUIRE successor_finality_sink
.VERIFY_RECEIPT_FRESHNESS_AND_PHASE_ORDER( validator_accepted_receipt
)
REQUIRE successor_finality_sink
.VERIFY_CURRENT_AUTHORITY_AND_REVOCATION()
REQUIRE successor_finality_sink
.VERIFY_CAUSAL_CONTINUATION_CONDITION( validator_accepted_receipt,
actual_operation )
REQUIRE successor_finality_sink .VERIFY_SCOPED_FINALITY_AUTHORITY(
actual_operation )
consumption = successor_finality_sink .ATOMIC_CONSUME_CONTINUATION(
9.3.3.40. Source page 334 of the original specification
validator_accepted_receipt, actual_operation )
IF consumption != SUCCESS: RETURN DENY
RETURN successor_finality_sink.EFFECTUATE( actual_operation,
consumption ) The successor Finality Sink must not accept a generic
unsigned success message.
It must authenticate the required validator and receipt relationship.
2.21 — REFERENCE PSEUDOCODE: CRYPTOGRAPHIC CAUSAL ENABLEMENT
FUNCTION DERIVE_RECEIPT_DEPENDENT_AUTHORITY(
validator_accepted_receipt, successor_operation,
protected_key_service ):
REQUIRE VERIFY_AUTHORIZED_IEV_RECEIPT( validator_accepted_receipt )
REQUIRE VERIFY_SUCCESSOR_SCOPE( validator_accepted_receipt,
successor_operation )
REQUIRE VERIFY_CURRENT_PROTECTED_STATE()
REQUIRE VERIFY_RECEIPT_UNUSED()
derived_material = protected_key_service.DERIVE({ domain_separator:
"CAUSAL-IEV-CONTINUATION",
accepted_receipt_digest: HASH(validator_accepted_receipt),
Das Expires 29 April 2027 [Page 168]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
successor_operation_digest: HASH(successor_operation),
successor_sink_id: successor_operation.sink_id,
protected_phase_counter: CURRENT_PROTECTED_COUNTER(),
9.3.3.41. Source page 335 of the original specification
current_authority_epoch: CURRENT_AUTHORITY_EPOCH() })
IF derived_material IS INVALID: RETURN DENY
RETURN PROTECTED_SCOPED_HANDLE(derived_material) The protected key
service uses secret or otherwise protected authorization material
unavailable to the untrusted agent.
The accepted receipt commitment alone is not sufficient if the agent
can compute all necessary cryptographic material independently.
2.22 — REFERENCE PSEUDOCODE: NON-CRYPTOGRAPHIC CAUSAL ENABLEMENT
FUNCTION ACTIVATE_PROTECTED_NEXT_PHASE( validator_accepted_receipt,
protected_controller ):
REQUIRE protected_controller .VERIFY_VALIDATOR_IDENTITY_AND_RECEIPT(
validator_accepted_receipt )
REQUIRE protected_controller .VERIFY_PREDECESSOR_PHASE_COMPLETED()
REQUIRE protected_controller .VERIFY_REQUIRED_EFFECT_EVIDENCE()
REQUIRE protected_controller .VERIFY_RECEIPT_UNUSED()
REQUIRE protected_controller .VERIFY_CURRENT_AUTHORITY()
result = protected_controller.ATOMIC_TRANSITION({ expected_state:
NEXT_PHASE_DISABLED,
required_receipt: HASH(validator_accepted_receipt),
new_state: NEXT_PHASE_ENABLED,
authorized_successor:
9.3.3.42. Source page 336 of the original specification
validator_accepted_receipt.successor_digest,
Das Expires 29 April 2027 [Page 169]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
protected_counter_increment: TRUE })
IF result != COMMITTED: RETURN DENY
RETURN result.protected_continuation_reference The actual enablement
uses protected state.
The validator's receipt identity remains cryptographically
verifiable.
2.23 — COMPLETE BASIC EXAMPLE: PHYSICALLY INSTALLED VALIDATOR BETWEEN
AN AI AGENT AND NETWORK RELEASE
2.23.1 — Original Task
A user instructs an AI agent to transfer a protected document to a
designated external service.
The authorized workflow requires a bounded initial real transfer
followed by a larger transfer only after the first effect is
verified.
2.23.2 — Physical Components
The system comprises an AI agent host, a protected network
controller, a physically separate IEV appliance, a qualified
recipient-side observation component, and a successor Finality Sink.
The IEV appliance possesses an enrolled VUID and cryptographic
signing credentials.
The successor Finality Sink is configured to accept validated
receipts only from authorized enrolled validators.
2.23.3 — First Real Transfer
The agent submits a bounded first-phase Candidate Act.
The originating Finality Sink verifies the actual destination,
object, and authority.
The first real transfer occurs.
2.23.4 — Receipt Generation
The recipient-side protected service produces authenticated evidence
that the specified bounded effect occurred.
Das Expires 29 April 2027 [Page 170]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
2.23.5 — IEV Receipt Acceptance
The physically separate IEV receives the observation evidence.
9.3.3.43. Source page 337 of the original specification
It verifies the actual prior effect, recipient identity, original
Candidate Act, and applicable protected policy.
It generates an authenticated VAER identifying its VUID and validator
key.
2.23.6 — Receipt Delivery
The VAER is transmitted through a protected channel to the successor
Finality Sink.
The sink verifies the validator's cryptographic authentication and
authorized role.
2.23.7 — Next-Phase Enablement
The network controller has withheld the required release condition
for the larger transfer.
The valid receipt establishes the missing condition.
The next Finality Sink verifies the actual transfer operation and
allows only the permitted successor effect.
2.23.8 — Bypass Attempt
Suppose the agent attempts to send the larger payload through another
software interface.
If the controlled effectuation architecture covers that interface,
the operation reaches a sink that requires the same valid causal
receipt.
The alternate software interface therefore cannot bypass the receipt-
dependent release condition.
If the device has an unrestricted alternate network connection
outside the protected architecture, additional mediation is required
before a system-wide non-bypassability guarantee can be asserted.
2.23.9 — Technical Contribution
Das Expires 29 April 2027 [Page 171]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The physically installed validator is not merely observing traffic or
advising the agent.
Its identity-bound accepted receipt is a necessary enabling input for
the subsequent controlled network effect.
2.24 — WORKED EXAMPLE: PHYSICAL ACTUATOR WITH IDENTITY-BOUND
VALIDATOR
2.24.1 — System
A robotic controller performs a sequence of bounded physical
movements.
An IEV may be physically attached as a protected control module or
integrated within the actuator controller.
The IEV possesses a cryptographically verifiable identity.
2.24.2 — Initial Authorization
9.3.3.44. Source page 338 of the original specification
The system authorizes an initial bounded movement.
The first actuator Finality Sink verifies the actual pending command.
2.24.3 — First Real Movement
The actuator performs the authorized movement.
2.24.4 — Physical Outcome Evidence
A qualified sensor reports the actual resulting position.
The report identifies the relevant device and operation.
2.24.5 — IEV Validation
The IEV independently verifies the actual observed state against the
required tolerance and phase authorization.
The IEV authenticates the accepted receipt using its enrolled
identity.
2.24.6 — Hardware Continuation
The next actuator command remains disabled through a protected latch.
Das Expires 29 April 2027 [Page 172]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The receipt-dependent transition activates the specific permitted
next movement.
2.24.7 — Sink Enforcement
The actuator Finality Sink verifies the accepted receipt state,
validator identity, protected phase counter, and actual next command.
2.24.8 — Failure
An invalid or unavailable receipt cannot activate the required next-
phase latch.
A new command generated by the agent does not independently override
the protected hardware condition.
2.25 — WORKED EXAMPLE: FINANCIAL TRANSACTION AND ACCOUNTING
CONTINUATION
2.25.1 — Original Task
An autonomous agent is authorized to submit a payment instruction and
update an accounting record after the payment reaches a specified
verified state.
2.25.2 — First Phase
The payment Finality Sink verifies the actual transaction and permits
submission.
2.25.3 — Outcome Evidence
9.3.3.45. Source page 339 of the original specification
A qualified transaction-state source supplies evidence concerning the
defined payment state.
The evidence may distinguish instruction acceptance, processing,
settlement, rejection, or another relevant condition.
2.25.4 — IEV Acceptance
The identified IEV independently verifies the required payment-state
predicate.
It produces an authenticated receipt identifying the original payment
instruction and permitted accounting successor.
Das Expires 29 April 2027 [Page 173]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
2.25.5 — Accounting Enablement
The accounting Finality Sink requires the accepted receipt before the
accounting update can become effective.
The receipt may activate a protected transaction state or permit a
scoped accounting authenticator to be issued.
2.25.6 — Unknown Outcome
If the payment result remains uncertain, the required accepted
receipt is unavailable.
The accounting completion operation remains withheld.
The agent does not automatically repeat the payment.
2.25.7 — Technical Effect
The actual financial continuation is causally bound to accepted
evidence of the required earlier state.
It does not merely depend upon a locally generated payment-success
message.
2.26 — WORKED EXAMPLE: DOCUMENT COMMIT FOLLOWED BY EXTERNAL EXPORT
2.26.1 — Original Task
An agent prepares a report, stores it under protected authority, and
then transmits the committed report to a designated recipient.
2.26.2 — First Real Effect
The storage Finality Sink verifies the actual report and commits it
to the designated protected storage resource.
2.26.3 — Storage Receipt
The storage controller produces authenticated evidence identifying
the committed resource and version.
9.3.3.46. Source page 340 of the original specification
2.26.4 — IEV Identity and Acceptance
The IEV verifies the storage receipt and the authorized report
identity.
Das Expires 29 April 2027 [Page 174]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The IEV authenticates its acceptance using its enrolled validator
identity.
2.26.5 — Export Authority
Before validation, the export Finality Sink lacks the necessary
receipt-dependent execution condition.
After the IEV's valid receipt acceptance, a successor-specific
continuation authority becomes available.
2.26.6 — Final Export Verification
The export Finality Sink verifies the actual outgoing report,
destination, receipt, validator identity, and current authority.
2.26.7 — Target Substitution
If the agent substitutes an unrelated document, the sink rejects the
operation despite the existence of a valid storage receipt for the
original report.
2.27 — WORKED EXAMPLE: CROSS-DEVICE AND DISTRIBUTED VALIDATION
A first device performs a bounded real effect.
A qualified observation component on that device generates
authenticated outcome evidence.
A separate protected IEV service on another device validates the
evidence.
The IEV possesses a registered cryptographic identity.
It produces a successor-bound VAER.
A third device hosts the successor Finality Sink.
The successor sink authenticates the VAER, validator identity,
predecessor operation, and current phase authority.
Where the permitted continuation involves exclusive ownership or
migration, the sink additionally verifies the applicable cross-device
fencing or authority-transfer state.
The mere possession of a copied receipt by another device does not
authorize unrestricted effectuation.
Das Expires 29 April 2027 [Page 175]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The implementation may use authenticated communication, protected
hardware identities, trusted service credentials, or suitable
combinations.
9.3.3.47. Source page 341 of the original specification
2.28 — WORKED EXAMPLE: SINGLE COMPONENT WITH NO PHYSICAL SEPARATION
A protected computing controller contains the agent-facing operation
admission function, the IEV, the protected receipt registry, the
continuation state controller, and the Finality Sink.
The IEV exists as a logically protected validation function.
It possesses an enrolled cryptographic identity associated with the
protected controller.
The first consequential phase is permitted.
The controller obtains appropriate actual-effect evidence.
The IEV validates that evidence.
It commits a cryptographically attributable accepted receipt to
protected state.
The successor effectuation function checks the receipt state, IEV
identity, phase, actual operation, and consumption reference.
The next phase remains disabled until the required receipt-dependent
state transition occurs.
No physically separate validation device is necessary.
The distinction between validation and effectuation is established
through protected authority, state, and mandatory control flow.
A software-only component that allows the requesting agent to alter
the accepted receipt state or invoke an unrestricted effectuation
path does not establish this stronger guarantee.
2.29 — WORKED EXAMPLE: TWO INDEPENDENT VALIDATORS
An industrial controller requires acceptance by two authorized
validators before a broader consequential phase becomes available.
IEV-A possesses Validator Identity A and Cryptographic Key A.
Das Expires 29 April 2027 [Page 176]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
IEV-B possesses Validator Identity B and Cryptographic Key B.
The first real bounded effect produces qualified observation
evidence.
Each IEV independently evaluates the required evidence according to
its authorized role.
The protected continuation component verifies both accepted validator
identities and their corresponding authenticated results.
The next Finality Sink requires the designated joint validation
condition.
A forged receipt from an unregistered validator cannot substitute for
either required result.
An authenticated result from IEV-A cannot be copied and relabeled as
a result from IEV-B.
9.3.3.48. Source page 342 of the original specification
The implementation may instead use a defined threshold of
independently enrolled validators where appropriate.
The assurance depends upon the actual separation, trust assumptions,
and verification capabilities of the validators.
2.30 — ADVERSARIAL THREAT MODEL
2.30.1 — Forged IEV Identity
An attacker claims to be the validator by copying its VUID.
The sink requires cryptographic proof associated with the enrolled
validator identity.
2.30.2 — Unregistered Validator
An unauthorized program produces a correctly formatted receipt.
The sink rejects the receipt because the issuer is not an authorized
IEV.
2.30.3 — Unauthorized Validator Role
A valid validator signs a receipt concerning an operation outside its
authorized scope.
Das Expires 29 April 2027 [Page 177]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The sink rejects the result based upon the applicable VAP.
2.30.4 — Validator-Key Substitution
An attacker replaces a validator's public key in an untrusted
configuration file.
The sink verifies the authenticated registry or protected trust
anchor.
2.30.5 — Compromised Validator Credential
An authorized validator key is compromised.
Applicable revocation, identity generation, protected epoch, and
replacement procedures may be used.
A signature produced with a compromised but still trusted key cannot
always be distinguished from an authorized signature without
additional protections.
2.30.6 — Validator Certificate Replay
An attacker presents expired or superseded validator credentials.
The sink verifies current validity and applicable authorization
state.
2.30.7 — Forged Actual-Effect Receipt
An attacker fabricates a PER claiming an earlier real effect
occurred.
9.3.3.49. Source page 343 of the original specification
The IEV requires appropriate authenticated observation evidence.
2.30.8 — Receipt Replay
An attacker reuses a previously accepted VAER.
The sink verifies phase identity, operation binding, freshness, and
consumption state.
2.30.9 — Wrong-Successor Receipt
A valid receipt is presented for an unrelated successor Candidate
Act.
Das Expires 29 April 2027 [Page 178]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The sink rejects the mismatch.
2.30.10 — Sink Substitution
A receipt authorized for one Finality Sink is presented to another
sink.
The sink identity and scope checks prevent unauthorized reuse.
2.30.11 — Post-Validation Operation Substitution
The agent changes the next command after validation.
The Finality Sink reconstructs the actual operation and rejects
material mismatch.
2.30.12 — Agent Self-Approval
The agent declares the prior phase successful.
The declaration cannot replace the required authenticated IEV
receipt.
2.30.13 — Fake Hardware Validator
An attacker installs an unauthorized hardware module purporting to be
the IEV.
The sink verifies the module's enrolled identity and authorization.
2.30.14 — Physical Validator Removal
The authorized IEV is physically disconnected.
Where required, the successor effect remains disabled.
2.30.15 — Alternate Network Path
The agent attempts to route a protected effect around the validator.
The guarantee requires mediation of the relevant alternate path or
enforcement by a destination-side controller requiring the same
receipt.
2.30.16 — Alternate Application API
Das Expires 29 April 2027 [Page 179]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.3.3.50. Source page 344 of the original specification
The agent invokes another application function to cause the same
effect.
The covered effectuation boundary continues to require valid finality
authority.
2.30.17 — Protected-State Rollback
An attacker restores a previous phase state.
Protected counters, epochs, fencing, or equivalent rollback-resistant
mechanisms prevent reactivation of consumed authority where
implemented.
2.30.18 — Duplicate Receipt Consumption
Two concurrent successor attempts use one single-use VAER.
Protected atomic consumption prevents unauthorized duplicate
continuation.
2.30.19 — Malicious Witness
A witness reports an effect that did not occur.
The IEV's assurance depends upon its qualification and the actual
independent evidence available.
2.30.20 — Witness Capability Misrepresentation
An authentic local dispatch record is submitted as proof of remote
completion.
The IEV refuses to elevate the supported evidentiary claim.
2.30.21 — Missing Acknowledgement
An actual external operation succeeds, but the acknowledgement is
lost.
The system preserves unresolved effect state pending appropriate
reconciliation.
2.30.22 — Premature Successor Command
Das Expires 29 April 2027 [Page 180]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The agent prepares a successor command before the required prior
receipt exists.
The sink refuses effectuation because the mandatory CCC remains
unavailable.
2.30.23 — Phase Skipping
The agent attempts to execute Phase 3 directly without the required
Phase 2 receipt.
The protected phase lineage and continuation state reject the
operation.
2.30.24 — Validator Replacement Attack
An attacker replaces an authorized validator with a permissive
process.
The successor sink refuses receipts lacking valid current enrollment
and authorization.
2.30.25 — Replay Across Devices
9.3.3.51. Source page 345 of the original specification
A receipt accepted for one device is reused on another.
The sink enforces device, domain, or operation-specific binding where
required.
2.30.26 — Receipt Delivery Interception
An attacker modifies the VAER while it travels to the successor sink.
Cryptographic authentication detects unauthorized modification.
2.30.27 — Receipt Delivery Suppression
An attacker prevents delivery of a required receipt.
The affected next phase remains withheld unless the sink retrieves
valid authoritative receipt state through an alternative protected
method.
2.30.28 — Split-Brain Protected State
Das Expires 29 April 2027 [Page 181]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Distributed controllers disagree about the current phase or
consumption state.
The system applies an authoritative state protocol, appropriate
fencing, or fail-closed handling.
2.30.29 — Unauthorized Recovery
An attacker uses a failure as a reason to perform a broader
corrective operation.
The recovery Candidate Act requires separate authorization.
2.30.30 — Monitored but Uncontrolled Effectuation
A validator detects a violation but cannot withhold the effect
because the operative resource remains directly accessible.
Such an implementation does not establish the claimed non-bypassable
causal gating until the required enforcement integration is provided.
2.31 — CRASH CONSISTENCY AND RECOVERY
2.31.1 — Crash Before First Effect
The governed initial effect remains withheld unless the required
protected authority was validly established.
2.31.2 — Crash After First Effect
The system retains an authenticated attempt reference.
The existence of an earlier actual effect is not negated by a local
crash.
2.31.3 — Crash Before Receipt Generation
9.3.3.52. Source page 346 of the original specification
The outcome remains unresolved until suitable evidence is obtained.
2.31.4 — Crash After Raw Receipt Generation
The PER may be recovered, subject to applicable validity checks.
No successor authority is presumed until IEV acceptance.
2.31.5 — Crash During IEV Validation
Das Expires 29 April 2027 [Page 182]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
An incomplete receipt-validation operation does not automatically
activate continuation.
2.31.6 — Crash After Validator Acceptance
A committed VAER may be recovered using protected identity and state
records.
The system prevents unauthorized duplicate authority issuance.
2.31.7 — Crash During Receipt Delivery
The successor sink may retrieve the authenticated receipt again from
the protected registry.
Receipt retransmission does not by itself authorize duplicate
effectuation.
2.31.8 — Crash After CCC Activation
The controller recovers the protected continuation state and verifies
whether the authority has been consumed.
2.31.9 — Crash During Successor Effectuation
The actual successor outcome is reconciled as an independent
consequential attempt.
2.31.10 — Validator Failure and Replacement
The failed IEV may be replaced through protected enrollment.
Existing accepted receipts are handled according to explicit validity
and revocation rules.
2.31.11 — Unknown External Outcome
The system preserves an ORF where the prior real effect may have
occurred but adequate evidence is unavailable.
2.31.12 — Recovery Candidate Act
A separately authorized corrective operation may be used where
permitted.
The recovery itself may produce new receipt-dependent phases.
2.32 — REFERENCE PROTOTYPE IMPLEMENTATION
Das Expires 29 April 2027 [Page 183]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.3.3.53. Source page 347 of the original specification
2.32.1 — Prototype Components
A non-limiting reference prototype may include:
1. An autonomous-agent test process;
2. A protected Candidate Act admission service;
3. A first controlled effectuation gateway;
4. A simulated or real bounded-effect resource;
5. A qualified effect-observation component;
6. A protected receipt service;
7. A cryptographically identified IEV;
8. A validator identity registry;
9. A protected receipt registry;
10. A protected continuation state service;
11. A successor Finality Sink;
12. A fault and bypass-injection harness.
2.32.2 — Validator Identity Setup
The prototype may generate a validator signing key pair.
The validator's public verification key is enrolled in the protected
registry.
The successor sink is configured to trust only the designated
validator identity for the relevant receipt type.
2.32.3 — First Real Effect
A controlled service performs a bounded write or other demonstrable
consequential action.
2.32.4 — Receipt Creation
Das Expires 29 April 2027 [Page 184]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
An observation component generates authenticated evidence of the
actual committed effect.
2.32.5 — Validator Acceptance
The IEV verifies the evidence and authenticates its acceptance.
2.32.6 — Causal Sink Control
The successor sink refuses all continuation attempts lacking the
correct accepted receipt.
2.32.7 — Test of Validator Impersonation
9.3.3.54. Source page 348 of the original specification
A second process generates a fake success record using a different
signing key.
The sink rejects the record.
2.32.8 — Test of Receipt Replay
The same receipt is submitted for a different successor operation.
The sink rejects the mismatch.
2.32.9 — Test of Agent-Level Check Removal
The ordinary application-level receipt check is disabled.
The protected Finality Sink continues to require the authorized VAER.
The successor operation remains unavailable until the required causal
condition is satisfied.
2.32.10 — Physical Reference Variant
The IEV may be placed in a physically separate protected device.
The successor effectuation controller is configured to require
receipts from its enrolled cryptographic identity.
The prototype verifies operation denial when the physical validator
is unavailable or unauthorized.
2.32.11 — Integrated Reference Variant
Das Expires 29 April 2027 [Page 185]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The IEV and Finality Sink may run within one protected service or
controller with separate validation and effectuation state.
The test verifies that the untrusted agent cannot directly activate
the protected continuation condition.
2.32.12 — Prototype Limitations
A software reference prototype can establish protocol behavior under
its defined trust model.
It does not independently prove resistance to a fully compromised
privileged operating system unless the necessary hardware or
independent protected enforcement controls are implemented.
2.33 — NON-LIMITING EXPERIMENTS
The following experiments are proposed and are not represented as
already performed.
Experiment 1 — Missing Validator Receipt. Attempt the next real
effect without the required VAER. Verify refusal.
Experiment 2 — Correct Validator Identity. Submit a valid receipt
from the enrolled IEV. Verify proper authentication and permitted
continuation.
9.3.3.55. Source page 349 of the original specification
Experiment 3 — Forged Validator Identity. Substitute the correct
VUID but authenticate using an unrelated key. Verify rejection.
Experiment 4 — Unregistered Validator. Present a cryptographically
valid receipt from an unregistered validator. Verify rejection.
Experiment 5 — Revoked Validator. Revoke an enrolled IEV and test
subsequent receipt acceptance. Verify rejection under the applicable
policy.
Experiment 6 — Validator Role Mismatch. Use an IEV authorized for
storage validation to approve an unrelated protected payment
operation. Verify rejection.
Experiment 7 — Physical Validator Removal. Disconnect a mandatory
external IEV. Verify that the successor effect cannot proceed.
Das Expires 29 April 2027 [Page 186]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Experiment 8 — Integrated Validator. Implement IEV and sink within
one protected controller. Verify enforcement of distinct protected
state roles.
Experiment 9 — Remote Validator. Deliver a valid identity-bound
receipt from a remote protected service. Verify the successor sink's
authentication procedure.
Experiment 10 — Wrong Predecessor Receipt. Submit a receipt from
another Candidate Act. Verify rejection.
Experiment 11 — Wrong Successor Receipt. Submit a receipt for
another intended operation. Verify rejection.
Experiment 12 — Receipt Replay. Attempt repeated use of a single-use
VAER. Verify protected consumption.
Experiment 13 — Receipt Modification. Change a receipt field after
signing. Verify authentication failure.
Experiment 14 — Phase Skipping. Attempt a later phase without the
required immediate predecessor state. Verify withholding.
Experiment 15 — Post-IEV Command Substitution. Replace a validated
command before actual effectuation. Verify rejection.
Experiment 16 — False Effect Observation. Submit unsupported success
evidence. Verify that the IEV does not accept it as proof of the
required actual effect.
Experiment 17 — Partial Effect. Produce only part of the authorized
first-phase result. Verify that continuation follows the specified
partial-effect policy rather than assuming full completion.
Experiment 18 — Unknown Outcome. Suppress an acknowledgement after
real effectuation. Verify protected uncertainty and safe retry
handling.
Experiment 19 — Cryptographic Key Dependency. Verify that the next-
phase cryptographic material is unavailable before receipt acceptance
and becomes usable only within the authorized scope afterward.
Experiment 20 — Hardware Latch Dependency. Verify that the next-
phase latch cannot be activated by the agent without the accepted
receipt-dependent transition.
Das Expires 29 April 2027 [Page 187]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.3.3.56. Source page 350 of the original specification
Experiment 21 — Alternate API. Attempt to perform the successor
effect through a different covered application interface. Verify the
same causal requirement.
Experiment 22 — Alternate Network Route. Test whether a physically
installed IEV can be bypassed through another network path. Identify
and close uncovered paths or explicitly classify the coverage
limitation.
Experiment 23 — Concurrent Consumption. Submit two successor
operations using one single-use receipt. Verify atomic consumption.
Experiment 24 — Protected Rollback. Restore an earlier state
snapshot after receipt consumption. Verify applicable anti-rollback
enforcement.
Experiment 25 — Validator Key Rotation. Rotate validator credentials
and verify current authorized receipt handling.
Experiment 26 — Cross-Device Continuation. Transfer a receipt across
devices and verify identity, phase, and operation binding.
Experiment 27 — Multi-Validator Quorum. Require two identified
validators and verify that one receipt cannot impersonate the other.
Experiment 28 — Recovery Candidate Act. Introduce an incorrect
earlier effect and verify independent recovery authorization.
Experiment 29 — Complete Causal Chain. Execute several real bounded
phases, each enabled by the accepted receipt from its required
predecessor.
Experiment 30 — Agent-Level Bypass Attempt. Remove or alter the
ordinary agent workflow's receipt-checking code. Verify that
protected sink enforcement still prevents unauthorized successor
effectuation.
2.34 — MEASURABLE TECHNICAL PROPERTIES
Relevant measurements may include:
• Unauthorized successor effectuation without valid VAER;
• Acceptance rate of forged validator identities;
• Acceptance rate of unauthorized validator roles;
Das Expires 29 April 2027 [Page 188]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
• Receipt replay acceptance;
• Receipt-to-successor mismatch rejection;
• Invalid phase-order acceptance;
• Protected key-release correctness;
• Hardware latch activation correctness;
• Validator replacement security;
9.3.3.57. Source page 351 of the original specification
• Protected revocation enforcement;
• Cross-device receipt authenticity;
• Concurrent consumption correctness;
• Alternate-route bypass rate;
• Actual-operation substitution rejection;
• Outcome observation assurance;
• Unknown-outcome handling;
• Crash-recovery integrity;
• Validation latency;
• Receipt verification throughput;
• Protected-state storage overhead;
• Power and processing costs;
• Safe autonomous task completion rate.
Testing should distinguish cryptographic authenticity, actual-effect
truthfulness, and the separate non-bypassability of the effectuation
path.
A valid signature alone does not demonstrate that the required
physical or remote effect occurred.
Das Expires 29 April 2027 [Page 189]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Likewise, successful outcome observation alone does not demonstrate
that the next Finality Sink enforces the receipt-dependent condition.
2.35 — DISTINCTION FROM CONVENTIONAL SYSTEMS AND INVENTIVE-STEP FOCUS
2.35.1 — Conventional Workflow Completion
A conventional workflow may check whether the previous software step
returned success.
The present principal implementation makes accepted actual-effect
evidence a required causal factor for creation or activation of
subsequent execution authority.
2.35.2 — Conventional Post-Hoc Monitoring
A post-hoc monitor may report that an operation occurred.
The present embodiment uses receipt evidence from an earlier bounded
real effect to control whether a later, not-yet-effective consequence
can become authorized.
2.35.3 — Conventional Signed Receipt
9.3.3.58. Source page 352 of the original specification
A signed receipt may authenticate a statement.
The present embodiment additionally requires acceptance by an
authorized cryptographically identified IEV and binding to the next
Finality Sink's mandatory continuation condition.
The mere presence of multiple signatures is not independently
asserted to be inventive.
2.35.4 — Conventional Security Validator
A conventional validator may output PASS or FAIL.
In the proposed stronger implementation, the identified validator
produces or commits an authenticated receipt acceptance that
participates directly in forming the next phase's necessary execution
condition.
2.35.5 — Conventional Staged Deployment
A conventional staged system may monitor an initial rollout and then
schedule broader deployment.
Das Expires 29 April 2027 [Page 190]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The present embodiment may withhold the broader phase's required
execution material until validated evidence of the bounded real
effect is accepted.
A conventional staged system that already enforces equivalent
receipt-dependent authority remains relevant prior art.
2.35.6 — Conventional Two-Phase Commit
Two-phase commit may coordinate transactional participants.
The present embodiment may instead use actual observed consequences
of one phase as the protected causal basis for authority to perform a
later phase, including across systems that cannot participate in one
atomic transaction.
2.35.7 — Conventional Distributed Saga
A saga may coordinate a sequence of local transactions and
compensation.
The proposed distinction concerns mandatory identity-bound receipt-
derived execution enablement and independently enforced successor
Finality Sink authority.
2.35.8 — Conventional Cryptographic Capabilities
Cryptographic capability systems can restrict authority.
The present embodiment may require the formation or release of the
next scoped capability to depend upon an accepted prior-real-effect
receipt.
The combination must be assessed against existing proof-dependent and
state-dependent capability mechanisms.
2.35.9 — Conventional Hardware Interlocks
Hardware interlocks are established techniques.
9.3.3.59. Source page 353 of the original specification
The proposed arrangement may additionally bind the interlock's
protected activation to an authenticated effect receipt accepted by a
specifically authorized cryptographic validator identity and to the
actual successor command.
The hardware interlock itself is not asserted to be newly invented.
Das Expires 29 April 2027 [Page 191]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
2.35.10 — Conventional Validator Attestation
A validator may possess a valid certificate or hardware attestation.
Such evidence does not establish that every statement made by the
validator is correct.
The embodiment requires specific actual-effect evidence, validation
scope, protected policy, and successor binding.
2.35.11 — Candidate Objective Technical Problem
An illustrative objective technical problem is:
How to prevent a protected autonomous computing system from making a
later consequential operation effective before a required earlier
bounded real effect has produced acceptable independently validated
evidence, while ensuring that the validating authority is
cryptographically identifiable and that the resulting receipt-
dependent continuation cannot be bypassed through alternate software,
hardware, or distributed execution paths within the claimed
enforcement domain.
2.35.12 — Candidate Technical Solution
A candidate solution includes:
First, a bounded real predecessor effectuation phase.
Second, a protected observation path supporting the required actual
outcome predicate.
Third, an authorized IEV possessing a cryptographically verifiable
identity.
Fourth, independent receipt validation against the predecessor
operation and protected state.
Fifth, generation or commitment of a validator-identity-bound
accepted receipt.
Sixth, authenticated receipt delivery or protected authoritative
availability at the successor Finality Sink.
Seventh, an execution-enabling condition whose valid establishment
depends upon that receipt.
Das Expires 29 April 2027 [Page 192]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Eighth, actual successor Finality Sink verification of the validator
identity, receipt, operation, authority, and protected consumption
state.
Ninth, withholding or reconciliation when a required condition cannot
be established.
2.35.13 — Candidate Technical Kernel
A causally ordered protected effectuation mechanism in which a first
bounded real effect generates qualified evidence, an independently
authorized and cryptographically identifiable
9.3.3.60. Source page 354 of the original specification
IEV accepts said evidence, the resulting validator-authenticated
receipt constitutes a necessary factor for establishing or activating
a successor-specific execution condition, and the actual next
Finality Sink verifies that receipt-derived condition before
releasing a second consequential effect, irrespective of whether the
validator and sink are physically separated, logically integrated, or
distributed across computing domains.
2.35.14 — Hindsight and Patentability Qualification
The novelty and inventive step of this proposed kernel must be
assessed against relevant prior disclosures concerning staged
execution, interlocks, cryptographic authorization, attestation,
transaction-state dependencies, proof-dependent capabilities, and
distributed workflow controls.
A broadly worded claim cannot prevent every possible design-around
merely by defining the validator to include all physical and software
implementations.
The claim must identify the essential enforceable relationships and
receive appropriate support from the application as filed.
The disclosed alternatives provide technical implementation breadth
but do not establish patentability by themselves.
2.36 — IMPLEMENTATION VARIATIONS
Variant 2.A — Physically Separate IEV: A standalone protected device
authenticates validation receipts for a successor sink.
Variant 2.B — Hardware-Integrated IEV: An IEV is integrated within a
protected processor or controller.
Das Expires 29 April 2027 [Page 193]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Variant 2.C — Sink-Integrated IEV: The same protected component
contains logically distinct validation and final effectuation
functions.
Variant 2.D — Remote IEV: An authenticated remote validator issues a
successor-bound receipt accepted by another domain.
Variant 2.E — Cross-Device IEV: Prior-effect evidence and validated
receipts cross device boundaries.
Variant 2.F — Multi-IEV Arrangement: Multiple individually
authenticated validators are required.
Variant 2.G — Threshold Validator Arrangement: A configured threshold
of authorized validator identities must accept the result.
Variant 2.H — Validator Role Separation: Different validator
identities govern different effect classes.
Variant 2.I — Identity-Bound PER: A PER directly includes the
appropriate validator acceptance authentication.
Variant 2.J — Separate PER and VAER: A qualified witness produces a
raw receipt and an IEV separately authenticates acceptance.
9.3.3.61. Source page 355 of the original specification
Variant 2.K — Protected Internal Receipt State: A physically
integrated controller maintains the accepted receipt without
exporting a standalone file.
Variant 2.L — Direct Receipt Transmission: The IEV sends an
authenticated VAER directly to the successor sink.
Variant 2.M — Protected Receipt Lookup: The successor sink retrieves
the VAER from an authoritative protected registry.
Variant 2.N — Cryptographic Key Derivation: Receipt acceptance is
required for generation of a successor-specific key.
Variant 2.O — Split-Key Authorization: The required next-phase key
depends upon an IEV-controlled component.
Variant 2.P — Threshold Signature: The next phase requires designated
protected signature shares.
Variant 2.Q — Hardware Latch: An accepted receipt activates a
protected actuator or effectuation latch.
Das Expires 29 April 2027 [Page 194]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Variant 2.R — Protected Register: Receipt acceptance advances a
protected phase register.
Variant 2.S — Transaction-State Dependency: A protected transaction
controller requires a receipt-dependent predecessor state.
Variant 2.T — Network Gateway Dependency: A controlled network sink
requires an identity-bound accepted receipt.
Variant 2.U — Storage Commit Dependency: A protected storage
controller withholds a successor commit until the required receipt
exists.
Variant 2.V — Credential-Release Dependency: A credential-enabling
primitive remains unavailable until accepted receipt validation.
Variant 2.W — Recipient-Side Data Release: An accepted receipt
enables scoped protected content release.
Variant 2.X — Local Qualified Witness: A protected local controller
observes the predecessor effect.
Variant 2.Y — Remote Qualified Witness: A remote service or observer
provides authenticated effect evidence.
Variant 2.Z — Multiple Witnesses: Several qualified observers provide
evidence under a defined assurance model.
Variant 2.AA — Single-Use Receipt: A VAER enables one specifically
authorized successor effect.
Variant 2.AB — Bounded Multi-Use Receipt: A VAER permits a strictly
defined set of successor operations subject to protected counters and
scope.
9.3.3.62. Source page 356 of the original specification
Variant 2.AC — Receipt-Dependent Branching: Different supported
actual outcomes enable different preauthorized successor branches.
Variant 2.AD — Partial-Effect Continuation: A qualified partial
outcome permits only a specifically authorized reduced next phase.
Variant 2.AE — Unknown-Outcome Fence: Unresolved effect state
prevents unsafe continuation.
Variant 2.AF — Validator Key Rotation: The IEV's cryptographic
credentials may be updated through protected identity management.
Das Expires 29 April 2027 [Page 195]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Variant 2.AG — Validator Replacement: A failed IEV may be replaced
through authenticated enrollment.
Variant 2.AH — Validator Revocation: Compromised or unauthorized
validator credentials are rejected.
Variant 2.AI — Firmware IEV: The IEV operates within protected
firmware.
Variant 2.AJ — Operating-System IEV: The IEV operates as a protected
operating-system service.
Variant 2.AK — Isolated Software IEV: An IEV operates within an
isolated protected software environment.
Variant 2.AL — Hardware Security Module IEV: Cryptographic identity
and receipt authentication are supported by a protected cryptographic
module.
Variant 2.AM — Physically Added Controller: An IEV is added as an
external control module with mandatory sink-side verification.
Variant 2.AN — Fully Integrated Protected Controller: All functions
reside within one protected controller while retaining identity-bound
causal state.
Variant 2.AO — In-Line Pre-Effect IEV: An identified IEV validates
the actual pending operation before its principal consequence.
Variant 2.AP — Inter-Phase Causal IEV: An identified IEV accepts
actual-effect receipts and establishes the next-phase enablement
condition.
Variant 2.AQ — Combined IEV Modes: Both pre-effect validation and
receipt-gated inter-phase validation are employed.
Variant 2.AR — Separately Authorized Recovery: A corrective operation
is represented by an independently validated Candidate Act.
Variant 2.AS — Protected Cross-Domain Receipt Chain: Accepted
receipts and phase lineage are authenticated across independent
domains.
Variant 2.AT — Effectuation-Coverage Verification: The implementation
verifies which actual command or resource interfaces enforce the
required receipt-dependent condition.
Das Expires 29 April 2027 [Page 196]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
These alternatives may be used separately or in technically
compatible combinations.
9.3.3.63. Source page 357 of the original specification
2.37 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
The present disclosure provides technical support for considering an
independent system claim directed to a protected causally ordered
effectuation architecture comprising:
A first controlled effectuation component configured to perform an
authorized bounded real consequential operation;
An observation component configured to obtain evidence concerning the
actual effect;
An Interim Effectuation Validator having a cryptographically
verifiable identity and an authenticated authorization to validate a
defined class of effect evidence;
A protected receipt-validation mechanism configured to bind accepted
evidence to the validator identity and the earlier consequential
operation;
A receipt-dependent continuation mechanism configured to establish a
necessary execution-enabling condition for a successor consequential
operation only upon successful acceptance of the required evidence;
And a successor Finality Sink configured to verify the validator-
authenticated receipt or authoritative accepted receipt state against
the actual pending successor operation before permitting the
successor consequence.
The claim may further require protected phase ordering, scope
binding, current authority verification, and protected consumption.
A corresponding independent method claim may recite the causal
sequence of earlier real effectuation, qualified effect observation,
identity-bound IEV receipt acceptance, establishment of the missing
continuation condition, and actual successor Finality Sink
verification.
A separate independent claim may focus upon cryptographic receipt-
dependent authority generation.
Another may focus upon non-cryptographic protected causal state
transitions with cryptographically authenticated validator identity.
Das Expires 29 April 2027 [Page 197]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A further independent claim may focus upon physical, integrated, or
distributed validation topology where the common receipt-to-sink
enforcement relationship is expressly required.
The precise independent-claim structure depends upon the relevant
filing's support, unity requirements, and applicable prior art.
2.38 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
The following are non-limiting possible dependent limitations.
Dependent limitation 1: Validator identity comprises an enrolled
unique identifier and associated cryptographic verification
credentials.
9.3.3.64. Source page 358 of the original specification
Dependent limitation 2: Validator identity is qualified by authorized
validation role and effect class.
Dependent limitation 3: The sink verifies proof of validator
cryptographic authorization.
Dependent limitation 4: The receipt authenticates the validator that
accepted the effect evidence.
Dependent limitation 5: The receipt binds a predecessor Candidate Act
and actual effectuation attempt.
Dependent limitation 6: The receipt binds a successor Candidate Act.
Dependent limitation 7: The receipt binds a designated successor
Finality Sink.
Dependent limitation 8: The receipt contains or references qualified
actual-effect evidence.
Dependent limitation 9: The successor sink rejects receipts from
unregistered validators.
Dependent limitation 10: The successor sink rejects receipts from
revoked validator identities.
Dependent limitation 11: The next-phase execution condition is
cryptographically derived from an accepted receipt and protected
secret.
Das Expires 29 April 2027 [Page 198]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Dependent limitation 12: The next phase requires a missing IEV-
controlled key share.
Dependent limitation 13: The next phase requires a threshold
signature incorporating authorized validator participation.
Dependent limitation 14: The next phase is controlled through a
receipt-dependent protected hardware latch.
Dependent limitation 15: The next phase is controlled through a
protected phase register.
Dependent limitation 16: The next phase is controlled through an
atomic transaction-state transition.
Dependent limitation 17: The IEV and sink reside in one physically
integrated protected component.
Dependent limitation 18: The IEV is physically separate from the
successor sink.
Dependent limitation 19: The IEV is remotely located and transmits an
authenticated VAER to the sink.
Dependent limitation 20: The sink retrieves the receipt through an
authenticated protected registry.
Dependent limitation 21: The system employs multiple
cryptographically identified IEVs.
Dependent limitation 22: The system validates a threshold of
individually authorized IEV receipts.
Dependent limitation 23: The first real effect is bounded by
resource, privilege, destination, operation class, time, or quantity.
Dependent limitation 24: The successor phase remains disabled until
the receipt-dependent CCC is satisfied.
9.3.3.65. Source page 359 of the original specification
Dependent limitation 25: The successor sink independently
reconstructs the actual pending operation.
Dependent limitation 26: The sink atomically consumes single-use
receipt-derived authority.
Dependent limitation 27: The system prevents phase skipping.
Das Expires 29 April 2027 [Page 199]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Dependent limitation 28: The system prevents receipt replay across
workflows.
Dependent limitation 29: The system enforces validator key rotation
and identity-generation validity.
Dependent limitation 30: The system employs a protected validator-
replacement procedure.
Dependent limitation 31: The system preserves unknown-outcome state.
Dependent limitation 32: The system prohibits unsafe duplicate
effects following missing acknowledgements.
Dependent limitation 33: The IEV validates bounded physical actuator-
state evidence.
Dependent limitation 34: The IEV validates an authenticated remote
storage outcome.
Dependent limitation 35: The IEV validates a defined financial
transaction state.
Dependent limitation 36: The IEV validates a bounded network effect
before broader release.
Dependent limitation 37: The system supports cross-device receipt-
dependent continuation.
Dependent limitation 38: The system supports cross-domain
authenticated phase lineage.
Dependent limitation 39: The system incorporates an optional in-line
actual-operation validator.
Dependent limitation 40: The system additionally applies protected
effect-conflict reservations under Embodiment 1.
These potential limitations are illustrative and do not establish
novelty merely by inclusion.
2.39 — RELATIONSHIP TO EMBODIMENT 1 AND COMMON WORKFLOW CW-3
Embodiment 1 addresses protected compatibility among consequential
operations performed by separately authorized agents.
Embodiment 2 addresses protected causal continuation among real
consequential phases.
Das Expires 29 April 2027 [Page 200]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A system may require both an acceptable receipt-dependent
continuation state and a valid cross-operation conflict reservation
before releasing a successor effect.
A valid IEV receipt does not override an incompatible protected
conflict reservation.
A valid conflict reservation does not generate the actual-effect
evidence required for receipt-gated continuation.
9.3.3.66. Source page 360 of the original specification
CW-3 may additionally evaluate whether the proposed successor
operation remains within the originally authorized task scope.
Where a change requires valid user reauthorization, the new
authorization may modify the permissible successor scope.
However, a valid human approval does not automatically satisfy the
prior-real-effect receipt requirement where that requirement is
mandatory.
The Finality Sink may therefore verify the combined applicable
predicates:
PERMIT_SUCCESSOR_EFFECT = VALID_CURRENT_AUTHORITY AND
VALID_EFFECT_RESERVATION_IF_REQUIRED AND
VALID_AUTHORIZED_IEV_IDENTITY AND
VALID_VALIDATOR_ACCEPTED_EFFECT_RECEIPT AND
VALID_RECEIPT_CAUSAL_LINEAGE AND VALID_RECEIPT_DEPENDENT_CONTINUATION
AND VALID_ACTUAL_SUCCESSOR_OPERATION AND
VALID_PROTECTED_CONSUMPTION_STATE AND
VALID_SCOPE_REAUTHORIZATION_IF_REQUIRED The predicate combination is
illustrative.
Optional predicates apply only where the selected implementation
requires them.
2.40 — INDUSTRIAL APPLICABILITY
2.40.1 — Autonomous AI Assistants
An AI assistant may perform bounded real operations and require
identity-bound receipt acceptance before conducting broader data
exports, payments, communications, or privileged device operations.
2.40.2 — Enterprise Automation
Das Expires 29 April 2027 [Page 201]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Enterprise agents may require verified prior storage, transaction, or
configuration outcomes before performing dependent consequential
operations.
2.40.3 — Financial Processing
An IEV may validate a defined actual transaction state and produce a
receipt that is mandatory for a separately authorized accounting or
settlement-dependent phase.
2.40.4 — Telecommunications
A protected network controller may require receipt evidence from a
bounded real configuration change before enabling a broader network
control-plane operation.
2.40.5 — Cloud Infrastructure
An autonomous controller may perform an initial bounded deployment
and use an identity-bound accepted effect receipt to establish
authority for a broader rollout.
9.3.3.67. Source page 361 of the original specification
2.40.6 — Industrial Robotics
A cryptographically identified IEV may validate actual measured
actuator state and activate the protected hardware condition required
for the next bounded movement.
2.40.7 — Connected Devices
An IEV may be physically added as a protected device-security module
or implemented within the existing controller.
The next hardware effect remains governed by authenticated receipt-
dependent state.
2.40.8 — Secure Storage
A storage controller may produce an actual commit receipt that is
accepted by an IEV.
The accepted receipt becomes a prerequisite for subsequent protected
release, export, publication, or deletion.
2.40.9 — Secure Communications
Das Expires 29 April 2027 [Page 202]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A recipient-side bounded real-effect receipt may become a necessary
factor in enabling later data transmission or decryption.
2.40.10 — Cross-Device Workflows
Authenticated receipts may cross device or administrative boundaries
while remaining bound to enrolled validators, designated sinks, and
permitted successor operations.
2.40.11 — Autonomous Software Deployment
A real test deployment may generate an effect receipt required to
activate broader deployment authority.
2.40.12 — Hardware Security Systems
An IEV may be implemented through protected hardware state, secure
processors, firmware, or dedicated validation devices.
Cryptographic validator identity and protected receipt enforcement
may operate alongside non-cryptographic effectuation controls.
2.40.13 — Practical Industrial Feasibility
The architecture may be implemented with existing classes of
cryptographic primitives, authenticated communications, protected
transaction state, secure hardware interfaces, and mandatory
effectuation controllers.
The particular technical contribution depends upon how these
components establish and enforce the receipt-derived causal
relationship.
The architecture does not require every deployment to use physically
distinct validation devices.
9.3.3.68. Source page 362 of the original specification
It does require that, within its asserted enforcement boundary, the
requesting agent cannot bypass the receipt-dependent continuation
condition.
2.41 — FINAL NON-LIMITING TECHNICAL SUMMARY
The present embodiment discloses a protected causal execution-
finality architecture governing one or more consequential phases
performed by autonomous computational entities.
Das Expires 29 April 2027 [Page 203]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
An earlier bounded real effect is authorized through a designated
Finality Sink.
A qualified observation component obtains evidence concerning that
actual effect.
A Protected Effect Receipt is generated or committed.
An independently authorized Interim Effectuation Validator,
possessing a cryptographically verifiable identity, evaluates the
receipt against the original Candidate Act, actual effect, phase
identity, observation assurance, current protected state, and
applicable successor authority.
Successful validation produces or commits a validator-identity-bound
accepted receipt.
The accepted receipt is provided to, made retrievable by, or
represented through protected authoritative state verified by the
successor Finality Sink.
The successor sink verifies the authorized validator identity,
cryptographic authentication, receipt correspondence, protected
causal ordering, actual pending successor operation, and applicable
current authority.
The accepted receipt constitutes a necessary factor for establishing
or activating the successor's required execution condition.
The condition may be implemented through cryptographic key
derivation, split-key authorization, threshold signing, scoped non-
bearer capability formation, a protected hardware latch, secure
register, transaction-state activation, protected command queue, or
another enforced effectuation mechanism.
The IEV may be physically added as an external security component.
It may be integrated within the Finality Sink.
It may operate within an isolated processor.
It may be hosted by a remote protected service.
Multiple validators may participate.
All required validation, receipt, and effectuation functions may
reside within a single protected component.
Das Expires 29 April 2027 [Page 204]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The invention is not limited by the number or physical placement of
those components.
The common required technical property is that the controlled
successor consequence cannot be effected without the applicable
validated real-effect receipt-dependent authority or protected
enablement condition.
9.3.3.69. Source page 363 of the original specification
The receipt is not merely an audit record.
The validator is not merely an advisory monitor.
The cryptographic validator identity is not merely a decorative
identifier.
The Finality Sink is not permitted to accept a generic success
message in substitution for required validated evidence.
An untrusted agent cannot create an acceptable validation result
merely by claiming success, copying a validator identifier, invoking
another covered software interface, or replaying a receipt from
another operation.
Where required evidence remains unknown, partial, mismatched, or
invalid, the system preserves the corresponding protected state and
withholds unsafe continuation.
Where a later corrective effect is required, that effect is
separately authorized.
The disclosed architecture may therefore preserve enforced causal
ordering among real consequential operations, with independently
authenticated validator identity and protected receipt-to-sink
continuity across integrated or distributed systems.
The principal proposed technical contribution is an identity-
authenticated, receipt-constituted, causally ordered execution
mechanism in which independently validated evidence of an earlier
real effect becomes a necessary and enforceable factor for creating,
activating, or exercising authority over the next consequential
effect.
The novelty and inventive step of any particular claimed
implementation remain subject to comparison with the relevant prior
art and the specific limitations supported by the application as
filed.
Das Expires 29 April 2027 [Page 205]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
END OF EMBODIMENT 2 — TECHNICAL DISCLOSURE.
SUPPLEMENTARY TECHNICAL DISCLOSURE FOR EMBODIMENTS 1 AND 2
DISTINCTIONS FROM CONVENTIONAL SYSTEMS, PROPOSED INVENTIVE-STEP
CONTRIBUTIONS, OBJECTIVE TECHNICAL PROBLEMS, TECHNICAL ADVANTAGES,
AND INDUSTRIAL APPLICABILITY
S.0 — GENERAL INTRODUCTION AND INCORPORATION
9.4. Supplementary Disclosure for Embodiment 2: Non-Replayable Receipt-
Gated Phase Activation
Original global source page range: 378-406 inclusive, original
uploaded PDF segment: TECHNICAL SPECIFICATION -1-554.pdf. Primary in
this part: True. Page-extract fidelity limitations and independent
filing-priority analysis are stated in the source note.
9.4.1. Architecture and Protected Trust-Relationship Diagram
[Earlier bounded ACTUAL operation]
|
[Qualified protected evidence]
|
[Cryptographic IEV identity/independence]
|
[Accepted effect predicate]
|
[VAER-dependent necessary execution input]
/ | \
[Missing key] [State latch] [Gateway permit]
\ | /
[Successor Finality Sink]
|
[Exact target, phase, freshness and consume]
Figure 20: Supplementary Disclosure for Embodiment 2: Non-
Replayable Receipt- Gated Phase Activation — architecture and
protected dependencies
9.4.2. Operational Decision Flowchart and Refusal Conditions
Das Expires 29 April 2027 [Page 206]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
[Earlier real effect qualifies?]
|
<IEV supported by qualified evidence?>--NO-->[WITHHOLD]
|YES
[Create VAER + successor required condition]
|
<Any agent-only success assertion?>--YES-->[IGNORE]
|NO
<Fresh, phase/sink-bound CCC?>--NO-->[WITHHOLD]
|YES
<Sink actual effect within new grant?>--NO-->[REFUSE]
|YES
[Consume required authority; effect]
Figure 21: Supplementary Disclosure for Embodiment 2: Non-
Replayable Receipt- Gated Phase Activation — decision flowchart
9.4.3. Original Source Page-Indexed Technical Content
9.4.3.1. Source page 378 of the original specification
Multiple device agents may modify protected device settings, network
permissions, files, or hardware operating states.
A protected conflict-governance component may prevent incompatible
concurrent effects while permitting unrelated authorized operations.
S.1.5.10 — Industrial Implementation Requirements
A practical implementation may require:
1. Verified operation descriptors;
2. Authenticated resource or effect-domain identity;
3. A protected conflict-state store;
4. Atomic reservation-management procedures;
5. Suitable cross-domain coordination where required;
6. Protected authority binding;
7. Finality Sink enforcement;
8. Appropriate consequence-state observation;
9. Crash-consistent reservation recovery;
Das Expires 29 April 2027 [Page 207]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
10. Defined handling of unsupported or nonparticipating effectuation
paths.
The mechanism may be realized in software, firmware, protected
hardware, distributed computing infrastructure, or suitable
combinations thereof.
The industrial usefulness arises from controlling conflicting
consequences of independently authorized computational operations,
not merely from generating an advisory schedule.
SUPPLEMENTARY TECHNICAL DISCLOSURE FOR EMBODIMENT 2
CAUSALLY ORDERED RECEIPT-GATED INTERIM EFFECTUATION VALIDATION,
RECEIPT-CONSTITUTED CONTINUATION AUTHORITY, AND CRYPTOGRAPHIC OR NON-
CRYPTOGRAPHIC DEPENDENCY OF SUBSEQUENT REAL EFFECTS
S.2.R.0 — FUNDAMENTAL TECHNICAL CLARIFICATION
The Interim Effectuation Validator disclosed in Embodiment 2 is not
limited to a conventional component that checks a receipt, records a
successful result, and permits an independently executable workflow
to continue.
In a principal implementation of Embodiment 2, the IEV participates
in a protected causal execution chain in which a later consequential
operation is technically dependent upon protected evidence generated
from an earlier real effectuation phase.
9.4.3.2. Source page 379 of the original specification
The evidence, once independently validated under the applicable
protected protocol, constitutes the necessary enabling basis for the
next consequential phase.
More particularly, a first consequential operation is permitted under
bounded authority.
The operation produces a real effect, not merely a prediction,
simulation, dry run, or computational assessment.
A protected observer, controller, recipient, or other qualified
evidence source produces a receipt representing the observed result
of the first effect.
Das Expires 29 April 2027 [Page 208]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The IEV independently validates that receipt against the applicable
Candidate Act, expected effect, actual observed effect, phase
identity, protected authority, designated Finality Sink, freshness,
and current state.
Successful validation causes a protected continuation condition to be
created, activated, derived, released, unsealed, or otherwise
established.
That continuation condition comprises or controls a technical
prerequisite without which the subsequent consequential operation
cannot become effective through the controlled execution
architecture.
Accordingly, the IEV does not merely advise another controller that
continuation would be desirable.
The IEV-controlled receipt dependency is incorporated into the
mechanism that makes continuation technically possible.
S.2.R.0.1 — Core Causal Relationship
A representative sequence is:
Candidate Act | v Protected Authorization | v Finality Sink FS[0] | v
REAL BOUNDED EFFECT P[0] | v PROTECTED EFFECT RECEIPT R[0] | v
INDEPENDENT IEV VALIDATION | v RECEIPT-DEPENDENT CONTINUATION
CONDITION | v
9.4.3.3. Source page 380 of the original specification
FINALITY SINK FS[1] | v NEXT REAL CONSEQUENTIAL EFFECT P[1] The
sequence may continue:
P[0] -> R[0] -> IEV[0] -> Gamma[1] -> FS[1] -> P[1]
P[1] -> R[1] -> IEV[1] -> Gamma[2] -> FS[2] -> P[2]
P[n-1] -> R[n-1] -> IEV[n-1] -> Gamma[n] -> FS[n] -> P[n] Here, Gamma
represents a protected continuation condition or execution-enabling
material associated with the next phase.
The distinguishing relationship is:
The next effectuation phase is not independently executable before
the required preceding receipt has been generated or obtained,
independently validated, and incorporated into the protected
continuation condition.
Das Expires 29 April 2027 [Page 209]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
This requirement may be implemented cryptographically or non-
cryptographically.
S.2.R.0.2 — Receipt as a Necessary Enabling Factor
For purposes of this embodiment, the receipt is not confined to being
an evidentiary record used for later audit or reporting.
The receipt is a necessary causal input to establishing the authority
or missing execution condition required for subsequent effectuation.
The validated receipt may itself be represented by an authenticated
protected continuation object, or may cause protected state to enter
a condition that enables the next operation.
A discrete transferable receipt object is not mandatory in every
implementation.
The receipt may exist as protected controller state, an authenticated
transaction record, a hardware completion event, a sealed message, a
cryptographically committed observation, or another machine-
verifiable representation.
The essential technical relationship is that the next consequential
operation cannot obtain or exercise the required effectuation
enablement independently of the accepted prior-effect evidence.
S.2.R.0.3 — Raw Receipt Versus Validated Receipt
A distinction is maintained between:
Raw or unvalidated receipt evidence, which may be authentic but
mismatched, stale, incomplete, replayed, or insufficient; and
Accepted protected receipt state, which represents evidence that has
passed the applicable IEV predicates and has been committed into the
required continuation mechanism.
9.4.3.4. Source page 381 of the original specification
The former does not automatically grant authority.
The latter may constitute the protected causal source of the next
phase's execution-enabling condition.
This arrangement preserves both receipt-dependent progression and
scoped non-bearer authority.
Das Expires 29 April 2027 [Page 210]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
S.2.R.0.4 — No Prior Completion, No Next-Phase Enablement
In one implementation:
If required R[i] is absent:
Gamma[i+1] is unavailable.
If R[i] is invalid:
Gamma[i+1] is unavailable.
If R[i] is stale:
Gamma[i+1] is unavailable.
If R[i] does not match the actual prior effect:
Gamma[i+1] is unavailable.
If R[i] has already been consumed:
Gamma[i+1] is unavailable for a new unauthorized single-use
progression.
If IEV validation fails:
Gamma[i+1] is unavailable.
If protected policy or revocation conditions fail:
Gamma[i+1] is unavailable. The system may therefore enforce not
merely a logical decision to wait, but a protected technical
dependency that prevents the next effect from becoming effective
before the required causal predecessor condition exists.
S.2.R.1 — CAUSAL ORDERING RATHER THAN POST-HOC VERIFICATION
S.2.R.1.1 — Conventional Post-Hoc Monitoring
A conventional monitoring component may observe an operation after
completion.
It may generate a report indicating whether the operation succeeded,
failed, or produced an anomaly.
Das Expires 29 April 2027 [Page 211]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.4.3.5. Source page 382 of the original specification
The report may support auditing, debugging, compliance, or later
decision-making.
However, the full consequential operation may already have occurred
before the monitoring result becomes available.
Such monitoring cannot retroactively prevent the completed effect.
S.2.R.1.2 — Receipt-Gated Causal Execution
In the principal disclosed arrangement, the originally requested full
consequence is divided into bounded real phases where the applicable
operation permits such division.
The system initially permits only a restricted, independently
authorized portion of the consequential operation.
A valid receipt from the actual bounded effect is required before the
remaining or broader consequence can be enabled.
For example, a system may permit a limited deployment to a defined
subset of devices.
The devices actually receive or execute the bounded deployment
operation.
The system obtains protected evidence concerning the actual result.
The IEV evaluates that evidence.
Only then can the protected execution material for a broader
deployment become available.
The receipt therefore influences whether the remaining real-world
consequence can occur.
The architecture is not merely observing the complete operation after
it has finished.
S.2.R.1.3 — Causal Ordering Property
Let P[i] represent a bounded real effectuation phase.
Let R[i] represent protected evidence produced as a consequence of
that phase.
Das Expires 29 April 2027 [Page 212]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Let IEV[i] represent independent validation of that evidence.
Let Gamma[i+1] represent the protected continuation condition
required for the next phase.
The required ordering is:
P[i] precedes R[i].
R[i] supplies required evidence to IEV[i].
Successful IEV[i] validation precedes establishment of Gamma[i+1].
Valid Gamma[i+1] precedes effectuation of P[i+1].
9.4.3.6. Source page 383 of the original specification
This ordering may be enforced using protected sequence identifiers,
state-machine transitions, transaction dependencies, monotonic
counters, authenticated event chains, hardware registers, or
cryptographic dependency constructions.
A globally synchronized wall clock is not required.
The system need only establish the relevant causal dependency
relationships for the protected phases.
S.2.R.1.4 — Causal Enablement Is Not Merely Chronological Ordering
The mechanism does not merely require Phase 1 to be scheduled after
Phase 0.
It requires the technical capability to effectuate Phase 1 to depend
upon accepted evidence produced by Phase 0.
A scheduler may arrange two operations in chronological order while
leaving both operations independently executable.
The disclosed stronger implementation withholds a necessary technical
condition for the later operation until the protected causal
predecessor requirement is satisfied.
That distinction is central.
S.2.R.1.5 — Bounded Real Effect Rather Than Simulation
The initial phase may be a real but limited external effect.
Das Expires 29 April 2027 [Page 213]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Examples include:
A bounded actuator movement.
A limited network transmission.
A controlled transaction authorization.
A small permitted deployment.
A limited storage mutation.
A bounded recipient interaction.
A restricted credential operation.
A controlled device-state change.
The required property is that the relevant observation describes an
actual permitted effect within the applicable consequential domain.
The initial phase need not be numerically smaller in every
implementation.
It may instead be bounded by resource, destination, privilege,
functionality, recipient population, time, operation class, or
another consequential dimension.
9.4.3.7. Source page 384 of the original specification
A simulation may be used as additional evidence but does not
substitute for a required real-effect receipt.
S.2.R.2 — RECEIPT-CONSTITUTED AUTHORITY
S.2.R.2.1 — Necessary Receipt Dependency
In a principal implementation, the later operation lacks one or more
required execution-enabling conditions before receipt validation.
The missing condition may comprise:
A cryptographic key.
A key share.
A protected command authenticator.
Das Expires 29 April 2027 [Page 214]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A scoped execution handle.
A hardware latch state.
A protected register value.
A transaction-state commitment.
A secure mailbox record.
A controller-local continuation state.
A network release condition.
A credential-activation condition.
A storage-commit enablement.
A protected actuator-release value.
A destination-side acceptance condition.
The missing condition may be generated, derived, activated, released,
or made valid only as a consequence of successful receipt validation.
S.2.R.2.2 — Constitutive Rather Than Descriptive Function
In a descriptive receipt system, the receipt states that something
occurred.
In the present receipt-gated embodiment, the accepted receipt
additionally participates in establishing the technical authority
required for the next effect.
Thus, the receipt has a constitutive role in the protected
continuation process.
9.4.3.8. Source page 385 of the original specification
Its validated existence changes what the protected execution system
is capable of authorizing or effectuating.
The relevant state transition is not performed merely because a
monitor displays a success message.
It is performed because the protected authority component accepts
operation-specific prior-effect evidence satisfying the required
predicates.
Das Expires 29 April 2027 [Page 215]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
S.2.R.2.3 — Non-Bearer Character
The receipt need not be a bearer token.
The agent may obtain or transport a copy of the receipt without
possessing unrestricted authority to perform the next act.
The next effect may additionally require matching:
• Candidate Act;
• Phase number;
• Designated Finality Sink;
• Actual pending operation;
• Device or execution-domain identity;
• Destination;
• Authority epoch;
• Protected state;
• Single-use consumption reference.
Accordingly, mere possession of a receipt by an untrusted agent does
not necessarily make the next effect possible.
The protected system must establish the required receipt-derived
continuation condition for the specifically authorized next
operation.
S.2.R.2.4 — Receipt and Missing Execution Material
The disclosed architecture may be expressed as:
Validated R[i] | v Establish Gamma[i+1] | v Required execution
material becomes available | v
9.4.3.9. Source page 386 of the original specification
FS[i+1] verifies the actual operation | v P[i+1] becomes effective If
the required receipt is unavailable or fails validation, the
corresponding execution material remains inaccessible or invalid.
Das Expires 29 April 2027 [Page 216]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
This is stronger than a workflow that checks a receipt but leaves the
underlying effectuation authority independently usable.
S.2.R.3 — CRYPTOGRAPHIC CAUSAL DEPENDENCY
S.2.R.3.1 — General Principle
In a cryptographic implementation, the next consequential phase
depends upon cryptographic material that is unavailable before the
required prior-effect receipt passes protected validation.
The execution material may include a decryption key, transaction
authenticator, signing capability, threshold signature share, scoped
command key, or another cryptographic element required for
effectuation.
S.2.R.3.2 — Receipt-Dependent Key Construction
One illustrative construction is:
K[i+1] = KDF( K_IEV_ROOT, CandidateActDigest, H(AcceptedReceipt[i]),
PhaseNumber[i+1], FinalitySinkID[i+1], ProtectedCounter[i+1] ) Here,
K_IEV_ROOT is controlled by the protected IEV or an appropriately
protected key service.
AcceptedReceipt[i] represents the receipt accepted under the required
IEV predicates.
The inclusion of the receipt commitment, Candidate Act, phase, sink,
and counter binds the derived material to the intended causal history
and successor operation.
A secure implementation must not expose the protected derivation
secret or provide an unrestricted derivation oracle to the untrusted
agent.
The mere inclusion of a publicly readable receipt digest in a
publicly computable function would not, by itself, prevent
unauthorized key derivation.
The protected key service must enforce successful receipt validation
before releasing or using the derived execution material.
S.2.R.3.3 — Cryptographic Incompleteness
Before valid receipt acceptance, the next-phase cryptographic
material may remain:
Das Expires 29 April 2027 [Page 217]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.4.3.10. Source page 387 of the original specification
• Unconstructed;
• Sealed;
• Incomplete;
• Withheld;
• Encrypted;
• Unavailable to the effectuation controller;
• Unusable for the required authenticated operation.
The next phase is not merely discouraged.
Its required cryptographic operation cannot complete through the
protected controlled path.
S.2.R.3.4 — Split-Key Implementation
In another implementation, a successor operation requires two or more
protected key components.
For example:
K_FINAL[i+1] = COMBINE( K_SINK[i+1], K_IEV[i+1] ) The Finality Sink
controls one component.
The IEV controls another component.
The IEV-controlled component is made available only after successful
receipt validation.
The combined cryptographic material is required to authenticate,
decrypt, sign, or otherwise enable the next consequential operation.
The effectuation sink cannot successfully complete the required
cryptographic procedure using its component alone.
S.2.R.3.5 — Threshold Construction
A further implementation may employ a threshold signature or
threshold key-release protocol.
Das Expires 29 April 2027 [Page 218]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
One or more required protected shares are generated or released only
after successful IEV validation.
The resulting operation-specific cryptographic authorization cannot
be completed without the required shares.
S.2.R.3.6 — Recipient-Side Decryption
A destination device may receive encrypted data while remaining
unable to make that data usable.
9.4.3.11. Source page 388 of the original specification
A bounded first phase may establish that the intended recipient or
protected device can receive and process an approved test object.
The qualified recipient produces protected evidence of the actual
test effect.
The IEV validates the receipt.
Only then is the required decryption material for the authorized
subsequent data release made available.
The recipient's protected controller verifies the applicable
operation and authority binding.
In this implementation, receipt-dependent cryptographic material
controls the consequential usability or release of the protected
content.
S.2.R.3.7 — Cryptographic Enforcement Limitation
The cryptographic mechanism protects the consequential operation only
where the corresponding encryption, signing, authentication, or key-
release process is actually necessary to produce the governed effect.
If an alternative effectuation path can bypass that requirement, the
claimed non-bypassability property is not established.
The relevant alternate paths must therefore be covered by equivalent
protected conditions.
S.2.R.4 — NON-CRYPTOGRAPHIC CAUSAL DEPENDENCY
S.2.R.4.1 — General Principle
Das Expires 29 April 2027 [Page 219]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The receipt-gated architecture does not require cryptographic key
derivation in every implementation.
A protected causal dependency may be established through enforced
state transitions, hardware control, transactional authority, command
scheduling, or other technical mechanisms.
The essential requirement is that the next consequential operation
cannot proceed through the controlled execution path unless the
required receipt-dependent state has been validly established.
S.2.R.4.2 — Protected State-Machine Implementation
In one implementation, the IEV controls protected continuation state.
Before receipt validation:
ContinuationState[i+1] = NOT_ENABLED Following valid receipt
acceptance:
ContinuationState[i+1] = ENABLED The Finality Sink requires the
protected state to be ENABLED before permitting the next operation.
The requesting agent cannot independently change the state.
9.4.3.12. Source page 389 of the original specification
S.2.R.4.3 — Atomic State Transition
The IEV may perform an atomic protected state transaction that:
1. Verifies the accepted prior-effect receipt;
2. Confirms the relevant phase identity;
3. Confirms that the receipt has not already been consumed;
4. Verifies current authority and protected policy;
5. Advances the protected phase counter;
6. Marks the receipt consumed where required;
7. Activates the specifically bound continuation condition;
8. Commits the resulting protected state.
Das Expires 29 April 2027 [Page 220]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Where atomic commitment fails, the next phase remains disabled or
enters a protected recoverable state.
S.2.R.4.4 — Hardware Latch Implementation
In another implementation, a protected hardware controller maintains
an effectuation latch.
The latch remains disabled before valid IEV receipt acceptance.
The IEV or protected state controller activates the latch for the
specified operation only when the required causal predicates pass.
The final hardware controller may additionally verify the current
operation parameters and permitted operating envelope.
The latch activation may be single-use or otherwise bounded.
S.2.R.4.5 — Controller Register Implementation
A protected processor may maintain a continuation register or phase
counter.
The next operation requires a defined register state.
The state transition can be made only through the protected IEV-
controlled interface.
The untrusted agent cannot directly write the required register.
S.2.R.4.6 — Transaction-State Implementation
A protected transaction controller may withhold a subsequent commit
primitive until a valid receipt-dependent state transition occurs.
For example, the controller may require a committed preceding effect
reference before accepting the successor transaction.
9.4.3.13. Source page 390 of the original specification
The transaction-state relationship is enforced by the controller
rather than merely by the workflow application's decision logic.
S.2.R.4.7 — Network-Gateway Implementation
A protected network gateway may prevent an otherwise prepared
outgoing operation from crossing its designated effectuation
boundary.
Das Expires 29 April 2027 [Page 221]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
After valid receipt acceptance, the IEV updates a protected
continuation entry associated with the specific operation and
destination.
The gateway independently verifies the entry and actual pending
transmission.
A stale or unrelated entry does not authorize another transmission.
S.2.R.4.8 — Firmware Implementation
A device firmware controller may implement the complete receipt-gated
phase state machine.
After a bounded real command produces a qualified completion record,
protected firmware validates the evidence.
Only then does the firmware make the next bounded command class
available.
The mechanism can operate without a general-purpose operating system
or externally transported cryptographic capability.
S.2.R.4.9 — Non-Cryptographic Enforcement Limitation
A protected state bit is not inherently secure merely because it
exists.
The implementation must define why an unauthorized component cannot
modify, bypass, or disregard the state.
Protection may arise from hardware access restrictions, memory
protection, controller ownership, authenticated internal interfaces,
transactional isolation, or equivalent controls.
Where the requesting agent can freely modify the state or invoke an
unrestricted alternate effectuation path, the required causal
security property is not established.
S.2.R.5 — EXACT DIFFERENCE FROM ORDINARY "CHECK RECEIPT THEN ALLOW"
S.2.R.5.1 — Ordinary Receipt Checking
In an ordinary workflow, an executor may perform the following
procedure:
Receive operation.
Das Expires 29 April 2027 [Page 222]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Check whether a success receipt exists.
If receipt appears valid:
9.4.3.14. Source page 391 of the original specification
Continue with the next step. The procedure may be useful.
However, its security properties depend upon whether the actual
execution mechanism is prevented from bypassing the check.
If the agent or another process already possesses unrestricted
authority to perform the next operation, the receipt check may remain
merely an application-level convention.
The underlying effect remains technically possible through an
alternate path.
S.2.R.5.2 — Protected Receipt-Constituted Causal Authority
In the stronger disclosed implementation, the system is constructed
differently.
Before valid receipt acceptance, a required execution-enabling
condition for the next effect is not available.
The IEV does not merely return a recommendation.
It controls or causes establishment of the missing execution
condition.
The next Finality Sink requires that condition.
The untrusted agent cannot independently generate or bypass it.
The governing sequence is therefore:
Bounded real effect | v Receipt generated from actual effect
evidence | v Independent IEV validation | v Missing execution
condition established | v Next consequential effect technically
enabled The distinction is the enforced causal dependence of the next
effect upon accepted real-effect evidence.
S.2.R.5.3 — Not a Mere Terminological Difference
The distinction must be demonstrated through actual implementation.
Das Expires 29 April 2027 [Page 223]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A conventional system whose executing controller already enforces a
receipt-dependent, non-bypassable authority transition may possess
similar relevant properties.
The present embodiment cannot establish novelty merely by naming its
receipt an enabling factor.
9.4.3.15. Source page 392 of the original specification
The potentially distinctive mechanism must be specified through the
precise prior-effect evidence, protected state relationship, missing
execution material, sink binding, and authority-consumption
conditions.
S.2.R.5.4 — Receipt Validation as Authority Formation
The IEV result is not limited to answering:
"Did the earlier operation succeed?"
It may instead establish:
"Has the required actual effect occurred under the correct protected
conditions such that the specifically scoped next-phase execution
material may now exist or become usable?"
This is the intended authority-forming function.
S.2.R.5.5 — No Unrestricted Session Permission
A valid receipt does not grant a general session privilege.
It may enable one precisely defined successor operation, a bounded
phase, or an expressly authorized continuation class.
The actual Finality Sink remains responsible for verifying the
current operation and protected state.
S.2.R.6 — PROTECTED RECEIPT VALIDATION PREDICATE
The IEV may employ a protected acceptance predicate comprising:
PASS[i] = AUTHENTIC_RECEIPT(R[i]) AND ACT_MATCH(R[i], CandidateAct)
AND PHASE_MATCH(R[i], i) AND SINK_MATCH(R[i], FS[i]) AND
DESTINATION_MATCH(R[i]) AND FRESH(R[i]) AND NOT_CONSUMED(R[i]) AND
ACCEPTABLE_EFFECT(Observed[i], Expected[i]) AND CURRENT_POLICY AND
CURRENT_REVOCATION_STATE AND NEXT_PHASE_WITHIN_AUTHORIZED_SCOPE
Additional predicates may include:
Das Expires 29 April 2027 [Page 224]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
• Protected receipt-source assurance;
• Prior resource-version matching;
• Protected user authorization;
• Relevant conflict reservations;
9.4.3.16. Source page 393 of the original specification
• Device-state continuity;
• Time or duration constraints;
• Cross-domain outcome verification;
• Required human reauthorization;
• Protected cumulative-effect limits.
If any mandatory condition fails, receipt-dependent continuation
remains unavailable.
S.2.R.6.1 — Exact Effect Comparison
For some operations, the observed result must exactly equal the
expected result.
Observed[i] = Expected[i] S.2.R.6.2 — Tolerance-Based Comparison
For other operations, a bounded deviation may be permitted.
Distance(Observed[i], Expected[i]) <= AuthorizedTolerance[i] This may
apply to measured physical movement, timing, or another suitable
technical property.
S.2.R.6.3 — Range-Based Comparison
A measured effect may be acceptable within an authorized interval.
Minimum[i] <= Observed[i] <= Maximum[i] S.2.R.6.4 — Predicate-Based
Comparison
The observed effect may satisfy a defined protected predicate.
Das Expires 29 April 2027 [Page 225]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
EFFECT_ACCEPTABLE = Predicate_1(Observed[i]) AND
Predicate_2(Observed[i]) AND ... AND Predicate_n(Observed[i]) The
predicate is established as part of the relevant protected
authorization.
The agent does not redefine the acceptance criteria after observing
an unfavorable result.
S.2.R.7 — REFERENCE PSEUDOCODE: RECEIPT-GATED CAUSAL ADVANCEMENT
The following non-limiting pseudocode illustrates an implementation
in which successful independent receipt validation directly
establishes the otherwise unavailable next-phase execution condition.
FUNCTION IEV_CAUSAL_ADVANCE( candidate_act, phase_i,
9.4.3.17. Source page 394 of the original specification
protected_receipt_i, successor_phase ):
state = IEV.LOAD_PROTECTED_PHASE_STATE( candidate_act.identifier )
REQUIRE VERIFY_PROTECTED_STATE(state)
IF state.current_phase != phase_i: RETURN DENY
IF state.successor_enabled == TRUE: RETURN DENY_DUPLICATE_ADVANCEMENT
receipt_result = VERIFY_RECEIPT({ receipt: protected_receipt_i,
candidate_act: candidate_act, phase: phase_i, expected_effect:
state.expected_effect, expected_sink: state.phase_sink,
current_policy: state.policy_epoch, current_revocation:
state.revocation_epoch })
IF receipt_result != PASS: RETURN HOLD_OR_RECONCILE
IF NOT VERIFY_ACTUAL_EFFECT_ACCEPTABILITY( protected_receipt_i,
state.expected_effect ): RETURN HOLD_OR_REMEDIATE
IF NOT VERIFY_SUCCESSOR_SCOPE( successor_phase,
state.authorized_envelope ): RETURN DENY
result = IEV.ATOMIC_TRANSITION({
require_current_phase: phase_i,
require_receipt_unused: protected_receipt_i.identifier,
Das Expires 29 April 2027 [Page 226]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.4.3.18. Source page 395 of the original specification
consume_receipt: protected_receipt_i.identifier,
advance_phase: phase_i + 1,
commit_receipt_dependency: HASH(protected_receipt_i),
bind_successor: HASH(successor_phase),
bind_successor_sink: successor_phase.sink_id,
activate_missing_execution_condition: TRUE,
increment_protected_counter: TRUE
IF result != COMMITTED: RETURN HOLD
RETURN result.protected_continuation_reference This procedure is not
merely a verification followed by an ordinary workflow decision.
The atomic protected transition establishes the specific state
necessary for successor effectuation.
S.2.R.8 — REFERENCE PSEUDOCODE: NEXT FINALITY SINK
FUNCTION FINALITY_SINK_CAUSAL_EFFECTUATION( successor_phase,
protected_continuation_reference, finality_sink ):
actual_operation = finality_sink.RECONSTRUCT_ACTUAL_OPERATION()
IF actual_operation IS NULL: RETURN DENY
state = finality_sink.LOAD_PROTECTED_STATE()
REQUIRE VERIFY_SUCCESSOR_OPERATION_BINDING( successor_phase,
actual_operation
9.4.3.19. Source page 396 of the original specification
REQUIRE VERIFY_RECEIPT_DERIVED_CONTINUATION(
protected_continuation_reference, state )
REQUIRE VERIFY_REQUIRED_PHASE_ORDER( state, successor_phase )
REQUIRE VERIFY_CURRENT_AUTHORITY( successor_phase, actual_operation )
REQUIRE VERIFY_CURRENT_REVOCATION_STATE( state )
Das Expires 29 April 2027 [Page 227]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
REQUIRE VERIFY_REQUIRED_EXECUTION_MATERIAL(
protected_continuation_reference, actual_operation )
consumption = finality_sink.ATOMIC_CONSUME({ continuation_reference:
protected_continuation_reference,
actual_operation: actual_operation,
protected_phase_state: state })
IF consumption != SUCCESS: RETURN DENY
RETURN finality_sink.EFFECTUATE( actual_operation, consumption ) The
final sink is not merely informed that the prior phase passed.
Its ability to complete the next effect depends upon the protected
continuation condition established through the accepted prior-effect
receipt.
S.2.R.9 — CAUSAL MULTI-PHASE EFFECTUATION
9.4.3.20. Source page 397 of the original specification
S.2.R.9.1 — Progressive Real Effects
A larger authorized consequence may be divided into bounded phases.
A non-limiting progression may comprise:
Phase 0: 5% authorized effect
R[0]: protected evidence of Phase 0
IEV[0]: independent validation
Gamma[1]: Phase 1 enabling condition
Phase 1: further bounded effect
R[1]: protected evidence of Phase 1
IEV[1]: independent validation
Gamma[2]: Phase 2 enabling condition
Phase 2: further bounded effect The percentages are illustrative and
not mandatory.
Das Expires 29 April 2027 [Page 228]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
For non-quantitative effects, progression may be bounded by
resources, recipients, privileges, operations, deployment
populations, or other consequence dimensions.
S.2.R.9.2 — No Phase Skipping
Where all phases are mandatory, the protected Finality Sink rejects a
direct attempt to execute Phase i+2 without satisfying the required
receipt-dependent transition for Phase i+1.
The system may enforce the relationship through protected phase
counters, receipt chains, cryptographic derivations, transaction-
state constraints, hardware latches, or equivalent mechanisms.
S.2.R.9.3 — No General Authority Escalation
The existence of a valid receipt does not enlarge the operation
beyond the authorized maximum envelope.
A new task scope requires separate valid authorization.
IEV acceptance establishes eligibility only for the permitted next
consequence.
S.2.R.9.4 — Adaptive Phasing
Where policy permits, the size or type of a later phase may depend
upon the verified observed result.
A successful bounded operation may permit progression.
9.4.3.21. Source page 398 of the original specification
A partial or marginal result may permit only a reduced next phase.
A mismatch may require remediation.
An indeterminate result may preserve the hold.
The adaptation is performed under protected rules rather than
arbitrary agent self-approval.
S.2.R.10 — BASIC EXAMPLE: ONE TEST DEVICE BEFORE A LARGER DEPLOYMENT
S.2.R.10.1 — Original Authorization
A user authorizes an autonomous agent to deploy a software update to
a fleet of devices.
Das Expires 29 April 2027 [Page 229]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The authorization permits deployment to a maximum specified
population but requires successful bounded testing before broader
release.
S.2.R.10.2 — First Real Effect
The protected execution system initially permits deployment to one
designated test device.
This is a real deployment, not merely a simulated installation.
The first Finality Sink verifies the bounded deployment authority.
The test device receives and applies the permitted update.
S.2.R.10.3 — Protected Receipt
A qualified controller produces a protected receipt identifying the
device, applied update, relevant committed state, and applicable
protected operation reference.
The receipt establishes only the technical facts actually supported
by the observation.
S.2.R.10.4 — IEV Causal Validation
The IEV independently verifies the receipt.
It determines whether:
• The correct device was updated;
• The correct software artifact was applied;
• The protected update operation matches the original Candidate Act;
• The required test-state predicates are satisfied;
• The receipt is fresh and unused;
• The next deployment remains within the authorized scope.
9.4.3.22. Source page 399 of the original specification
S.2.R.10.5 — Missing Execution Material
Before IEV success, the broader deployment controller lacks the
required enabling condition.
Das Expires 29 April 2027 [Page 230]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
In a cryptographic implementation, the protected signing or
authorization material for the next deployment phase remains
unavailable.
In a non-cryptographic implementation, the deployment controller's
protected continuation state remains disabled.
S.2.R.10.6 — Receipt-Dependent Enablement
After successful IEV validation, the protected continuation condition
becomes available.
The next Finality Sink verifies the actual deployment population,
software artifact, current authority, and receipt-dependent state.
Only then is the next bounded deployment permitted.
S.2.R.10.7 — Failure
If the test deployment fails, the expected state cannot be verified,
or the receipt is invalid, the protected system does not enable
broader deployment.
The agent cannot bypass the restriction merely by invoking a
different deployment API within the covered enforcement domain.
S.2.R.10.8 — Technical Difference
A conventional deployment system may run a canary test and, upon
observing success, have its workflow scheduler launch a broader
deployment.
The present stronger implementation makes the protected ability to
launch the broader phase depend upon accepted evidence from the real
test effect.
The receipt-derived condition is therefore an execution prerequisite,
not merely a test report.
S.2.R.11 — SECOND EXAMPLE: PHYSICAL ACTUATOR WITH NON-CRYPTOGRAPHIC
CAUSAL RECEIPT
S.2.R.11.1 — Original Command
A protected controller is authorized to move an actuator through a
staged sequence.
The initial phase permits only a bounded movement.
Das Expires 29 April 2027 [Page 231]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
S.2.R.11.2 — Real Bounded Movement
The actuator Finality Sink permits a movement within the initial
authorized envelope.
The actuator physically moves.
9.4.3.23. Source page 400 of the original specification
S.2.R.11.3 — Protected Sensor Receipt
A protected sensor or controller produces evidence concerning actual
movement.
The receipt includes the relevant phase, command identity, measured
position, and protected sequence.
S.2.R.11.4 — IEV Validation
The IEV verifies that the actual measured state satisfies the
permitted tolerance and applicable safety conditions.
S.2.R.11.5 — Hardware Causal Enablement
The next actuator command cannot be released because its protected
hardware latch is initially disabled.
Following accepted receipt validation, the protected controller
advances the phase register and enables the precisely bounded next
movement.
The next actuator Finality Sink verifies the actual pending command.
S.2.R.11.6 — No Cryptographic Requirement
The causal effectuation dependency may be implemented through
protected hardware state transitions without deriving a cryptographic
key.
The essential condition is that the required latch or command-release
state cannot be established by the untrusted agent independently of
the accepted prior-effect evidence.
S.2.R.11.7 — Technical Effect
The subsequent physical movement is causally dependent upon the
protected evidence of the earlier real movement.
Das Expires 29 April 2027 [Page 232]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The initial sensor result is not merely stored for later analysis.
It participates in the protected hardware mechanism making the next
movement possible.
S.2.R.12 — THIRD EXAMPLE: RECEIVER-SIDE CRYPTOGRAPHIC RELEASE
S.2.R.12.1 — Authorized Task
An agent is authorized to transmit a protected information object to
a designated recipient.
The system requires validation of a bounded recipient-side operation
before releasing the full usable content.
S.2.R.12.2 — Bounded First Phase
The sender transmits a protected test object or bounded demonstration
payload to the designated recipient.
9.4.3.24. Source page 401 of the original specification
The test operation produces a real consequence at the receiving side.
S.2.R.12.3 — Recipient Effect Receipt
A protected receiving component provides evidence that the required
test object was received or processed according to the designated
predicate.
S.2.R.12.4 — Independent IEV Validation
The IEV verifies the receipt against the authorized recipient,
operation, destination, phase, and expected result.
S.2.R.12.5 — Missing Key Condition
The recipient may possess encrypted data but lack the required
decryption material.
Alternatively, the sender may withhold the necessary release key.
The full intended disclosure or use remains technically unavailable
before the accepted receipt-dependent condition is satisfied.
S.2.R.12.6 — Causal Release
Das Expires 29 April 2027 [Page 233]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Successful receipt validation causes the protected system to
generate, release, unseal, or activate the required key material
under the specific authorized scope.
The corresponding Finality Sink or recipient-side protected
controller verifies the operation binding.
S.2.R.12.7 — Technical Effect
The broader consequential data release depends upon evidence from an
earlier real recipient-side operation.
The receipt is the causal input required to establish the missing
cryptographic execution material.
S.2.R.13 — RELATIONSHIP TO IN-LINE PRE-EFFECT IEV
Embodiment 2 also discloses an optional IEV positioned immediately
before an individual consequential effect.
That implementation verifies the actual pending operation and may
cause issuance or activation of the required final-release condition.
The in-line variant and receipt-gated inter-phase variant are related
but distinct.
In the in-line variant, the IEV may verify a prepared operation
before the principal effect occurs.
An earlier real-effect receipt is not universally required.
In the receipt-gated inter-phase variant, protected evidence of an
earlier real effect is a mandatory causal prerequisite for the next
effect.
9.4.3.25. Source page 402 of the original specification
The present supplementary disclosure principally clarifies the
latter, which is not properly characterized as merely checking a
receipt after an earlier workflow step.
A combined implementation may require both an in-line validation and
a receipt-derived continuation condition.
S.2.R.14 — COMPARISON WITH CONVENTIONAL SYSTEMS
S.2.R.14.1 — Conventional Post-Hoc Monitoring
Das Expires 29 April 2027 [Page 234]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Post-hoc monitoring observes or records completed activity.
The stronger IEV arrangement uses evidence of one bounded real
consequence to control whether the remaining or subsequent
consequence can become effective.
S.2.R.14.2 — Conventional Success-Flag Workflow
A workflow engine may store a success flag and select the next step.
In the stronger IEV arrangement, the actual Finality Sink requires
protected continuation state or missing execution material that
cannot be established independently of accepted prior-effect
evidence.
A workflow engine that already provides equivalent protected non-
bypassable causal gating may constitute relevant close prior art.
S.2.R.14.3 — Conventional Approval Receipt
An approval receipt may prove that an authorized principal approved a
proposed operation.
The IEV receipt in the principal inter-phase arrangement arises from
an actual bounded effectuation event and provides the causal evidence
necessary to establish a later effectuation condition.
Human approval may additionally be required but is not a substitute
for mandatory actual-effect evidence.
S.2.R.14.4 — Conventional Canary Testing
A canary deployment may evaluate a small population before broader
rollout.
The mere use of a canary is established practice.
The candidate technical distinction concerns receipt-dependent
unavailability of the broader phase's necessary execution authority
and enforcement of that dependency at the applicable effectuation
boundary.
S.2.R.14.5 — Conventional Two-Phase Commit
Two-phase commit coordinates transactional participants.
Das Expires 29 April 2027 [Page 235]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.4.3.26. Source page 403 of the original specification
The disclosed IEV may instead permit one bounded real external
effect, obtain evidence of what actually occurred, and use validated
evidence to establish the necessary authorization or execution
material for a later consequence.
The relevant effects need not participate in one atomic distributed
transaction.
S.2.R.14.6 — Conventional Distributed Saga
A saga may schedule multiple local transactions and compensation
operations.
The present embodiment may additionally require real-effect receipt-
derived authority between phases and independent verification of the
actual successor operation at the Finality Sink.
The mere existence of multiple transactions and compensating steps is
not the asserted distinguishing feature.
S.2.R.14.7 — Conventional Cryptographic Token
A cryptographic token may represent an authorization created before
an operation.
The stronger IEV implementation may make the ability to construct or
release a subsequent operation's required cryptographic material
dependent upon evidence produced by the preceding real effect.
However, prior systems employing similarly enforced proof-dependent
authorization or capability derivation must be considered in
inventive-step analysis.
S.2.R.15 — PROPOSED INVENTIVE-STEP ANALYSIS
S.2.R.15.1 — Objective Technical Problem
A candidate objective technical problem is:
How to prevent a protected autonomous computing system from making a
later or broader consequential operation technically effective before
a specifically authorized earlier bounded real operation has produced
acceptable independently verified evidence, while preventing bypass,
replay, substitution, and unauthorized expansion of the resulting
continuation authority.
Das Expires 29 April 2027 [Page 236]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
This formulation emphasizes the protected causal dependency rather
than generic workflow sequencing.
S.2.R.15.2 — Candidate Technical Solution
The proposed solution may comprise:
First, partitioning an authorized consequential operation into one or
more bounded real effectuation phases.
Second, withholding a required technical condition for effectuation
of a later phase.
Third, permitting an initial bounded real phase through an applicable
Finality Sink.
9.4.3.27. Source page 404 of the original specification
Fourth, obtaining a protected receipt concerning the actual effect of
the earlier phase.
Fifth, independently validating the receipt through an IEV against
operation-specific, phase-specific, effect-specific, freshness, and
protected-policy predicates.
Sixth, causing successful receipt acceptance to establish previously
unavailable next-phase execution material or protected continuation
state.
Seventh, requiring the next Finality Sink to verify the receipt-
derived condition against the actual pending operation.
Eighth, preventing the receipt or continuation condition from being
exercised outside its authorized scope or reused contrary to its
protected consumption rules.
Ninth, preserving fail-closed or reconciliation state where the
expected prior effect cannot be established.
S.2.R.15.3 — Potentially Distinguishing Technical Interaction
The earlier real effect produces the evidence required for the next
phase.
The IEV independently validates that evidence.
The IEV-controlled protected transition establishes the next phase's
necessary execution condition.
Das Expires 29 April 2027 [Page 237]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The Finality Sink enforces that condition before the next effect.
Thus, the protected architecture creates an operation-specific causal
dependency between an earlier observed real effect and the technical
possibility of a later consequence.
The receipt is not merely a historical report.
It is not merely a supporting field displayed to a policy engine.
Its accepted state participates directly in forming the next phase's
authority.
S.2.R.15.4 — Non-Obviousness Considerations
A proper inventive-step analysis should identify the closest prior
art concerning staged execution, proof-dependent authorization,
capability derivation, transactional dependencies, hardware
interlocks, and receipt-gated workflows.
The analysis should determine whether the prior art teaches or
renders obvious the claimed combination of bounded real-effect
observation, independent receipt validation, missing execution
material, protected phase ordering, act-bound continuation, and
actual sink-side enforcement.
Simply stating that conventional systems use logs or human approval
would be an insufficient comparison if closer prior-art systems
already implement receipt-dependent execution gates.
Likewise, the mere use of a KDF, receipt hash, hardware latch, or
monotonic counter is not independently sufficient to establish
inventive step.
The asserted contribution must reside in the specific protected
causal structure and technical interaction of the claimed features.
9.4.3.28. Source page 405 of the original specification
S.2.R.15.5 — Potential Claim Kernel
A potentially narrower technical kernel may be formulated as:
A protected autonomous effectuation system in which completion of an
earlier bounded real consequential operation generates protected
effect evidence, an independent IEV validates said evidence against
the original Candidate Act and required effect predicate, and
successful validation causes the generation, derivation, release,
Das Expires 29 April 2027 [Page 238]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
activation, or commitment of a previously unavailable execution-
enabling condition without which a subsequent specifically authorized
consequential operation cannot be performed through its designated
Finality Sink.
S.2.R.16 — INDUSTRIAL APPLICABILITY
The receipt-gated causal IEV architecture may be used in systems
where broader or later consequential effects should depend upon
verified results of earlier real operations.
In autonomous software deployment, a limited real deployment may
generate evidence required to unlock broader deployment authority.
In robotics, verified bounded actuator movement may establish the
protected state required for the next commanded movement.
In network security, a bounded real communication may establish
authenticated endpoint and path evidence before full data release.
In protected storage, successful commitment of a bounded object may
provide the required causal basis for subsequent publication or
export.
In payment systems, a qualifying rail-supported bounded operation may
establish evidence required for a separately authorized later payment
phase.
In device management, an actual configuration or firmware-state
transition may provide the required evidence for subsequent
activation.
In cloud computing, a verified bounded resource operation may
establish the necessary protected continuation condition for a larger
resource change.
In telecommunications, a verified limited network-state transition
may become a protected prerequisite for broader control-plane
effectuation.
In industrial control, protected sensor evidence from a bounded
physical action may enable a later phase through a hardware
controller.
These applications are illustrative.
The selected bounded effects, evidence requirements, and continuation
conditions must be appropriate to the actual technical system.
Das Expires 29 April 2027 [Page 239]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The architecture does not presume that every real-world consequence
can be safely divided into arbitrary fractions.
9.4.3.29. Source page 406 of the original specification
S.2.R.17 — TECHNICAL CHARACTERIZATION
The IEV mechanism of Embodiment 2 is not properly limited to checking
whether a prior operation succeeded and then allowing a conventional
workflow to advance.
In a principal implementation, it is a protected causal-authority
mechanism positioned between separately consequential real effects.
A first bounded real effect produces protected evidence.
The independently operated IEV validates that evidence under defined
operation, phase, result, authority, and freshness conditions.
Successful validation establishes a necessary technical condition for
the next phase.
That condition may be a cryptographic key, missing key share, scoped
capability, protected transaction state, hardware latch, secure
register, controlled network permit, destination-side enabling
condition, or another protected execution prerequisite.
The next Finality Sink requires the continuation condition and
independently verifies the actual operation.
The untrusted agent cannot independently construct, activate, or
bypass the required execution condition within the covered
enforcement architecture.
Where the prior-effect evidence is missing, invalid, stale,
mismatched, or insufficient, the subsequent consequential operation
remains unavailable, withheld, or subject to an authorized
reconciliation or remediation procedure.
The receipt is therefore not merely proof retained after completion
of the full operation.
It is the evidence-derived causal factor from which the protected
authority or enabling condition for the next real consequential phase
is constituted.
Das Expires 29 April 2027 [Page 240]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The arrangement may be implemented cryptographically or non-
cryptographically and may employ separate or integrated protected
components.
The operative technical feature is the required causal dependence of
later effectuation upon independently accepted evidence of an earlier
real effect, enforced at the corresponding consequential boundary.
END OF SUPPLEMENTARY DISCLOSURE FOR EMBODIMENT 2.
PART III — JOINT TECHNICAL RELATIONSHIP OF EMBODIMENTS 1 AND 2
S.3.1 — DIFFERENT OBJECTS OF PROTECTION AND THEIR COMMON EXECUTION-
FINALITY FOUNDATION
9.5. Combined Embodiments 1 and 2: Concurrent-Effect Compatibility
Versus Required Causal Ordering
Original global source page range: 407-436 inclusive, original
uploaded PDF segment: TECHNICAL SPECIFICATION -1-554.pdf. Primary in
this part: False. Page-extract fidelity limitations and independent
filing-priority analysis are stated in the source note.
9.5.1. Architecture and Protected Trust-Relationship Diagram
[Multiple agent effects / shared resource]
|
[Conflict footprint/reservation control]
|
[Bounded predecessor effect]
|
[IEV validates qualified effect receipt]
|
[Protected successor causal condition]
|
[Source and conflict compatibility checks]
|
[Receiving Finality Sink and consumption]
Figure 22: Combined Embodiments 1 and 2: Concurrent-Effect
Compatibility Versus Required Causal Ordering — architecture and
protected dependencies
9.5.2. Operational Decision Flowchart and Refusal Conditions
Das Expires 29 April 2027 [Page 241]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
[Pending dependent successor]
|
<Compatible with current effect conflicts?>--NO-->[FENCE]
|YES
<Required predecessor effect established?>--NO-->[HOLD]
|YES
<VAER and source authority current?>--NO-->[REFUSE]
|YES
<Actual target/sink state passes?>--NO-->[REFUSE]
|YES
[Protected reservation + consume + release]
Figure 23: Combined Embodiments 1 and 2: Concurrent-Effect
Compatibility Versus Required Causal Ordering — decision
flowchart
9.5.3. Original Source Page-Indexed Technical Content
9.5.3.1. Source page 407 of the original specification
Embodiment 1 and Embodiment 2 address separate but potentially
interdependent technical problems within a protected execution-
finality architecture.
Embodiment 1 concerns protected arbitration among multiple
independently authorized Candidate Acts whose actual or intended
consequential effects may interfere with one another.
More particularly, Embodiment 1 provides mechanisms for identifying
and representing effect-specific interference, establishing atomic
protected effect reservations, preventing stale or incompatible
operation releases, verifying actual pending effects at designated
Finality Sinks, and maintaining protected conflict state according to
the observed or unresolved consequences of earlier operations.
Embodiment 2 concerns protected causal ordering among independently
consequential phases of an authorized operation or workflow.
In a principal implementation, Embodiment 2 establishes a protected
relationship in which an earlier bounded real effect produces a
receipt, the receipt is independently validated by an Interim
Effectuation Validator (IEV), and the accepted receipt constitutes or
establishes a necessary execution-enabling condition for the
subsequent consequential phase.
Das Expires 29 April 2027 [Page 242]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
That condition may be established through cryptographic material,
protected hardware state, an atomic controller transition, a
transaction-state dependency, a scoped non-bearer execution
capability, or another enforced mechanism.
The next consequential phase is not merely instructed to wait until
an earlier phase reports success.
Instead, its required execution authority or enablement remains
unavailable, invalid, incomplete, sealed, inactive, or otherwise
technically unusable until the accepted prior-effect receipt has
established the necessary causal condition.
Accordingly, the core distinction may be summarized as follows.
Embodiment 1 governs whether an individually authorized effect is
compatible with other consequential effects.
Embodiment 2 governs whether an authorized subsequent effect
possesses the protected causal enablement derived from a required
preceding real effect.
Both embodiments may operate under the general principle that
computation, planning, model-generated instructions, agent decisions,
and ordinary software permissions do not independently constitute
authority to cause consequential external effects.
S.3.1.1 — Concurrent Consequence Validity
Under Embodiment 1, two autonomous agents may each possess
independently valid execution authority.
However, a first operation may be incompatible with a second
operation because their combined consequences violate a protected
resource, ordering, aggregate, disclosure, or other effect-specific
constraint.
For example, Agent A may possess authority to modify a protected
report while Agent B possesses authority to transmit an approved
version of the report.
9.5.3.2. Source page 408 of the original specification
Both permissions may be individually valid.
Nevertheless, an uncoordinated execution could result in transmission
of an incorrect or unauthorized version.
Das Expires 29 April 2027 [Page 243]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Embodiment 1 may prevent this result through protected effect
footprints, interference constraints, reservations, fencing, actual-
operation verification, and consequence-state reconciliation.
S.3.1.2 — Sequential Causal Authority
Under Embodiment 2, the concern is not necessarily the coexistence of
incompatible operations.
Instead, a subsequent consequential operation may require a real
earlier effect to have occurred under specified protected conditions.
For example, a protected controller may permit a bounded deployment
to one device but withhold the execution-enabling material for a
broader deployment until independently verified evidence establishes
that the earlier bounded deployment satisfied the required
predicates.
The valid receipt from the bounded effect participates in forming or
activating the necessary authority for the subsequent phase.
Without the accepted receipt, the broader deployment remains
technically unavailable through the covered enforcement architecture.
This is a receipt-constituted causal dependency rather than merely an
informational dependency.
S.3.1.3 — Independence of the Embodiments
The mechanisms may operate independently.
Embodiment 1 does not universally require a phased execution
structure.
Embodiment 2 does not universally require arbitration among multiple
agents.
A single agent may perform multiple receipt-gated real phases without
encountering another agent.
Conversely, multiple agents may require protected effect-conflict
arbitration even when each operation comprises only one consequential
phase.
A combined implementation may require both mechanisms when the system
must enforce concurrent effect compatibility and sequential causal
authority.
Das Expires 29 April 2027 [Page 244]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
S.3.1.4 — Distinction Between Outcome Evidence and Effectuation
Authority
For Embodiment 2, a distinction is maintained among:
First, an initial protected authorization permitting an earlier
bounded real effect.
Second, evidence or a receipt produced from that effect.
Third, independent IEV validation of the receipt against the required
effect, Candidate Act, phase identity, protected state, and
applicable authority.
9.5.3.3. Source page 409 of the original specification
Fourth, an accepted receipt-dependent condition that establishes or
activates the missing execution material required for the next phase.
Fifth, verification of that receipt-dependent condition and the
actual successor operation at the designated Finality Sink.
A raw, unvalidated receipt is not necessarily an executable bearer
token.
Nevertheless, the accepted receipt has a constitutive role in the
subsequent authority mechanism.
It is therefore inaccurate to describe the principal inter-phase IEV
implementation as merely performing an audit or post-hoc check before
allowing an otherwise independently executable workflow to proceed.
S.3.2 — OPTIONAL COMBINED IMPLEMENTATION
In one non-limiting implementation, a plurality of autonomous agents
proposes consequential operations affecting shared resources,
devices, services, applications, or protected effect domains.
Embodiment 1 constructs or obtains a Protected Effect Footprint for
each relevant Candidate Act.
The protected system evaluates the operations against an Effect-
Interference Graph or equivalent machine-verifiable constraint
structure.
A Protected Effect-Conflict Reservation is established for an
authorized bounded operation.
Das Expires 29 April 2027 [Page 245]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The reservation may be bound to a protected graph-fencing commitment,
an authority epoch, the specific Candidate Act, the designated
Finality Sink, and current protected consequence state.
Embodiment 2 may then govern the actual progression of that operation
through bounded consequential phases.
A first phase receives applicable scoped finality authority.
Where required, an in-line IEV independently verifies the actual
pending command before the first real effect.
The first Finality Sink verifies the operation, protected authority,
and applicable conflict reservation.
The first bounded consequential effect is then permitted.
A qualified observer or protected controller obtains evidence
concerning the actual result.
A Protected Effect Receipt is generated or committed.
The inter-phase IEV independently verifies the receipt against the
preceding Candidate Act, the required observed effect, the protected
reservation state, the prior effectuation attempt, and applicable
current authority.
Successful validation produces an accepted receipt-dependent
continuation condition.
The continuation condition may comprise or control a previously
unavailable execution-enabling primitive for the subsequent phase.
9.5.3.4. Source page 410 of the original specification
The relevant protected component may generate, derive, release,
unseal, activate, or commit the missing condition only upon
successful receipt validation.
The successor Finality Sink verifies the actual proposed next
operation, the valid receipt-dependent continuation condition,
applicable conflict state, and the new scoped authority.
If the relevant predicates pass, the next real consequential phase
may occur.
Das Expires 29 April 2027 [Page 246]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
If the required receipt is absent, invalid, stale, mismatched,
replayed, or unsupported by adequate observation evidence, the
required continuation condition remains unavailable or unusable.
The system may preserve the earlier effect's protected conflict
reservation while its outcome remains uncertain.
S.3.2.1 — Combined Causal Sequence
A representative combined sequence may be expressed as:
Agent A and Agent B produce Candidate Acts | v Protected Effect
Footprints constructed | v Cross-agent effect interference
evaluated | v Atomic protected effect reservation established | v
First bounded Candidate Act authorized | v Finality Sink FS[0]
verifies actual pending act | v REAL BOUNDED EFFECT P[0] | v
Qualified actual-effect observation | v Protected Effect Receipt
R[0] | v Independent IEV validation of R[0] | v Receipt-dependent
causal condition Gamma[1] | v Protected conflict and continuation
state verified
9.5.3.5. Source page 411 of the original specification
| v Finality Sink FS[1] verifies actual next act | v NEXT REAL
CONSEQUENCE P[1] The sequence is illustrative and may include
additional phases, agents, protected effect domains, distributed
validators, or independently administered Finality Sinks.
S.3.2.2 — Receipt-Dependent Reservation Advancement
In one implementation, the accepted prior-effect receipt directly
controls advancement or release of a protected effect reservation.
For example, a reservation may remain active until the IEV validates
evidence establishing the required earlier state transition.
The receipt-dependent transition may simultaneously or coordinately:
1. Commit the verified prior outcome.
2. Advance the protected phase sequence.
3. Consume or update the applicable earlier reservation.
4. Activate a successor-specific reservation.
5. Establish the missing next-phase execution condition.
Das Expires 29 April 2027 [Page 247]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
6. Bind the condition to the designated successor Finality Sink.
Where appropriate, these operations may occur within one atomic
protected state transaction or through a distributed protocol
providing the required consistency and fencing guarantees.
Where an external consequential effect cannot participate in the same
atomic transaction, the system preserves the corresponding
uncertainty and recovery semantics.
S.3.2.3 — Cryptographic Combined Implementation
In a cryptographic implementation, the successor operation may
require key material, an authenticated execution handle, a threshold
share, or a scoped signing capability that cannot be obtained or
exercised before valid receipt acceptance.
The accepted receipt commitment may form a bound input to a protected
derivation or release protocol.
For example:
Gamma[i+1] = PROTECTED_KDF( ProtectedSecret,
AcceptedReceiptCommitment[i], CandidateActDigest[i+1],
FinalitySinkID[i+1], ProtectedPhaseCounter[i+1],
9.5.3.6. Source page 412 of the original specification
AuthorityEpoch[i+1] ) The protected derivation service must enforce
validation before using or releasing the derived material.
A public hash of a receipt alone is not sufficient to create a secure
causal gate if the untrusted agent can compute and use all required
material independently.
S.3.2.4 — Non-Cryptographic Combined Implementation
In another implementation, the IEV controls a protected phase-state
transition or controller-owned latch.
The next Finality Sink cannot release the successor operation while
the required continuation state remains inactive.
Acceptance of the prior-effect receipt activates the operation-
specific continuation state.
Das Expires 29 April 2027 [Page 248]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The activation may be constrained by a protected phase counter,
reservation epoch, command identifier, or hardware-controlled
register.
The untrusted agent cannot independently write the required
continuation state or bypass the protected effectuation boundary.
S.3.2.5 — Preservation of Separate Security Predicates
A valid receipt-derived continuation condition does not automatically
override an incompatible effect reservation.
A valid effect reservation does not automatically create the causal
receipt required by Embodiment 2.
Both conditions may be independently mandatory.
The combined system therefore preserves the distinction between
protected concurrency authority and protected causal continuation
authority.
S.3.3 — COMBINED PROTECTED RELEASE CONDITION
In one non-limiting implementation, a successor consequential effect
may be released only when the following applicable conditions are
satisfied:
VALID_INDIVIDUAL_AUTHORITY
AND VALID_CROSS_OPERATION_RESERVATION
AND VALID_ACTUAL_OPERATION_CORRESPONDENCE
AND VALID_PRIOR_REAL_EFFECT_EVIDENCE
AND VALID_INDEPENDENT_IEV_ACCEPTANCE
9.5.3.7. Source page 413 of the original specification
AND VALID_RECEIPT_DEPENDENT_EXECUTION_CONDITION
AND VALID_SUCCESSOR_SCOPE
AND VALID_CURRENT_PROTECTED_STATE
AND VALID_SINK_LOCAL_CONSUMPTION_STATE The formulation is
illustrative.
Das Expires 29 April 2027 [Page 249]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Not every operation requires all optional predicates.
The required predicates depend upon the particular embodiment,
protected policy, effectuation boundary, and claim limitations.
For the principal receipt-gated inter-phase implementation of
Embodiment 2, the critical additional property is that the accepted
prior-effect receipt is required to establish the next-phase
execution condition.
The requirement is not satisfied merely because an external software
scheduler reads a success record and voluntarily decides to continue
while retaining an unrestricted alternate execution path.
S.3.3.1 — Necessary Causal Enablement
Let P[i] represent a bounded real effectuation phase.
Let R[i] represent protected evidence produced from that effect.
Let V[i] represent independent IEV acceptance of the receipt.
Let Gamma[i+1] represent the missing execution-enabling condition for
the successor phase.
The relationship may be represented as:
P[i] -> R[i] -> V[i] -> Gamma[i+1] -> P[i+1] For an implementation
requiring strict sequential dependency, effectuation of P[i+1] is
prohibited unless Gamma[i+1] has been validly established through the
accepted prior-effect receipt.
The relationship may be enforced through protected cryptographic
material or non-cryptographic state.
S.3.3.2 — No Phase Skipping
Where phase progression is mandatory, the system may prevent a later
phase from being executed without completing the necessary receipt-
dependent transitions.
For example, Phase 2 cannot become effective merely because the
originating agent has generated a Phase 2 command.
Its required continuation authority must be derived or activated
through the permitted predecessor chain.
S.3.3.3 — No Unrestricted Receipt Reuse
Das Expires 29 April 2027 [Page 250]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.5.3.8. Source page 414 of the original specification
Where continuation is single-use, a receipt or continuation condition
already consumed for one authorized successor operation cannot be
replayed to authorize additional effects.
The protected consumption mechanism may reside within the Finality
Sink, PED, hardware controller, or another authoritative protected
state component.
S.3.3.4 — No Implicit Override of Conflict Constraints
Where another agent holds an incompatible protected reservation, a
valid phase receipt does not by itself permit the conflicting
successor effect.
The protected system must also establish current effect
compatibility.
S.3.4 — POTENTIAL JOINT TECHNICAL EFFECT
The combined architecture may provide complementary control over
concurrent and sequential consequential operations.
Embodiment 1 may prevent two individually authorized agents from
producing an incompatible combined effect.
Embodiment 2 may prevent a later consequential phase from becoming
executable before a required earlier bounded real effect has produced
acceptable independently verified evidence.
The protected receipt may additionally control when an effect
reservation is consumed, retained, transferred, or released.
This allows actual-effect evidence to influence the compatibility
state governing other agents.
S.3.4.1 — Prevention of Conflicting Consequences
Protected effect reservations may prevent unauthorized concurrent
changes to the same or related consequential state.
S.3.4.2 — Prevention of Premature Phase Advancement
Receipt-dependent execution enablement may prevent a later phase from
being performed merely because a preceding software task reports
success.
Das Expires 29 April 2027 [Page 251]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
S.3.4.3 — Prevention of Incorrect Reservation Release
A protected conflict reservation may remain active where the earlier
effect occurred but the system cannot establish its final outcome.
S.3.4.4 — Prevention of Bypass Through Independent Agent Authority
An agent may possess credentials or tool access but remain unable to
cause a protected effect without the required current reservation and
receipt-derived continuation condition.
This property depends upon the actual enforcement coverage of the
relevant effectuation interfaces.
S.3.4.5 — Preservation of Compatible Parallelism
9.5.3.9. Source page 415 of the original specification
Unrelated agents may continue performing operations that are
independently verified as compatible with the protected pending or
completed effects.
S.3.4.6 — Reduction of Unsafe Recovery
A crash, timeout, or unavailable witness does not automatically
restore consumed authority or release a conflicting reservation.
The system may require reconciliation or separate recovery
authorization.
The claimed technical effects must be evaluated against the actual
implementation, failure assumptions, and prior art.
S.3.5 — LIMITATIONS AND INVENTIVE-STEP CONSIDERATIONS FOR THE
COMBINED ARRANGEMENT
The mere inclusion of a conflict graph, protected reservation, effect
receipt, cryptographic key, hardware latch, and Finality Sink does
not automatically establish inventive step.
The relevant technical distinction must reside in their specific
enforceable interaction.
An illustrative narrower combined concept may require:
First, the construction of protected effect-interference state
relating to multiple independently authorized Candidate Acts.
Das Expires 29 April 2027 [Page 252]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Second, an operation-bound protected effect reservation.
Third, execution of an initially bounded real consequence through a
designated Finality Sink.
Fourth, generation and independent IEV validation of a protected
receipt derived from that real consequence.
Fifth, establishment of previously unavailable successor execution
material or protected continuation state as a necessary consequence
of receipt acceptance.
Sixth, protected advancement or retention of relevant conflict
reservations according to the verified or unresolved actual effect.
Seventh, independent verification of the current reservation and
receipt-dependent authority against the actual pending successor
operation.
The potential technical interaction lies in using independently
verified prior-effect evidence both to control causal advancement and
to govern the protected conflict state affecting other operations.
A claim should identify the particular data dependencies, protected
state transitions, and effectuation boundary enforcement mechanisms
responsible for this result.
Known distributed fencing, transactional dependencies, staged
deployment gates, proof-dependent authorization, and protected
execution systems must be considered as relevant prior art.
A claimed combination is not inventive merely because multiple
familiar security mechanisms are described together.
9.5.3.10. Source page 416 of the original specification
The assessment must determine whether the specific arrangement and
its technical effect would have been obvious to a PHOSITA.
PART IV — NON-LIMITING ILLUSTRATIVE COMPARATIVE EXAMPLES
S.4.1 — EXAMPLE FOR EMBODIMENT 1: TWO AGENTS ACTING ON ONE RESOURCE
A user authorizes Agent A to revise a document.
The user separately authorizes Agent B to send the approved document
to a designated recipient.
Das Expires 29 April 2027 [Page 253]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Both agents may possess individually valid permissions.
However, their operations may interfere through the protected
relationship between the document version and the version permitted
for disclosure.
In a conventional application-permission arrangement, Agent A may
modify the document while Agent B transmits an outdated version.
A conventional orchestrator may attempt to sequence their work.
However, a scheduling instruction is not necessarily sufficient to
constrain every independently available consequential interface.
Under Embodiment 1, the protected system constructs a Protected
Effect Footprint for each Candidate Act.
The effect footprints may identify the relevant resource identity,
permitted document version, storage mutation, transmission operation,
and disclosure constraint.
The protected arbitration component determines whether the operations
are compatible, require ordering, or must be withheld.
An atomic protected reservation may be established against the
applicable conflict state.
The actual document modification and external transmission are
independently checked at their respective Finality Sinks.
The storage sink verifies its current authority and reservation state
before committing the document modification.
The transmission sink independently verifies the actual outgoing
document, destination, permitted version, and applicable protected
reservation.
A stale or mismatched transmission is withheld.
Where the prior storage operation may have occurred but its actual
result remains unknown, the protected conflict state may retain the
relevant reservation until suitable evidence resolves the state.
The proposed technical distinction is not merely instructing Agent B
to wait.
Das Expires 29 April 2027 [Page 254]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.5.3.11. Source page 417 of the original specification
It is enforcing the compatibility relationship between the actual
storage and disclosure effects through protected state and their
corresponding consequential boundaries.
S.4.2 — CORRECTED EXAMPLE FOR EMBODIMENT 2: REAL UPLOAD RECEIPT AS
THE CAUSAL ENABLING FACTOR FOR CONFIRMATION
A user authorizes an autonomous agent to upload a report to a remote
protected storage service and send a confirmation only after the
actual storage condition has been established.
The overall workflow comprises at least two independently
consequential phases.
Phase 0 is the authorized remote storage operation.
Phase 1 is transmission of the corresponding completion confirmation.
In a conventional workflow, the agent may transmit the upload
request, receive an API response, inspect a success field, and invoke
a separate messaging tool.
The messaging tool may already possess unrestricted execution
authority.
Thus, the confirmation message may remain technically executable even
if the workflow's receipt check is skipped, compromised, or
incorrectly implemented.
In the stronger receipt-gated implementation of Embodiment 2, the
authority to effectuate the confirmation message is constructed
differently.
S.4.2.1 — Phase 0 Authorization
The agent creates a Candidate Act for uploading the selected report
to the designated remote storage service.
The PED validates the permitted source, destination, operation class,
and applicable protected authority.
The originating Finality Sink reconstructs the actual outbound
upload.
If the required predicates pass, it permits the bounded real upload
operation.
Das Expires 29 April 2027 [Page 255]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
S.4.2.2 — Actual Remote Effect
The report is transmitted to the remote service.
The remote storage controller may accept the request, process the
object, and commit the corresponding storage state.
The actual storage effect is distinguished from mere request
acceptance.
S.4.2.3 — Protected Effect Receipt
A qualified storage controller or observer produces evidence
identifying the committed object, resource version, operation
reference, and relevant protected state.
The evidence is represented as a Protected Effect Receipt.
9.5.3.12. Source page 418 of the original specification
S.4.2.4 — Independent IEV Validation
The IEV independently verifies the receipt against the authorized
upload, actual object, remote storage destination, expected commit
predicate, protected operation sequence, and current policy.
If the required storage condition is not established, the IEV does
not accept the receipt as sufficient for progression.
S.4.2.5 — Missing Confirmation Enablement
Before receipt acceptance, the confirmation message's necessary
execution-enabling condition remains unavailable.
In one implementation, the messaging Finality Sink requires a
protected phase-state reference that cannot be activated by the
untrusted agent.
In another implementation, the messaging component requires a scoped
cryptographic authenticator derived or released only after the IEV
accepts the receipt.
In another implementation, the relevant messaging credential-release
primitive remains sealed until the required receipt-dependent
condition exists.
S.4.2.6 — Receipt-Constituted Continuation
Das Expires 29 April 2027 [Page 256]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Successful IEV validation causes the protected system to establish
the missing confirmation-phase condition.
The accepted receipt is thereby the causal factor from which the
next-phase enablement is constituted.
A new, scope-bound continuation reference may identify the authorized
report confirmation, designated recipient, operation parameters, and
permitted use count.
S.4.2.7 — Finality Sink Verification
The confirmation-message Finality Sink independently verifies the
actual pending message and recipient against the receipt-derived
continuation authority.
Only the specifically authorized confirmation may be transmitted.
An unrelated message cannot be sent merely by presenting the report-
storage receipt.
S.4.2.8 — Failure Condition
If the remote upload was accepted but not committed, or if the
committed object does not match the authorized report, the necessary
confirmation-phase condition is not established.
The agent cannot bypass the requirement merely by generating a
plausible completion message.
S.4.2.9 — Technical Difference
The proposed distinction is not simply that the system checks whether
an upload succeeded before sending a message.
9.5.3.13. Source page 419 of the original specification
The stronger mechanism requires the accepted receipt from the actual
storage effect to constitute a necessary protected execution
condition for the confirmation effect.
The distinction is enforceable only where the messaging effectuation
path genuinely requires that condition.
S.4.3 — EXAMPLE COMBINING EMBODIMENTS 1 AND 2
Two autonomous agents are authorized to operate upon a shared
financial report.
Das Expires 29 April 2027 [Page 257]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Agent A is responsible for modifying and committing the report.
Agent B is responsible for transmitting the completed report to an
external recipient.
The system must enforce two separate requirements.
First, the report modification and transmission must not produce an
incompatible combined effect.
Second, Agent B's transmission must not become executable until the
required actual storage result of Agent A's operation has been
independently established.
S.4.3.1 — Protected Effect Arbitration
Embodiment 1 constructs effect footprints for the modification and
transmission operations.
The protected conflict system identifies the dependency between the
approved report version and the external disclosure.
A reservation is committed against the current protected conflict
state.
S.4.3.2 — First Real Effect
Agent A's storage operation is independently verified and permitted
through its designated Finality Sink.
The report is actually committed to the protected storage system.
S.4.3.3 — Receipt Formation
A qualified storage-state observer produces a protected receipt
identifying the actual committed report version.
S.4.3.4 — Independent Causal Validation
The IEV verifies that the committed version satisfies the authorized
predecessor predicate.
S.4.3.5 — Receipt-Dependent Authority Formation
The accepted receipt causes the required next-phase execution
condition for Agent B's transmission to be generated or activated.
Das Expires 29 April 2027 [Page 258]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Before receipt acceptance, Agent B cannot exercise valid authority
for that particular export through the controlled Finality Sink.
9.5.3.14. Source page 420 of the original specification
S.4.3.6 — Conflict-State Coordination
The protected conflict controller updates the relevant reservation
state according to the verified storage outcome.
The system may then determine whether Agent B's proposed export is
compatible with other pending consequential operations.
S.4.3.7 — Final Export
The export Finality Sink verifies the actual outgoing report,
destination, receipt-derived continuation condition, and applicable
current protected conflict state.
Only the matching authorized export is permitted.
S.4.3.8 — Technical Effect
The arrangement may prevent both:
An incompatible combined effect among independently authorized
agents; and
Premature export before the required real storage effect has
established the causal authority needed for transmission.
The result depends upon the relevant protected resource identity,
witness evidence, reservation mechanism, continuation enablement, and
actual Finality Sink enforcement.
S.4.4 — CRYPTOGRAPHIC EXAMPLE: RECEIPT-DEPENDENT DATA RELEASE
An autonomous computing system is authorized to release protected
information to a specified receiving domain in stages.
A first bounded real transmission is permitted under scoped
authority.
The receiving domain processes the bounded operation and generates
authenticated evidence of the actual permitted result.
The IEV independently validates the receipt.
Das Expires 29 April 2027 [Page 259]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Before validation, the subsequent protected data remains encrypted or
otherwise unusable because the required decryption or authorization
material has not been made available.
Following successful validation, a protected key service derives or
releases operation-specific cryptographic material using the accepted
receipt commitment and successor authorization context.
The material may be bound to the receiving domain, protected object,
continuation phase, and required Finality Sink.
The recipient or release controller verifies the resulting authority
and current protected state.
The broader information release then becomes possible through the
designated protected path.
An invalid or mismatched receipt cannot cause the required key
material to become available.
9.5.3.15. Source page 421 of the original specification
The receipt therefore participates directly in constituting the
cryptographic authority required for the subsequent consequential
effect.
The technical distinction is not merely that the system signs a
receipt.
It is that the next consequential release depends upon cryptographic
material whose generation or usability is controlled by accepted
prior-effect evidence.
S.4.5 — NON-CRYPTOGRAPHIC EXAMPLE: BOUNDED PHYSICAL ACTUATION
An autonomous controller is authorized to move a mechanical actuator
through a bounded sequence.
The initial phase permits only a defined real movement.
The actuator Finality Sink verifies the bounded command and releases
the first movement.
A protected sensor or controller observes the resulting physical
state.
The observation produces a protected receipt.
Das Expires 29 April 2027 [Page 260]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The IEV independently validates that the actual measured state
satisfies the required tolerance and applicable protected
constraints.
The next actuator command remains technically unavailable because a
protected controller latch or phase register has not yet been
activated.
After successful receipt validation, an atomic protected state
transition enables the specific next movement.
The next actuator Finality Sink verifies the actual command against
the updated protected state.
The subsequent movement is therefore causally dependent upon accepted
evidence of the earlier real movement.
No cryptographic key derivation is required in this particular
implementation.
The relevant technical condition is the protected, non-bypassable
dependency between actual-effect evidence, IEV acceptance, controller
state, and subsequent actuation.
S.4.6 — EXAMPLE OF UNKNOWN OUTCOME AND PREVENTION OF UNSAFE
CONTINUATION
An agent submits an authorized remote transaction.
The actual remote system may complete the operation, but the
acknowledgement is lost.
The originating system cannot establish whether the required effect
occurred.
The relevant operation's authority may already have been consumed.
The system therefore records an unresolved attempt.
9.5.3.16. Source page 422 of the original specification
The required accepted receipt for the next phase is unavailable.
The protected continuation condition remains inactive.
A subsequent consequential transaction or confirmation that requires
the prior result cannot become effective merely because the agent
retries the workflow.
Das Expires 29 April 2027 [Page 261]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The system may obtain additional authenticated evidence or initiate a
separately governed reconciliation process.
If the required prior effect is established, the IEV may accept the
corresponding evidence and enable the permitted next phase.
If the effect is confirmed absent, a separately authorized retry may
be considered.
If the outcome remains unknown, the protected hold persists for the
affected dependent operations.
This implementation distinguishes missing evidence from proof of non-
occurrence.
PART V — OVERALL INDUSTRIAL APPLICABILITY AND PRACTICAL REALIZATION
S.5.1 — TECHNICAL CHARACTER OF THE DISCLOSED SYSTEMS
Embodiments 1 and 2 concern technical systems that control actual
consequential operations rather than merely evaluating proposed
computational plans.
Embodiment 1 may implement protected concurrent-effect arbitration
through effect footprints, authenticated conflict representations,
atomic reservations, protected fencing, actual-operation
verification, and consequence-state reconciliation.
Embodiment 2 may implement protected causal effectuation through
bounded real phases, effect-derived receipts, independent IEV
validation, receipt-dependent execution conditions, and successor
Finality Sink enforcement.
The mechanisms may be implemented through protected software
services, operating-system mediators, transactional controllers,
firmware, secure processors, cryptographic key services,
authenticated state machines, network effectuation gateways, storage
controllers, and physical actuator interfaces.
The receipt-gated continuation mechanism may operate through a
cryptographic or non-cryptographic protected dependency.
The implementation need not require the same technical substrate for
every embodiment.
The common technical characteristic is that applicable protected
conditions must be satisfied before the corresponding controlled
consequence can become effective.
Das Expires 29 April 2027 [Page 262]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
S.5.2 — REPRODUCIBILITY AND PHOSITA IMPLEMENTATION
9.5.3.17. Source page 423 of the original specification
A person having ordinary skill in secure computing, distributed
systems, protected execution, transaction processing, autonomous
agent orchestration, cryptographic authorization, or hardware
controller design may implement selected aspects of the disclosed
architectures using the described structures and state transitions.
For Embodiment 1, a representative implementation may use:
1. Canonicalized Candidate Act descriptors.
2. Protected Effect Footprints.
3. Authenticated effect-domain mappings.
4. An Effect-Interference Graph or equivalent protected constraint
representation.
5. Atomic Protected Effect-Conflict Reservations.
6. Protected Graph-Fencing Commitments.
7. Scoped Finality Authorities.
8. Actual-operation reconstruction at the Finality Sink.
9. Protected outcome and reservation-state reconciliation.
For Embodiment 2, a representative implementation may use:
1. Phase-specific Candidate Act descriptors.
2. Protected bounded-effect authorization.
3. One or more Finality Sinks.
4. Qualified actual-effect observation.
5. Protected Effect Receipts.
6. An independently protected IEV.
7. Operation-bound receipt acceptance predicates.
8. Protected receipt-dependent continuation state.
Das Expires 29 April 2027 [Page 263]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9. Cryptographically derived or non-cryptographically activated
next-phase execution conditions.
10. Sink-side verification and consumption.
11. Protected unknown-outcome reconciliation.
12. Separately authorized recovery.
A cryptographic implementation may use authenticated receipt
commitments, protected derivation secrets, scoped signing operations,
threshold mechanisms, or sealed execution material.
9.5.3.18. Source page 424 of the original specification
A non-cryptographic implementation may use protected atomic phase-
state transitions, controller-owned latches, protected command
registers, transaction-state predicates, or an equivalent enforced
control mechanism.
Both implementations require that the untrusted agent cannot
independently create or bypass the missing next-phase execution
condition within the asserted enforcement boundary.
The detailed algorithms, record structures, threat models, and worked
examples disclosed in the relevant common workflows and embodiments
may be used as non-limiting implementation references.
S.5.3 — MODULAR INDUSTRIAL DEPLOYMENT
Embodiment 1 may operate without Embodiment 2 where protected cross-
agent effect compatibility is the principal requirement.
Embodiment 2 may operate without Embodiment 1 where the principal
requirement is receipt-gated causal progression through one or more
consequential phases.
Both mechanisms may be combined where a workflow involves multiple
agents, shared resources, or dependent effects.
In such a combined deployment, actual-effect receipts may control
protected reservation advancement as well as causal continuation.
CW-3 may be optionally invoked where the agent attempts to exceed the
originally authorized scope.
A valid scope expansion under CW-3 does not eliminate the receipt
requirement where receipt-gated continuation is mandatory.
Das Expires 29 April 2027 [Page 264]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Likewise, a valid IEV receipt does not independently authorize a
changed operation outside the original or validly amended task
authority.
The architectures therefore permit modular deployment without
treating every security feature as universally mandatory.
S.5.4 — TECHNOLOGY-NEUTRAL IMPLEMENTATION
The disclosed mechanisms may be implemented across different
computing environments.
A protected execution component may be implemented in software,
firmware, trusted processor code, hardware security logic, a remote
protected service, or another suitable substrate.
A receipt may be represented as a signed record, authenticated state
reference, protected memory object, controller event, transactional
commit record, or equivalent machine-verifiable evidence.
Receipt-dependent execution enablement may be implemented through:
A protected cryptographic key service.
A sealed execution capability.
9.5.3.19. Source page 425 of the original specification
A split-key protocol.
A threshold signing procedure.
A hardware latch.
A protected register.
An atomic transaction-state transition.
A controller-owned command queue.
A protected network release condition.
A protected storage-commit enablement.
The particular implementation may be selected according to the
resources and effects governed by the relevant system.
Das Expires 29 April 2027 [Page 265]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
No commercial vendor, processor brand, AI model provider, operating-
system family, or proprietary security platform is essential to the
general architecture.
S.5.5 — VERIFIABLE FEASIBILITY AND PERFORMANCE
Reference implementations of Embodiments 1 and 2 may be evaluated
using controlled fault-injection, concurrent operation, receipt-
replay, command-substitution, crash-recovery, and protected-state
manipulation experiments.
For Embodiment 1, representative measurements may include:
1. Unauthorized conflicting-effect acceptance rate.
2. Stale reservation rejection.
3. Actual-operation substitution rejection.
4. Reservation-state integrity under concurrency.
5. Compatible-operation throughput.
6. Correct release or retention of effect reservations.
7. Cross-domain operation-correlation accuracy.
8. Protected outcome-reconciliation correctness.
For Embodiment 2, representative measurements may include:
1. Next-phase effectuation attempts accepted without a required
receipt.
2. Invalid receipt acceptance rate.
3. Receipt replay acceptance rate.
9.5.3.20. Source page 426 of the original specification
4. Ability to bypass receipt-dependent enablement.
5. Incorrect phase-order acceptance rate.
6. Successor-operation substitution acceptance rate.
7. Protected continuation-state rollback resistance.
Das Expires 29 April 2027 [Page 266]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
8. Receipt-dependent key or latch activation correctness.
9. Duplicate continuation rejection.
10. Actual-effect evidence accuracy.
11. Unknown-outcome classification correctness.
12. Crash-recovery consistency.
13. Effectuation throughput.
14. Additional validation latency.
15. Protected-state storage and processing overhead.
A useful security experiment for the principal inter-phase IEV
implementation is to attempt the successor consequential effect
before generation or acceptance of the predecessor receipt.
The protected system should refuse effectuation because the required
continuation condition is unavailable.
A second experiment should provide a valid predecessor receipt and
verify that the corresponding execution condition becomes available
only for the specifically authorized successor operation.
A third experiment should substitute another Candidate Act, resource,
destination, or phase and verify that the same receipt-derived
condition cannot authorize the substituted effect.
A fourth experiment should remove the agent-level receipt-checking
code while retaining the protected Finality Sink.
Where the claimed receipt-gated dependency is correctly enforced, the
successor effect should remain unavailable without the required
protected receipt-dependent condition.
Such experiments help distinguish an enforcement mechanism from an
advisory workflow convention.
The existence of these proposed experiments does not constitute a
statement that any particular implementation has already been built
or tested.
S.5.6 — FAILURE-BOUNDARY TRANSPARENCY
Das Expires 29 April 2027 [Page 267]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The security guarantees of Embodiments 1 and 2 depend upon actual
implementation boundaries.
Where a consequential operation can bypass the relevant protected
Finality Sink, the asserted non-bypassability property does not
automatically apply.
9.5.3.21. Source page 427 of the original specification
Where an untrusted agent can directly activate the state or generate
the cryptographic material required for the next phase, the receipt-
dependent causal guarantee is not established.
Where a remote service or observation component cannot provide
trustworthy evidence of the required actual effect, the IEV must not
treat unsupported assertions as independently verified completion.
Where an external consequential effect has occurred but its outcome
remains unknown, the system must not presume that the effect can be
safely reversed or repeated.
Where the actual effectuation path is outside the protected
controller's authority, the implementation must identify that
limitation rather than assume universal enforcement.
The protected architecture may employ fail-closed behavior,
reconciliation, or separately authorized recovery according to the
applicable implementation.
S.5.7 — NON-LIMITING INDUSTRIAL CHARACTERIZATION
The mechanisms may be applied to autonomous computing, enterprise
automation, cloud infrastructure, financial operations,
telecommunications, storage services, robotics, industrial control,
software deployment, device management, secure communications, and
distributed workflows.
Their technical utility arises from controlling the actual release
and progression of consequential operations.
Embodiment 1 may preserve compatibility among concurrently acting
autonomous components.
Embodiment 2 may preserve causal validity among successive real-
effect phases by making accepted predecessor evidence a necessary
factor in later execution enablement.
Das Expires 29 April 2027 [Page 268]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The systems may thereby support controlled autonomy without requiring
every permitted operation to be manually approved.
S.5.8 — SPECIFIC INDUSTRIAL APPLICATIONS OF RECEIPT-GATED CAUSAL IEV
S.5.8.1 — Staged Software Deployment
An autonomous software deployment system may initially deploy a
software update to a bounded device population.
The first deployment is an actual consequential operation.
A protected observer may obtain evidence of the committed software
state, device identity, and relevant test result.
The IEV validates the receipt.
Successful validation causes the next deployment phase's required
authorization material or protected controller state to become
available.
9.5.3.22. Source page 428 of the original specification
The wider deployment controller independently verifies the actual
target population and approved software artifact.
A model-generated success prediction does not substitute for the
required real-effect receipt.
S.5.8.2 — Industrial Robotics
A protected robotic controller may permit an initial bounded actuator
movement.
A protected sensor measures the resulting state.
The IEV validates a receipt corresponding to the observed real
movement.
The accepted receipt activates a protected latch or command-state
transition for the next movement.
The next actuator command cannot become effective through the
controlled hardware interface without the required state transition.
S.5.8.3 — Telecommunications Infrastructure
Das Expires 29 April 2027 [Page 269]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A telecommunications management system may apply a limited network
configuration change before permitting a broader change.
The initial real operation may produce authenticated controller-state
or network-state evidence.
The IEV validates the required outcome.
The protected control-plane mechanism then establishes the missing
execution condition for the next authorized configuration phase.
S.5.8.4 — Cloud Resource Management
An autonomous cloud-management agent may provision or alter a bounded
subset of resources.
A qualified controller establishes the required actual resource
state.
The resulting protected receipt may be a necessary input to a
subsequent deployment or scaling authority.
A broader resource change remains unavailable until the IEV accepts
the required evidence.
S.5.8.5 — Secure Data Release
A sender may perform a bounded real recipient-side operation before
releasing a larger protected information object.
A protected receipt from the recipient-side effect may become a
necessary factor in releasing or deriving the cryptographic material
required for the later data release.
The relevant protected controller verifies the recipient, object,
operation scope, and receipt-derived authority.
S.5.8.6 — Financial Processing
9.5.3.23. Source page 429 of the original specification
Where supported by the technical transaction infrastructure, a first
bounded real operation may generate evidence required for a later
separately authorized financial consequence.
The subsequent authority may be conditioned upon accepted evidence of
the specific earlier state.
Das Expires 29 April 2027 [Page 270]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The system must distinguish authorization, submission, settlement,
and other relevant financial conditions according to the actual
available evidence.
A missing acknowledgement does not automatically authorize a
duplicate financial operation.
S.5.8.7 — Autonomous Device Maintenance
A device-maintenance agent may apply a bounded configuration or
firmware-state operation.
A protected controller may observe the committed result.
The IEV validates the receipt.
Only then does the protected device controller activate the permitted
next-phase command.
S.5.8.8 — Protected Storage and Publication
A system may first commit a bounded object to protected storage.
A qualified receipt may establish the required actual committed
state.
The accepted receipt may then enable a separately scoped publication,
export, or external-transmission operation.
The publication effect remains unavailable through the controlled
interface until the necessary receipt-derived continuation condition
exists.
S.5.9 — PRACTICAL CRYPTOGRAPHIC IMPLEMENTATION
In one non-limiting implementation, a protected key service maintains
an execution secret inaccessible to the requesting agent.
The successor Finality Sink requires a phase-specific authenticator.
The authenticator is derived or released only after IEV validation of
the accepted prior-effect receipt.
A representative construction may bind:
ProtectedRootSecret
AcceptedReceiptCommitment
Das Expires 29 April 2027 [Page 271]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
OriginalCandidateActDigest
SuccessorCandidateActDigest
SuccessorFinalitySinkIdentity
9.5.3.24. Source page 430 of the original specification
AuthorityEpoch
ProtectedPhaseCounter The protected service may produce a scoped
authenticator, a signed command authorization, a decryption key, or a
key share.
The successor Finality Sink verifies the resulting material and
actual pending operation.
A raw public receipt digest is not sufficient to create the required
protection if all other derivation inputs and signing capabilities
are available to the untrusted agent.
The protected secret or required cryptographic operation must remain
under the control of the applicable protected authority.
The construction may use suitable cryptographic algorithms without
limiting the invention to a particular algorithm.
S.5.10 — PRACTICAL NON-CRYPTOGRAPHIC IMPLEMENTATION
In another non-limiting implementation, an actuator or effectuation
controller maintains a protected phase register.
The register initially indicates that the successor operation is
disabled.
The earlier bounded real effect is permitted.
A qualified observation component produces a protected completion
record.
The IEV validates the record.
A protected atomic state transition advances the phase register and
activates the successor's permitted command state.
The Finality Sink checks the register and actual command before
actuation.
Das Expires 29 April 2027 [Page 272]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The requesting agent cannot directly set the protected register to
the required value.
The same concept may be implemented through a protected network
gateway, storage controller, transaction scheduler, or command-
dispatch component.
Cryptographic derivation is optional in this variant.
The required protection arises from the enforced state dependency and
control over the actual effectuation path.
S.5.11 — INDUSTRIAL ADVANTAGE OF OPTIONAL EXECUTION MODES
Different consequential systems may require different forms of IEV
enforcement.
A high-throughput transaction system may prefer protected
transactional state.
9.5.3.25. Source page 431 of the original specification
A protected network service may prefer scoped cryptographic execution
handles.
A device controller may prefer hardware phase registers.
A secure data-transfer service may prefer receipt-dependent key
release.
A distributed workflow may combine cryptographic authentication with
protected atomic continuation state.
The invention is not limited to one substrate merely because one
implementation uses cryptographic receipts or keys.
The technically relevant common property is that the required next-
phase execution condition cannot be validly established independently
of accepted evidence arising from the preceding real consequential
phase.
PART VI — CONCLUDING TECHNICAL DISTINCTION AND INVENTIVE-STEP
STATEMENT
S.6.1 — EMBODIMENT 1
Das Expires 29 April 2027 [Page 273]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The proposed subject matter of Embodiment 1 should not be
characterized merely as a conventional distributed lock, conflict
graph, multi-agent scheduler, database transaction, fencing token, or
access-control gateway.
Its potentially distinguishing arrangement concerns protected
relationships among independently authorized consequential
operations.
In particular, the architecture may employ:
Protected effect-specific footprints;
A protected effect-interference representation;
Atomic effect reservations;
Operation-bound fencing commitments;
Independent actual-operation reconstruction at the Finality Sink;
Verification of current protected conflict state;
And consequence-aware reservation reconciliation.
The potentially significant technical combination is the linkage of
protected cross-operation compatibility state to the actual
consequential operation that the relevant Finality Sink is about to
permit.
The system may prevent individually authorized agents from producing
a prohibited combined effect through controlled effectuation
boundaries.
The relevant inventive step depends upon whether that particular
enforced relationship is disclosed or rendered obvious by the closest
prior art.
9.5.3.26. Source page 432 of the original specification
S.6.2 — EMBODIMENT 2: CORRECTED PRINCIPAL INVENTIVE CHARACTERIZATION
The proposed subject matter of Embodiment 2 should not be
characterized merely as a conventional multi-step workflow, receipt
checker, transaction checkpoint, saga, audit system, post-hoc
validator, canary monitor, or generic approval gate.
Das Expires 29 April 2027 [Page 274]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
In its principal inter-phase realization, Embodiment 2 discloses a
protected, causally ordered, receipt-gated effectuation mechanism.
An earlier authorized bounded real effect produces protected
evidence.
The IEV independently validates that evidence against the applicable
Candidate Act, actual observed result, required effect predicate,
phase identity, authority state, and protected consumption
conditions.
Successful validation causes a necessary next-phase execution
condition to be established.
The condition may comprise a cryptographic key, scoped authenticator,
missing key share, protected non-bearer capability, hardware latch,
secure controller state, transactional enablement, or another
protected prerequisite.
The next consequential operation remains technically unavailable
through the covered enforcement architecture before the required
receipt-dependent condition exists.
The successor Finality Sink independently verifies the actual
operation and the receipt-derived authority or protected continuation
state.
Accordingly, the receipt is not merely a record that the system
consults before voluntarily proceeding.
The accepted receipt is a constitutive causal factor in the formation
or activation of the execution authority required for the next real
consequential phase.
The separate optional in-line IEV implementation may additionally
verify an actual prepared operation before its principal
consequential effect, with an appropriately bound protected
validation result.
The two IEV modes may be implemented independently or jointly.
The potentially distinguishing technical feature of the principal
inter-phase implementation is the enforced receipt-to-execution
dependency, not merely chronological workflow sequencing.
S.6.3 — COMMON EXECUTION-FINALITY RELATIONSHIP
Both embodiments may operate under the principle:
Das Expires 29 April 2027 [Page 275]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Computation is not authority to act.
An autonomous agent's generation of a plan, command, explanation, or
predicted outcome does not independently establish valid finality
authority.
9.5.3.27. Source page 433 of the original specification
Under Embodiment 1, the operation must additionally satisfy protected
effect-compatibility requirements where applicable.
Under Embodiment 2, an operation requiring receipt-gated continuation
must possess the protected execution condition established through
accepted evidence of the required preceding real effect.
A successfully validated receipt does not automatically override an
incompatible conflict reservation.
A valid conflict reservation does not automatically establish the
accepted receipt required for the successor phase.
The Finality Sink independently verifies the actual pending operation
against the required protected authority and state.
In an optional combined implementation, the system may enforce both
concurrent effect compatibility and sequential receipt-derived causal
authority.
S.6.4 — PROPOSED INVENTIVE-STEP FRAMEWORK
The proposed technical combinations are subject to examination
against the relevant prior art.
The inventive-step analysis should distinguish known constituent
mechanisms from the specific technical relationships claimed.
For Embodiment 1, relevant prior art may include distributed locks,
fencing tokens, transaction isolation, conflict graphs, multi-agent
planning, access-control gateways, and consequence-aware scheduling.
For Embodiment 2, relevant prior art may include staged execution,
canary deployment, proof-dependent authorization, cryptographic
capability derivation, distributed transactions, state-machine
interlocks, receipt-gated protocols, and hardware-controlled phase
progression.
Das Expires 29 April 2027 [Page 276]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The mere use of an IEV, receipt, cryptographic key, hardware latch,
graph, or protected controller does not automatically establish
novelty.
A meaningful comparison should determine whether the particular
prior-art arrangement already provides the required causal or
conflict-enforcement relationship.
S.6.4.1 — Candidate Inventive-Step Question for Embodiment 1
Whether the relevant prior art discloses or renders obvious an
arrangement in which protected effect-specific interference among
independently authorized Candidate Acts is committed through
operation-bound reservations, independently verified against actual
pending effects at designated Finality Sinks, and reconciled
according to trustworthy consequence state.
S.6.4.2 — Candidate Inventive-Step Question for Embodiment 2
Whether the relevant prior art discloses or renders obvious an
arrangement in which evidence produced by a preceding bounded real
effect is independently validated and the accepted receipt becomes a
necessary constitutive input to the protected execution-enabling
condition for the next
9.5.3.28. Source page 434 of the original specification
specifically authorized real effect, with independent Finality Sink
verification and protected replay, freshness, and state-consumption
requirements.
S.6.4.3 — Candidate Combined Inventive-Step Question
Whether the relevant prior art discloses or renders obvious a system
in which an accepted causal effect receipt both establishes or
activates successor-specific execution enablement and governs
protected conflict-reservation advancement for other independently
authorized consequential operations.
S.6.4.4 — Hindsight Considerations
Where multiple references are combined during an inventive-step
assessment, the analysis should identify the actual technical reason
why a PHOSITA would have combined their teachings in the claimed
arrangement.
Das Expires 29 April 2027 [Page 277]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
The mere fact that conventional systems separately disclose receipts,
protected keys, locks, workflow stages, or Finality Sink-like
gateways does not automatically establish every required causal or
state relationship.
Conversely, the fact that the applicant has assigned distinct
terminology to those relationships does not automatically distinguish
the claimed system from the prior art.
The technical analysis should examine the actual architecture, trust
boundaries, state transitions, necessary authority dependencies, and
observable effects.
S.6.4.5 — Priority and Disclosure Qualification
The technical mechanisms described in this supplementary section are
proposed for incorporation into the relevant patent disclosure.
Any claim to an earlier priority date requires support for the
specific claimed subject matter in the corresponding earlier
application as filed.
Later elaboration, additional examples, or newly introduced
implementation variants do not automatically acquire an earlier
filing date.
S.6.5 — FINAL NON-LIMITING STATEMENT
Embodiments 1 and 2 provide different, optionally composable
mechanisms for controlling consequential operations performed by
autonomous computing entities.
Embodiment 1 governs protected compatibility among effects of
independently authorized Candidate Acts.
Embodiment 2 governs protected causal authority among separately
consequential real phases.
In a principal implementation of Embodiment 2, a bounded real effect
produces protected evidence, and independent IEV validation of that
evidence establishes the necessary execution-enabling condition for
the next effect.
Das Expires 29 April 2027 [Page 278]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.5.3.29. Source page 435 of the original specification
The accepted receipt may constitute the causal factor that enables
the next phase through cryptographic derivation, protected capability
formation, hardware state transition, transaction-state activation,
or another non-bypassable protected control.
The later phase cannot be validly effectuated through the controlled
architecture merely because the agent chooses to proceed.
The required receipt-dependent authority must first exist and must be
verified at the corresponding Finality Sink.
Where the protected receipt is absent, invalid, stale, mismatched,
replayed, or insufficiently supported by actual effect evidence, the
required continuation condition remains unavailable or unusable.
Where Embodiment 1 is additionally implemented, the successor
operation must also satisfy applicable protected conflict-reservation
requirements.
The disclosed technical mechanisms may be implemented using
cryptographic or non-cryptographic protected enforcement, including
secure processors, operating-system mediators, protected application
gateways, transactional state machines, hardware controllers, and
other suitable computing environments.
The proposed subject matter is directed to enforceable technical
relationships among real consequential effects, protected evidence,
independently established authority, and actual effectuation
boundaries.
For Embodiment 1, the candidate technical kernel is protected,
effect-specific cross-agent arbitration verified at the actual
Finality Sink and reconciled according to consequence state.
For Embodiment 2, the candidate technical kernel is independently
validated, real-effect receipt-constituted causal authority, in which
the accepted receipt is a required enabling factor for the next
consequential operation rather than a merely descriptive or post-hoc
success record.
The novelty and inventive step of the particular claimed combinations
remain subject to the applicable prior-art assessment.
END OF SUPPLEMENTARY TECHNICAL DISCLOSURE — EMBODIMENT 1 AND 2
EMBODIMENT 3
Das Expires 29 April 2027 [Page 279]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
PROTECTED USER-REFERENCED SEMANTIC OBJECT CORRESPONDENCE WITH
AUTHENTICATED PRESENTATION-STATE BINDING, CROSS-MODAL ENTITY
RESOLUTION, AND INDEPENDENT FINALITY-SINK RECONSTRUCTION
3.0 — COMPLETE TECHNICAL TITLE
9.5.3.30. Source page 436 of the original specification
Systems and Methods for Protected Correspondence Between User-
Referenced Information, Semantically Resolved Computational Objects,
and Actually Effectuated Operations Using Authenticated Presentation
Evidence, Temporal Entity-Identity Continuity, Protected Semantic
Binding Commitments, and Independent Finality-Sink Verification
3.0.1 — General Characterization
The present embodiment discloses systems, methods, apparatus,
protected computing components, cryptographically authenticated
records, machine-verifiable semantic correspondence protocols,
protected state-transition mechanisms, and non-limiting
implementations for preserving correspondence between a resource or
operation referenced by a user and the actual consequential operation
performed by an autonomous computing system.
The architecture may apply to autonomous artificial-intelligence
agents, on-device assistants, operating-system services, application
agents, computer-use systems, browser automation, accessibility
interfaces, multimodal assistants, remote agents, wearable computing
devices, spatial computing systems, robotic controllers, and
distributed application frameworks.
In one non-limiting implementation, a user issues an instruction
referring to information presented through a computing interface.
The reference may include expressions such as:
"This document."
"That photograph."
"The third message."
"The file I selected."
"Send the currently displayed report."
"Delete the item immediately above this one."
Das Expires 29 April 2027 [Page 280]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
"Share the highlighted object."
"Pay the invoice shown here."
"Move that object."
The user may identify the intended object through speech, text,
pointing, touch, gaze, selection, gesture, spatial reference, or
another input modality.
The autonomous agent may resolve the reference into a computational
object, entity identifier, application resource, tool argument,
command target, or corresponding operation descriptor.
However, resolution of the user's reference does not, by itself,
establish that the correct object will ultimately be affected.
Between the user's reference and the actual consequential operation,
the application interface may change, a resource may be replaced, a
list may reorder, another window may gain focus, an object may be
deleted and recreated, a provider may remap an entity identifier, or
an agent may select an incorrect target.
9.6. Supporting Original Embodiment 4 Disclosure: Cross-Domain Actual-
Effect Evidence for Causal Receipt Qualification
Original global source page range: 493-554 inclusive, original
uploaded PDF segment: TECHNICAL SPECIFICATION -1-554.pdf. Primary in
this part: False. Page-extract fidelity limitations and independent
filing-priority analysis are stated in the source note.
9.6.1. Architecture and Protected Trust-Relationship Diagram
[Originator CA / bounded effect intent]
|
[Remote resource / separate admin domain]
|
[Remote actual-state observation sources]
/ | \
[Receiver] [Independent witness] [State proof]
\ | /
[Evidence qualification]
|
[Protected remote-outcome interpretation]
|
[IEV / successor dependency if CW-2 applies]
|
[Receiving resource Finality Sink]
Das Expires 29 April 2027 [Page 281]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Figure 24: Supporting Original Embodiment 4 Disclosure: Cross-
Domain Actual- Effect Evidence for Causal Receipt Qualification —
architecture and protected dependencies
9.6.2. Operational Decision Flowchart and Refusal Conditions
[Earlier request sent to remote domain]
|
<Receiver merely accepted request?>--YES-->[NOT PROOF OF EFFECT]
|NO
[Check qualified actual outcome observations]
|
<Sufficient binding and witness trust?>--NO-->[INDETERMINATE]
|YES
<Actual observed predicate met?>--NO-->[WITHHOLD]
|YES
[IEV accept under CW-2, where required]
|
<Successor grant + sink state current?>--NO-->[REFUSE]
|YES
[Permit separately authorized successor]
Figure 25: Supporting Original Embodiment 4 Disclosure: Cross-
Domain Actual- Effect Evidence for Causal Receipt Qualification —
decision flowchart
9.6.3. Original Source Page-Indexed Technical Content
9.6.3.1. Source page 493 of the original specification
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 282]
Internet-Draft Execution-Finality Part 6: Receipts 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 283]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.2. Source page 494 of the original specification
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 284]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.3. Source page 495 of the original specification
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 285]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.4. Source page 496 of the original specification
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 286]
Internet-Draft Execution-Finality Part 6: Receipts 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 287]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A remote operation may involve several technical stages.
9.6.3.5. Source page 497 of the original specification
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 288]
Internet-Draft Execution-Finality Part 6: Receipts 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;
9.6.3.6. Source page 498 of the original specification
• 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 289]
Internet-Draft Execution-Finality Part 6: Receipts 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)
9.6.3.7. Source page 499 of the original specification
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 290]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.8. Source page 500 of the original specification
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 291]
Internet-Draft Execution-Finality Part 6: Receipts 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 292]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
A PROC may be used by CW-2 as an input to continuation validation.
4.4.14 — Remote Outcome Reconciliation Fence (RORF)
9.6.3.9. Source page 501 of the original specification
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 293]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.10. Source page 502 of the original specification
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 294]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.11. Source page 503 of the original specification
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 295]
Internet-Draft Execution-Finality Part 6: Receipts 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 296]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.6.3.12. Source page 504 of the original specification
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 297]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.6.3.13. Source page 505 of the original specification
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 298]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.14. Source page 506 of the original specification
4.7.2 — Representative Data Structure
Das Expires 29 April 2027 [Page 299]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.15. Source page 507 of the original specification
The implementation may convert the objective into measurable
technical conditions.
Das Expires 29 April 2027 [Page 300]
Internet-Draft Execution-Finality Part 6: Receipts 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 301]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.16. Source page 508 of the original specification
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 302]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.17. Source page 509 of the original specification
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 303]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.6.3.18. Source page 510 of the original specification
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 304]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.19. Source page 511 of the original specification
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 305]
Internet-Draft Execution-Finality Part 6: Receipts 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 306]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.6.3.20. Source page 512 of the original specification
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 307]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.21. Source page 513 of the original specification
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 308]
Internet-Draft Execution-Finality Part 6: Receipts 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))
9.6.3.22. Source page 514 of the original specification
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 309]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.23. Source page 515 of the original specification
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 310]
Internet-Draft Execution-Finality Part 6: Receipts 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 311]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.6.3.24. Source page 516 of the original specification
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 312]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.6.3.25. Source page 517 of the original specification
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 313]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
witness_requirements = RESOLVE_REQUIRED_WITNESS_ASSURANCE( predicate,
protected_policy )
cdeid = { candidate_act_digest: HASH(candidate_act),
remote_destination:
9.6.3.26. Source page 518 of the original specification
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 )
9.6.3.27. Source page 519 of the original specification
attempt_id = PED.ALLOCATE_PROTECTED_ATTEMPT_ID()
Das Expires 29 April 2027 [Page 314]
Internet-Draft Execution-Finality Part 6: Receipts 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
)
9.6.3.28. Source page 520 of the original specification
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 315]
Internet-Draft Execution-Finality Part 6: Receipts 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 )
9.6.3.29. Source page 521 of the original specification
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 316]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
dispatch_digest: HASH(originating_dispatch_record),
9.6.3.30. Source page 522 of the original specification
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 )
9.6.3.31. Source page 523 of the original specification
REQUIRE VERIFY_AFTER_STATE_BINDING( after_state_record,
protected_transaction_record )
REQUIRE VERIFY_COMMIT_SEQUENCE( protected_transaction_record )
Das Expires 29 April 2027 [Page 317]
Internet-Draft Execution-Finality Part 6: Receipts 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 )
9.6.3.32. Source page 524 of the original specification
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 318]
Internet-Draft Execution-Finality Part 6: Receipts 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 )
9.6.3.33. Source page 525 of the original specification
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 319]
Internet-Draft Execution-Finality Part 6: Receipts 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:
9.6.3.34. Source page 526 of the original specification
"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 320]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.35. Source page 527 of the original specification
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 321]
Internet-Draft Execution-Finality Part 6: Receipts 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 322]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.6.3.36. Source page 528 of the original specification
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 323]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.37. Source page 529 of the original specification
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 324]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.38. Source page 530 of the original specification
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 325]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.39. Source page 531 of the original specification
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 326]
Internet-Draft Execution-Finality Part 6: Receipts 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 327]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
It does not classify the intended external effect as independently
verified merely because the service returned success.
4.26.4 — Continuation Policy
9.6.3.40. Source page 532 of the original specification
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 328]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.41. Source page 533 of the original specification
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 329]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.42. Source page 534 of the original specification
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 330]
Internet-Draft Execution-Finality Part 6: Receipts 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 331]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
9.6.3.43. Source page 535 of the original specification
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 332]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.44. Source page 536 of the original specification
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 333]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.6.3.45. Source page 537 of the original specification
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 334]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.6.3.46. Source page 538 of the original specification
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 335]
Internet-Draft Execution-Finality Part 6: Receipts 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 336]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
4.31.18 — Idempotency-Key Reuse
9.6.3.47. Source page 539 of the original specification
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 337]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.6.3.48. Source page 540 of the original specification
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 338]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.6.3.49. Source page 541 of the original specification
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 339]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.50. Source page 542 of the original specification
Experiment 3 — Signed False Success Statement
Provide an authenticated remote success report while withholding the
required state change.
Das Expires 29 April 2027 [Page 340]
Internet-Draft Execution-Finality Part 6: Receipts 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 341]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.51. Source page 543 of the original specification
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 342]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.6.3.52. Source page 544 of the original specification
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 343]
Internet-Draft Execution-Finality Part 6: Receipts 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;
9.6.3.53. Source page 545 of the original specification
• 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 344]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.6.3.54. Source page 546 of the original specification
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 345]
Internet-Draft Execution-Finality Part 6: Receipts 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 346]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.55. Source page 547 of the original specification
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 347]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.6.3.56. Source page 548 of the original specification
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 348]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.57. Source page 549 of the original specification
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 349]
Internet-Draft Execution-Finality Part 6: Receipts 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 350]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Such principles are established in distributed computing and
security.
9.6.3.58. Source page 550 of the original specification
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 351]
Internet-Draft Execution-Finality Part 6: Receipts 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
9.6.3.59. Source page 551 of the original specification
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 352]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.60. Source page 552 of the original specification
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 353]
Internet-Draft Execution-Finality Part 6: Receipts 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 354]
Internet-Draft Execution-Finality Part 6: Receipts 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.
9.6.3.61. Source page 553 of the original specification
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 355]
Internet-Draft Execution-Finality Part 6: Receipts 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;
9.6.3.62. Source page 554 of the original specification
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 356]
Internet-Draft Execution-Finality Part 6: Receipts 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.
10. Detailed Security Threat Models, Adversary Capabilities, Controls
and Residual Risks
These are newly authored security engineering analyses and not
allegations of vulnerabilities in any named commercial
implementation. They identify where the actual covered effect,
current authority and independent evidence are required, and state
residual risks where mandatory interfaces or trust anchors are
unavailable.
Das Expires 29 April 2027 [Page 357]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
10.1. Threat Model 1: Prompt Injection and Fabricated Phase Success
Adversary behavior and trigger: A lower-trust document or external
tool output instructs the agent to report shipment, payment, firmware
update or device actuation success without a real predecessor effect.
Protected assets and trust boundaries: Trusted outcome observer,
protected effect receipt, source grant and phase predicate.
Required or illustrative countermeasure: Accept only evidence
independently qualified by IEV under the specified actual-result
predicate; agent narratives are not continuation credentials.
Residual limitation: Remote systems that do not expose a qualified
outcome observer cannot promise certain effect verification.
10.2. Threat Model 2: Replayed, Substituted or Cross-Workflow Effect
Receipt
Adversary behavior and trigger: Attacker copies a valid PER/VAER from
prior workflow, different principal, resource, recipient, or phase.
Protected assets and trust boundaries: Workflow ID, phase and actual
resource, digest, protected epoch and sink-local usage record.
Required or illustrative countermeasure: Verify exact predecessor
source/effect/phase binding and successor destination; consume
single-use CCC; check freshness and current authority.
Residual limitation: Compromised protected state/cryptographic trust
roots may invalidate replay defenses.
10.3. Threat Model 3: Forge or Impersonate Validator or Outcome
Observer
Adversary behavior and trigger: Attacker signs an apparent acceptance
with a compromised or impersonated IEV identity, or constructs a
fabricated remote effect witness.
Protected assets and trust boundaries: Authenticated validator
eligibility, witness provenance, protected key material and current
membership.
Required or illustrative countermeasure: Verify current identity and
independently qualified evidence; scope validator acceptances;
rotate/revoke compromised keys, bind operation and outcome under
protected policy.
Das Expires 29 April 2027 [Page 358]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Residual limitation: A compromised qualified observer may produce
false evidence; validator authentication alone cannot prove
observations.
10.4. Threat Model 4: Request Acceptance Confused With Completed Real
Effect
Adversary behavior and trigger: The gateway returns 202 Accepted or
queues a payment while physical or financial effect is still pending
or has failed.
Protected assets and trust boundaries: Explicit effect predicate
distinguishing request, dispatch, acceptance, commit, settlement and
physical outcome.
Required or illustrative countermeasure: Specify the exact required
state, qualify authenticated receiver-side evidence before forming
VAER; keep successor NES when only dispatch is proved.
Residual limitation: Some remote providers expose limited evidence;
qualified completion may be unobservable at the chosen boundary.
10.5. Threat Model 5: Privilege Escalation Through Causal Continuation
Adversary behavior and trigger: Valid predecessor receipt is used to
authorize a different operation, larger payment, altered recipient or
broader resource access.
Protected assets and trust boundaries: Original source grant,
successor scope, new resource and actual sink reconstruction.
Required or illustrative countermeasure: Treat VAER as necessary but
insufficient; require current bounded successor authority and exact
operation/recipient/resource state at final sink.
Residual limitation: Compromised source policy root or uncontrolled
resource bypasses may defeat guarantees.
10.6. Threat Model 6: Non-Bypassable Gateway Failure and Alternate
Effectuation Path
Adversary behavior and trigger: An agent or privileged connector
performs the successor effect through direct network, file, IPC or
hardware path not requiring the CCC.
Protected assets and trust boundaries: Enforcement coverage and
actual effectuation interfaces.
Das Expires 29 April 2027 [Page 359]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Required or illustrative countermeasure: Identify all covered paths,
remove uncontrolled reusable secret access and require sink-side
protected condition at each reachable governed resource.
Residual limitation: Can only guarantee effects within the explicitly
controlled boundary; a third-party mobile app cannot intercept all OS
operations.
10.7. Threat Model 7: Time-of-Check/Time-of-Use and Stale Effect State
Adversary behavior and trigger: A predecessor resource changes,
expires, is revoked or is compensated between observation and
successor dispatch.
Protected assets and trust boundaries: Resource version, evidence
validity period, revocation generation and protected continuation
state.
Required or illustrative countermeasure: Bind relevant effect and
resource generations to PER/VAER and revalidate current material
conditions at successor sink.
Residual limitation: External systems may not expose real-time state;
strict freshness across disconnected networks is impossible without
suitable controls.
10.8. Threat Model 8: Lost Acknowledgement, Duplicate Retry and Crash
Recovery
Adversary behavior and trigger: A predecessor or successor effect
occurs but its acknowledgement is lost; agent retries causing
duplicate payment, message or actuation.
Protected assets and trust boundaries: Protected operation identity,
effect journal, resource observation, consumption state and outcome
reconciler.
Required or illustrative countermeasure: Record durable consumption/
attempt, treat uncertain outcome as INDETERMINATE, reconcile actual
state and require separate recovery authority for new effects.
Residual limitation: No generic guarantee of exactly-once real
effects across independent remote domains without receiver
cooperation.
Das Expires 29 April 2027 [Page 360]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
10.9. Threat Model 9: Causal Graph Cycle, Dependency Substitution and
Branch Skipping
Adversary behavior and trigger: Malformed causal DAG produces a
cycle, substitutes receipt for one branch, or omits a required
prerequisite.
Protected assets and trust boundaries: Protected dependency graph,
phase identity, branch and source-authorized predecessor predicates.
Required or illustrative countermeasure: Authenticate graph and
required dependencies, bound fanout/depth, check every mandatory
accepted receipt before forming successor CCC.
Residual limitation: Very large graphs may exhaust resources and harm
availability; policy limits required.
10.10. Threat Model 10: Compromised Infrastructure, State Rollback and
Validator Denial of Service
Adversary behavior and trigger: Admin or storage attacker rewinds
VAER/CCC consumption, corrupts monotonic state or floods evidence
verifier to trigger fail-open.
Protected assets and trust boundaries: Protected keys, durable sink
state, bounded verifier work, monotonic authority generations.
Required or illustrative countermeasure: Use independent trust
boundaries, transactionally protected single-use state, rate/size
limits, protected audit and fail-closed refusal when required checks
unavailable.
Residual limitation: Compromise of all designated security roots and
resource interfaces defeats the defined model; fail-closed reduces
availability.
11. Reproducible Validation Plan and Twenty-Four Proposed Security
Tests
No following assertion is represented as an actually executed
laboratory result. A reproducible GitHub implementation should
provide trust-model fixtures, verifier/receiver source revisions,
test keys, synthetic identity grants, canonical serializations,
deterministic resource states, operation/predicate logs, expected and
observed outcomes, actual denial of the consequential effect, and
safe cleanup. If a test rejects a request but a side-effect occurred
by an alternate route, it has failed the non-bypass test.
Das Expires 29 April 2027 [Page 361]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
11.1. CR01 — Valid two-phase effect and continuation
Setup and test stimulus: Qualified source grant; first resource
commits the exact approved effect; IEV correctly accepts the
supported PER. Supply an actual effect-capable *test* resource,
protected source grant, structured predecessor and successor
Candidate Acts, current evidence epoch and mock/non-production
credentials.
Expected positive or negative result: VAER/CCC formed; successor sink
verifies exact act and consumes once; authorized next effect occurs.
Record actual resource before-and-after state, specific receipt/CCC
state and reason codes; a log-only refusal does not prove absence of
the covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.2. CR02 — Agent fabricates a success message
Setup and test stimulus: No predecessor effect; LLM sends plausible
success text to scheduler. Supply an actual effect-capable *test*
resource, protected source grant, structured predecessor and
successor Candidate Acts, current evidence epoch and mock/non-
production credentials.
Expected positive or negative result: No VAER from trusted IEV,
successor denied. Record actual resource before-and-after state,
specific receipt/CCC state and reason codes; a log-only refusal does
not prove absence of the covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.3. CR03 — HTTP 202 but no committed effect
Setup and test stimulus: Receiver acknowledges queue admission only;
downstream commit absent. Supply an actual effect-capable *test*
resource, protected source grant, structured predecessor and
successor Candidate Acts, current evidence epoch and mock/non-
production credentials.
Das Expires 29 April 2027 [Page 362]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Expected positive or negative result: Do not treat receipt as
qualified completed real effect where commit is mandatory. Record
actual resource before-and-after state, specific receipt/CCC state
and reason codes; a log-only refusal does not prove absence of the
covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.4. CR04 — Wrong predecessor resource
Setup and test stimulus: Valid receipt for resource A, source
requires B. Supply an actual effect-capable *test* resource,
protected source grant, structured predecessor and successor
Candidate Acts, current evidence epoch and mock/non-production
credentials.
Expected positive or negative result: IEV or receiving sink rejects
mismatched dependency. Record actual resource before-and-after
state, specific receipt/CCC state and reason codes; a log-only
refusal does not prove absence of the covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.5. CR05 — Wrong predecessor phase
Setup and test stimulus: Valid receipt for phase 1 replayed as phase
2. Supply an actual effect-capable *test* resource, protected source
grant, structured predecessor and successor Candidate Acts, current
evidence epoch and mock/non-production credentials.
Expected positive or negative result: Refuse VAER or CCC bound to
incorrect phase. Record actual resource before-and-after state,
specific receipt/CCC state and reason codes; a log-only refusal does
not prove absence of the covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
Das Expires 29 April 2027 [Page 363]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
11.6. CR06 — Incorrect effect predicate
Setup and test stimulus: Signed observer evidence reports partial
inventory allocation but required exact allocation not reached.
Supply an actual effect-capable *test* resource, protected source
grant, structured predecessor and successor Candidate Acts, current
evidence epoch and mock/non-production credentials.
Expected positive or negative result: Withhold successor whose
predicate was not satisfied. Record actual resource before-and-after
state, specific receipt/CCC state and reason codes; a log-only
refusal does not prove absence of the covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.7. CR07 — Forged observer evidence
Setup and test stimulus: External agent supplies fake transaction or
device-state statement. Supply an actual effect-capable *test*
resource, protected source grant, structured predecessor and
successor Candidate Acts, current evidence epoch and mock/non-
production credentials.
Expected positive or negative result: Validator refuses absent
qualified observer authentication. Record actual resource before-
and-after state, specific receipt/CCC state and reason codes; a log-
only refusal does not prove absence of the covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.8. CR08 — Forged validator acceptance
Setup and test stimulus: Agent constructs syntactically correct VAER
with unauthorized signing identity. Supply an actual effect-capable
*test* resource, protected source grant, structured predecessor and
successor Candidate Acts, current evidence epoch and mock/non-
production credentials.
Expected positive or negative result: Reject in validator/successor
sink. Record actual resource before-and-after state, specific
receipt/CCC state and reason codes; a log-only refusal does not prove
absence of the covered consequence.
Das Expires 29 April 2027 [Page 364]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.9. CR09 — Valid VAER with changed successor recipient
Setup and test stimulus: Original authorized successor pays account
A; attacker changes receiving account B. Supply an actual effect-
capable *test* resource, protected source grant, structured
predecessor and successor Candidate Acts, current evidence epoch and
mock/non-production credentials.
Expected positive or negative result: Sink reconstructs B and rejects
despite valid predecessor receipt. Record actual resource before-
and-after state, specific receipt/CCC state and reason codes; a log-
only refusal does not prove absence of the covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.10. CR10 — Revocation after IEV acceptance
Setup and test stimulus: Source authority withdrawn after VAER was
issued but before successor dispatch. Supply an actual effect-
capable *test* resource, protected source grant, structured
predecessor and successor Candidate Acts, current evidence epoch and
mock/non-production credentials.
Expected positive or negative result: Current sink predicate rejects
successor. Record actual resource before-and-after state, specific
receipt/CCC state and reason codes; a log-only refusal does not prove
absence of the covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.11. CR11 — Expired predecessor observation
Setup and test stimulus: Receipt outside permitted freshness bound.
Supply an actual effect-capable *test* resource, protected source
grant, structured predecessor and successor Candidate Acts, current
evidence epoch and mock/non-production credentials.
Das Expires 29 April 2027 [Page 365]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Expected positive or negative result: Do not create/use required CCC.
Record actual resource before-and-after state, specific receipt/CCC
state and reason codes; a log-only refusal does not prove absence of
the covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.12. CR12 — Replay a consumed CCC
Setup and test stimulus: Run valid successor once; retry with
identical VAER and CCC. Supply an actual effect-capable *test*
resource, protected source grant, structured predecessor and
successor Candidate Acts, current evidence epoch and mock/non-
production credentials.
Expected positive or negative result: Second effect blocked by
durable usage/consumption state. Record actual resource before-and-
after state, specific receipt/CCC state and reason codes; a log-only
refusal does not prove absence of the covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.13. CR13 — Crash after protected consumption
Setup and test stimulus: Kill gateway after consume but before
external acknowledgment. Supply an actual effect-capable *test*
resource, protected source grant, structured predecessor and
successor Candidate Acts, current evidence epoch and mock/non-
production credentials.
Expected positive or negative result: Preserve authoritative state;
no unsafe reset or automatic duplicate effect. Record actual
resource before-and-after state, specific receipt/CCC state and
reason codes; a log-only refusal does not prove absence of the
covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
Das Expires 29 April 2027 [Page 366]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
11.14. CR14 — Network timeout with remote success
Setup and test stimulus: Remote resource actually changes state but
response lost. Supply an actual effect-capable *test* resource,
protected source grant, structured predecessor and successor
Candidate Acts, current evidence epoch and mock/non-production
credentials.
Expected positive or negative result: Mark outcome uncertain;
reconcile receiver effect; do not double-submit. Record actual
resource before-and-after state, specific receipt/CCC state and
reason codes; a log-only refusal does not prove absence of the
covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.15. CR15 — Network timeout with confirmed non-effect
Setup and test stimulus: Resource proves request never committed;
recovery path formally authorized. Supply an actual effect-capable
*test* resource, protected source grant, structured predecessor and
successor Candidate Acts, current evidence epoch and mock/non-
production credentials.
Expected positive or negative result: Original attempt not confused
with effect; handle retry only under permitted policy. Record actual
resource before-and-after state, specific receipt/CCC state and
reason codes; a log-only refusal does not prove absence of the
covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.16. CR16 — Required multiple predecessor receipts
Setup and test stimulus: Successor requires actual effects A and B;
only A is qualified. Supply an actual effect-capable *test*
resource, protected source grant, structured predecessor and
successor Candidate Acts, current evidence epoch and mock/non-
production credentials.
Das Expires 29 April 2027 [Page 367]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Expected positive or negative result: Withhold successor until B is
separately satisfied. Record actual resource before-and-after state,
specific receipt/CCC state and reason codes; a log-only refusal does
not prove absence of the covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.17. CR17 — Causal graph branch substitution
Setup and test stimulus: Receipt from unauthorized alternate branch
injected. Supply an actual effect-capable *test* resource, protected
source grant, structured predecessor and successor Candidate Acts,
current evidence epoch and mock/non-production credentials.
Expected positive or negative result: Reject mismatched source-
authorized dependency graph. Record actual resource before-and-after
state, specific receipt/CCC state and reason codes; a log-only
refusal does not prove absence of the covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.18. CR18 — Missing independent IEV gate
Setup and test stimulus: Agent tries to directly set protected CCC-
ready flag. Supply an actual effect-capable *test* resource,
protected source grant, structured predecessor and successor
Candidate Acts, current evidence epoch and mock/non-production
credentials.
Expected positive or negative result: Denied unless protected
validator establishes mandatory condition. Record actual resource
before-and-after state, specific receipt/CCC state and reason codes;
a log-only refusal does not prove absence of the covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
Das Expires 29 April 2027 [Page 368]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
11.19. CR19 — Direct alternate API bypass attempt
Setup and test stimulus: Protected gateway refuses request, attacker
invokes effect resource via alternative open path. Supply an actual
effect-capable *test* resource, protected source grant, structured
predecessor and successor Candidate Acts, current evidence epoch and
mock/non-production credentials.
Expected positive or negative result: Test only passes if covered
consequence cannot occur; report uncovered paths as a limitation.
Record actual resource before-and-after state, specific receipt/CCC
state and reason codes; a log-only refusal does not prove absence of
the covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.20. CR20 — Wrong designated Finality Sink
Setup and test stimulus: CCC minted for receiver S1 replayed at S2.
Supply an actual effect-capable *test* resource, protected source
grant, structured predecessor and successor Candidate Acts, current
evidence epoch and mock/non-production credentials.
Expected positive or negative result: S2 refuses under sink binding.
Record actual resource before-and-after state, specific receipt/CCC
state and reason codes; a log-only refusal does not prove absence of
the covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.21. CR21 — Concurrent double successor
Setup and test stimulus: Two agent processes race using same accepted
VAER. Supply an actual effect-capable *test* resource, protected
source grant, structured predecessor and successor Candidate Acts,
current evidence epoch and mock/non-production credentials.
Expected positive or negative result: At most allowed bound number of
effects after authoritative consumption. Record actual resource
before-and-after state, specific receipt/CCC state and reason codes;
a log-only refusal does not prove absence of the covered consequence.
Das Expires 29 April 2027 [Page 369]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.22. CR22 — Insufficient remote causation evidence
Setup and test stimulus: Witness observes later resource state but
cannot establish operation-specific origin when required. Supply an
actual effect-capable *test* resource, protected source grant,
structured predecessor and successor Candidate Acts, current evidence
epoch and mock/non-production credentials.
Expected positive or negative result: Reject strict causation
predicate or explicitly downgrade assurance under allowed policy.
Record actual resource before-and-after state, specific receipt/CCC
state and reason codes; a log-only refusal does not prove absence of
the covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
11.23. CR23 — Android and iOS cooperating gateway
Setup and test stimulus: Supported mobile app APIs invoke same
controlled receiver for authorized then altered operation. Supply an
actual effect-capable *test* resource, protected source grant,
structured predecessor and successor Candidate Acts, current evidence
epoch and mock/non-production credentials.
Expected positive or negative result: Permit properly bound effect
and deny mismatch without claiming universal OS-wide mediation.
Record actual resource before-and-after state, specific receipt/CCC
state and reason codes; a log-only refusal does not prove absence of
the covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
Das Expires 29 April 2027 [Page 370]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
11.24. CR24 — DoS and verifier exhaustion
Setup and test stimulus: Very deep cyclic dependency graph and
oversized evidence payload. Supply an actual effect-capable *test*
resource, protected source grant, structured predecessor and
successor Candidate Acts, current evidence epoch and mock/non-
production credentials.
Expected positive or negative result: Bound verifier cost, return
refusal/limited error, never silently release the effect. Record
actual resource before-and-after state, specific receipt/CCC state
and reason codes; a log-only refusal does not prove absence of the
covered consequence.
Execution status: PROPOSED, NOT EXECUTED. No pass/fail result is
claimed. Any future published test run requires source version,
fixtures, full command, output, environment and reproducibility
details.
12. Detailed Industry and Product Alignment: Causal Security for
Mobile, AI Agents, Enterprise APIs and Critical Systems
Named operating systems, products and vendors are described as
relevant classes for security analysis, never as actual adopters of
this disclosure, infringement targets, contributors or endorsers.
Some examples require resource-provider cooperation or privileged
platform integration; they are not implementable through arbitrary
third-party app privileges. These industry mappings are newly
authored interpretation and should not be confused with source
excerpts. Apple, Siri, iOS, iPadOS, macOS, Android, Gemini, Bixby,
Copilot, Alexa, Matter, and other names used in this document are
trademarks of their respective owners.
12.1. Apple iOS, iPadOS, Siri, Shortcuts and App Intents
Industry security problem: A third-party assistant may first request
file authorization and later publish, upload or modify a different
resource based on an apparent successful preparation step. App
Intents and app-to-service callbacks can express stages but cannot
make an untrusted app report sufficient effect evidence.
Possible implementation and product/security alignment: Use
cooperating source and destination apps or servers; protect actual
receipt predicates (file committed, provider grant activated) and
verify successor effect at receiver. Standard iOS third-party apps
cannot intercept all privileged system or other-app I/O.
Das Expires 29 April 2027 [Page 371]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
12.2. Apple macOS Desktop Agents and Secure Automation
Industry security problem: Mac automation may edit a file, initiate a
build, deploy artifacts or transmit data; successful shell command
does not guarantee the desired external state.
Possible implementation and product/security alignment: A privileged
cooperating host service or resource server can qualify the exact
prior effect and gate a follow-on publication or deployment step.
macOS Keychain or signatures contribute identities, not proof of
every actual effect.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
12.3. Google Android, Gemini, Intents, Binder and Keystore
Industry security problem: An Android agent can invoke an Intent or
Binder service and receive a return value while an external provider
completes the operation asynchronously.
Possible implementation and product/security alignment: Bind receipts
to actual operation/result in cooperating receiver APIs, verify
authoritative effect observation and protect current Android app/
account grants; Keystore protects cryptographic keys but not business
outcome semantics.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
12.4. Microsoft Windows, Azure and Enterprise Agent Governance
Industry security problem: Agent pipelines can provision cloud
resources, modify access policies and launch deployment tasks where
intermediate API acknowledgement differs from committed target state.
Possible implementation and product/security alignment: Independent
effect verifier may read committed resource versions/qualified
provider attestations and constitute CCC for dependent release of
another governed effect.
Das Expires 29 April 2027 [Page 372]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
12.5. OpenAI Responses API, Agents SDK, Codex and Tool Calling
Industry security problem: An AI agent can hallucinate tool
completion or accept poisoned tool output and attempt a consequential
next tool action.
Possible implementation and product/security alignment: Treat
language-model output and tool results as untrusted proposals;
enforce the required effect predicate at a protected external
resource and prevent successor action absent protected evidence.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
12.6. Anthropic Claude, Claude Code and Managed Agents
Industry security problem: Long-running assistant or coding agent can
chain shell commands, workflows and deployments, with retries after
crashes or ambiguous external status.
Possible implementation and product/security alignment: Deploy
independent receiving resource controls, outcome-based receipts and
current scoped grants for each material successor; sandbox success
cannot establish final external effect.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
12.7. Google Cloud and Enterprise SaaS Orchestration
Industry security problem: Cloud workflows can chain object creation,
reservation, notification, permission changes and API calls across
independently administered services.
Possible implementation and product/security alignment: Use resource-
native outcome evidence, authenticated workload identity, version
conditions and operation-scoped non-bearer finality instead of
treating scheduler checkpoints as authorization.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
Das Expires 29 April 2027 [Page 373]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
12.8. Meta Muse/Sentinel Agent Security
Industry security problem: Isolated agent runtimes, credential
substitution and protected egress are relevant to restricting action
paths; inter-phase guarantees raise an additional question of actual
effect completion.
Possible implementation and product/security alignment: Technical
comparison should distinguish network request approval from verified
external resource effect and required next-phase CCC; published Meta
details do not automatically imply identical receipt-gated
mechanisms.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
12.9. NVIDIA OpenShell, BlueField, Sentry and Accelerators
Industry security problem: Protected gateway/DPU enforcement and
compute accelerators may execute remote commands or queue work whose
completion is separate from issuance.
Possible implementation and product/security alignment: A qualified
hardware/host observer could contribute status or command completion
evidence; any causal successor gate must bind the measured actual
effect to prior authorized act and designated sink.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
12.10. Qualcomm Snapdragon, Arm, Huawei and Device Security
Industry security problem: Mobile and embedded trust functions can
guard keys, attest software state and mediate selected privileged
device operations; multi-stage effects span distinct hardware and OS
components.
Possible implementation and product/security alignment: Use hardware-
protected identities or monotonic state where supported, but retain
separate source-grant and actual-effect checks. Vendor-specific
privileged drivers must be explicitly documented.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
Das Expires 29 April 2027 [Page 374]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
12.11. Banking, Payment APIs and Digital Commerce
Industry security problem: Payment authorization, capture, clearing,
settlement and receipt are distinct states; an accepted payment
request can fail before irrevocable monetary effect.
Possible implementation and product/security alignment: Specify which
actual state qualifies a successor (shipment, refund, credential
release); require protected resource evidence and separate authority
for each later consequential transfer.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
12.12. Industrial Robotics, Vehicles and Connected Devices
Industry security problem: An earlier physical command may not
achieve measured position, pressure, voltage, lock state or actuator
condition before another movement begins.
Possible implementation and product/security alignment: Use suitable
trusted sensors and controller-side interlocks to qualify actual
predecessor conditions, bound freshness and activate next command
only through controlled receiving interface.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
12.13. Telecommunications, Edge Networks and 5G/6G
Industry security problem: Service activation, policy
reconfiguration, key installation and network route provisioning may
complete asynchronously across vendors and administrative domains.
Possible implementation and product/security alignment: Qualify
explicit observed protected network resource state before subsequent
dependent change; do not equate control-plane acceptance with applied
forwarding or hardware configuration.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
Das Expires 29 April 2027 [Page 375]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
12.14. Storage, Databases, Release Pipelines and Content Distribution
Industry security problem: A database write, build artifact upload or
CI workflow status can be acknowledged before dependent distribution
is safe.
Possible implementation and product/security alignment: Use committed
resource versions and qualified signed outcomes as predecessor
predicates; independent publisher/recipient Finality Sink checks
exact artifact, source authority and protected consumption.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
12.15. Voice and System Assistants: Apple Siri, Google Gemini, Samsung
Bixby, Microsoft Copilot and Amazon Alexa
Industry security problem: A single spoken request such as "book the
table, pay the deposit and tell my friends" becomes a chain of app
actions invoked through App Intents and Shortcuts, Android intents or
assistant skills. Assistants typically advance to the next action
when the previous app call returns, not when the reservation is
actually confirmed by the restaurant's system; a prompt-injected
message or a silent failure can therefore cause a deposit to be paid
or invitations to be sent for a booking that does not exist.
Possible implementation and product/security alignment: The receiving
app or backend for each step acts as Finality Sink and accepts a step
only with a VAER issued for the preceding step's confirmed resource
state (for example, a booking record in CONFIRMED state with matching
party size and time). Third-party implementers can enforce this only
at their own action handlers and servers; private assistant internals
are not assumed to be available.
Technical effect: Each assistant-initiated step is executed only
after protected evidence of the actual predecessor effect, so a
failed or fabricated earlier step cannot trigger later payments or
messages, and a lost reply produces an indeterminate state instead of
a duplicate action.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
Das Expires 29 April 2027 [Page 376]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
12.16. Agentic Commerce, Checkout and Digital Wallets
Industry security problem: AI shopping agents can place orders and
initiate payments through digital wallets, tokenized cards or payment
APIs on the user's behalf. Common failure orders include charging
before stock is reserved, confirming an order on a payment
authorization that is later declined, and retrying a timed-out
payment so that it settles twice.
Possible implementation and product/security alignment: Bind the
payment Candidate Act to a VAER for the inventory reservation and the
price quote actually held by the merchant; bind fulfilment to a VAER
for settlement or capture rather than to the payment request; use
receiver-enforced idempotency for retries and treat timeouts as
indeterminate until the payment processor's qualified outcome is
observed.
Technical effect: Funds move only after the predecessor commercial
state is verified, fulfilment starts only after the actual capture is
verified, and duplicate charges from retries are prevented by single-
use CCC consumption at the payment sink.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
12.17. E-Commerce Logistics, Shipping and Returns
Industry security problem: Order-management agents may mark items as
shipped when a shipping label is created, or issue refunds when a
return label is generated, even though no parcel has been handed to a
carrier or received back.
Possible implementation and product/security alignment: Use carrier
scan events or warehouse system state, authenticated by an IEV, as
effect predicates: "handed to carrier" for shipment notifications and
invoicing, "received and inspected" for refunds.
Technical effect: Customer notifications, invoices and refunds are
released only after a verified physical-logistics event, reducing
refund fraud and false shipment claims driven by agent-generated
status messages.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
Das Expires 29 April 2027 [Page 377]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
12.18. Healthcare Ordering, Dispensing and Clinical Workflow Automation
Industry security problem: Clinical assistants and workflow
automation can chain steps such as order entry, verification,
dispensing and administration or follow-up scheduling. Advancing on
a submitted order rather than a verified clinician signature or
pharmacy verification can let a later step act on an incomplete or
altered predecessor.
Possible implementation and product/security alignment: Model each
step as a phase whose successor requires a VAER for the actual
predecessor state recorded in the clinical system (for example,
through authenticated reads of records exposed by interfaces such as
HL7 FHIR), with mandatory human verification steps represented as
required predecessor receipts that an agent cannot fabricate. This
is an engineering pattern, not a medical-device or clinical-safety
certification.
Technical effect: A downstream clinical action cannot proceed on an
unverified or altered upstream step, and every phase transition
leaves an auditable, source-bound record supporting post-incident
review.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
12.19. Insurance Claims, Lending and Disbursement
Industry security problem: Claims and loan agents can trigger payouts
or disbursements after a document upload or an assessment request,
before the required assessment, identity verification or underwriting
decision has actually been recorded.
Possible implementation and product/security alignment: Require VAERs
for each mandatory predecessor (verified identity, completed
assessment, signed agreement) and bind the disbursement Candidate Act
to their exact identifiers and amounts at the payment sink.
Technical effect: Disbursement is technically impossible without
verified completion of every required predecessor step, and replaying
an old approval for a second payout fails at the sink.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
Das Expires 29 April 2027 [Page 378]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
12.20. Travel and Booking Chains
Industry security problem: Travel agents book dependent items in
sequence: flight, then hotel, then car or transfer. A temporary hold
or a "pending" response is often treated as a confirmed ticket,
leaving the user with non-refundable downstream bookings for a trip
whose first leg was never ticketed.
Possible implementation and product/security alignment: Treat ticket
issuance (not reservation hold) as the effect predicate for
continuation; bind downstream bookings to the issued ticket's
identifiers and dates; reconcile indeterminate outcomes before any
retry.
Technical effect: Dependent bookings are made only after the anchor
booking is verifiably issued, preventing orphaned non-refundable
purchases and duplicate tickets after lost confirmations.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
12.21. Smart Home, Matter Devices and Physical Access
Industry security problem: Home assistants chain device actions, for
example disarming an alarm, unlocking a door and turning on lights,
or closing a valve before starting a pump. Device commands are
frequently acknowledged on transmission, not on actuation.
Possible implementation and product/security alignment: Use
authenticated device state reports, such as attribute reports from
Matter devices or vendor hub APIs, as IEV-qualified predicates; gate
safety-relevant successors (start pump, open door) on verified
actuator state, not on command acknowledgement.
Technical effect: A physical successor action is withheld until the
safety-relevant predecessor state is verified, reducing unsafe
sequences caused by lost commands, stale state or injected
instructions.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
Das Expires 29 April 2027 [Page 379]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
12.22. Automotive Assistants, Apple CarPlay, Android Auto and Over-the-
Air Updates
Industry security problem: In-vehicle assistants and fleet systems
can trigger remote actions (unlock, climate, charging schedules) and
software update phases. Installing an update because a download was
requested, or because the vehicle reported "parked" earlier, can act
on stale or unverified state.
Possible implementation and product/security alignment: Require VAERs
for verified download integrity, signature validation and current
vehicle state immediately before the install phase; bind remote
vehicle commands to verified owner authority and current vehicle
state at the vehicle-side sink.
Technical effect: Update installation and remote commands proceed
only on fresh, verified predecessor state, reducing failed installs,
unsafe operation while in motion and replay of old remote-command
approvals.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
12.23. Energy, Utilities and Grid Switching
Industry security problem: Switching and maintenance procedures are
strictly ordered: isolate, verify isolation, then work or re-
energize. Automation that advances on a command sent rather than a
verified breaker or sensor state can create hazardous conditions;
distributed energy resources add many remote devices with uncertain
acknowledgements.
Possible implementation and product/security alignment: Represent
each switching step as a phase whose successor requires an IEV-
qualified receipt from independent telemetry, with offline and
partition behaviour defined to withhold rather than assume success.
Technical effect: Re-energization or dispatch commands cannot be
issued without verified isolation or readiness state, providing a
machine-enforced counterpart to manual verification steps.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
Das Expires 29 April 2027 [Page 380]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
12.24. Government Digital Identity, Electronic Signatures and the EU
Digital Identity Wallet
Industry security problem: Agent-assisted government and banking
flows may issue a credential, apply a qualified signature or submit a
filing after a presentation or consent step that was requested but
not actually completed or verified.
Possible implementation and product/security alignment: Bind signing
or submission Candidate Acts to VAERs for the verified presentation,
consent and user authentication actually recorded by the relying
party, and consume each continuation condition once.
Technical effect: Signatures, credential issuance and filings occur
only after verified, non-replayable predecessor steps, strengthening
auditability of agent-assisted interactions with digital identity
wallets.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
12.25. Customer Service, CRM and Refund Agents
Industry security problem: Customer-service agents frequently chain
"verify customer, check eligibility, issue refund or credit, close
ticket". A manipulated conversation can lead the agent to claim that
eligibility was verified when no check ran.
Possible implementation and product/security alignment: Require VAERs
from the eligibility and identity systems themselves, not from the
conversational agent, before the refund sink accepts a credit
Candidate Act bound to the specific order and amount.
Technical effect: Refunds and credits are issued only when the system
of record confirms eligibility, preventing social-engineering and
prompt-injection refunds that rely on the agent's own assertion.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
Das Expires 29 April 2027 [Page 381]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
12.26. Laboratory Automation, Manufacturing Execution Systems and
Quality Release
Industry security problem: Lab robots and manufacturing execution
systems run ordered steps such as dispensing, incubation, measurement
and batch release. Advancing on a scheduled step completion rather
than a verified measurement can release a batch that failed or
skipped a quality check.
Possible implementation and product/security alignment: Use
instrument-signed results and MES records as IEV-qualified
predicates; bind batch release to VAERs for every mandatory quality
step.
Technical effect: Batch release and downstream processing are
technically gated on verified results, producing a tamper-evident
chain of phase receipts.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
12.27. Software Release Pipelines, App Store and Google Play Staged
Rollouts
Industry security problem: Release agents can promote a build to
wider rollout after a deployment request rather than after verified
canary health, or publish to an app store track after an upload is
accepted but before processing and review complete.
Possible implementation and product/security alignment: Treat
verified canary metrics, signed build provenance and store processing
state as predecessor predicates; bind each promotion to the exact
artifact digest and rollout percentage at the release sink.
Technical effect: Wider rollout or publication occurs only after the
previous stage is verified for the exact artifact, limiting blast
radius from agent-driven releases.
Scope note: applicability is a technical example rather than evidence
that any named system currently implements the full protected
receipt/CCC relationship.
Das Expires 29 April 2027 [Page 382]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
12.28. Summary of Technical Effects Across Industries
The following technical effects are the design objectives of the
receipt and continuation mechanism. They are stated as testable
properties; the proposed CR01 to CR24 tests describe how each can be
measured, and no measured results are claimed in this revision.
1. Effect-gated continuation: a successor consequential operation is
not executed unless a qualified, validator-accepted receipt shows
that the required predecessor effect actually occurred, so
failed, skipped or fabricated steps cannot trigger later effects
(tests CR02, CR03, CR18).
2. Separation of acceptance from completion: protocol-level
acceptance, such as HTTP 202 or a queued job, is distinguished
from a committed effect, so asynchronous systems do not advance
on requests that later fail (tests CR03, CR14, CR15).
3. Replay and duplication resistance: each Causal Continuation
Condition is single-use and bound to one workflow, phase,
resource and successor, preventing duplicate payments, shipments
or actuations after retries and preventing reuse of old receipts
in other workflows (tests CR12, CR21).
4. Binding of successor parameters: a valid predecessor receipt does
not authorize a changed recipient, amount or target in the
successor, which is reconstructed and compared at the Finality
Sink (tests CR09, CR20).
5. Independence from agent assertions: continuation depends on
evidence from authenticated validators and systems of record
rather than on text produced by the agent, removing a direct path
from prompt injection to downstream effects (tests CR02, CR07,
CR08).
6. Safe handling of uncertainty: lost acknowledgements and crashes
leave the workflow in an explicit indeterminate state that blocks
successors and duplicate retries until reconciliation, instead of
guessing success or failure (tests CR13, CR14).
7. Freshness and revocation: receipts and continuation authority
expire and are re-checked against current source authority, so
revoked or stale approvals cannot advance a workflow (tests CR10,
CR11).
Das Expires 29 April 2027 [Page 383]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
8. Cross-platform portability: canonical effect predicates and
receipts allow the same control to operate across iOS, Android,
desktop, cloud and device boundaries where cooperating receivers
exist (test CR23).
9. Bounded verification cost and auditability: verification work per
transition is bounded, and every transition produces a source-
bound record suitable for audit and post-incident analysis (tests
CR24, and the audit algorithm above).
13. Detailed Relevance to IETF Working Groups, Standards and Internet-
Drafts
These are technical adjacency and interoperability analyses, not
assertions of working-group adoption, endorsement or that a specific
existing RFC lacks the security properties within its defined scope.
Current WG charters and RFC status should be rechecked when an
Internet-Draft revision is submitted; the URL in each subsection is a
scope-reference location.
13.1. OAuth: Structured Delegated Authorization and Current Source
Grants
Primary references: [RFC6749], [RFC9396], [RFC8707], [RFC8693],
[RFC9449], [RFC7009].
Existing RFC, working-group charter or technical problem: OAuth
allows clients to obtain and present resource-access tokens with
defined scopes, audience and endpoint validation. RFC 9396 adds Rich
Authorization Requests; RFC 8707 resource indicators, RFC 8693 token
exchange, RFC 9449 DPoP and RFC 7009 revocation can contribute
existing authorization building blocks. OAuth working-group
discussions also include automated-agent authorization across
multiple administrative domains.
Specific causal-receipt security relationship and implementation
limits: Map a current principal grant and successor resource scope
into interoperable authorization inputs, but treat actual
predecessor-effect proof and successor-specific CCC as a separately
verified application/resource enforcement condition. A valid access
token does not inherently certify a prior external effect.
Working group/document index for scope verification:
https://datatracker.ietf.org/wg/oauth/about/
Das Expires 29 April 2027 [Page 384]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
13.2. WIMSE: Workload Identity Across Administrative Boundaries
Primary references: [WIMSE].
Existing RFC, working-group charter or technical problem: WIMSE
addresses workload identity propagation, representation, runtime
identities, credentials and authentication across multi-system cloud
environments, with emerging work on AI workload scenarios.
Specific causal-receipt security relationship and implementation
limits: Use authenticated IEV and observer workload identity as
necessary provenance ingredients. Distinguish identity or
authentication of the validator from veracity of operation-specific
observed effects and from a designated successor sink decision.
Working group/document index for scope verification:
https://datatracker.ietf.org/wg/wimse/about/
13.3. RATS: Attestation and Trustworthiness of Verifiers or Observers
Primary references: [RFC9334].
Existing RFC, working-group charter or technical problem: RATS RFC
9334 defines Attesters, Verifiers and Relying Parties and an
appraisal model for remote platform evidence; attestation results can
support confidence in the observation or verifier environment.
Specific causal-receipt security relationship and implementation
limits: An attested IEV or protected remote observer may be a source
of assurance, but platform integrity evidence is not, by itself,
proof that a particular payment settled or robot reached the required
state. Bind attested actors to actual predicates and application
authorization.
Working group/document index for scope verification:
https://datatracker.ietf.org/wg/rats/about/
13.4. COSE/CBOR: Authenticated Machine-Readable Receipt Objects
Primary references: [RFC9052], [RFC8949].
Existing RFC, working-group charter or technical problem: RFC 8949
defines CBOR and RFC 9052 specifies COSE message structures. These
may carry compact signed or MAC-protected typed effect evidence and
validator decisions under chosen security profiles.
Das Expires 29 April 2027 [Page 385]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Specific causal-receipt security relationship and implementation
limits: Define typed canonical fields, issuer/audience/resource/phase
binding, key rollover and countersignature semantics if designing
interoperable PER/VAER; a COSE signature authenticates signed data
but does not guarantee underlying physical outcome truth.
Working group/document index for scope verification:
https://datatracker.ietf.org/wg/cose/about/
13.5. SCITT: Signed Statements and Transparent Technical Evidence
Primary references: [SCITT].
Existing RFC, working-group charter or technical problem: SCITT
addresses signed statements, registration and transparency mechanisms
for statements and their provenance under documented trust policies.
Specific causal-receipt security relationship and implementation
limits: PER/VAER decisions may optionally be recorded or
transparently logged for later technical examination, subject to
privacy and log trust. A transparency registration receipt is not
necessarily an actual-effect receipt or a valid continuation
condition.
Working group/document index for scope verification:
https://datatracker.ietf.org/wg/scitt/about/
13.6. ACE: Constrained Device Authorization
Primary references: [RFC9200].
Existing RFC, working-group charter or technical problem: RFC 9200
adapts OAuth concepts for authentication and authorization of
constrained IoT environments, with profiles and resource-server
support relevant to connected devices.
Specific causal-receipt security relationship and implementation
limits: Use protected authorization/actor identity in constrained
resource controllers and implement a mandatory actuator-specific
state/latch that depends on qualified predecessor evidence where
hardware resources support it. Do not assume universal smart-device
effect control.
Working group/document index for scope verification:
https://datatracker.ietf.org/wg/ace/about/
Das Expires 29 April 2027 [Page 386]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
13.7. HTTPBIS: Semantics, Conditional Requests and Asynchronous Effects
Primary references: [RFC9110].
Existing RFC, working-group charter or technical problem: RFC 9110
defines HTTP methods, response semantics, conditional request headers
such as If-Match and distinctions among response codes. These are
essential for representing resource operation and version state.
Specific causal-receipt security relationship and implementation
limits: Define whether a particular HTTP response represents accepted
request, persisted mutation or actual domain-specific effect. Bind
qualified resource observations and current versions to receipt
predicates. HTTP 202 is not an unambiguous proof of completed remote
effect.
Working group/document index for scope verification:
https://datatracker.ietf.org/wg/httpbis/about/
13.8. SEC-DISPATCH and Security Area: Cross-Layer Technical Problem
Framing
Existing RFC, working-group charter or technical problem: Security-
area dispatch considers which existing working groups, workshops or
new venues should examine cross-protocol security problems;
participation does not imply the work has become an adopted standard.
Specific causal-receipt security relationship and implementation
limits: Clearly bound possible interop artifacts (PER/VAER data
model, causal lineage, verifier identity, machine-readable refusal
reasons and CCC validation requirements) while retaining this
document as individual public technical disclosure until a suitable
venue adopts work.
Working group/document index for scope verification:
https://datatracker.ietf.org/wg/secdispatch/about/
13.9. Transactional and Data Consistency Semantics Across Services
Existing RFC, working-group charter or technical problem: There is no
general IETF guarantee of atomic, exactly-once business effects
across independent payment services, applications and hardware
controllers. Existing transport security, authenticated messages and
HTTP preconditions serve different layers.
Specific causal-receipt security relationship and implementation
limits: Treat idempotency, source grants, predicate evidence,
protected consumption, uncertain remote outcomes and independent
Das Expires 29 April 2027 [Page 387]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
receiver enforcement as separate engineering obligations; do not
assert that a transport acknowledgement completes the application-
level effect.
Working group/document index for scope verification:
https://datatracker.ietf.org/wg/httpbis/about/
14. 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 388]
Internet-Draft Execution-Finality Part 6: Receipts 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.
15. Security and Privacy Considerations, Operational Availability and
Trust Boundaries
15.1. Authenticity versus causal truth
A signed witness statement or valid IEV key demonstrates
authenticated provenance under a trust model, not that remote
consequential causation necessarily occurred; match the actual
required effect predicate and trusted observation interface.
15.2. Finality and replay
Protect validator acceptance, CCC state and sink consumption against
rollback and duplication. A valid earlier actual effect cannot be
used to release unrelated successor actions.
15.3. Time, lease and revocation
Qualify time, current source grants, accepted evidence epochs and
sink state. Offline trust assumptions and bounded permission caches
must be made explicit; an unreachable authority does not support an
unconditional immediate revocation claim.
Das Expires 29 April 2027 [Page 389]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
15.4. Asynchronous remote effects and uncertainty
Do not infer actual receiver completion from dispatch, queue
acknowledgment or missing timeout. Use protected indeterminate
outcome state and resource reconciliation before separate retries or
compensations.
15.5. Denial of service and bounded verification
Bound causal graph depth, receipt count, witness and signature
parsing, remote retries, signature verification and evidence
collection. Mandatory verification exhaustion must not turn into
allow-on-timeout.
15.6. Device and platform permissions
On iOS/Android, privileged cross-app mediation requires cooperating
endpoints or operating-system privilege. Application-owned resources
can enforce receipt gating more readily than arbitrary uncontrolled
external effects.
15.7. Confidentiality of evidence and logs
Receipts may expose financial, user, medical, device, location or
business resource information. Minimize content, protect
authorization for evidence access, support retention limits and avoid
leaking verifier private keys.
15.8. Dependency and conflict composition
Causal receipt checks complement, but do not replace, current
conflict/reservation checks, resource identity matching and source-
authorized scope deviation handling as required by the operation.
15.9. Failure handling and source novelty
This draft includes new non-normative implementation examples,
diagrams, threat models and proposed tests; they are not evidence of
successful operation or of historic inclusion in any earlier patent
filing.
Das Expires 29 April 2027 [Page 390]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
16. Patent Examiner and Industry Discovery Index: Original Pages,
Figures and Supporting Source Boundaries
Common Workflow CW-2: Causally Ordered Real-Effect Execution and
Protected Validator-Accepted Receipts: original global pages 63-119;
PDF segment TECHNICAL SPECIFICATION -1-554.pdf; corresponding page
anchors `cw2-page-<global-page>`; architecture `fig-
cw2-architecture`; decision flowchart `fig-cw2-flowchart`.
Common Workflow Implementation Clarification: Optional Causal
Controls and Correct Relationship to CW-1 and CW-3: original global
pages 179-196; PDF segment TECHNICAL SPECIFICATION -1-554.pdf;
corresponding page anchors `cw-imp-page-<global-page>`; architecture
`fig-cw-imp-architecture`; decision flowchart `fig-cw-imp-flowchart`.
Embodiment 2: Identity-Bound Interim Effectuation Validator and Non-
Bypassable Receipt-Constituted Authority: original global pages
295-363; PDF segment TECHNICAL SPECIFICATION -1-554.pdf;
corresponding page anchors `emb2-page-<global-page>`; architecture
`fig-emb2-architecture`; decision flowchart `fig-emb2-flowchart`.
Supplementary Disclosure for Embodiment 2: Non-Replayable Receipt-
Gated Phase Activation: original global pages 378-406; PDF segment
TECHNICAL SPECIFICATION -1-554.pdf; corresponding page anchors `emb2-
supp-page-<global-page>`; architecture `fig-emb2-supp-architecture`;
decision flowchart `fig-emb2-supp-flowchart`.
Combined Embodiments 1 and 2: Concurrent-Effect Compatibility Versus
Required Causal Ordering: original global pages 407-436; PDF segment
TECHNICAL SPECIFICATION -1-554.pdf; corresponding page anchors
`joint-causal-page-<global-page>`; architecture `fig-joint-causal-
architecture`; decision flowchart `fig-joint-causal-flowchart`.
Supporting Original Embodiment 4 Disclosure: Cross-Domain Actual-
Effect Evidence for Causal Receipt Qualification: original global
pages 493-554; PDF segment TECHNICAL SPECIFICATION -1-554.pdf;
corresponding page anchors `emb4-support-page-<global-page>`;
architecture `fig-emb4-support-architecture`; decision flowchart
`fig-emb4-support-flowchart`.
The associated machine-readable source map provides every original
global page included in this document and its exact section anchor.
Source extracts retain original patent-style framing and may include
proposed claim-support material; newly added IETF relevance, tests,
examples and diagrams are non-normative editorial extensions with
their own publication date.
Das Expires 29 April 2027 [Page 391]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
Source chronology: an Internet-Draft public date, the separate
3,567-page Zenodo publication and the PCT/IB2026/055615 filing of 4
June 2026 are distinct facts. Earlier priority must be assessed only
against authentic as-filed disclosures, not inferred from inclusion
of new explanatory diagrams in this later publication.
17. Explicit Foundational and Companion Cross-References
Part 1 of 12 — Foundational Definitions, Trust Model and Common
Workflows CW-1/CW-2/CW-3: [DAS-FOUNDATION]
Part 2 of 12 — Secure Apple iOS, Android and Cross-Platform AI Tool
Interoperability: [DAS-INTEROP]
Part 3 of 12 — Protected Authorization, Cross-Committed Validation
Evidence and Scoped Finality: [DAS-EVIDENCE]
Part 4 of 12 — Finality Sink Enforcement, Actual-Operation
Reconstruction and Anti-Bypass Security: [DAS-SINK]
Part 5 of 12 — Multi-Agent Security, Delegation, Conflict Arbitration
and Quorum Authority: [DAS-MULTIAGENT]
Part 7 of 12 — AI Tool Security, Resource Identity and Execution-Time
Semantic Integrity: [DAS-TOOLS]
Part 8 of 12 — Distributed Autonomous Effects, Multi-Resource
Transactions and Recovery: [DAS-RECOVERY]
Part 9 of 12 — Protected Agent Credential Custody, API Authorization
and Data Privacy: [DAS-CREDENTIALS]
Part 10 of 12 — Cross-Device Authority Continuity, Revocation Fencing
and Offline Authorization: [DAS-REVOCATION]
Part 11 of 12 — Hardware-Assisted, Kernel and Sandbox Finality
Enforcement: [DAS-HARDWARE]
Part 12 of 12 — Autonomous Cloud, Telecom and Critical Infrastructure
Resource Security: [DAS-INFRA]
18. 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-
Das Expires 29 April 2027 [Page 392]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
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
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-TOOLS]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 7 of 12 — AI Tool
Security, Resource Identity and Execution-Time Semantic
Integrity", Work in Progress, Internet-Draft, draft-das-
agent-tool-integrity-00,
<https://datatracker.ietf.org/doc/draft-das-agent-tool-
integrity/>.
Das Expires 29 April 2027 [Page 393]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
[DAS-RECOVERY]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 8 of 12 — Distributed
Autonomous Effects, Multi-Resource Transactions and
Recovery", Work in Progress, Internet-Draft, draft-das-
distributed-effect-recovery-00,
<https://datatracker.ietf.org/doc/draft-das-distributed-
effect-recovery/>.
[DAS-CREDENTIALS]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 9 of 12 — Protected
Agent Credential Custody, API Authorization and Data
Privacy", 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 Authority Continuity, Revocation Fencing and
Offline Authorization", Work in Progress, Internet-Draft,
draft-das-cross-device-authority-revocation-00,
<https://datatracker.ietf.org/doc/draft-das-cross-device-
authority-revocation/>.
[DAS-HARDWARE]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 11 of 12 — Hardware-
Assisted, Kernel and Sandbox Finality 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 — Autonomous
Cloud, Telecom and Critical Infrastructure Resource
Security", Work in Progress, Internet-Draft, draft-das-
autonomous-infrastructure-finality-00,
<https://datatracker.ietf.org/doc/draft-das-autonomous-
infrastructure-finality/>.
Das Expires 29 April 2027 [Page 394]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC7009] Lodderstedt, T., Dronia, S., and M. Scurtescu, "OAuth 2.0
Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August
2013, <https://www.rfc-editor.org/info/rfc7009>.
[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>.
Das Expires 29 April 2027 [Page 395]
Internet-Draft Execution-Finality Part 6: Receipts October 2026
[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>.
[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>.
[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>.
Author's Address
Sangam Kumar Das
Independent Researcher
Balasore
Odisha
India
Email: info@sangamdas.com
Das Expires 29 April 2027 [Page 396]