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] | ---NO--->[HOLD / RECONCILE] | YES [Create protected effect receipt] | -----NO--->[WITHHOLD] | YES -NO--->[WITHHOLD] | YES [Accept VAER; constitute CCC] | --NO--->[WITHHOLD] | YES [Successor sink reconstructs actual act] | --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] | --NO-->[HOLD] |YES [PER collected under protected observer] | --NO-->[WITHHOLD] |YES --NO-->[WITHHOLD] |YES [Constitute protected VAER/CCC] | --NO-->[WITHHOLD] |YES --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] | --NO-->[CW-1 only] |YES [Observe real effect + qualify evidence] | --NO-->[WITHHOLD] |YES [Check successor source and scope] | --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] | --NO-->[WITHHOLD] |YES --NO-->[WITHHOLD] |YES [Accept VAER under protected identity] | [Constitute necessary continuation condition] | --YES-->[UNSAFE DESIGN] |NO --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?] | --NO-->[WITHHOLD] |YES [Create VAER + successor required condition] | --YES-->[IGNORE] |NO --NO-->[WITHHOLD] |YES --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] | --NO-->[FENCE] |YES --NO-->[HOLD] |YES --NO-->[REFUSE] |YES --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] | --YES-->[NOT PROOF OF EFFECT] |NO [Check qualified actual outcome observations] | --NO-->[INDETERMINATE] |YES --NO-->[WITHHOLD] |YES [IEV accept under CW-2, where required] | --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-`; 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-`; 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-`; 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-`; 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-`; 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-`; 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, . [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, . [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, . [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, . [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, . [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, . 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, . [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, . [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, . [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, . [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, . 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, . [PCT-055615] Das, S., "Published international application WO 2026/150382 (PCT/IB2026/055615)", 2026, . [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property Rights in IETF Technology", RFC 8179, BCP 79, DOI 10.17487/RFC8179, May 2017, . [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, . [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, . [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, . [RFC7009] Lodderstedt, T., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, . [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, . 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, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", RFC 9052, DOI 10.17487/RFC9052, August 2022, . [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, . [RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP Semantics", RFC 9110, DOI 10.17487/RFC9110, June 2022, . [WIMSE] Internet Engineering Task Force, "Workload Identity in Multi System Environments (wimse) Working Group", . [SCITT] Internet Engineering Task Force, "Supply Chain Integrity, Transparency, and Trust (scitt) Working Group", . [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, . Author's Address Sangam Kumar Das Independent Researcher Balasore Odisha India Email: info@sangamdas.com Das Expires 29 April 2027 [Page 396]