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
draft-das-protected-authority-evidence-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sangam Das | ||
| Last updated | 2026-10-26 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Github - DAS Execution-Finality: Runnable Reference Model and 400 Executed Tests
iOS and Android Interoperability for Secure Third Party AI Tools - Cross-Platform Execution Finality, Hardware Security, and Interoperability (3,567-Page Specification |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-das-protected-authority-evidence-00
Independent Submission S. Das
Internet-Draft Independent Researcher
Intended status: Informational 26 October 2026
Expires: 29 April 2027
Secure AI Execution-Finality for iOS, Android, and Cross-Platform AI
Agents, Part 3: Protected Source Authority, Cross-Committed Evidence,
and Scoped Non-Bearer Finality
draft-das-protected-authority-evidence-00
Abstract
When Apple Siri runs an App Intent, Google Gemini triggers an Android
action, or a third-party AI agent calls a cloud API on a user's
behalf, the request usually carries valid credentials: an OAuth
token, an iOS Keychain or Android Keystore key, or a signed approval.
Valid credentials are not the same as authority for the exact
operation. Prompt injection, stolen or reused tokens, forged or
substituted approvals, stale delegated authority, replayed
authorizations, and crashes between the authorization decision and
the effect can each disconnect an apparent permission from the file
export, payment, secret use, cloud change, or device command that is
actually executed.
This document, Part 3 of a twelve-part series, specifies the
authority and evidence layer of execution finality. It describes how
to capture protected source authority from the originating principal;
collect protected evidence when a request is formed; validate it
again, independently, at execution time; cross-commit the two so that
neither can be substituted; issue operation-scoped, non-bearer
finality enablement that is useless if copied; and consume it once,
under protected state, at an independently verifying Finality Sink.
It also specifies crash-consistent journaling and reconciliation of
indeterminate remote outcomes, keeping local consumption of authority
distinct from completion of the external effect. Reference
algorithms, six threat models, and twenty reproducible positive and
negative tests are included. Part 1 of the series defines the shared
terminology and common workflows.
The document treats existing IETF mechanisms as qualified inputs
rather than final authority: OAuth 2.0 Rich Authorization Requests
and Demonstrating Proof of Possession (DPoP); Workload Identity in
Multi-System Environments (WIMSE); Remote ATtestation procedureS
(RATS); CBOR Object Signing and Encryption (COSE) for evidence
encoding; Authentication and Authorization for Constrained
Environments (ACE); Supply Chain Integrity, Transparency, and Trust
(SCITT) signed statements; and HTTP conditional requests and
Das Expires 29 April 2027 [Page 1]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
redirects. 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 Apple
Intelligence, Siri, and App Intents; Google Android with Gemini,
Intents, Binder, and Android Keystore; Samsung Bixby and Microsoft
Copilot; Microsoft Windows and Azure; agent platforms from OpenAI,
Anthropic, Google Cloud, and Meta; NVIDIA, Qualcomm, Arm, and Huawei
hardware; API banking and digital signatures; Kubernetes and service
meshes; telecommunications; and robotics. Product names are
illustrative and imply no endorsement or implementation by any
vendor. For the EU Artificial Intelligence Act (Regulation (EU)
2024/1689), cross-committed, operation-level evidence and single-use
consumption records can help providers and deployers address record-
keeping, traceability, human-oversight, and robustness and
cybersecurity requirements where those obligations apply; this is a
technical mapping, not a conformity claim or legal advice.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Das Expires 29 April 2027 [Page 2]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Table of Contents
1. Introduction: Part 3 of 12, Security Problem Space and Full
Series Guide . . . . . . . . . . . . . . . . . . . . . . 8
1.1. Complete Twelve-Part Series Directory and Planned
Datatracker Identifiers . . . . . . . . . . . . . . . . . 9
1.1.1. Part 1 of 12: Foundational Definitions, Protected
Consequential Authority, Trust Model, and CW-1/CW-2/CW-3
Workflows . . . . . . . . . . . . . . . . . . . . . . 9
1.1.2. Part 2 of 12: Apple iOS, Android, Desktop, Cloud and
Secure Third-Party AI Tool Interoperability . . . . . 9
1.1.3. Part 3 of 12: Protected Source Authorization,
Cross-Committed Evidence and Scoped Non-Bearer
Finality . . . . . . . . . . . . . . . . . . . . . . 9
1.1.4. Part 4 of 12: Actual-Operation Reconstruction,
Sink-Local State and Non-Bypassable Effectuation . . 9
1.1.5. Part 5 of 12: Multi-Agent Delegation, Conflict
Arbitration and Authority Lineage . . . . . . . . . . 10
1.1.6. Part 6 of 12: Qualified Actual-Effect Receipts and
Causal Phase Continuation . . . . . . . . . . . . . . 10
1.1.7. Part 7 of 12: Tool Semantics, Resource Identity, Model
Provenance and Runtime Integrity . . . . . . . . . . 10
1.1.8. Part 8 of 12: Distributed Outcome Verification, Crash
Recovery and Multi-Resource Effects . . . . . . . . . 10
1.1.9. Part 9 of 12: Credential Brokerage, Non-Exportable
Secret Exercise and Privacy Releases . . . . . . . . 10
1.1.10. Part 10 of 12: Device Migration, Revocation, Fences,
Ownership Generations and Offline Effects . . . . . . 10
1.1.11. Part 11 of 12: Kernel, Sandbox, DPU, Accelerator and
Hardware-Bound Effect Control . . . . . . . . . . . . 10
1.1.12. Part 12 of 12: Enterprise, Cloud, Telecom and
Critical-Infrastructure Consequence Governance . . . 11
2. Related Patent-Pending Technical Disclosure, IETF IPR Process,
and Planned GitHub Implementation . . . . . . . . . . . . 11
3. Keywords and Technical Discovery Index . . . . . . . . . . . 12
4. Source Vocabulary, Terminology Boundaries, and Local
Definitions . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Candidate Act and Non-Effective State . . . . . . . . . . 12
4.2. Source Authority . . . . . . . . . . . . . . . . . . . . 12
4.3. Protected Collection-Time Evidence . . . . . . . . . . . 12
4.4. Independent Execution-Time Validation . . . . . . . . . . 13
4.5. Cross-Committed Validation Evidence . . . . . . . . . . . 13
4.6. Scoped Non-Bearer Finality Enablement . . . . . . . . . . 13
4.7. Finality Sink . . . . . . . . . . . . . . . . . . . . . . 13
4.8. Protected Consumption and Journal . . . . . . . . . . . . 13
4.9. Source vs Editorial Technical Extensions . . . . . . . . 13
5. Part 3 Architecture and Operational Model . . . . . . . . . . 14
Das Expires 29 April 2027 [Page 3]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
6. PHOSITA Implementation Using Existing Libraries, Gateways,
Databases and Platform Interfaces . . . . . . . . . . . . 15
6.1. Controlled Proof-of-Concept Topology . . . . . . . . . . 16
6.2. Apple iOS and iPadOS Integration . . . . . . . . . . . . 16
6.3. Android Integration . . . . . . . . . . . . . . . . . . . 16
6.4. Windows, Linux and Cloud Agent Environments . . . . . . . 16
6.5. Source Grant Registry . . . . . . . . . . . . . . . . . . 16
6.6. Protected Evidence Collectors . . . . . . . . . . . . . . 17
6.7. Cryptographic Evidence Representation . . . . . . . . . . 17
6.8. Authority Constitution Service . . . . . . . . . . . . . 17
6.9. Receiving Finality Sink and Effect Reconstruction . . . . 17
6.10. Transactional Journal and Consumption . . . . . . . . . . 17
6.11. Revocation and Delegation . . . . . . . . . . . . . . . . 18
6.12. Concurrency and Race Safety . . . . . . . . . . . . . . . 18
6.13. Bounded Verification and Denial of Service . . . . . . . 18
6.14. Operations, Deployment and Trust Assessment . . . . . . . 18
6.15. Reference Code Publication and Provenance . . . . . . . . 18
7. Reference Data Structures, Interfaces and Non-Normative
Algorithms . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Candidate Act, Source Authority and Protected Evidence . 19
7.2. Cross-Commitment and Sink-Limited Non-Bearer Authority . 19
7.3. Collection-Time Evidence Qualification Algorithm . . . . 20
7.4. Independent Execution-Time Validation Algorithm . . . . . 20
7.5. Constitute Scoped Non-Bearer Finality . . . . . . . . . . 20
7.6. Finality Sink Verification and Consumption . . . . . . . 21
7.7. Crash-Consistent Effect-Intent Journal . . . . . . . . . 21
7.8. Indeterminate Outcome Reconciliation . . . . . . . . . . 21
7.9. Attack-Failure Decision Matrix . . . . . . . . . . . . . 22
8. Source-Grounded Technical Specification: Evidence, Authority,
Journaling and Standards Adapters . . . . . . . . . . . . 22
8.1. Original Invention: Cross-Platform Authorization and Effect
Semantics . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1.1. Architecture and Protected Trust Boundaries . . . . . 23
8.1.2. Operational Decisions and Fail-Closed State
Transitions . . . . . . . . . . . . . . . . . . . . . 23
8.1.3. Page-Indexed Original Technical Disclosure . . . . . 23
8.2. CW-1: Common Protected Execution-Finality Workflow —
Evidence and Authority Foundations . . . . . . . . . . . 42
8.2.1. Architecture and Protected Trust Boundaries . . . . . 42
8.2.2. Operational Decisions and Fail-Closed State
Transitions . . . . . . . . . . . . . . . . . . . . . 43
8.2.3. Page-Indexed Original Technical Disclosure . . . . . 43
8.3. CW-2: Validator-Qualified Effect Receipt — Evidence
Dependency Context . . . . . . . . . . . . . . . . . . . 106
8.3.1. Architecture and Protected Trust Boundaries . . . . . 106
8.3.2. Operational Decisions and Fail-Closed State
Transitions . . . . . . . . . . . . . . . . . . . . . 106
8.3.3. Page-Indexed Original Technical Disclosure . . . . . 106
Das Expires 29 April 2027 [Page 4]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.4. Embodiment 15: Cross-Domain Evidence Commitment,
Independent Validation and Non-Bearer Finality . . . . . 128
8.4.1. Architecture and Protected Trust Boundaries . . . . . 128
8.4.2. Operational Decisions and Fail-Closed State
Transitions . . . . . . . . . . . . . . . . . . . . . 128
8.4.3. Page-Indexed Original Technical Disclosure . . . . . 129
8.5. Embodiment 16: Crash-Consistent Finality Journaling and
Indeterminate Outcome Reconciliation . . . . . . . . . . 210
8.5.1. Architecture and Protected Trust Boundaries . . . . . 210
8.5.2. Operational Decisions and Fail-Closed State
Transitions . . . . . . . . . . . . . . . . . . . . . 210
8.5.3. Page-Indexed Original Technical Disclosure . . . . . 211
8.6. Miscellaneous Embodiment M-2: Existing Authorization
Standards as Qualified Inputs, Not Finality . . . . . . . 297
8.6.1. Architecture and Protected Trust Boundaries . . . . . 297
8.6.2. Operational Decisions and Fail-Closed State
Transitions . . . . . . . . . . . . . . . . . . . . . 297
8.6.3. Page-Indexed Original Technical Disclosure . . . . . 298
9. Formalized Threat Models, Protected Assets, Attacker
Capabilities and Residual Risks . . . . . . . . . . . . . 365
9.1. Prompt Injection and Unauthorized Agent Tool Effects . . 365
9.1.1. Attacker precondition and exploit path . . . . . . . 365
9.1.2. Protected assets and security predicates . . . . . . 365
9.1.3. Proposed defense and observables . . . . . . . . . . 365
9.1.4. Residual limitations . . . . . . . . . . . . . . . . 365
9.1.5. Validation link . . . . . . . . . . . . . . . . . . . 365
9.2. Replay, Credential Possession and Cloned Authority . . . 365
9.2.1. Attacker precondition and exploit path . . . . . . . 365
9.2.2. Protected assets and security predicates . . . . . . 365
9.2.3. Proposed defense and observables . . . . . . . . . . 366
9.2.4. Residual limitations . . . . . . . . . . . . . . . . 366
9.2.5. Validation link . . . . . . . . . . . . . . . . . . . 366
9.3. Forged, Replaced or Colluding Evidence . . . . . . . . . 366
9.3.1. Attacker precondition and exploit path . . . . . . . 366
9.3.2. Protected assets and security predicates . . . . . . 366
9.3.3. Proposed defense and observables . . . . . . . . . . 366
9.3.4. Residual limitations . . . . . . . . . . . . . . . . 366
9.3.5. Validation link . . . . . . . . . . . . . . . . . . . 366
9.4. Delegation, Scope Widening and Revocation Race . . . . . 366
9.4.1. Attacker precondition and exploit path . . . . . . . 367
9.4.2. Protected assets and security predicates . . . . . . 367
9.4.3. Proposed defense and observables . . . . . . . . . . 367
9.4.4. Residual limitations . . . . . . . . . . . . . . . . 367
9.4.5. Validation link . . . . . . . . . . . . . . . . . . . 367
9.5. Crash, Duplicate Dispatch and Unknown Outcome . . . . . . 367
9.5.1. Attacker precondition and exploit path . . . . . . . 367
9.5.2. Protected assets and security predicates . . . . . . 367
9.5.3. Proposed defense and observables . . . . . . . . . . 367
Das Expires 29 April 2027 [Page 5]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
9.5.4. Residual limitations . . . . . . . . . . . . . . . . 367
9.5.5. Validation link . . . . . . . . . . . . . . . . . . . 368
9.6. Bypass, Alternate Credential Path and Protected-Component
Compromise . . . . . . . . . . . . . . . . . . . . . . . 368
9.6.1. Attacker precondition and exploit path . . . . . . . 368
9.6.2. Protected assets and security predicates . . . . . . 368
9.6.3. Proposed defense and observables . . . . . . . . . . 368
9.6.4. Residual limitations . . . . . . . . . . . . . . . . 368
9.6.5. Validation link . . . . . . . . . . . . . . . . . . . 368
10. Reproducible Proposed Test Plan: 20 Independent Positive and
Negative Cases . . . . . . . . . . . . . . . . . . . . . 368
10.1. T01: Authorized iOS-originated API update . . . . . . . 369
10.2. T02: Android intent-induced prompt injection . . . . . . 369
10.3. T03: Alter request body after validation . . . . . . . . 369
10.4. T04: Replay consumed finality enablement . . . . . . . . 370
10.5. T05: Stale originating source grant . . . . . . . . . . 370
10.6. T06: Compromised collection evidence . . . . . . . . . . 371
10.7. T07: Cross-commitment substitution . . . . . . . . . . . 371
10.8. T08: Execution validator independence failure . . . . . 372
10.9. T09: Unbound sink redirection . . . . . . . . . . . . . 372
10.10. T10: Source credential scope exceeds user grant . . . . 372
10.11. T11: Two concurrent workers use same authority . . . . . 373
10.12. T12: Crash between local consume and external
dispatch . . . . . . . . . . . . . . . . . . . . . . . 373
10.13. T13: Dispatch completes but acknowledgment lost . . . . 374
10.14. T14: Receiver lacks duplicate suppression . . . . . . . 374
10.15. T15: Resource alias and HTTP redirect mutation . . . . . 375
10.16. T16: Revocation registry unreachable . . . . . . . . . . 375
10.17. T17: Snapshot restores consumed journal . . . . . . . . 375
10.18. T18: Alternate direct egress bypass . . . . . . . . . . 376
10.19. T19: High-volume malicious evidence workload . . . . . . 376
10.20. T20: Cross-platform end-to-end audit reproducibility . . 377
11. Detailed Industry and Product Alignment: Security Problems,
Integration Paths and Deployment Boundaries . . . . . . . 377
11.1. Apple iOS, iPadOS, macOS, Apple Intelligence, Siri and App
Intents . . . . . . . . . . . . . . . . . . . . . . . . 377
11.2. Google Android, Gemini, Intents, Binder IPC and Android
Keystore . . . . . . . . . . . . . . . . . . . . . . . 378
11.3. Microsoft Windows, Azure and Agent Execution
Containers . . . . . . . . . . . . . . . . . . . . . . 378
11.4. OpenAI Responses API, Agents SDK, Codex and Computer-Use
Workloads . . . . . . . . . . . . . . . . . . . . . . . 378
11.5. Anthropic Claude, Claude Code and Managed Agents . . . . 379
11.6. Google Cloud and Enterprise Agent Services . . . . . . . 379
11.7. Meta Agent Runtimes, Muse/Sentinel and Brokered
Credentials . . . . . . . . . . . . . . . . . . . . . . 379
11.8. NVIDIA OpenShell/Sentry, GPUs, DPUs and Hardware
Gateways . . . . . . . . . . . . . . . . . . . . . . . 379
Das Expires 29 April 2027 [Page 6]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
11.9. Qualcomm Snapdragon, Mobile SoCs and Trusted Security
Hardware . . . . . . . . . . . . . . . . . . . . . . . 380
11.10. Huawei Mobile, Cloud and Telecommunications Devices . . 380
11.11. Arm Security Architecture and Trusted Execution
Environments . . . . . . . . . . . . . . . . . . . . . 380
11.12. Financial Systems, Payments, API Banking and Digital
Signatures . . . . . . . . . . . . . . . . . . . . . . 380
11.13. Cloud APIs, Enterprise SaaS, Kubernetes and Service
Mesh . . . . . . . . . . . . . . . . . . . . . . . . . 381
11.14. Telecommunications, 5G/6G, IoT and Edge Devices . . . . 381
11.15. Robotics, Industrial Controllers and Critical
Infrastructure . . . . . . . . . . . . . . . . . . . . 381
11.16. Patent Examiners and Prior-Art Technical Researchers . . 381
11.17. Voice and System Assistants: Samsung Bixby, Microsoft
Copilot, Amazon Alexa, and Assistant-Initiated Actions 382
12. Detailed Relevance to IETF Working Groups, RFCs and
Security-Protocol Interoperability . . . . . . . . . . . 382
12.1. OAuth WG: Fine-Grained Authorization and
Sender-Constrained Credentials . . . . . . . . . . . . . 382
12.2. WIMSE WG: Workload Identity Across Multi-System Trust
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 383
12.3. RATS WG: Trusted Attestation and Evidence Appraisal . . 383
12.4. COSE, CBOR, Cryptographic Message Evidence . . . . . . . 384
12.5. ACE WG: Constrained Authorization for Embedded and Mobile
Effects . . . . . . . . . . . . . . . . . . . . . . . . 384
12.6. SCITT WG: Signed Statements and Transparency . . . . . . 384
12.7. HTTPBIS and HTTP Semantics: Conditional Effects and
Redirects . . . . . . . . . . . . . . . . . . . . . . . 385
12.8. SEC-DISPATCH, Security Area and Cross-WG Review . . . . 385
13. Relevance to the EU Artificial Intelligence Act . . . . . . . 386
14. Security, Privacy, Availability, Operational and IANA
Considerations . . . . . . . . . . . . . . . . . . . . . 387
14.1. Independence and Collusion . . . . . . . . . . . . . . . 387
14.2. Proof of Authority vs Proof of Effect . . . . . . . . . 387
14.3. Nonce, Epoch, Replay and Storage Rollback . . . . . . . 387
14.4. Canonicalization and Type Confusion . . . . . . . . . . 387
14.5. Sensitive Evidence and Privacy . . . . . . . . . . . . . 387
14.6. Availability and Verification Exhaustion . . . . . . . . 388
14.7. Remote Outcome and Crash Semantics . . . . . . . . . . . 388
14.8. Publication and IANA Status . . . . . . . . . . . . . . 388
15. Patent Examiner and Industry Discovery Cross-Index: Original
Page and Figure Locations . . . . . . . . . . . . . . . . 388
16. Cross-References to the Foundation and Companion
Internet-Drafts . . . . . . . . . . . . . . . . . . . . . 389
17. Public Sources and Planned Companion References . . . . . . . 390
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 393
Das Expires 29 April 2027 [Page 7]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
1. Introduction: Part 3 of 12, Security Problem Space and Full Series
Guide
The problem addressed here is evidence-to-effect authority confusion:
an app or AI agent may hold an identity token, signed request, access
permission or historic approval while lacking current authority for
the actual pending consequence. This Part 3 describes how protected
evidence about the source permission, contextual operation and
current execution-time state is maintained separately from the lower-
trust tool or model output; how appropriate independent checks bind
those observations; and how their results are converted into narrowly
scoped finality authority verified at the actual effectuation
boundary. Merely signing agent intent is insufficient whenever the
sink can observe an effect differing materially from that intent.
Industry search context includes secure Apple iOS and Google Android
AI tools; mobile identity and app-to-app permission handoff;
OpenAI/Anthropic/Google enterprise agents; Microsoft Windows and
Azure-hosted workloads; Meta-style isolated agents and credential
brokers; NVIDIA, Qualcomm and Arm protected computing; API, HTTP,
OAuth/OIDC, service-to-service authorization, financial payment
signing, credential rotation and industrial effects. These are
technical application fields and external-security problem classes,
not assertions that named products implement the disclosed proposal.
This is an individually proposed informational technical disclosure
for public inspection and independent engineering review, not an
approved IETF standard, a claim of working-group endorsement or a
conformance certification. Its primary publication purpose is
discoverable technical documentation for patent examiners and
engineers; details of as-filed patent priority or patentability are
outside this Internet-Draft.
This Part 3 does not redefine the protected Candidate Act, Non-
Effective State, Protected Enforcement Domain, independent Finality
Sink, and CW-1/CW-2/CW-3 concepts established by Part 1. It adds the
source-defined evidence and authority mechanisms, especially
Embodiments 15 and 16, and examines the interoperability adapters of
Miscellaneous Embodiment M-2. Specialized sink-local mechanics are
in Part 4; causal prior-effect receipts in Part 6; credential custody
and privacy release in Part 9; and device-state/epoch revocation in
Part 10.
Das Expires 29 April 2027 [Page 8]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
1.1. Complete Twelve-Part Series Directory and Planned Datatracker
Identifiers
The following are stable planned document identifiers within this
publication project. A Datatracker address should not be treated as
an active published Internet-Draft until the corresponding submission
has been accepted. Full external references and their versions are
subject to final submission-time verification.
1.1.1. Part 1 of 12: Foundational Definitions, Protected Consequential
Authority, Trust Model, and CW-1/CW-2/CW-3 Workflows
Document identifier: draft-das-interoperable-consequence-authority .
Planned document URL: https://datatracker.ietf.org/doc/draft-das-
interoperable-consequence-authority/ .
Foundational reference. Defines common terms and workflows,
including CA/NES/PED/Finality Sink and CW-1, CW-2, CW-3.
1.1.2. Part 2 of 12: Apple iOS, Android, Desktop, Cloud and Secure
Third-Party AI Tool Interoperability
Document identifier: draft-das-cross-platform-ai-interoperability .
Planned document URL: https://datatracker.ietf.org/doc/draft-das-
cross-platform-ai-interoperability/ .
1.1.3. Part 3 of 12: Protected Source Authorization, Cross-Committed
Evidence and Scoped Non-Bearer Finality
Document identifier: draft-das-protected-authority-evidence . Planned
document URL: https://datatracker.ietf.org/doc/draft-das-protected-
authority-evidence/ .
This document. Defines evidence and source-authority binding,
validation independence, scoped non-bearer finality and relevant
journal consistency.
1.1.4. Part 4 of 12: Actual-Operation Reconstruction, Sink-Local State
and Non-Bypassable Effectuation
Document identifier: draft-das-finality-sink-enforcement . Planned
document URL: https://datatracker.ietf.org/doc/draft-das-finality-
sink-enforcement/ .
Das Expires 29 April 2027 [Page 9]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
1.1.5. Part 5 of 12: Multi-Agent Delegation, Conflict Arbitration and
Authority Lineage
Document identifier: draft-das-multi-agent-authority-control .
Planned document URL: https://datatracker.ietf.org/doc/draft-das-
multi-agent-authority-control/ .
1.1.6. Part 6 of 12: Qualified Actual-Effect Receipts and Causal Phase
Continuation
Document identifier: draft-das-causal-effect-receipts . Planned
document URL: https://datatracker.ietf.org/doc/draft-das-causal-
effect-receipts/ .
1.1.7. Part 7 of 12: Tool Semantics, Resource Identity, Model
Provenance and Runtime Integrity
Document identifier: draft-das-agent-tool-integrity . Planned
document URL: https://datatracker.ietf.org/doc/draft-das-agent-tool-
integrity/ .
1.1.8. Part 8 of 12: Distributed Outcome Verification, Crash Recovery
and Multi-Resource Effects
Document identifier: draft-das-distributed-effect-recovery . Planned
document URL: https://datatracker.ietf.org/doc/draft-das-distributed-
effect-recovery/ .
1.1.9. Part 9 of 12: Credential Brokerage, Non-Exportable Secret
Exercise and Privacy Releases
Document identifier: draft-das-agent-credential-privacy . Planned
document URL: https://datatracker.ietf.org/doc/draft-das-agent-
credential-privacy/ .
1.1.10. Part 10 of 12: Device Migration, Revocation, Fences, Ownership
Generations and Offline Effects
Document identifier: draft-das-cross-device-authority-revocation .
Planned document URL: https://datatracker.ietf.org/doc/draft-das-
cross-device-authority-revocation/ .
1.1.11. Part 11 of 12: Kernel, Sandbox, DPU, Accelerator and Hardware-
Bound Effect Control
Document identifier: draft-das-hardware-execution-finality . Planned
document URL: https://datatracker.ietf.org/doc/draft-das-hardware-
execution-finality/ .
Das Expires 29 April 2027 [Page 10]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
1.1.12. Part 12 of 12: Enterprise, Cloud, Telecom and Critical-
Infrastructure Consequence Governance
Document identifier: draft-das-autonomous-infrastructure-finality .
Planned document URL: https://datatracker.ietf.org/doc/draft-das-
autonomous-infrastructure-finality/ .
2. Related Patent-Pending Technical Disclosure, IETF IPR Process, and
Planned GitHub Implementation
The principal earlier 8,598-page international technical disclosure
identified for this project is international application PCT/
IB2026/055615, filed 4 June 2026 and published as WO 2026/150382
[PCT-DAS]. Separate application PCT/IB2025/058316 must not be
conflated with that 8,598-page disclosure. The present document is
derived from a different 3,567-page technical specification whose
public source is documented below. Inclusion of a topic in this Part
3 does not establish that its exact wording is supported by any
particular filing date without examination of the as-filed records.
Relevant IETF IPR disclosures, application identifiers, potential
claim coverage and any licensing declarations must be filed
separately with the IETF disclosure mechanism, as applicable. The
author intends to supplement the relevant formal IPR records with
verified details. The timing requirements of BCP 79 [BCP79] apply
independently of this explanatory note; a statement that details may
be provided later does not postpone or replace any required timely
IPR disclosure. This text makes no claim that particular claims are
granted or essential to an IETF specification.
A GitHub implementation and reproducibility package are planned,
potentially including reference interfaces, validation algorithms,
protected-state schemas, negative security tests and optional
Android/iOS gateway examples. The repository link and claims of
execution will be added only after a repository and test artifacts
exist. The illustrative algorithms and 20 test cases below are
proposed engineering aids and are not represented as historically
filed code or completed experiments.
Complete original public 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 https://doi.org/10.5281/
zenodo.23657985 . This Zenodo publication is not itself the same file
as the 8,598-page PCT disclosure.
Das Expires 29 April 2027 [Page 11]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
3. Keywords and Technical Discovery Index
AI-agent security; execution finality; secure AI tool calls; Apple
iOS security; iPadOS app security; macOS protected execution; Android
permissions; Android Binder IPC; Android Keystore; cross-platform
authorization; secure third-party AI tools; mobile sandbox security;
prompt injection; agent authorization; policy enforcement point;
consequential-operation validation; source authorization; Protected
Enforcement Domain; Candidate Act; Non-Effective State; Finality
Sink; actual-operation reconstruction; independent execution-time
validation; collection-time protected evidence; cross-committed
evidence; non-bearer finality enablement; cryptographic capabilities;
OAuth 2.0; Rich Authorization Requests RFC 9396; DPoP RFC 9449;
WIMSE; RATS attestation; COSE; CBOR; ACE constrained authorization;
SCITT; HTTP request signing; API credential abuse; receipt vs
capability; non-replayable token; secure credential gateway; key
custody; protected monotonic journal; exactly-once authorization vs
effect; transactional commit; idempotency; crash consistency; source
authority revocation; IETF intellectual property rights; patent
examination; enterprise agent security; cloud resource authorization;
financial transaction signing; trusted execution environment;
hardware security module; dynamic resource identity; authorization-
to-effect translation; actor and sink independence; evidence
forensics.
4. Source Vocabulary, Terminology Boundaries, and Local Definitions
4.1. Candidate Act and Non-Effective State
A Candidate Act is a structured proposed consequential operation.
Non-Effective State means that proposal remains unable to create its
governed consequential effect while mandatory current validation and
sink checks are outstanding. Both are defined in the foundational
Part 1; the present treatment emphasizes attaching independent
evidence without prematurely enabling an effect.
4.2. Source Authority
The competent original or delegated permission for a specific
consequential scope, distinct from possession of an identity
credential, a tool permission or successful message authentication.
4.3. Protected Collection-Time Evidence
Evidence collected under the applicable protected domain and binding
assumptions at an earlier point when principal authorization, device
context, intended effect and other relevant predicates are qualified.
Das Expires 29 April 2027 [Page 12]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
4.4. Independent Execution-Time Validation
A current, separately protected validation procedure required for the
pending operation. Independence may be architectural or
administrative within a stated trust model; use of two functions in
the same uncontrolled trust domain does not automatically prove
independence.
4.5. Cross-Committed Validation Evidence
A protected linkage between qualified collection-time evidence and
execution-time assessment, binding the particular effect and current
authority conditions so substitution or stale-approval reuse can be
detected under the chosen construction.
4.6. Scoped Non-Bearer Finality Enablement
An operation/sink/scope-bound finality eligibility or activation
artifact that is insufficient as transferable generic authority to
cause unrelated effects merely by possession; a sink validates it in
protected context and consumes or enforces it under current state.
4.7. Finality Sink
The independently enforcing boundary able to obtain or reconstruct
the actual pending operation; compare it to qualified protected
evidence and enablement; verify protected sink-local state; and
refuse or control effectuation.
4.8. Protected Consumption and Journal
An authoritative monotonic or equivalently protected state transition
recording that a particular enablement has been consumed, reserved,
refused or remains indeterminate; journal durability and actual
external-effect outcome must be distinguished.
4.9. Source vs Editorial Technical Extensions
Sections titled Original Source Page reproduce the user-provided
3,567-page specification in source page order. Newly authored
schemas, pseudocode, attack matrices, explanatory figures, mappings
and proposed tests are examples provided by this draft; they do not
alter the original as-filed disclosure or establish test success.
Das Expires 29 April 2027 [Page 13]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
5. Part 3 Architecture and Operational Model
The actual technical dependency is: original source permission
establishes the maximum qualified effect envelope; protected
collection-time assessment records relevant evidence; independently
qualified execution-time observation checks current authority and
actual operation context; cross-commitment prevents unsupported
substitution between instances; scoped finality enablement is
constituted only within the authorized effect envelope; the receiving
protected Finality Sink compares the actual pending operation and
durable state; and the effect remains withheld on a failed required
predicate. Optional cryptographic signature, attestation, trusted
hardware, gateway service, or authorization format is not universally
mandatory.
[Source principal / authorized effect scope]
|
[Agent / mobile app / cloud tool] (untrusted proposal)
|
[Candidate Act]
|
[NES holding]
|
+----------------+-----------------+
| |
[Collection-time PED A] [Execution-time PED B]
[identity, source, scope] [current operation/context]
[protected evidence C] [independent evidence V]
| |
+-------------[cross-commit]-------+
|
[Protected source authority check]
|
[Scoped NON-BEARER enablement]
|
===== effectuation boundary / trust break =====
|
[Protected Finality Sink]
[observe ACTUAL operation + protected state]
/ \
[failed predicate] [all match/current]
| |
[WITHHOLD] [commit use / effect]
Figure 1: Part 3 Evidence and Finality Authority — Protected
Domains and Trust Boundaries
Das Expires 29 April 2027 [Page 14]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
[Propose specific consequential effect] -> [CA held in NES]
|
<Original competent source scope?>---NO--->[WITHHOLD]
|YES
[Qualify collection-time protected evidence]
|
<Independent fresh execution-time evidence?>--NO-->[WITHHOLD]
|YES
<Cross-commit and effect binding current?>--NO-->[WITHHOLD]
|YES
[Constitute sink-scoped non-bearer finality]
|
[Sink reconstructs actual pending operation]
|
<Exact authorized operation & sink state?>--NO-->[WITHHOLD]
|YES
[Atomic protected consumption / journal transition]
|
<Effect outcome locally or remotely established?>
|confirmed |no effect |unknown
v v v
[record result] [record denial] [quarantine/reconcile]
Figure 2: Part 3 Evidence and Finality Authority — Operational
Decision Flow
6. PHOSITA Implementation Using Existing Libraries, Gateways, Databases
and Platform Interfaces
This chapter is newly written practical reference guidance and does
not claim a specific implementation was present in the earlier
application or executed as an experiment. A competent software-
security engineer can prototype effect-specific authorization using
authenticated APIs, protected source-permission records,
deterministic resource descriptors, separately administered
validation services, transactionally committed consumption records,
and an effect-controlling receiving service. Stronger non-
bypassability beyond that service boundary requires operating-system,
provider or hardware integration that an ordinary third-party mobile
application may not possess.
Das Expires 29 April 2027 [Page 15]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
6.1. Controlled Proof-of-Concept Topology
Construct an untrusted agent/client producing a Candidate Act, a
source-grant registry, a PED-A evidence collector, a separately
controlled PED-B validator, a non-bearer enablement authority and an
independent effect gate controlling a demo database or HTTP service.
Protect administrative and cryptographic keys and verify that the
agent cannot directly access the final resource.
6.2. Apple iOS and iPadOS Integration
Use public App Intents, extension APIs and app-controlled network
calls where available, with authenticated user consent evidence and
appropriately protected Keychain keys. The application may submit to
its own protected gateway, but an ordinary third-party iOS app cannot
assume access to other apps or private systemwide kernel enforcement.
Finality is strongest when the actual receiving service or authorized
platform component enforces it.
6.3. Android Integration
Use application components and intents, explicit exported component
restrictions, Binder caller checks where available, Android Keystore
for cryptographic material where appropriate, and server-side
resource gates. A successful Android runtime permission or Keystore
signature alone does not establish that the particular consequential
operation remains within originating scope.
6.4. Windows, Linux and Cloud Agent Environments
A controlled service gateway may run in its own process, container,
virtual machine or otherwise protected administrative domain. Where
necessary, OS access controls or kernel gates restrict alternate
effect-capable file, network or device paths. Merely tracing egress
without ability to stop it does not establish non-bypassability.
6.5. Source Grant Registry
Maintain an authenticated originating principal, delegated authority
chain, permitted effect class, resource identity, allowed methods,
recipients, data release scope, expiry, revocation version and
explicit allowed recovery policies. A broad API token privilege does
not enlarge a smaller original task grant.
Das Expires 29 April 2027 [Page 16]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
6.6. Protected Evidence Collectors
Generate collection-time evidence from a qualified independent view
of principal authorization and device context; use current execution-
time evidence for actual target identity, resource version,
revocation, consent scope and operation content. Authenticate the
origin and freshness of evidence and bind both observations to an
operation identifier.
6.7. Cryptographic Evidence Representation
Use established cryptographic primitives and authenticated transport,
and where technically appropriate COSE/CBOR or a versioned JSON
canonicalization profile for evidence records. Distinguish
authentication of data from establishing its actual meaning or
current validity. Include algorithm agility, key rotation and
explicit source trust assumptions.
6.8. Authority Constitution Service
Mint or constitute a scoped non-bearer enablement only after all
mandatory evidence predicates succeed. Bind it to the designated
receiving sink, particular source grant, effect commitment, expiry/
epoch and protected uniqueness or consumption state. Do not give the
agent a reusable all-purpose credential.
6.9. Receiving Finality Sink and Effect Reconstruction
Place actual operation observation at the protected resource
boundary: database update controller, send gateway, file export
service, signing key custodian or device command gate. Obtain actual
operation fields from the effect-capable interface rather than
trusting an SDK-displayed intention. Refuse operations outside the
authorized bound.
6.10. Transactional Journal and Consumption
Persist the enablement state atomically before exposure to the
governed effect under the chosen fault model. A database transaction
can provide durable local consumption but cannot guarantee a remote
irreversible side effect occurred exactly once. Support distinct
outcome states and receiver-backed idempotency where available.
Das Expires 29 April 2027 [Page 17]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
6.11. Revocation and Delegation
Validate the current source grant, delegation chain and relevant
revocation generation at the sink. Protected state can be
invalidated by credential rotation, administrator action, device
change or policy update; stale approvals are not silently
grandfathered.
6.12. Concurrency and Race Safety
Serialize protected consumption through a database unique constraint,
CAS transaction or equivalent authenticated monotonic state. Ensure
two workers racing to effect the same operation cannot both
successfully exercise the same single-use authority within the
defined controlled interface.
6.13. Bounded Verification and Denial of Service
Limit malformed evidence, cryptographic verification work, parser
depth, replay cache growth and remote attestation latency. Handle
validation exhaustion and unavailable mandatory evidence by
withholding controlled effects rather than turning off the finality
gate.
6.14. Operations, Deployment and Trust Assessment
Document independent failure domains, source of truth for grants and
revocation, who can bypass the sink, how crash state survives restart
and who can issue new permissions. State unprotected effect paths as
explicit exclusions; without their control, generalized ecosystem-
wide enforcement cannot be promised.
6.15. Reference Code Publication and Provenance
When the GitHub package is released, provide pinned commit hashes,
schema versions, a software bill of materials, independent test logs,
license notices, reproducibility commands and a revision-to-source-
page matrix. Until release, all examples remain unexecuted
proposals.
7. Reference Data Structures, Interfaces and Non-Normative Algorithms
The example messages and pseudocode in this section are editorial
implementation guidance. Their fields are illustrative translations
of source-described security relationships, not a registered IETF
serialization nor a verbatim copy of an original patent claim. The
actual invention disclosure may permit different cryptographic and
non-cryptographic implementations, subject to the mandatory effect/
Das Expires 29 April 2027 [Page 18]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
authority relationships applicable to the chosen embodiment.
7.1. Candidate Act, Source Authority and Protected Evidence
CandidateAct = {
schema_version, candidate_id, requesting_workload,
origin_principal, source_grant_id, delegated_scope,
intended_effect_class, resource_identity, method,
permitted_effect_envelope, parameters_commitment,
receiving_sink_id, grant_generation, expiry,
revocation_generation, operation_nonce
}
CollectionEvidence = {
collection_domain_id, protected_observation_time,
candidate_id, source_grant_commitment,
qualified_effect_descriptor, policy_generation,
authority_context_digest, evidence_authentication
}
ExecutionEvidence = {
independent_validator_id, protected_execution_time,
actual_operation_or_presentation_commitment,
resource_version, current_owner, revocation_generation,
sink_route_id, validation_result, evidence_authentication
}
Figure 3: Illustrative implementation aid 1: Candidate Act,
Source Authority and Protected Evidence
7.2. Cross-Commitment and Sink-Limited Non-Bearer Authority
CrossCommittedValidation = {
candidate_id, collection_evidence_reference,
execution_evidence_reference, descriptor_schema_version,
commitment_to_both_instances, declared_independence_profile,
acceptable_effect_scope, current_authority_generation
}
ScopedFinality = {
operation_id, one_authorized_effect_commitment,
designated_finality_sink, source_grant_reference,
validation_commitment_reference, expiration,
revocation_generation, non_transferability_conditions,
protected_consumption_reference
}
Figure 4: Illustrative implementation aid 2: Cross-Commitment and
Sink-Limited Non-Bearer Authority
Das Expires 29 April 2027 [Page 19]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
7.3. Collection-Time Evidence Qualification Algorithm
qualify_collection(source_request):
ca = construct_candidate_act(source_request)
hold_non_effective(ca)
REQUIRE original_source_scope_authenticated(ca)
REQUIRE actual_effect_envelope_is_bounded(ca)
ev1 = protected_observe_source_authority_and_context(ca)
REQUIRE qualified_evidence_origin_and_freshness(ev1)
commit(ev1, ca.candidate_id, source_policy_generation)
RETURN ev1
ON any required-failure: WITHHOLD without effect
Figure 5: Illustrative implementation aid 3: Collection-Time Evidence
Qualification Algorithm
7.4. Independent Execution-Time Validation Algorithm
validate_execution(ca, ev1, pending_operation):
ev2 = independent_protected_observation(pending_operation)
REQUIRE ev2.validator_not_uncontrolled_by_requester
REQUIRE current_source_grant(ca)
REQUIRE current_resource_version_and_revocation(ev2)
REQUIRE operation_equivalent_to_authorized_scope(ev1, ev2)
REQUIRE controlled_effectuation_coverage(ev2.sink_route_id)
RETURN protected_cross_commit(ev1, ev2, ca)
ON any required-failure: WITHHOLD without effect
Figure 6: Illustrative implementation aid 4: Independent
Execution-Time Validation Algorithm
7.5. Constitute Scoped Non-Bearer Finality
constitute_finality(candidate, cross_commitment):
REQUIRE cross_commitment.current_and_valid
REQUIRE source_authority_current(candidate)
REQUIRE no_unqualified_material_change(candidate)
return protected_constitution(
operation_id = candidate.id,
permitted_effect = candidate.effect_commitment,
designated_sink = candidate.receiving_sink,
grant_generation = candidate.grant_generation,
evidence_ref = cross_commitment.ref,
single_use_state = FRESH)
Figure 7: Illustrative implementation aid 5: Constitute Scoped
Non-Bearer Finality
Das Expires 29 April 2027 [Page 20]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
7.6. Finality Sink Verification and Consumption
attempt_effect(finality_ref, actual_effect):
observed = sink_independent_reconstruction(actual_effect)
REQUIRE finality_ref.designated_sink == this_sink
REQUIRE verify_cross_committed_evidence(finality_ref)
REQUIRE observed == currently_authorized_effect_descriptor
REQUIRE current_source_resource_policy_and_revocation(observed)
BEGIN atomic protected transaction
REQUIRE authority_state(finality_ref) == FRESH
UPDATE authority_state(finality_ref) = CONSUMED
RECORD operation_commitment_and_intent(observed)
COMMIT
execute_exact_governed_effect(observed)
RECORD confirmed_or_unknown_outcome()
ON failed REQUIRE: WITHHOLD; DO NOT EFFECT
Figure 8: Illustrative implementation aid 6: Finality Sink
Verification and Consumption
7.7. Crash-Consistent Effect-Intent Journal
JournalRecord = {
logical_operation_id, candidate_id, sink_id,
effect_commitment, authorization_generation,
cross_commitment_ref, state, replay_fence,
resource_version, receiver_idempotency_key,
durable_transition_counter, external_outcome_reference
}
possible_state = {PREPARED, CONSUMED, DISPATCHED,
CONFIRMED_EFFECT, CONFIRMED_NO_EFFECT,
INDETERMINATE, RECONCILED}
Never infer CONFIRMED_NO_EFFECT from an HTTP timeout.
Never reset CONSUMED merely because a client crashed.
Figure 9: Illustrative implementation aid 7: Crash-Consistent
Effect-Intent Journal
7.8. Indeterminate Outcome Reconciliation
Das Expires 29 April 2027 [Page 21]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
reconcile(logical_operation_id):
rec = read_protected_journal(logical_operation_id)
if rec.state in {CONFIRMED_EFFECT, CONFIRMED_NO_EFFECT}:
return rec.qualified_outcome
observation = query_qualified_receiving_resource(rec)
if observation.proves_specific_actual_effect:
mark_confirmed_effect_and_preserve_consumption()
elif observation.proves_non_effect_and_retry_authorized:
# new Candidate Act or receiver-idempotent retry
propose_retry_under_current_authority()
else:
mark_indeterminate_and_withhold_duplicate_effect()
Figure 10: Illustrative implementation aid 8: Indeterminate Outcome
Reconciliation
7.9. Attack-Failure Decision Matrix
if forged_evidence => deny
if current_revocation_failed => deny
if actual_resource_mismatch => deny
if actual_operation_mismatch=> deny
if replay_or_consumed => deny
if authority_scope_widening => deny
if sink_unreachable => withhold
if external_outcome_unknown => preserve consumption; reconcile
if all required predicates => consume and effect at sink
Figure 11: Illustrative implementation aid 9: Attack-Failure
Decision Matrix
8. Source-Grounded Technical Specification: Evidence, Authority,
Journaling and Standards Adapters
This section retains the underlying 3,567-page specification in
indexed page units, so that patent examiners and implementing
engineers can locate substantive original disclosures. Page extracts
are arranged according to their global source page numbers; non-
limiting or optional statements retain their source wording. Modern
reference schemas and analytic diagrams elsewhere in Part 3 are
supplemental explanations only. Source transcription does not
independently verify priority support in the distinct 8,598-page PCT
document.
Das Expires 29 April 2027 [Page 22]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.1. Original Invention: Cross-Platform Authorization and Effect
Semantics
Original source global pages 1-14. Preserved for technical
discoverability and traceability; consult the cited full Zenodo
document for complete source context. This part primarily
concentrates on evidence binding, scope, non-bearer authority and
protected journal consumption; other documents provide specialized
enforcement, device handoff and actual effect receipt details.
8.1.1. Architecture and Protected Trust Boundaries
[Original source grant]-->[Android/iOS platform evidence]
| |
v v
[Candidate Act/NES]------>[Effect descriptor]
|
[Independent PED]
|
[Finality Sink]
Figure 12: Original Invention: Cross-Platform Authorization and
Effect Semantics — Protected Architecture
8.1.2. Operational Decisions and Fail-Closed State Transitions
[App/tool operation proposed]
|
<Source permission bounded?>--NO-->[Hold]
|YES
[Platform evidence qualified]
|
<Actual resource/effect matched?>--NO-->[Hold]
|YES
[Sink validate/consume/effect]
Figure 13: Original Invention: Cross-Platform Authorization and
Effect Semantics — Decision Flowchart
8.1.3. Page-Indexed Original Technical Disclosure
8.1.3.1. Original global source page 1
TITLE OF THE INVENTION
Das Expires 29 April 2027 [Page 23]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
SYSTEMS AND METHODS FOR CROSS-PLATFORM INTEROPERABLE EXECUTION-
FINALITY CONTROL, PROTECTED AUTHORITY CONTINUITY, AND CONSEQUENCE
ENFORCEMENT ACROSS HETEROGENEOUS OPERATING SYSTEMS, DEVICES, AND
AUTONOMOUS COMPUTING ENVIRONMENTS
ABSTRACT
Disclosed are systems and methods for interoperable protected
execution-finality control across heterogeneous operating systems,
including Android, iOS, and other mobile, desktop, cloud, and
embedded environments. A proposed consequential operation is
represented as a Candidate Act and retained in a Non-Effective State.
Platform-specific adapters translate qualified authorization,
identity, application, device, and security evidence into a protected
canonical effect descriptor without converting upstream permission
into execution authority. A Protected Enforcement Domain verifies
originating and delegated authority, current revocation, operation
semantics, and enforcement-path coverage, and constitutes scoped non-
bearer finality enablement. A designated Finality Sink independently
obtains or reconstructs the actual pending operation, verifies its
correspondence with protected evidence and current sink-local state,
and controls authorization consumption before effectuation. Cross-
device transfer may employ authenticated ownership epochs and source
fencing. Unavailable mandatory enforcement causes withholding. The
architecture preserves vendor-independent authority semantics while
accommodating distinct platform security mechanisms and covered
consequential interfaces.
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates generally to computer security,
operating-system interoperability, protected execution control,
autonomous artificial-intelligence systems, distributed
authorization, trusted computing, and the governance of consequential
operations across heterogeneous computing environments.
More particularly, the invention concerns systems, methods,
apparatus, machine-readable authorization structures, protected
execution components, and interoperable enforcement protocols for
preserving and verifying execution authority when applications,
autonomous agents, services, computational workloads, or device-
control functions operate across different operating systems,
hardware architectures, administrative domains, security substrates,
and communication environments.
Das Expires 29 April 2027 [Page 24]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The invention is applicable to mobile operating systems, including
Android, iOS, iPadOS, and other mobile platforms; desktop operating
systems, including macOS, Windows, Linux, and other computing
environments; and wearable devices, embedded controllers,
communication systems, cloud infrastructures, confidential-computing
environments, virtual machines, autonomous robots, vehicles, and
future computing platforms.
8.1.3.2. Original global source page 2
The named operating systems and commercial environments are
illustrative, non-limiting examples. The invention does not require
participation by any particular operating-system provider,
manufacturer, application ecosystem, or proprietary technology.
2. Increasing Fragmentation of Operating-System and Application
Security
Modern computing environments comprise multiple independently
administered operating systems, application ecosystems, device
manufacturers, identity providers, cloud services, and security
architectures.
Different platforms may implement substantially different mechanisms
for application isolation, permission enforcement, credential
storage, interprocess communication, secure execution, hardware-
backed cryptographic operations, network control, user approval, and
access to sensitive resources.
For example, one operating system may expose selected protected
application interfaces, permission services, secure hardware
functions, and controlled background-execution facilities, while
another operating system may provide different forms of application
sandboxing, entitlement verification, privileged-service mediation,
or device-security interfaces.
These mechanisms may individually provide useful technical security
properties, but their differences complicate the preservation of a
consistent and independently enforceable authorization relationship
when a computational task crosses platform boundaries.
A permission recognized by one operating system is not necessarily
semantically equivalent to an entitlement, authorization, credential,
or protected resource grant recognized by another.
Das Expires 29 April 2027 [Page 25]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Likewise, the ability of one application or service to request an
operation does not establish that a receiving application, operating
system, privileged controller, or remote resource is authorized to
produce the requested consequential effect.
Accordingly, interoperability between computing environments requires
more than the exchange of commands, files, credentials, permissions,
application messages, or authenticated identities.
3. Limitations of Conventional Cross-Platform Interoperability
Conventional interoperability systems commonly enable information
exchange, task synchronization, remote procedure invocation,
application linking, cross-device communication, identity federation,
and service-to-service authorization.
Such mechanisms may permit a task initiated in a first environment to
continue in a second environment.
However, technical interoperability does not necessarily establish
interoperable execution authority.
An application operating in an Android-based environment may generate
a request intended to produce an effect within an iOS-based
environment, or vice versa.
8.1.3.3. Original global source page 3
The receiving environment may authenticate the sending application,
accept a structured request, recognize a permitted service identity,
or validate a delegated credential.
Nevertheless, the requested operation may differ materially from the
operation originally authorized by the relevant principal.
The difference may concern the actual resource, recipient, outgoing
information, operation parameters, current resource version,
delegated scope, original authorization conditions, or applicable
device-security state.
A successful communication handshake, authenticated application
request, or cross-platform permission translation therefore does not,
by itself, establish authority for the actual consequential
operation.
4. Absence of Uniform Execution-Finality Semantics
Das Expires 29 April 2027 [Page 26]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Existing operating systems and application frameworks frequently
distinguish among authenticated identities, permissions, application
capabilities, hardware entitlements, and resource-access policies.
However, those mechanisms do not necessarily implement the same
technical meaning of final authorization at the boundary where a
consequential operation becomes effective.
An approval generated in one domain may be consumed by an
intermediary service in another domain, while the ultimate resource
modification occurs through a different component.
A receiving component may interpret the approved operation
differently, apply a different authorization scope, or invoke an
additional privileged interface.
Consequently, upstream authorization may become detached from the
actual operation eventually executed.
This problem becomes particularly significant when the operation
concerns persistent data modification, confidential information
export, credential activation, financial instructions, network
transmission, device configuration, physical actuation, or another
consequential operation.
There remains a technical need for a platform-independent
representation of protected consequential authority whose operative
meaning is verified at the actual effectuation boundary rather than
inferred solely from the success of an upstream permission mechanism.
5. Autonomous Artificial-Intelligence Agents and Cross-Platform
Execution
Autonomous AI agents and computational assistants increasingly
perform tasks involving multiple applications, devices, execution
environments, and remotely administered services.
An agent may receive an instruction on a mobile device, perform
planning using a remote computational service, delegate part of the
task to another agent, retrieve information from a third-party
application, and subsequently request a consequential operation
through a different platform.
Das Expires 29 April 2027 [Page 27]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.1.3.4. Original global source page 4
The original task may pass through several computational
transformations, including model inference, tool selection, message
translation, task delegation, application-interface invocation, and
execution-context migration.
These transformations may alter the representation of the requested
operation without necessarily establishing renewed authority from the
originating principal.
Moreover, autonomous agents may encounter malicious instructions,
compromised external content, stale task context, incorrect resource
references, hallucinated operation parameters, or manipulated tool
responses.
A computational system may therefore generate a technically
executable command that exceeds the scope of the original
authorization.
Merely isolating the agent within a sandbox, authenticating its
identity, or restricting access to selected tools does not
necessarily prevent an unauthorized effect through another accessible
execution route.
The fundamental technical issue is the separation between
computational capability and independently established authority to
cause a real consequence.
6. Cross-Device Authority Duplication and Migration
Cross-device continuity presents additional security and consistency
problems.
When a task moves between devices, the transfer may include
application state, execution context, cached credentials, model
state, memory, instructions, command queues, or unfinished
operations.
However, transferring computational state does not automatically
transfer valid authority to perform consequential operations.
Similarly, transferring a task to a receiving device does not
automatically invalidate effectuation authority remaining on the
originating device.
Das Expires 29 April 2027 [Page 28]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
For example, a user may initiate an autonomous workflow on one mobile
operating system and continue the workflow on another mobile or
desktop environment.
If both environments retain independently usable authority for the
same unfinished operation, duplicate or conflicting consequences may
occur.
A stale device may also resume after suspension, recover an outdated
application state, or attempt to exercise authority that has already
been transferred, revoked, consumed, or superseded.
Conventional data synchronization alone does not necessarily
establish exclusive execution ownership, protected authority epochs,
source-device fencing, or destination-local validation of the actual
consequential operation.
7. Inconsistent Enforcement Capabilities Across Platforms
Different operating systems and devices expose different levels of
control over applications, privileged services, network
communications, storage operations, hardware functions, and security-
sensitive interfaces.
8.1.3.5. Original global source page 5
Some environments permit enforcement through operating-system
security components or protected hardware controllers.
Other environments may permit only application-level mediation,
approved extension interfaces, managed-service gateways, server-side
authorization, or remote resource enforcement.
Certain security mechanisms provide blocking capability, while others
provide observation, logging, notification, policy advice, or post-
operation auditing.
A system that merely receives a security event cannot necessarily
prevent the corresponding effect.
Likewise, a system that controls one application interface may not
control an alternative interface capable of producing the same
consequence.
A generic interoperability layer that assumes identical operating-
system privileges or uniform enforcement interfaces may therefore
provide incomplete protection when deployed across heterogeneous
platforms.
Das Expires 29 April 2027 [Page 29]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A need exists to determine the actual enforcement capability of each
participating security mechanism and to qualify whether the relevant
effectuation path is subject to mandatory protected control.
8. Limitations of Credential-Based and Permission-Based Approaches
Conventional authorization systems may use access tokens,
cryptographic signatures, structured permission grants, proof-of-
possession protocols, mutual authentication, credential brokers,
hardware-backed keys, and delegated authorization.
These mechanisms provide valuable security functions.
However, successful authentication, credential validity, permission
possession, or cryptographic proof does not necessarily establish
that a particular resource-side consequential operation remains
authorized at execution time.
An access token may remain valid while the operation exceeds its
intended effect scope.
A cryptographic signature may authenticate an earlier approval while
the actual destination, resource identity, operation semantics, or
policy state has changed.
A credential broker may possess technical authority to perform a
broad range of operations even when the requesting agent is permitted
to initiate only one narrowly defined action.
Accordingly, the security problem is not resolved merely by
transferring, translating, exchanging, or validating credentials
between operating systems.
The actual consequential effect must remain independently bound to
current protected authority.
9. Revocation, Replay, and Distributed-State Problems
Cross-platform environments may maintain authorization and revocation
state in multiple administrative domains.
8.1.3.6. Original global source page 6
A source device may revoke authority while a destination device
remains disconnected.
A remote service may receive a revocation notification after a
previously authorized operation has already entered a queue.
Das Expires 29 April 2027 [Page 30]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A cached permission decision may remain locally available after the
underlying grant has expired or changed.
Similarly, a previously generated authorization artifact may be
copied, replayed, presented to another execution sink, or restored
through an outdated application or virtual-machine snapshot.
These conditions create technical risks involving stale authority,
duplicate effectuation, inconsistent consumption accounting, and
delayed enforcement of revocation.
Immediate revocation cannot be assumed in a disconnected receiving
domain without an appropriate supporting mechanism.
Interoperable execution control must therefore account for authority
generations, bounded validity, protected consumption state,
revocation dependencies, and conservative handling of uncertain
distributed conditions.
10. Technical Problem Addressed by the Invention
In view of the foregoing limitations, there exists a need for an
interoperable protected execution architecture capable of governing
consequential operations across heterogeneous operating systems,
devices, applications, and administrative domains without requiring
identical security implementations or transferring unrestricted
authority between them.
More particularly, the technical problem is how to:
(a) preserve the scope and identity of originating execution
authority across different platforms;
(b) translate heterogeneous authorization and security evidence into
a machine-verifiable, operation-specific effect representation;
(c) prevent a computational request, authenticated identity,
credential, or platform permission from independently constituting
final authority;
(d) maintain proposed consequential operations in an enforceable non-
effective condition;
(e) establish protected finality enablement dependent upon current
authority, revocation, security context, and applicable enforcement
capability;
Das Expires 29 April 2027 [Page 31]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
(f) independently verify the actual pending consequential operation
at the receiving resource or device boundary;
(g) prevent unauthorized replay, stale-owner execution, cross-
platform scope expansion, or duplicate effectuation;
(h) support bounded delegation and authenticated transfer of
execution authority between heterogeneous environments; and
8.1.3.7. Original global source page 7
(i) preserve the required security properties even when different
platforms employ different software, hardware, communication, and
authorization mechanisms.
The present invention addresses these technical problems through a
protected, operation-specific execution-finality architecture having
interoperable authority semantics and qualified platform-specific
enforcement implementations.
SUMMARY OF THE INVENTION
1. General Overview
The present invention provides systems, methods, apparatus, protected
execution components, interoperable authorization protocols, machine-
verifiable records, and computer-implemented procedures for governing
consequential computational operations across heterogeneous operating
systems and computing environments.
The disclosed architecture is applicable to Android, iOS, and other
mobile operating systems, together with desktop, cloud, edge,
embedded, industrial, network, robotic, and future autonomous
computing systems.
The invention does not require the participating environments to
implement identical operating-system kernels, security frameworks,
application permission models, hardware architectures, cryptographic
processors, or proprietary communication protocols.
Instead, the architecture establishes a common protected execution-
finality relationship in which a proposed operation remains non-
effective until the required operation-specific authority is
established and verified by a technical boundary capable of
withholding the governed consequence.
The foundational principle is that computation is not authority to
act.
Das Expires 29 April 2027 [Page 32]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The production, transmission, translation, delegation, or receipt of
a computational request does not automatically establish authority to
produce its external or persistent effect.
2. Platform-Independent Execution-Finality Framework
In one implementation, the system comprises a Requesting
Computational Entity, a Candidate Act construction component, a Non-
Effective Holding Mechanism, one or more Protected Enforcement
Domains, protected authorization and evidence adapters, an authority
preparation component, and at least one designated Finality Sink.
The requesting computational entity may operate within a mobile
application, autonomous assistant, operating-system service, cloud
agent, remote tool, embedded controller, or other computational
workload.
A proposed consequential operation is represented as a Candidate Act
containing or referencing the security-relevant identity, operation
class, resource, destination, parameters, originating authority, and
applicable execution context.
The proposed operation is maintained in a Non-Effective State by an
enforceable holding mechanism until the relevant protected conditions
are satisfied.
8.1.3.8. Original global source page 8
A protected authority controller verifies applicable evidence and
establishes scoped execution-finality enablement.
The actual Finality Sink obtains or reconstructs the pending
consequential operation and determines whether it corresponds to the
protected authorization before permitting the effect.
The number, placement, and physical implementation of the
participating components may vary according to the selected platform
and threat model.
3. Interoperability Between Android, iOS, and Other Operating
Systems
In a non-limiting embodiment, the invention provides interoperable
protected execution-finality control between computing environments
operating different mobile operating systems, including Android-based
and iOS-based devices.
Das Expires 29 April 2027 [Page 33]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A consequential operation initiated within a first platform may be
represented using a protected canonical effect descriptor and
communicated to an authorized receiving component operating within a
second platform.
The receiving component does not automatically treat the originating
platform's permission, application entitlement, authenticated
message, or credential as sufficient authority to cause the requested
effect.
Instead, the receiving platform applies its own qualified protected
verification and enforcement mechanisms while preserving the required
operation-specific authorization conditions.
For example, a task originating within an Android-based application
may be evaluated by a protected authorization service and
subsequently presented to a controlled application function, resource
gateway, or qualified effectuation component associated with an iOS-
based environment.
Conversely, a task originating in an iOS-based environment may be
submitted to a protected resource interface associated with an
Android-based environment.
In either direction, execution remains dependent upon independently
verified authority, current applicable state, and the actual
consequential operation.
The same technical relationship may apply to interoperability
involving iPadOS, macOS, Windows, Linux, other mobile or desktop
systems, cloud services, embedded platforms, and subsequently
developed operating systems.
The invention does not presume that any operating system exposes
unrestricted kernel, application, network, or hardware interception
facilities. Enforcement is implemented through qualified interfaces
actually available and authorized within the relevant deployment,
including protected application dispatchers, privileged brokers,
managed resource controllers, remote enforcement gateways, and
destination-side Finality Sinks.
4. Protected Authorization-to-Effect Translation
Das Expires 29 April 2027 [Page 34]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.1.3.9. Original global source page 9
In another aspect, the invention provides a protected translation
mechanism configured to obtain authorization and security information
from heterogeneous source systems and convert the relevant
information into a bounded consequential-operation representation.
The source information may comprise identity assertions, application
permissions, delegated authorization records, structured action
descriptions, protected device state, cryptographic authentication
evidence, resource-access restrictions, or other qualified security
information.
A protected translation controller determines the actual technical
meaning of the requested operation and produces or verifies a
canonical effect descriptor.
The descriptor may identify an originating principal, requesting
component, actual operation class, resource identity, effective
recipient, operation parameters, permitted effect envelope, relevant
policy state, and designated enforcement boundary.
Different platforms may employ different native permission names or
resource-interface structures while using equivalent protected effect
semantics for the specific governed operation.
A source permission is not silently expanded merely because the
receiving platform implements a broader technical operation.
Where the protected translation cannot establish the necessary
correspondence, the affected consequential operation remains
withheld.
5. Independent Protected Authority Across Platform Boundaries
The invention further provides a Protected Enforcement Domain
configured to evaluate applicable originating authority, delegated
scope, current resource conditions, relevant revocation dependencies,
security-substrate qualifications, and operation-specific validation
evidence.
The Protected Enforcement Domain may comprise a protected operating-
system component, independently secured service, secure processor,
trusted execution environment, hardware controller, remote protected
validator, or compatible combination thereof.
Das Expires 29 April 2027 [Page 35]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
In implementations requiring separate collection-time and execution-
time validation, corresponding protected evidence instances may
independently evaluate the applicable Candidate Act and establish
authenticated evidence commitments.
A protected finality controller may subsequently create, activate,
derive, sign, or otherwise constitute scoped non-bearer execution
enablement.
Such enablement may be bound to the specific operation, permitted
effect, resource identity, designated sink, relevant authority
generation, current enforcement coverage, validity conditions, and
protected consumption state.
The enablement need not be provided to the requesting application as
a reusable transferable credential.
6. Independent Finality Sink Verification
8.1.3.10. Original global source page 10
A principal aspect of the invention is the independent verification
of the actual pending operation at its consequential enforcement
boundary.
The Finality Sink may comprise a protected application-function
dispatcher, network gateway, storage transaction controller,
credential-release interface, cloud API enforcement component, device
command controller, hardware interface, payment dispatcher, or other
qualified effectuation mechanism.
The Finality Sink obtains or reconstructs relevant actual operation
parameters from the controlled effectuation path.
The sink compares the pending operation against the authorized effect
descriptor, protected validation evidence, scoped finality
enablement, current authority state, and applicable sink-local
protected state.
A material mismatch, stale authorization, unqualified enforcement
path, revoked permission, unsupported resource identity, or invalid
authority-consumption condition prevents the governed operation from
becoming effective.
Where single-use or bounded-use authorization applies, the relevant
protected consumption transition is enforced before the corresponding
consequence is released.
Das Expires 29 April 2027 [Page 36]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
7. Cross-Device Execution Authority Continuity and Migration
In another embodiment, the invention enables the controlled migration
or reestablishment of unfinished execution authority between
heterogeneous computing environments.
A computational workflow may move between smartphones, tablets,
desktop computers, cloud instances, edge devices, virtual machines,
hardware accelerators, or other computational systems.
The movement of computational state is distinguished from the
transfer of authority to produce consequential effects.
Where exclusive operation ownership is required, the system may
establish authenticated device identities, protected ownership
generations, monotonic authority epochs, source-device fencing, and
destination-specific finality enablement.
A previous execution environment is prevented, through the applicable
protected enforcement mechanisms, from exercising stale authority
after exclusive effectuation ownership has been transferred.
The destination Finality Sink independently verifies current
ownership, authorized effect scope, actual operation parameters, and
protected consumption state.
A copied task image, migrated process, restored snapshot, or
transferred credential reference does not independently create or
duplicate execution authority.
8. Cross-Provider and Cross-Agent Interoperability
8.1.3.11. Original global source page 11
The architecture may additionally support interoperability between
computational agents and application services administered by
different providers.
An originating principal may authorize a bounded task that is
subsequently delegated through one or more agents, services, devices,
or administrative domains.
Protected delegation records may preserve originating authority
references, delegated scope, relevant resource limits, current
revocation dependencies, and authenticated delegation relationships.
Das Expires 29 April 2027 [Page 37]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A receiving agent may perform authorized computation without
receiving unrestricted authority over the originating principal's
resources.
Where a consequential operation is delegated, the receiving Finality
Sink verifies the current authorized scope and the actual pending
effect.
The transfer of task information, agent messages, inference results,
or executable instructions does not itself enlarge the original
permitted authority.
9. Dynamic Platform-Security Qualification
In another aspect, the invention provides a mechanism for qualifying
heterogeneous security components according to the properties they
actually establish.
A protected controller may identify whether a selected security
mechanism provides authentication, observation, advisory policy
evaluation, isolation, revocation notification, resource control, or
mandatory blocking of a specified effect.
The controller may maintain protected enforcement-qualification
records identifying the current security component, controlled
resource, enforcement mode, operation-visibility capability,
applicable configuration generation, and unresolved bypass
conditions.
A component is not treated as equivalent to another merely because
both are described as security mechanisms.
A replacement operating-system interface, application gateway,
sandbox mechanism, cryptographic provider, or hardware controller
must provide the properties required for the corresponding protected
operation.
Material changes to enforcement capability or relevant execution
semantics may invalidate dependent finality authorization until
revalidation is completed.
10. Interoperability Through Existing and Future Technical
Mechanisms
Das Expires 29 April 2027 [Page 38]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The invention may employ existing authorization protocols,
authenticated communication mechanisms, structured operation
representations, interprocess communication, cryptographic
signatures, protected key storage, secure processors, transactional
state stores, and resource-side enforcement interfaces.
Such mechanisms are individually usable as established technical
implementation substrates.
8.1.3.12. Original global source page 12
In selected embodiments, typed JSON, CBOR, deterministic binary
encodings, or other canonical machine-readable representations may
communicate protected operation and evidence information.
Platform-specific adapters may translate native authorization or
application-operation representations into the required interoperable
protected structures.
The architecture is not restricted to one serialization format,
cryptographic algorithm, permission framework, application-
development environment, transport protocol, or processor instruction
set.
The operative requirements concern the preservation of protected
authority dependencies, correct actual-operation correspondence,
sufficient enforcement coverage, and verified finality control.
11. Revocation, Replay Prevention, and Protected State Continuity
The invention may maintain protected authorization generations,
revocation references, consumption records, device-ownership epochs,
current resource state, and relevant enforcement-coverage
information.
Before releasing an operation, the applicable Finality Sink verifies
the protected state required by the selected implementation.
Previously valid authorization may be rejected when the source
authority has been revoked, the relevant resource has materially
changed, or the permitted authority has already been consumed.
A replayed or misdirected finality reference does not automatically
authorize another operation or a different Finality Sink.
Disconnected environments may employ bounded offline authority,
protected counters, expiry constraints, or other conservative
validity mechanisms where technically supported.
Das Expires 29 April 2027 [Page 39]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Where current mandatory authorization cannot be established, the
corresponding governed consequence remains withheld rather than being
released on the assumption that earlier authorization remains valid.
12. Platform-Independent Security Without Mandatory Vendor
Dependence
The invention is not limited to a specific commercial operating
system, manufacturer, application store, cloud provider, hardware-
security product, AI model, or agent framework.
Its implementation may use different qualified security substrates
for different effect classes and deployment environments.
For example, one implementation may use a protected application
gateway, another may use a privileged operating-system resource
controller, and another may use a hardware-backed Finality Sink or
independently controlled remote service.
An implementation need not reproduce the internal architecture of
another operating system to establish a protected execution-finality
relationship over operations that it can actually govern.
8.1.3.13. Original global source page 13
Where a particular platform does not provide an authorized mechanism
capable of withholding a selected local operation, the architecture
does not assume that such an operation is protected by a merely
observational interface. Protection may instead be implemented at an
available qualified resource, service, gateway, or destination
boundary, subject to the corresponding enforcement coverage.
Accordingly, interoperability concerns equivalent protected
execution-authority semantics and enforceable consequence control
rather than mandatory uniformity of proprietary platform mechanisms.
13. Optional Specialized Technical Extensions
The disclosed architecture may be combined with compatible
specialized verification mechanisms described in the specification.
Such mechanisms may include protected cross-agent conflict
coordination, semantic correspondence between a user-selected object
and an actual operation target, cumulative privacy-exposure
constraints, delegated-authority conservation, operation-semantics
continuity, hardware command control, protected physical-state
validation, authenticated actual-effect evidence, and receipt-gated
causal continuation.
Das Expires 29 April 2027 [Page 40]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Where an operation requires one of these specialized conditions, the
applicable condition may become a mandatory predicate of that
operation's finality authorization.
However, the presence of an optional verification mechanism in one
embodiment does not make the mechanism universally necessary for
every implementation.
Each embodiment may select the components required for the particular
consequential effect and intended technical trust model.
14. Technical Advantages and Effects
The disclosed invention seeks to provide a common protected
execution-finality framework across heterogeneous operating systems
and computing environments while accommodating their different native
security implementations.
The architecture can provide operation-specific protection against
authorization-to-effect mismatches, stale permission use,
unauthorized scope expansion, duplicate effectuation, cross-device
authority conflicts, and selected enforcement-bypass conditions
within the coverage of the implementation.
It distinguishes the authority to compute, transmit, delegate,
authenticate, or access a tool from the protected authority required
to produce a particular real-world or persistent consequence.
The invention may further preserve authority continuity when a
workflow moves across Android, iOS, other operating systems,
independent applications, remote agents, and cloud or hardware
execution environments.
Unlike an architecture that relies solely upon uniform platform
permissions or transferable credentials, the disclosed relationship
conditions consequential effectuation upon independently verified
protected authority and actual-operation correspondence at a
qualified enforcement boundary.
8.1.3.14. Original global source page 14
The resulting framework enables heterogeneous platforms to contribute
different security mechanisms while retaining the required protected
relationships between original authority, consequential operation,
current state, and final effectuation.
15. Scope and Non-Limiting Character of the Disclosure
Das Expires 29 April 2027 [Page 41]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The foregoing summary describes representative implementations and is
not intended to restrict the invention to a particular arrangement,
operating system, software framework, network architecture, security
processor, cryptographic protocol, or commercial implementation.
Compatible features described in the specification may be employed
independently or in combination, subject to their applicable
technical requirements.
The disclosed algorithms, machine-readable records, state
transitions, reference implementations, examples, and experimental
procedures are illustrative and non-limiting aids to enable a person
having ordinary skill in the art to implement the corresponding
embodiments.
A component may perform multiple logical functions, and selected
functions may be distributed across independently protected domains,
provided that the technical properties expressly required by the
relevant implementation are preserved.
The invention encompasses present and future qualified
implementations of interoperable execution-finality control across
heterogeneous computing environments, within the scope supported by
the detailed disclosure and the appended claims.
8.2. CW-1: Common Protected Execution-Finality Workflow — Evidence and
Authority Foundations
Original source global pages 15-62. Preserved for technical
discoverability and traceability; consult the cited full Zenodo
document for complete source context. This part primarily
concentrates on evidence binding, scope, non-bearer authority and
protected journal consumption; other documents provide specialized
enforcement, device handoff and actual effect receipt details.
8.2.1. Architecture and Protected Trust Boundaries
[Source principal]-->[CA / NES]-->[Collection PED]
|
[Independent validator]
|
[Cross-committed evidence]
|
[Scoped finality authority]
|
[Actual Finality Sink]
Das Expires 29 April 2027 [Page 42]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Figure 14: CW-1: Common Protected Execution-Finality Workflow —
Evidence and Authority Foundations — Protected Architecture
8.2.2. Operational Decisions and Fail-Closed State Transitions
[Source act proposed]
|
[Hold in NES; collect evidence]
|
<Fresh independent validation?>--NO-->[Withhold]
|YES
[Constitute scoped authority]
|
<Sink actual act matches?>--NO-->[Withhold]
|YES
[Consume and effect]
Figure 15: CW-1: Common Protected Execution-Finality Workflow —
Evidence and Authority Foundations — Decision Flowchart
8.2.3. Page-Indexed Original Technical Disclosure
8.2.3.1. Original global source page 15
COMMON MASTER WORKFLOW CW-1
MODULAR PROTECTED EXECUTION-FINALITY ARCHITECTURE WITH ACTUAL-
OPERATION RECONSTRUCTION, INDEPENDENT PROTECTED AUTHORITY, NON-
BYPASSABLE CONSEQUENCE ENFORCEMENT, CROSS-DOMAIN SECURITY, AND
OPTIONAL ADVANCED TECHNICAL MECHANISMS FOR PRESENT AND FUTURE
AUTONOMOUS COMPUTING SYSTEMS
CW-1.0 — PURPOSE, TECHNICAL FIELD, AND GENERAL DESCRIPTION
The present disclosure provides a Common Master Workflow, designated
CW-1, for governing consequential operations proposed, prepared,
scheduled, delegated, transmitted, or otherwise initiated by
autonomous computational entities.
Such entities may include artificial-intelligence agents, machine-
learning systems, autonomous assistants, multi-agent execution
frameworks, operating-system services, applications, device
controllers, distributed software services, embedded computing
systems, robotic controllers, programmable hardware, communication
infrastructure, and other computational entities capable of
initiating externally consequential operations.
Das Expires 29 April 2027 [Page 43]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
CW-1 establishes a common technical foundation for the inventions and
embodiments described subsequently in this specification.
The workflow distinguishes the computational production of a proposed
operation from the protected technical authority required to cause
its consequential effect.
In a principal implementation, an operation proposed by a
computational entity is represented as a Candidate Act and is
maintained in a Non-Effective State until applicable authorization
conditions are satisfied.
A Protected Enforcement Domain evaluates the applicable evidence,
authorization, current technical conditions, and protected state.
The applicable protected authority produces, enables, or commits
scoped finality authorization.
A Finality Sink independently obtains or reconstructs the actual
pending operation and verifies the authority against the real
operation presented at the consequential boundary.
The Finality Sink permits the specified consequence only upon
successful verification of all mandatory conditions.
The authorization may be cryptographically represented, maintained as
protected state, implemented through secure hardware, or realized
through a combination of protected software and hardware mechanisms.
The system may operate across a single processor, multiple processes,
multiple devices, administrative domains, protected controllers, or
distributed infrastructure.
CW-1.0.1 — Fundamental Technical Principle
The foundational principle is:
8.2.3.2. Original global source page 16
Computation is not authority to act.
The production of a command, plan, model output, tool invocation,
workflow instruction, transaction proposal, or executable operation
does not itself confer final authority to cause the corresponding
consequential effect.
Das Expires 29 April 2027 [Page 44]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Similarly, an agent's successful authentication, possession of an API
credential, access to a software tool, or apparent satisfaction of an
application-level policy does not automatically establish the
complete protected authority required by a particular execution-
finality implementation.
The relevant authority must be verified according to the defined
protected trust model and at an enforcement boundary capable of
withholding the actual effect.
CW-1.0.2 — Common Architecture Rather Than One Mandatory Physical
Arrangement
CW-1 is not restricted to one hardware or software topology.
The protected validation function and Finality Sink may be separated
or integrated.
The protected authority may reside within a dedicated security
processor, secure microcontroller, isolated execution environment,
protected operating-system service, firmware controller, remote
protected authorization service, or another computing substrate
providing the required security properties.
A single protected component may implement multiple logical
functions.
Alternatively, each function may be distributed among independently
controlled devices.
The defining technical relationship is the controlled progression
from Candidate Act through protected authorization to independent
final effectuation verification.
The physical number of processors, devices, servers, or communication
links is not an essential limitation unless expressly required by a
particular embodiment.
CW-1.0.3 — General Proposed Inventive Direction
The candidate technical contribution of CW-1 concerns the combination
and enforcement relationships among operation-specific non-authority,
protected evidence evaluation, scoped execution enablement, actual
pending-operation reconstruction, sink-local protected state, and
effectuation-boundary control.
Das Expires 29 April 2027 [Page 45]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The proposed distinction is not that an AI agent uses a sandbox,
cryptographic key, access-control rule, approval screen, or security
gateway.
Those techniques are individually established.
The technical question is whether a particular implemented
combination makes independently verified, operation-specific
protected authority a necessary condition for the actual
consequential effect and prevents an untrusted computational entity
from bypassing that condition through an alternative route within the
claimed enforcement coverage.
CW-1.0.4 — Optional Technical Extensions
8.2.3.3. Original global source page 17
CW-1 supports additional mechanisms addressing concurrent agents,
conflicting effects, semantic target correspondence, delegated
authority, privacy constraints, resource allocation, protected state
continuity, remote execution, actual outcome witnessing, hardware
enforcement, user reauthorization, and causal continuation between
consequential phases.
Each extension may be applied individually or in compatible
combinations.
No optional mechanism is universally mandatory merely because it
appears in CW-1.
Where an embodiment expressly requires a particular technical
feature, omission of that feature is not treated as satisfying the
corresponding embodiment.
CW-1.0.5 — Scope of Present and Future Implementations
The common architecture is applicable to presently implementable
systems using protected software gateways, secure processors,
transaction controllers, cryptographic authorization, hardware
command gates, protected storage, and authenticated communication.
It also supports proposed advanced implementations involving cross-
provider autonomous agents, heterogeneous compute accelerators,
multi-device autonomy, safety-critical robotic systems, advanced
communication networks, confidential computing, distributed protected
validators, and future effect-capable hardware interfaces.
Das Expires 29 April 2027 [Page 46]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The advanced implementations are technical alternatives and
development directions, not assertions that such systems have already
been built or commercially deployed.
CW-1.1 — RELATIONSHIP TO INDIVIDUAL EMBODIMENTS
CW-1 provides a reusable common protected execution framework for the
subsequent embodiments.
An individual embodiment may incorporate the baseline Candidate Act,
Non-Effective State, Protected Enforcement Domain, scoped authority,
and Finality Sink mechanisms without requiring every additional
verification module.
For example, a cross-agent conflict embodiment may require protected
conflict reservations.
A semantic correspondence embodiment may require evidence linking a
user-observed object to the actual operation target.
A privacy-composition embodiment may require protected cumulative
disclosure state.
A phased-effectuation embodiment may require an authenticated prior
real-effect receipt.
A protected device-migration embodiment may require exclusive
authority ownership and stale-owner fencing.
The relevant technical requirements are selected according to the
particular effect being governed.
CW-1.1.1 — Reference to CW-2
CW-2 provides an optional specialized mechanism for causally ordered
receipt-gated effectuation.
8.2.3.4. Original global source page 18
Where the principal inter-phase CW-2 implementation is selected, an
earlier bounded real effect produces qualified evidence accepted by
an authorized cryptographically identifiable Interim Effectuation
Validator.
The validator-accepted receipt is a necessary causal enabling factor
for the next consequential phase.
Das Expires 29 April 2027 [Page 47]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The next Finality Sink verifies the applicable authenticated receipt-
dependent condition before permitting the successor effect.
CW-1 does not require that every single-effect operation use such a
phased continuation mechanism.
CW-1.1.2 — Reference to CW-3
CW-3 may provide optional protected anomaly-triggered human or
automated reauthorization.
Where an autonomous operation departs from its originally authorized
scope, a protected system may require renewed approval.
However, approval does not automatically satisfy unrelated mandatory
technical predicates, including current resource identity, finality
authority, physical safety constraints, or an applicable CW-2 causal
receipt.
CW-1.1.3 — Independent Inventive Contributions
Each subsequent embodiment may disclose additional technical
structures, state transitions, algorithms, threat models, actual
enforcement interfaces, and technical effects.
The general existence of CW-1 does not establish that every optional
embodiment is novel or inventive.
Individual technical contributions must be evaluated in relation to
their corresponding prior art.
CW-1.2 — TECHNICAL PROBLEMS AND LIMITATIONS OF CONVENTIONAL SYSTEMS
CW-1.2.1 — Conventional Permission Does Not Necessarily Govern Actual
Consequence
A conventional access-control system may determine whether a
requesting principal has permission to use a resource.
The permitted software may nevertheless construct different actual
command parameters after the authorization check.
For example, an agent may receive permission to send a selected
document to a designated destination.
After the initial permission is granted, the selected document,
destination, version, or transmission parameters may change.
Das Expires 29 April 2027 [Page 48]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.2.3.5. Original global source page 19
A static permission does not necessarily establish that the actual
later transmission corresponds to the authorized operation.
CW-1 addresses this problem through operation-specific authority
binding and final enforcement against the actual pending effect.
CW-1.2.2 — Conventional Authentication Does Not Establish Full
Execution Authority
Authentication establishes an identity under a particular trust
model.
It does not necessarily establish that every requested operation by
the authenticated entity is authorized.
For example, a validly authenticated autonomous process may attempt a
payment, file export, network transmission, or device operation
outside its permitted task scope.
CW-1 separates authenticated origin from finality authorization.
CW-1.2.3 — Conventional Sandboxing Does Not Necessarily Bind Each
Effect
A sandbox may restrict access to files, networks, processes, or
devices.
Such isolation is useful and may be an important implementation
component.
However, permission to access an interface does not necessarily
establish that every operation through the interface is specifically
authorized.
CW-1 may use a sandbox while additionally requiring operation-
specific protected evidence and sink-side authorization.
CW-1.2.4 — Conventional Approval May Be Temporally Detached
An approval may concern a proposed operation at an earlier time.
The actual operation may be executed later under changed resource,
runtime, policy, or destination conditions.
CW-1 may require revalidation at the effectuation boundary or binding
to protected current-state evidence.
Das Expires 29 April 2027 [Page 49]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
CW-1.2.5 — Conventional Tool Gateways May Be Advisory or Incomplete
A tool gateway may inspect application requests.
However, an agent may possess access to another effect-capable
interface.
An enforcement mechanism is non-bypassable only to the extent that
the relevant alternative effectuation routes are controlled.
CW-1 introduces explicit effectuation-path coverage as a technical
requirement where system-wide protection is asserted.
CW-1.2.6 — Conventional Agent Coordination May Lack Protected
Authority
8.2.3.6. Original global source page 20
A multi-agent orchestrator may assign tasks and request that agents
execute in a particular order.
An instruction to wait, avoid conflicts, or ask permission does not
necessarily prevent another agent from acting through an
independently available credential or tool.
The present architecture may incorporate protected conflict
governance and final sink enforcement.
CW-1.2.7 — Conventional Audit Logging Is Not Prevention
A log may establish that an operation was attempted or completed.
However, an audit entry made after an unauthorized effect does not
prevent the effect.
CW-1 may use protected evidence before release and final sink
verification before effectuation.
Optional post-effect evidence has a distinct function concerning
actual outcome and possible later causal continuation.
CW-1.2.8 — Conventional Remote Acknowledgements May Be Incomplete
A local network send confirmation may establish that a command was
transmitted.
It does not necessarily prove that the remote operation completed.
Das Expires 29 April 2027 [Page 50]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
CW-1 distinguishes dispatch evidence, actual effect evidence, and
verified remote outcome.
CW-1.2.9 — Conventional Credential Possession May Create Broad
Authority
A reusable API credential may permit many operations.
If a compromised agent can directly exercise the credential,
authorization may be broader than the specific approved task.
CW-1 may employ credential brokers, scoped finality capabilities,
protected command authentication, or sink-local authorization to
reduce the mismatch between credential possession and permitted
effect.
CW-1.2.10 — Proposed Objective Technical Problem
An illustrative objective technical problem is:
How to ensure that an operation generated or requested by an
autonomous computational entity cannot produce its governed
consequential effect unless a protected enforcement system verifies
operation-specific authority against the actual pending operation and
current applicable protected state at a technical boundary capable of
withholding the effect, while accommodating heterogeneous execution
interfaces, distributed authority, changing runtime conditions, and
optional specialized verification requirements.
CW-1.3 — COMMON PROTECTED SYSTEM ARCHITECTURE
CW-1.3.1 — Requesting Computational Entity
8.2.3.7. Original global source page 21
A Requesting Computational Entity, or RCE, may comprise an AI agent,
application, service, workflow orchestrator, autonomous controller,
delegated tool, operating-system process, remote execution system, or
another component capable of proposing or initiating a consequential
operation.
The RCE may perform inference, planning, task decomposition, data
processing, and operation preparation.
It does not automatically acquire final execution authority from
those functions.
CW-1.3.2 — Candidate Act Construction Component
Das Expires 29 April 2027 [Page 51]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The Candidate Act Construction Component identifies a proposed
consequential operation and constructs a machine-verifiable
representation.
A Candidate Act Descriptor may bind the actual action class,
resource, destination, requesting principal, permitted effect, parent
task, current scope, and relevant authority context.
The component may be located within a protected dispatcher,
application gateway, operating system, secure processor, or service
infrastructure.
CW-1.3.3 — Non-Effective Holding Mechanism
A Non-Effective Holding Mechanism maintains the proposed operation
before its governed consequence becomes effective.
The hold may be implemented through a protected command queue,
disabled network transmission, sealed operation buffer, uncommitted
storage transaction, blocked actuator command, withheld credential
release, or another actual enforcement structure.
A simulated hold that does not prevent effectuation through the
relevant controlled path does not satisfy the required property.
CW-1.3.4 — Protected Enforcement Domain
A Protected Enforcement Domain, or PED, evaluates evidence and
maintains protected authority state.
It may be realized through a secure processor, isolated execution
environment, hardware security component, protected operating-system
service, secure firmware, or remote protected authority.
The PED may maintain cryptographic keys, protected counters,
revocation state, permitted operation scopes, evidence commitments,
current policy versions, and capability-consumption state.
CW-1.3.5 — Extended Verification Module Interface
An Extended Verification Module Interface, or EVMI, permits
specialized verification functions to evaluate relevant aspects of a
Candidate Act.
The modules may verify semantic identity, resource constraints,
privacy exposure, cross-agent conflicts, runtime integrity, actual
outcome evidence, or other mandatory technical predicates.
Das Expires 29 April 2027 [Page 52]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.2.3.8. Original global source page 22
The EVMI may be an internal protected function call, an authenticated
service interface, secure monitor operation, or distributed
validation protocol.
CW-1.3.6 — Protected Evidence Source
A Protected Evidence Source supplies information used to establish
authorization or actual operation correspondence.
Evidence may originate from protected application state, a trusted
controller, authenticated remote service, protected hardware
register, secure sensor, or another qualified technical source.
The trustworthiness of a source depends upon its actual observation
or control capabilities.
CW-1.3.7 — Protected Authority Preparation Component
A protected authority component constructs, derives, signs,
activates, or otherwise prepares the execution-enabling material
required for the specific authorized act.
The resulting authority may be represented as an Execution Handle,
App-Scoped Fractional Capability, protected command authorization,
scoped cryptographic capability, or equivalent finality enablement.
CW-1.3.8 — Finality Gate
A Finality Gate coordinates applicable authorization predicates and
determines whether finality authority may become usable.
The gate may be integrated with the PED or Finality Sink.
The gate is not assumed to provide complete protection unless the
actual effectuation boundary enforces its required decision.
CW-1.3.9 — Finality Sink
A Finality Sink, or FS, is the technical component or boundary at
which the governed operation can be permitted or refused before its
specified consequence occurs.
Das Expires 29 April 2027 [Page 53]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A sink may comprise a network egress controller, storage commit
controller, payment dispatcher, protected application-function
dispatcher, sensor-release interface, secure display controller,
hardware actuator interface, or another relevant effectuation
component.
The sink obtains or reconstructs the actual pending operation and
verifies the required protected authority before allowing it.
CW-1.3.10 — Protected State and Evidence Store
A Protected State and Evidence Store maintains relevant
authorization, validation, attempt, consumption, revocation,
continuation, and recovery state.
It may be local, replicated, or distributed.
Its consistency mechanism is selected according to the technical
guarantees required.
8.2.3.9. Original global source page 23
CW-1.3.11 — Protected Effect Observation Component
An optional Protected Effect Observation Component, or PEOC, obtains
evidence concerning an earlier actual consequential effect.
The component does not presume that sending a command proves
completion of the requested remote or physical result.
CW-1.3.12 — Interim Effectuation Validator
An optional Interim Effectuation Validator may provide independent
pre-effect operation validation or receipt-gated inter-phase
continuation.
Where a CW-2 receipt-gated phase is mandatory, the IEV has a
cryptographically verifiable identity, and its accepted prior-effect
receipt becomes a necessary causal factor for successor effectuation.
CW-1.3.13 — Effectuation-Path Coverage Controller
An optional Effectuation-Path Coverage Controller maintains evidence
concerning the interfaces through which a particular effect class may
be produced.
Das Expires 29 April 2027 [Page 54]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
It may identify authorized gateways, system interfaces, hardware
access routes, privileged services, credential-release paths, and
application dispatchers.
Where required, the controller detects coverage changes and
invalidates assumptions that a protected sink remains mandatory.
CW-1.3.14 — Protected Authority and Validator Identity Registry
A protected registry may identify trusted PED instances, valid
Finality Sinks, authorized validation modules, permitted validator
identities, cryptographic credentials, and current revocation state.
The registry may support local and cross-domain trust establishment.
CW-1.4 — TRUST MODEL AND PROTECTED ASSUMPTIONS
The system distinguishes computational entities that request
operations from components authorized to permit the corresponding
consequences.
A requesting agent may be untrusted with respect to finality
authority.
An application may supply useful operation context without possessing
authority to mint protected execution capabilities.
An operating-system service may transport authority objects without
being entitled to expand their permitted scope.
A remote service may supply authenticated observations without being
treated as trustworthy for outcomes outside its technical visibility.
A cryptographically authenticated message proves provenance under the
applicable key assumptions, not the truth of every statement in that
message.
8.2.3.10. Original global source page 24
CW-1.4.1 — Protected Authority Boundary
The PED and applicable Finality Sink must maintain the authority
material and state necessary to prevent unauthorized release under
the claimed threat model.
CW-1.4.2 — Software-Only Trust Model
Das Expires 29 April 2027 [Page 55]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A protected software service may provide useful isolation from
ordinary agent processes.
However, a software-only implementation is not presumed secure
against a fully compromised privileged operating system unless
additional appropriate protection exists.
CW-1.4.3 — Hardware-Backed Trust Model
A hardware-backed implementation may use protected processors, secure
elements, hardware-controlled effectuation, isolated command buffers,
or cryptographic identity modules.
Hardware isolation does not eliminate the need to verify correct
policy, command binding, and actual effect coverage.
CW-1.4.4 — Remote Trust Model
A remote protected authority may communicate with a local Finality
Sink through authenticated messages.
The local sink independently verifies the authorization rather than
treating remote approval as unrestricted local execution permission.
CW-1.4.5 — Distributed Trust Model
Several domains may cooperate in validation and effectuation.
Each participating domain has an authenticated identity, permitted
role, and defined protected state responsibilities.
An implementation may employ consensus, quorum validation, fencing,
or other distributed coordination when necessary.
Such mechanisms are not automatically required for every local
single-sink operation.
CW-1.4.6 — Explicit Boundary Qualification
A claimed non-bypassability property applies to the effectuation
paths actually controlled by the implementation.
An architecture that does not mediate an alternative route capable of
producing the same governed consequence cannot automatically claim
protection against that route.
CW-1.5 — COMMON MACHINE-VERIFIABLE RECORDS
Das Expires 29 April 2027 [Page 56]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
CW-1.5.1 — Candidate Act Descriptor
8.2.3.11. Original global source page 25
A Candidate Act Descriptor may contain the requesting entity
identity, original task reference, action class, permitted resource,
destination, operation arguments, designated Finality Sink, current
authority scope, protected context, and applicable module references.
The descriptor may also include actual observed resource state,
operation-semantics identity, permitted transformations, and
protected freshness values.
The specific fields are selected according to the operation.
CW-1.5.2 — Protected Validation Evidence Record
A Protected Validation Evidence Record, or PVER, binds a Candidate
Act to applicable protected validation results.
The record may comprise cryptographically authenticated data,
protected local state, a signed receipt, or an equivalent integrity-
protected representation.
It does not require a blockchain or ledger.
CW-1.5.3 — Extended Verification Evidence
Extended Verification Evidence, or EVE, represents a specialized
verification module's authenticated result.
The result may bind the Candidate Act, module identity, evaluated
predicate, evidence source, current state, and applicable
effectuation constraint.
CW-1.5.4 — Scoped Finality Authority
Scoped Finality Authority, or SFA, means an execution-enabling
authority object, protected state, or capability constrained to the
corresponding permitted effect.
It may bind operation parameters, resource, destination, designated
sink, validity period, protected evidence, and consumption
conditions.
An SFA need not be a freely transferable bearer token.
CW-1.5.5 — Protected Effect Receipt
Das Expires 29 April 2027 [Page 57]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A Protected Effect Receipt records or represents authenticated
evidence concerning an earlier actual effectuation attempt or
outcome.
Its validity depends upon the observation source and supported effect
predicate.
Where CW-2 receipt-gated continuation is required, the receipt
accepted by an authorized IEV becomes the necessary causal enabling
factor for the next protected phase.
CW-1.5.6 — Continuation Authority Record
A Continuation Authority Record represents successor-specific
authority associated with accepted prior-effect evidence or other
applicable continuation predicates.
8.2.3.12. Original global source page 26
Where CW-2 applies, a CAR may directly incorporate or be constituted
through the required validator-accepted receipt.
CW-1.5.7 — Protected Consumption Record
A Protected Consumption Record identifies whether a bounded
authorization has already been reserved, consumed, or invalidated.
It may include a protected counter, unique operation reference, state
version, or equivalent anti-replay mechanism.
CW-1.5.8 — Protected Effectuation Coverage Record
An optional Protected Effectuation Coverage Record identifies which
enforcement paths are expected to control a particular effect class.
It may record authorized interfaces, relevant security policy,
versioned controller identities, and measured coverage state.
CW-1.5.9 — Protected Semantic Correspondence Record
A Protected Semantic Correspondence Record may bind a user-visible or
application-visible referent to the actual operation target.
It may carry evidence concerning object identity, version,
presentation state, destination, or other applicable context.
CW-1.5.10 — Protected Authority Lineage Record
Das Expires 29 April 2027 [Page 58]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
An optional Protected Authority Lineage Record may represent the
relationship among original authority, delegated authority, successor
operations, and applicable resource or effect constraints.
CW-1.5.11 — Deterministic Encoding and Canonicalization
Protected records may employ deterministic binary encoding, canonical
structured data, typed fields, or another unambiguous representation.
The protocol must specify how equivalent or distinct operations are
represented.
Differences in string normalization, resource aliases, numerical
representation, schema version, nested object ordering, and encoded
payload interpretation may affect actual-operation correspondence.
A cryptographic digest is only as meaningful as the canonical
representation from which it is derived.
CW-1.6 — DETAILED COMMON EXECUTION WORKFLOW
PHASE CW-1.6.0 — PROTECTED AUTHORITY INITIALIZATION
8.2.3.13. Original global source page 27
The system establishes protected trust anchors, authority state,
enrolled principals, valid sinks, current policy versions,
cryptographic verification material, applicable module identities,
and revocation state.
Where needed, the system also establishes validator identities and
effectuation-path coverage information.
Initialization may occur during device enrollment, protected service
startup, session initiation, application registration, or another
suitable event.
An earlier enrollment does not automatically authorize all later
consequential acts.
PHASE CW-1.6.1 — REQUEST RECEIPT AND ORIGIN AUTHENTICATION
A requesting computational entity submits a proposed operation.
The receiving component identifies the apparent requester and obtains
available authentication evidence.
Das Expires 29 April 2027 [Page 59]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The system distinguishes authenticated principal identity from a
model-generated declaration of authority.
An unverified claim that an agent is permitted to act is
insufficient.
PHASE CW-1.6.2 — CANDIDATE ACT CONSTRUCTION
The operation is converted into a Candidate Act Descriptor.
The descriptor identifies the consequential operation sufficiently to
distinguish it from materially different alternatives.
Where required, the descriptor binds the actual resource, recipient,
destination, payment amount, physical target, application function,
or other effect-specific parameters.
PHASE CW-1.6.3 — NON-EFFECTIVE HOLD
The system establishes an enforceable hold.
A network transmission may be withheld.
A storage transaction may remain uncommitted.
An actuator command may remain disabled.
A credential may remain inaccessible.
A protected operation may remain in a sealed command buffer.
The hold must be capable of preventing the governed consequence
through the designated protected path.
PHASE CW-1.6.4 — EVIDENCE COLLECTION
8.2.3.14. Original global source page 28
The system obtains relevant identity, authority, context, operation,
resource, destination, runtime, and policy evidence.
The evidence is classified by source and assurance.
An unsupported assertion is not silently promoted into protected
proof.
PHASE CW-1.6.5 — REQUIRED VERIFICATION MODULE SELECTION
Das Expires 29 April 2027 [Page 60]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The protected system determines which specialized verification
predicates apply.
Module selection may depend upon action class, resource class,
privacy sensitivity, cross-agent activity, semantic ambiguity,
physical actuation, runtime conditions, or prior-effect dependency.
An untrusted agent may propose a task classification but cannot
suppress a mandatory module merely by omitting its identifier.
PHASE CW-1.6.6 — BASELINE AUTHORIZATION
The PED verifies applicable requesting-principal authority, action
scope, resource permission, destination, current revocation state,
and policy requirements.
Failure of a mandatory predicate prevents release.
PHASE CW-1.6.7 — SPECIALIZED VERIFICATION
Selected modules verify additional predicates.
For example, a conflict module may verify compatibility with another
authorized operation.
A semantic module may verify the actual resource corresponding to a
user's selected object.
A privacy module may verify cumulative disclosure constraints.
A physical-scene module may verify the intended actuator target.
An optional outcome module may verify an earlier actual effect.
PHASE CW-1.6.8 — COMPOSITE PROTECTED DECISION
The PED or an authorized coordinator combines the applicable results.
A representative abstract condition is:
BASELINE_AUTHORITY_VALID
AND REQUIRED_MODULES_VALID
AND CURRENT_PROTECTED_STATE_VALID
Das Expires 29 April 2027 [Page 61]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
AND REQUIRED_ENFORCEMENT_PATH_VALID The composition may be
implemented through one controller or multiple authenticated
protected domains.
8.2.3.15. Original global source page 29
Mandatory denials are not overridden by omission of the relevant
module.
PHASE CW-1.6.9 — PROTECTED STATE RESERVATION
Where required, the system atomically reserves operation-specific
state.
It may allocate a consumption reference, reserve a resource,
establish a conflict fence, bind a semantic target, or record a
current authority epoch.
PHASE CW-1.6.10 — VALIDATION EVIDENCE COMMITMENT
The PED commits applicable protected validation evidence.
Where a particular implementation requires an authenticated receipt
before authority release, the receipt commitment must succeed.
An untrusted process log is not a substitute for required protected
evidence.
PHASE CW-1.6.11 — SCOPED AUTHORITY FORMATION
The protected system creates, activates, derives, signs, or otherwise
establishes the required finality authority.
The authority is bound to the specific permitted act or bounded class
of acts.
It may be represented as a sealed capability, execution handle,
protected command authorization, or sink-local enablement state.
PHASE CW-1.6.12 — AUTHORITY PRESENTATION
The resulting authority is supplied or made available to the
designated Finality Sink.
An untrusted process may transport a reference without obtaining
authority to alter it.
PHASE CW-1.6.13 — ACTUAL PENDING-OPERATION RECONSTRUCTION
Das Expires 29 April 2027 [Page 62]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The Finality Sink obtains or reconstructs the actual operation
presented for effectuation.
Where technically possible, the sink obtains relevant parameters from
the controlled dispatch or effectuation interface rather than relying
exclusively upon the original agent-declared intent.
The sink may verify the actual target, destination, resource version,
command parameters, operation semantics, and relevant current state.
PHASE CW-1.6.14 — SINK-TIME REVALIDATION
The Finality Sink compares the actual operation with the protected
authority.
Where a material parameter or applicable protected state has changed,
the sink may refuse effectuation or require renewed authorization.
The verification may include current revocation, ownership, resource
reservation, semantic correspondence, and mandatory module-specific
predicates.
8.2.3.16. Original global source page 30
PHASE CW-1.6.15 — PROTECTED CONSUMPTION
Where the operation requires single-use authority, the sink
atomically reserves or consumes the applicable authorization
reference.
The state transition prevents unauthorized duplicate effects under
the selected enforcement assumptions.
PHASE CW-1.6.16 — CONTROLLED EFFECTUATION
The sink permits the specified actual consequence.
The effect may comprise a network transmission, payment submission,
storage commit, application-function dispatch, physical command,
sensor disclosure, protected data release, or other consequential
operation.
PHASE CW-1.6.17 — EFFECT ATTEMPT RECORD
The system records or commits appropriate information concerning the
effectuation attempt.
Das Expires 29 April 2027 [Page 63]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The attempt record distinguishes authority consumption from verified
external completion.
PHASE CW-1.6.18 — ACTUAL OUTCOME CLASSIFICATION
Where required, a qualified observation component evaluates the
actual result.
The outcome may be confirmed successful, partially completed,
mismatched, confirmed absent, or unknown.
A timeout is not automatically treated as proof that the effect did
not occur.
PHASE CW-1.6.19 — OPTIONAL CAUSAL CONTINUATION
Where CW-2 receipt-gated continuation applies, the accepted actual-
effect receipt is authenticated by a required IEV identity and
becomes a necessary enabling factor for the successor phase.
The successor Finality Sink independently verifies the receipt-
dependent condition before releasing the next consequential act.
Where CW-2 is not selected, the operation may terminate or proceed
according to another valid authorization protocol.
PHASE CW-1.6.20 — COMPLETION, RECOVERY, OR TERMINATION
The system records the appropriate completed, withheld, unresolved,
or recovery-required state.
A subsequent compensating operation requires its own applicable
authorization where it constitutes a new consequential act.
CW-1.7 — COMMON PROTECTED STATE MACHINE
8.2.3.17. Original global source page 31
The system may employ states representing proposed, held, prepared,
validated, authorized, sink-verified, effectuation-attempted,
outcome-confirmed, outcome-unknown, recovery-pending, and terminated
conditions.
The precise state names are non-limiting.
The important requirement is that authority-sensitive transitions
occur through protected procedures.
Das Expires 29 April 2027 [Page 64]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A transition from prepared to effectuation-ready requires
satisfaction of the applicable current authority.
A transition from effectuation-attempted to confirmed-completion
requires suitable actual-outcome evidence where that evidence is
mandatory.
A transition from an earlier phase to a receipt-gated successor
requires the appropriate validated receipt-dependent condition.
A system may combine several logical states within one protected
controller provided it preserves the necessary protected transition
semantics.
CW-1.7.1 — Anti-Rollback State
Protected state may include monotonic counters, authority epochs,
secure storage, fencing references, or other anti-rollback
mechanisms.
CW-1.7.2 — Crash-Recoverable State
Consequential attempts whose outcomes may become uncertain may be
associated with durable protected attempt references.
CW-1.7.3 — Distributed State
Where state is distributed, the implementation identifies the
authoritative owner or coordination protocol.
A stale replica cannot automatically authorize an irreversible
effect.
CW-1.7.4 — Termination After Partial Consequence
A workflow may terminate while a real external effect remains in
existence.
The system does not relabel an already completed external consequence
as non-effective.
CW-1.8 — GENERALIZED REFERENCE ALGORITHM
The following pseudocode is a non-limiting architectural
implementation.
FUNCTION PROTECTED_EXECUTION_FINALITY( request, requester_context,
protected_policy,
Das Expires 29 April 2027 [Page 65]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.2.3.18. Original global source page 32
designated_sink ):
state = PED.LOAD_PROTECTED_STATE()
REQUIRE PED.VERIFY_STATE(state)
cad = CONSTRUCT_CANDIDATE_ACT( request, requester_context,
designated_sink, state )
REQUIRE VERIFY_CANDIDATE_ACT(cad)
hold = ESTABLISH_NON_EFFECTIVE_HOLD( request, cad )
REQUIRE VERIFY_HOLD(hold)
evidence = COLLECT_RELEVANT_EVIDENCE( cad, requester_context, state )
REQUIRE VERIFY_REQUIRED_EVIDENCE_SOURCES( evidence )
required_modules = PED.RESOLVE_REQUIRED_MODULES( cad,
protected_policy, state )
REQUIRE VERIFY_MANDATORY_MODULE_COMPLETENESS( required_modules )
baseline = PED.VALIDATE_BASELINE( cad, evidence, protected_policy )
IF baseline != PASS: RETURN DENY_BEFORE_EFFECT
8.2.3.19. Original global source page 33
FOR EACH module IN required_modules:
result = INVOKE_PROTECTED_MODULE( module, cad, evidence, state )
IF result != PASS: RETURN DENY_OR_DEFER
REQUIRE VERIFY_COVERED_EFFECTUATION_PATH( cad, designated_sink )
authority = PED.ATOMIC_PREPARE_AUTHORITY( cad, evidence, state )
IF authority IS INVALID: RETURN DENY_BEFORE_EFFECT
actual_operation = designated_sink.RECONSTRUCT_PENDING_OPERATION(
hold )
Das Expires 29 April 2027 [Page 66]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
REQUIRE designated_sink.VERIFY_ACTUAL_OPERATION( actual_operation,
cad )
REQUIRE designated_sink.VERIFY_SCOPED_AUTHORITY( authority,
actual_operation )
REQUIRE designated_sink.VERIFY_CURRENT_STATE()
consumption = designated_sink.ATOMIC_CONSUME( authority,
actual_operation )
IF consumption != SUCCESS: RETURN DENY_BEFORE_EFFECT
8.2.3.20. Original global source page 34
attempt = designated_sink.EFFECTUATE( actual_operation, consumption )
outcome = CLASSIFY_SUPPORTED_OUTCOME( attempt )
PED.COMMIT_OUTCOME_STATE( cad, attempt, outcome )
IF REQUIRES_CAUSAL_RECEIPT_CONTINUATION( cad ):
receipt = OBTAIN_QUALIFIED_EFFECT_RECEIPT( cad, attempt, outcome )
vaer = AUTHORIZED_IEV_ACCEPT_RECEIPT( receipt,
current_protected_state )
IF vaer IS INVALID: RETURN WITHHOLD_SUCCESSOR_EFFECT
RETURN PROVIDE_CAUSAL_RECEIPT_TO_NEXT_SINK( vaer, permitted_successor
)
RETURN EFFECTUATION_RESULT( attempt, outcome ) The pseudocode does
not require synchronous execution of every non-dependent step.
Parallel validation may be permitted where protected state and
dependency conditions remain valid.
However, independent authority verification and protected state
consumption must preserve the technical invariants applicable to the
operation.
CW-1.9 — COMMON EXTENDED VERIFICATION MODULES
Das Expires 29 April 2027 [Page 67]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.2.3.21. Original global source page 35
CW-1.9.1 — Module A: Context, Semantic, and Identity Verification
Module A may verify correspondence between user-observed objects and
actual effectuation targets.
It may verify resource aliases, selected document versions, physical
targets, semantic referents, trusted interface state, application-
object identity, and source provenance.
A proposed candidate inventive combination may bind independently
observed semantic or object identity to an operation-specific
protected authorization and require the Finality Sink to verify the
actual target before effectuation.
The module may be particularly relevant to computer-use agents,
multimodal assistants, cross-application automation, and physical-
scene interactions.
CW-1.9.2 — Module B: Protected Authority, Privacy, and Resource
Governance
Module B may evaluate privacy-exposure limits, protected resource-
allocation constraints, multi-principal authority, disclosure
permissions, sensor restrictions, and cumulative consequence budgets.
A potentially distinguishing arrangement may require the actual
Finality Sink to verify current cumulative protected state rather
than rely solely upon independently permitted individual operations.
CW-1.9.3 — Module C: Multi-Agent and Distributed Authority
Module C may evaluate cross-agent effect conflicts, protected
resource reservations, delegation scope, authority attenuation,
device ownership, and multi-domain operation dependencies.
A protected reservation may become a mandatory condition at the
actual Finality Sink.
The module may incorporate the specialized mechanisms of Embodiment
1.
CW-1.9.4 — Module D: Execution Integrity and Environmental
Verification
Das Expires 29 April 2027 [Page 68]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Module D may verify action-contract integrity, operation-semantics
compatibility, execution-path coverage, runtime conditions, software-
update state, hardware constraints, and protected scheduling
requirements.
It may require revalidation following relevant environment changes.
CW-1.9.5 — Module E: Actual Effect, Causal Continuation, and Recovery
Module E may evaluate actual-effect evidence, authenticated receipts,
validator identity, successor phase requirements, and uncertainty-
preserving recovery.
Where CW-2 receipt-gated continuation is mandatory, the IEV's
accepted real-effect receipt becomes an indispensable factor in the
authority required by the next Finality Sink.
CW-1.9.6 — Module Independence
A module is not required to perform unrelated technical functions.
8.2.3.22. Original global source page 36
A semantic verification result does not establish financial
settlement.
A resource-reservation result does not establish actual external
effect completion.
A valid actual-effect receipt does not automatically grant
unrestricted future authority.
CW-1.10 — COMPOSITION OF PROTECTED MODULE DECISIONS
The protected coordinator identifies mandatory modules according to
the Candidate Act and current protected policy.
Each module provides a decision bound to the corresponding operation
and applicable state.
The coordinator verifies the module identity and result.
Where a module requires sink-time enforcement, its result includes or
references the mandatory condition.
A module may restrict authority, withhold an effect, or require
renewed validation.
Das Expires 29 April 2027 [Page 69]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
It may not unilaterally expand original task authority unless the
appropriate protected reauthorization procedure permits that
expansion.
CW-1.10.1 — Mandatory-Module Completeness
A requesting agent cannot remove a mandatory verification requirement
by omitting it from the request.
CW-1.10.2 — Operation-Specific Binding
A verification result for one Candidate Act is not automatically
valid for another.
CW-1.10.3 — Freshness
An old validation result may become invalid after a relevant policy,
resource, authority, or runtime change.
CW-1.10.4 — Protected State Continuity
Required module state is updated using appropriate concurrency and
rollback protection.
CW-1.10.5 — Denial Precedence
A mandatory denial condition cannot be ignored merely because another
module returned permission.
CW-1.10.6 — Causal Continuation Priority
Where receipt-gated causal continuation is mandatory, a general
authorization approval does not substitute for the required
validator-accepted predecessor receipt.
CW-1.10.7 — Distributed Module Verification
8.2.3.23. Original global source page 37
Modules may reside in independent domains.
The coordinator and Finality Sink verify the authenticated results
according to the applicable trust configuration.
CW-1.11 — PROTECTED EXECUTION INVARIANTS
Invariant I — Computation/Authority Separation. Generating a command
does not constitute authority to effectuate it.
Das Expires 29 April 2027 [Page 70]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Invariant II — Non-Effective Holding. An operation requiring
protected finality remains non-effective until applicable release
conditions are satisfied.
Invariant III — Actual-Operation Correspondence. Final authority is
verified against the operation actually pending at the effectuation
boundary.
Invariant IV — Scoped Authority. Finality authorization cannot be
expanded by copying, forwarding, re-encoding, or transporting an
authority reference.
Invariant V — Non-Bypassable Effectuation. Every effectuation route
covered by the claimed protection enforces the applicable finality
condition.
Invariant VI — Protected Consumption. Single-use authority cannot be
exercised again through unauthorized replay or stale-state
restoration.
Invariant VII — Module Constraint Preservation. Mandatory technical
predicates remain enforced at the required boundary.
Invariant VIII — Current-State Validation. Applicable protected
conditions are current when they must remain valid until
effectuation.
Invariant IX — Trusted Evidence Classification. Unsupported
statements are not silently treated as independently verified facts.
Invariant X — Effect/Receipt Distinction. A permission or dispatch
record does not automatically prove that the external consequence
occurred.
Invariant XI — Receipt-Gated Continuation. Where CW-2 requires a
validated actual-effect receipt, the next effect cannot proceed
through the protected sink independently of that receipt-derived
condition.
Invariant XII — Validator Identity. An IEV receipt is accepted only
when the relevant authorized cryptographic validator identity can be
verified.
Invariant XIII — No Authority Inflation. Delegated or derived
authority does not exceed its protected source scope.
Das Expires 29 April 2027 [Page 71]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Invariant XIV — Cross-Agent Compatibility. Where conflict governance
applies, an effectuation must satisfy current protected conflict
constraints.
Invariant XV — Unknown-Outcome Honesty. A missing acknowledgement is
not automatically classified as confirmed absence of effect.
8.2.3.24. Original global source page 38
Invariant XVI — Recovery Separation. Corrective consequential acts
are separately governed.
Invariant XVII — Protected Ownership. Where execution authority is
exclusive, superseded or stale owners cannot validly reuse that
authority.
Invariant XVIII — Semantic Binding. Where user-visible or model-
referenced targets are security-relevant, the actual effect target
must satisfy the protected correspondence predicate.
Invariant XIX — Identity/Role Distinction. A component may be
authentic but unauthorized for the requested function.
Invariant XX — Enforcement Coverage Qualification. Security claims
are bounded by the actual protected effectuation paths and threat
model.
CW-1.12 — DETAILED THREAT MODELS
CW-1.12.1 — Prompt-Injection-Induced Unauthorized Operation
An autonomous agent processes untrusted instructions embedded within
a document, web page, message, or external tool response.
The malicious content attempts to redirect the agent toward an
unauthorized operation.
The protected architecture prevents the model-generated command from
becoming effectually authoritative solely because the agent produced
it.
The Candidate Act must satisfy the applicable protected authorization
and actual sink verification.
CW-1.12.2 — Model Hallucination
An agent fabricates a resource identity, recipient, transaction
state, or operation result.
Das Expires 29 April 2027 [Page 72]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The protected system evaluates the applicable evidence independently.
A model-generated assertion does not satisfy a predicate requiring
authenticated external state.
CW-1.12.3 — Compromised Tool Interface
An intermediary tool modifies operation arguments after approval.
The Finality Sink reconstructs the actual command and rejects a
material mismatch.
CW-1.12.4 — Stolen Reusable Credential
An attacker obtains a reusable API credential.
Where the protected effectuation path requires a separate operation-
bound finality condition, possession of that credential alone is
insufficient for the protected operation.
The specific protection depends upon whether the destination or
mediated path actually requires the additional condition.
CW-1.12.5 — Alternative API Bypass
8.2.3.25. Original global source page 39
An agent invokes a different application interface to produce an
effect.
The implementation must route the claimed governed effect through an
equivalent protected Finality Sink.
If an uncovered interface remains available, the claimed protection
is incomplete for that effect.
CW-1.12.6 — Direct Network Bypass
A malicious process attempts direct network transmission around an
application-layer gateway.
A deployment claiming network-level non-bypassability may require
operating-system mediation, hardware egress control, network
isolation, or destination-side authorization.
CW-1.12.7 — Direct Hardware Bypass
Das Expires 29 April 2027 [Page 73]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A process attempts to address an actuator, storage device, radio
interface, or peripheral through an alternate hardware interface.
The applicable hardware controller must enforce the protected release
condition where system-wide physical effect control is asserted.
CW-1.12.8 — Time-of-Check/Time-of-Use Substitution
An authorized operation is changed after validation.
The sink verifies the actual pending operation and applicable current
state.
CW-1.12.9 — Stale Approval
An agent attempts to execute under a previously valid authorization
after a relevant revocation, policy update, or resource change.
The sink verifies current applicable validity conditions.
CW-1.12.10 — Capability Replay
An attacker copies a scoped authority and attempts to repeat the
effect.
Protected nonce or consumption state prevents unauthorized duplicate
exercise.
CW-1.12.11 — Cross-Sink Capability Reuse
An authority intended for one sink is presented to another.
The receiving sink rejects an authority whose required audience or
sink binding does not match.
CW-1.12.12 — Validator Impersonation
An attacker copies a validator identifier and fabricates an approval.
Where an IEV is mandatory, the sink verifies the authorized
validator's cryptographic identity and receipt.
8.2.3.26. Original global source page 40
CW-1.12.13 — Validator Replacement
An attacker substitutes a permissive IEV.
Das Expires 29 April 2027 [Page 74]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The sink rejects receipts lacking current authorized validator
enrollment.
CW-1.12.14 — Forged Actual Outcome
An agent claims that an earlier remote or physical effect succeeded.
The protected outcome observer requires evidence capable of
supporting the required actual-effect predicate.
CW-1.12.15 — Missing Remote Acknowledgement
A remote operation may have succeeded even though the originating
system received no response.
The system preserves an unknown-outcome condition and avoids
automatic unsafe repetition.
CW-1.12.16 — State Rollback
An attacker restores a software snapshot containing old authority.
Protected counters, epochs, or authoritative external state prevent
unauthorized reuse where implemented.
CW-1.12.17 — Cross-Agent Conflict
Two agents independently receive valid authorization but attempt
mutually incompatible effects.
A protected conflict module may establish reservations that are
independently enforced at the respective sinks.
CW-1.12.18 — Delegation Expansion
An agent delegates a narrow task while a downstream service attempts
a broader operation.
The protected system verifies the delegation lineage and prevents
unauthorized scope expansion.
CW-1.12.19 — Semantic Target Substitution
An application changes the resource corresponding to a visible
selection.
The relevant semantic module verifies the relationship between the
authorized referent and actual selected target.
Das Expires 29 April 2027 [Page 75]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
CW-1.12.20 — Runtime Update Drift
A software update changes the actual semantics of an operation.
Where action-contract integrity is required, the protected system
verifies the current operation semantics and may require
reauthorization.
8.2.3.27. Original global source page 41
CW-1.12.21 — Tool Schema Manipulation
An untrusted tool provider changes the interpretation of an API
parameter.
The protected system may bind authority to a specific verified action
contract or semantic schema version.
CW-1.12.22 — Credential-Broker Confusion
A protected credential broker may be asked to release credentials for
a different resource or destination from the originally authorized
operation.
The broker verifies operation binding and scope before release.
CW-1.12.23 — Privacy Leakage Across Multiple Operations
An agent may perform several individually permitted disclosures that
collectively violate a protected privacy constraint.
A cumulative privacy module may track relevant protected exposure
state.
CW-1.12.24 — Device Authority Split-Brain
Two devices attempt to exercise the same exclusive unfinished
authority.
Protected ownership epochs or fencing prevent stale ownership from
authorizing duplicate effects.
CW-1.12.25 — Physical Target Drift
A physical object moves or is replaced between authorization and
actuation.
Das Expires 29 April 2027 [Page 76]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The protected system may require current target-identity evidence
before movement.
CW-1.12.26 — Denial-of-Service Against Validators
An attacker floods a required validation component with requests.
The protected architecture may employ bounded work, rate limits,
priority rules, reservation expiry, and fail-closed behavior for
mandatory predicates.
A validation timeout is not treated as successful authorization.
CW-1.12.27 — Cryptographic Verification Exhaustion
An attacker submits malformed or computationally expensive evidence
intended to exhaust the verifier.
The system may enforce input-size limits, bounded parsing, supported
algorithm restrictions, and resource-aware verification scheduling.
CW-1.12.28 — Malicious Evidence Source
A source authenticates false or manipulated data.
8.2.3.28. Original global source page 42
The system's guarantees depend upon source qualification, independent
observation, and the actual trust model.
Cryptographic authentication alone does not ensure factual
correctness.
CW-1.12.29 — Compromised Privileged Operating System
An attacker controls privileged software.
A software-only gate under the attacker's full control may be
bypassed.
Claims requiring resistance to such compromise must rely upon
appropriately independent protected components, hardware, or
destination-side enforcement.
CW-1.12.30 — Compromised Firmware or Hardware Controller
A malicious effectuation controller ignores required authorization.
Das Expires 29 April 2027 [Page 77]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The architecture may require independently protected hardware,
measured firmware, external control, redundancy, or equivalent
mechanisms under the intended threat model.
No single protection is assumed to resist compromise of its complete
trusted computing base.
CW-1.12.31 — Distributed Network Partition
Protected domains become disconnected.
The system may continue unrelated operations whose authority remains
locally sufficient.
Operations requiring unavailable distributed agreement or current
remote state are withheld.
CW-1.12.32 — Long-Lived Offline Authority
A disconnected device attempts to use previously provisioned
authority.
A protected implementation may enforce a bounded offline scope,
monotonic counters, expiry, or preallocated limited execution budget.
It cannot simultaneously claim unrestricted offline availability and
immediate global revocation without an appropriate supporting
mechanism.
CW-1.12.33 — Unknown Future Effectuation Interface
A software or hardware update introduces a new way to produce the
governed effect.
An optional coverage-attestation mechanism may detect the relevant
interface change and require new enforcement configuration before
protected authorization resumes.
CW-1.13 — FAILURE HANDLING AND RECOVERY
CW-1.13.1 — Failure Before Authorization
8.2.3.29. Original global source page 43
The Candidate Act remains non-effective.
CW-1.13.2 — Failure During Validation
Das Expires 29 April 2027 [Page 78]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A mandatory failed or unavailable verifier prevents corresponding
authorization.
CW-1.13.3 — Failure After Authority Preparation
Protected authority state is recovered or invalidated according to
the applicable consumption and freshness rules.
CW-1.13.4 — Failure After Sink Consumption
A consumed authority is not automatically restored merely because
effectuation acknowledgement is absent.
CW-1.13.5 — Partial External Effect
The system records the supported partial result and governs remaining
operations separately.
CW-1.13.6 — Unknown External Effect
The system preserves an unresolved attempt and prevents unsafe
dependent continuation or retry.
CW-1.13.7 — Revocation During Execution
Revocation may prevent future effects that have not crossed the
governed boundary.
A completed effect is not retroactively erased.
CW-1.13.8 — Recovery Authorization
A corrective effect may be represented as a new Candidate Act with
its own finality authority.
CW-1.13.9 — Validator Failure
Where CW-2 or another mandatory validator is required, failure does
not automatically authorize bypass.
CW-1.13.10 — Protected State Corruption
An operation is withheld where the mandatory protected state cannot
be validated or safely reconstructed.
CW-1.14 — CROSS-DOMAIN AND HETEROGENEOUS IMPLEMENTATIONS
Das Expires 29 April 2027 [Page 79]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
CW-1 may operate across mobile devices, desktop systems, enterprise
endpoints, cloud services, edge computers, embedded controllers,
vehicles, robots, secure communication infrastructure, and
distributed application systems.
An agent may request an operation in one domain while protected
authorization occurs in another.
8.2.3.30. Original global source page 44
The actual Finality Sink may reside in a third domain.
The receiving sink authenticates the applicable evidence and verifies
the actual operation independently.
CW-1.14.1 — Local Device Enforcement
A local protected controller may govern storage, network,
application, or hardware effects.
CW-1.14.2 — Cloud Enforcement
A protected cloud gateway may govern service API calls, database
commits, resource provisioning, and credential activation.
CW-1.14.3 — Cross-Provider Agents
Agents operating under different administrative providers may
exchange task requests without transferring unrestricted execution
authority.
Each consequential operation remains subject to applicable local
protected authorization.
CW-1.14.4 — Edge and Embedded Devices
Low-power devices may use compact protected state and hardware-
controlled release conditions.
CW-1.14.5 — Hardware Accelerators
A protected system may mediate effect-capable accelerator interfaces
where they can modify persistent resources, initiate direct memory
access, release network data, or produce another governed
consequence.
CW-1.14.6 — Physical Actuation
Das Expires 29 April 2027 [Page 80]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
An actuator controller may enforce scoped command authority and
relevant current physical-state predicates.
CW-1.14.7 — Delayed Connectivity
A system with intermittent connectivity may employ preauthorized
bounded operations, local protected state, and conservative
reconciliation after reconnection.
CW-1.15 — NON-LIMITING PRESENT-DAY INDUSTRIAL IMPLEMENTATION
CW-1.15.1 — Enterprise AI-Agent Gateway
A presently implementable reference system may comprise an AI agent,
a request interceptor, a protected authorization service, and a
controlled API gateway.
The agent proposes an operation.
The interceptor constructs the Candidate Act.
8.2.3.31. Original global source page 45
The protected authorization service evaluates the permitted operation
and current state.
The gateway independently verifies the actual outgoing request.
The gateway rejects a materially substituted destination, resource,
or operation.
This implementation may use existing cryptographic authentication,
protected service isolation, structured authorization, and
transaction-state techniques.
Its distinctive proposed feature must be identified in the actual
operation-bound protected enforcement relationship, not merely in use
of an ordinary API gateway.
CW-1.15.2 — Mobile or Desktop Assistant
A device assistant may request file access, message transmission,
application invocation, network communication, or device
configuration changes.
The device's protected execution system may require an operation-
specific finality authorization before the actual effect.
Das Expires 29 April 2027 [Page 81]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A protected dispatcher or controller may verify the actual pending
operation.
Where required, device security components may provide protected
state and cryptographic identity.
CW-1.15.3 — Multi-Agent Cloud Workflow
Several agents may generate resource-modification requests.
A conflict module may identify incompatible operations.
A protected state store may establish effect reservations.
Each actual cloud-operation sink verifies current authority and
applicable reservation state.
CW-1.15.4 — Autonomous Financial Workflow
An agent may propose a financial instruction.
The protected system binds the intended amount, recipient, account
scope, and designated dispatch controller to the Candidate Act.
The dispatch sink verifies the actual pending instruction.
Actual settlement remains distinct from local dispatch and may
require qualified outcome evidence.
CW-1.15.5 — Industrial Device Controller
An autonomous controller may generate a physical command.
A protected controller verifies the actual target and operating
envelope.
The actuator remains disabled until valid finality conditions pass.
8.2.3.32. Original global source page 46
CW-1.16 — PHOSITA FEASIBILITY AND REFERENCE PROTOTYPES
CW-1.16.1 — Minimum Software Reference Prototype
A practical minimum prototype may use two separately executing
processes.
Das Expires 29 April 2027 [Page 82]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The first process simulates an autonomous agent that generates
operation requests.
The second process implements a protected authorization and finality
gateway under a defined software trust model.
The agent does not possess direct access to the simulated
consequential resource.
The gateway constructs or validates Candidate Act descriptors,
verifies permitted operation scope, maintains protected consumption
state, and performs the final effect.
This prototype can demonstrate operation binding, single-use
authority, replay rejection, and fail-closed handling.
It cannot by itself establish resistance to compromise of the
operating-system kernel hosting both processes.
CW-1.16.2 — Protected Credential-Broker Prototype
A credential broker may retain a reusable service credential outside
the agent's access.
The agent submits a Candidate Act.
A protected authority validates the operation.
The controlled gateway performs the permitted request using the
credential.
The agent does not receive unrestricted credential material.
The prototype can test whether a substituted request changes the
actual effectuation parameters and whether the gateway rejects the
mismatch.
CW-1.16.3 — Protected Sink Prototype
A storage controller may maintain an initially uncommitted operation.
The PED generates an operation-bound authority.
The storage sink checks the actual record, version, and mutation
parameters before commit.
The test may substitute the pending object after authorization.
Das Expires 29 April 2027 [Page 83]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Correct operation requires rejection of a materially different
object.
CW-1.16.4 — Cross-Agent Conflict Prototype
Two agents may propose independently valid but incompatible
mutations.
8.2.3.33. Original global source page 47
A protected reservation service may determine the applicable
ordering.
Each sink verifies current reservation state.
The prototype may test stale reservations, concurrent attempts, and
recovery after a crash.
CW-1.16.5 — CW-2 Causal Receipt Prototype
A first protected sink performs a bounded real storage operation.
A qualified observer supplies actual commit evidence.
A cryptographically identified IEV accepts the evidence.
The accepted receipt becomes the necessary condition for a second
sink to perform a protected export.
The second sink rejects an attempted export without the correct
validator-authenticated receipt.
CW-1.16.6 — Hardware-Backed Prototype
A protected controller or security module may store finality
authority and consumption state.
The effectuation interface may be configured so that ordinary
application processes cannot bypass the required controller.
The implementation can test hardware-enforced withholding and
protected key or state access.
CW-1.16.7 — Feasibility Metrics
Das Expires 29 April 2027 [Page 84]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Testing may measure unauthorized effect acceptance, substitution
detection, replay rejection, validation latency, throughput,
protected-state overhead, crash recovery, concurrent state
correctness, and actual enforcement coverage.
Results should distinguish theoretical properties, software
simulations, implementation measurements, and independently validated
hardware behavior.
CW-1.17 — OPTIONAL PRESENT-DAY INVENTIVE TECHNICAL EXTENSIONS
The following optional concepts may be implemented using existing
classes of computing technology. Each is a proposed area of
technical differentiation, not a declaration that the underlying
constituent techniques are individually new.
CW-1.17.1 — Protected Effectuation-Path Coverage Commitment
A protected controller may maintain an authenticated description of
all known effect-capable routes relevant to a designated
consequential resource.
The system may detect when an application, driver, network interface,
or hardware configuration change creates an unmediated path.
8.2.3.34. Original global source page 48
Where the claimed protection depends upon complete mediation,
authority release may be withheld until the relevant path coverage is
revalidated.
A reference implementation may enumerate and test controlled software
and device interfaces under an explicitly defined coverage model.
The candidate inventive contribution would concern making coverage
state a mandatory predicate for operation-specific finality
authority.
CW-1.17.2 — Sink-Local Actual-Operation Equality
A Finality Sink may compare a protected authorized descriptor with
the operation actually presented to the controlled boundary.
The sink may verify all material effect parameters rather than merely
an upstream request digest.
A reference implementation may use controller-owned command buffers
or trusted dispatcher interfaces.
Das Expires 29 April 2027 [Page 85]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The candidate distinction concerns independent reconstruction and
mandatory release-time correspondence.
CW-1.17.3 — Protected Operation-Semantics Version Binding
An authorization may bind not only a function name but also the
semantics of the function's permitted effect.
A tool update or schema change may invalidate the earlier
correspondence.
The sink may require current verified operation-semantics
compatibility.
A prototype may vary parameter meaning or schema version and test
whether stale authority is rejected.
CW-1.17.4 — Protected Multi-Interface Resource Identity
Different applications may expose the same underlying resource
through different identifiers.
A protected resolver may establish authenticated equivalence among
resource identities.
The final authorization may bind the resolved target rather than only
a string supplied by the agent.
A feasibility prototype may map a document across storage, sharing,
and transmission interfaces.
CW-1.17.5 — Protected Delegation Attenuation
An original principal may authorize an agent to perform a narrow
task.
The agent may delegate part of the task to another service.
Each delegation may be constrained by the original permitted effect,
resource, destination, and authority state.
The final sink verifies the applicable delegation lineage.
8.2.3.35. Original global source page 49
CW-1.17.6 — Protected Credential-Release Finality
Das Expires 29 April 2027 [Page 86]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A credential broker may retain reusable credentials while the agent
receives only constrained operation references.
The broker may release or exercise privileged credentials only for a
verified actual operation.
This may support cloud API gateways, enterprise connectors, and
device-management infrastructure.
CW-1.17.7 — Cross-Agent Effect Reservation
Independently authorized agents may be required to satisfy protected
effect-conflict reservations before performing potentially
interfering operations.
This extension may employ the specialized techniques disclosed in
Embodiment 1.
CW-1.17.8 — Protected Semantic Target Continuity
A user may approve an operation involving an object visible on a
screen or in another interface.
The system may preserve the relationship between the approved
referent and actual target.
The sink refuses a substituted object unless the change is separately
authorized.
CW-1.17.9 — Protected Privacy Exposure Accumulation
A protected privacy module may maintain an authenticated cumulative
exposure state across multiple otherwise permitted operations.
The final sink may require that the new disclosure remain within
applicable limits.
CW-1.17.10 — Protected Causal Receipt Continuation
An operation may be divided into bounded real-effect phases.
A cryptographically identified IEV may accept a qualified predecessor
receipt.
The resulting accepted receipt becomes a necessary factor in the next
sink's effectuation authority.
This optional extension is detailed in CW-2.
Das Expires 29 April 2027 [Page 87]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
CW-1.17.11 — Protected Unknown-Outcome Fence
A protected controller may maintain an unresolved attempt state when
an external effect may have occurred.
The state may prevent unsafe retry, conflicting effectuation, or
premature continuation.
CW-1.17.12 — Protected Authority Ownership Across Devices
A protected ownership epoch may ensure that only one designated
device can exercise an exclusive unfinished authorization.
8.2.3.36. Original global source page 50
A superseded device's authority may be fenced at the actual sink.
CW-1.17.13 — Protected Validation Work Budget
The PED may allocate bounded computation and memory resources for
validating a Candidate Act.
Malformed or adversarially expensive proof requests may be rejected
without exhausting resources needed for protected operations.
This extension may be relevant to high-throughput security gateways
and embedded devices.
CW-1.17.14 — Protected Deadline-Aware Finality Scheduling
A protected scheduler may consider command deadlines, safety
constraints, and verification costs.
It may choose a permitted verification strategy while preserving
mandatory security predicates.
A deadline does not convert an inconclusive mandatory check into
permission.
CW-1.17.15 — Protected Sink Coverage After Software Updates
Following relevant application, operating-system, or firmware
updates, the system may verify that the same consequential interfaces
remain controlled.
Authority may be restricted until new effectuation-path coverage is
established.
Das Expires 29 April 2027 [Page 88]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
CW-1.17.16 — Protected Multi-Principal Authority
Some effects may require authority from more than one principal.
The protected system may combine distinct authenticated approvals
while preserving the specified operation scope and Finality Sink
verification.
CW-1.17.17 — Protected Receipt-Dependent Recovery
An adverse but verified outcome may support a narrowly scoped
recovery operation.
The protected receipt may serve as a causal prerequisite for
recovery, without granting unlimited corrective authority.
CW-1.17.18 — Protected Runtime Influence Attribution
A specialized module may examine the provenance or influence of
untrusted instructions, tool outputs, persistent memory, or external
content on a proposed operation.
Such evidence may become an additional sink-enforced restriction
where the implementation can support the required attribution.
The system does not assume that all neural inference can be perfectly
explained or traced.
CW-1.18 — ADVANCED FUTURE-ORIENTED OPTIONAL TECHNICAL CONCEPTS
8.2.3.37. Original global source page 51
The following concepts address plausible extensions of autonomous
computing and effectuation infrastructure. They are proposed
technical variations, not statements of present commercial adoption,
experimental success, or patentability.
CW-1.18.1 — Cross-Provider Autonomous-Agent Effectuation
Future agent ecosystems may involve multiple independently
administered agents cooperating on one task.
A protected authority may bind permitted effects across delegation
boundaries without giving every participant unrestricted access to
the original principal's credentials.
A final destination-side sink may verify the operation under a
locally enforceable scoped authorization.
Das Expires 29 April 2027 [Page 89]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A reference implementation can presently approximate this arrangement
using authenticated service-to-service messages and controlled tool
gateways.
CW-1.18.2 — Protocol-Neutral Tool Effectuation
An agent may invoke operations through different communication
protocols, RPC interfaces, local application functions, database
APIs, or direct hardware commands.
The protected system may transform different protocol-level requests
into a common effect-specific descriptor.
The final sink may verify the actual consequential parameters
independently of the original protocol syntax.
The technical difficulty lies in establishing correct, non-ambiguous
operation semantics across heterogeneous interfaces.
CW-1.18.3 — Dynamic Tool Discovery with Protected Contract Binding
An autonomous agent may discover new tools at runtime.
A protected registry may identify which tools produce governed
effects and which sink requirements apply.
Newly discovered tools may remain restricted until their effectuation
contracts and necessary enforcement interfaces are verified.
The agent cannot eliminate mandatory authorization by selecting a
previously unknown tool name.
CW-1.18.4 — Secure Compute-Accelerator Effectuation
Future accelerators may execute increasingly autonomous computation
and may initiate memory, storage, network, or device effects.
An optional protected controller may mediate effect-capable
accelerator outputs or command queues.
8.2.3.38. Original global source page 52
The technical focus is the consequential release boundary, not the
accelerator's internal mathematical computation.
CW-1.18.5 — Confidential Agent Execution
Das Expires 29 April 2027 [Page 90]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A confidential computing environment may protect selected agent state
or secrets.
CW-1 may additionally require that protected or attested computation
obtain finality authority before causing consequential effects
outside the protected environment.
Confidentiality of computation does not automatically establish
authorization of its external outputs.
CW-1.18.6 — Autonomous Edge-to-Cloud Migration
A task may move between local and cloud execution.
Protected authority may remain bound to the permitted operation even
if the computational location changes.
A protected migration state may fence the previous execution owner
where exclusivity is required.
CW-1.18.7 — Future Communication Networks
Autonomous network management may involve dynamic resource
allocation, radio configuration, network slicing, edge processing,
and distributed control.
A protected effectuation mechanism may govern the actual
configuration changes at relevant controllers.
The disclosure does not depend upon a particular future cellular
generation or communication standard.
CW-1.18.8 — Multi-Sensor Physical Autonomy
A future autonomous device may combine camera, depth, position,
audio, radio, and other sensor inputs.
A protected physical-scene module may verify the intended target
immediately before actuation.
The final controller may require current target correspondence and
authorized operating constraints.
CW-1.18.9 — Autonomous Vehicle and Fleet Coordination
Vehicles or machines may propose independently authorized movements
or shared resource operations.
Das Expires 29 April 2027 [Page 91]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A protected effect-conflict system may govern incompatible
commitments, while device-local sinks enforce actual commands.
Real-world safety requires appropriate physical control and sensing
systems beyond generic cryptographic authorization.
CW-1.18.10 — Extended-Reality and Spatial Computing
8.2.3.39. Original global source page 53
An assistant may act upon objects selected through spatial
interfaces.
A protected semantic correspondence system may bind the selected
virtual or physical referent to the actual effectuation target.
The system may prevent substitution caused by changes in spatial
registration, application state, or target identity.
CW-1.18.11 — Future Chiplet and Heterogeneous Hardware Controllers
A processor may include multiple isolated computing and control
units.
The PED, validators, and Finality Sinks may be distributed among the
units.
Authenticated internal interfaces may establish authority and state
continuity.
The same protected causal and effectuation relationships may be
implemented without a separate external security appliance.
CW-1.18.12 — Post-Quantum Cryptographic Migration
A protected system may permit migration to different cryptographic
authentication mechanisms when required by evolving threat models or
standards.
The protected authority and receipt formats may carry algorithm
identifiers and credential generations.
The correctness of the finality architecture is not tied to one
particular present-day signature algorithm.
Post-quantum cryptography itself is not claimed as a new invention
merely by being used for validator or sink authentication.
Das Expires 29 April 2027 [Page 92]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
CW-1.18.13 — Privacy-Preserving Distributed Verification
A remote verifier may establish selected authorization predicates
without receiving all underlying private data.
Suitable commitments, authenticated attestations, selective
disclosure, or privacy-preserving proofs may be used where
technically appropriate.
The final sink must still obtain sufficient evidence to verify the
required actual-operation conditions.
CW-1.18.14 — Autonomous Cross-Organization Transactions
Several organizations may operate independent protected controllers.
A single workflow may require effects in different administrative
domains.
Each domain may independently enforce its own finality requirements
while accepting narrowly scoped authenticated evidence from
cooperating domains.
The architecture must define trust, authority ownership, and failure
behavior across network partitions.
8.2.3.40. Original global source page 54
CW-1.18.15 — Self-Adjusting Verification Under Protected Constraints
A system may select among approved verification procedures based upon
operation risk, current technical state, computational resources, or
observation availability.
Mandatory safety or authorization predicates remain preserved.
A learned risk score does not itself override a failed protected
constraint.
CW-1.18.16 — Future Autonomous Hardware Peripherals
An effect-capable peripheral may perform operations with limited
involvement from the host processor.
The peripheral may incorporate a protected Finality Sink or accept
constrained authority from another protected controller.
Das Expires 29 April 2027 [Page 93]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The relevant consequential primitive remains subject to the
applicable operation-bound conditions.
CW-1.18.17 — Protected Real-Effect Evidence Across Long Delays
Some distributed systems may experience significant communication
delay or intermittent connectivity.
The architecture may use bounded local authority, authenticated
causal evidence, and protected replay-resistant state to govern
delayed continuation.
Where current global state is unavailable, the permitted autonomous
scope must be constrained by the defined safety and consistency
assumptions.
CW-1.18.18 — Future Machine-to-Machine Economic Operations
Autonomous devices may initiate resource purchases, usage
commitments, settlements, or access grants.
A protected sink may verify actual transaction parameters and
applicable authority.
Receipt-gated continuation may be applied where a later economic
effect requires confirmation of an earlier actual transaction state.
CW-1.18.19 — Future Distributed Actuation with Independent Witnessing
A physical operation may occur in one domain while another protected
system observes its result.
A cryptographically identified IEV may validate the observed effect
and establish the next operation's causal authority.
The receiving Finality Sink verifies the accepted receipt.
CW-1.18.20 — Future Operation-Level Enforcement as a Shared
Infrastructure Service
A computing platform may expose protected execution-finality controls
as a service usable by several applications or agent frameworks.
8.2.3.41. Original global source page 55
The service may manage Candidate Act descriptors, validator
identities, protected evidence, scoped capabilities, and sink
enforcement interfaces.
Das Expires 29 April 2027 [Page 94]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Applications may innovate independently in planning and computation
while the protected service continues to govern consequential
effects.
CW-1.19 — ADVANCED OPTIONAL INVENTIVE COMBINATIONS
CW-1.19.1 — Cross-Interface Actual-Effect Identity and Sink Coverage
One optional combination binds an effect-specific resource identity
to a protected inventory of relevant effectuation paths.
A new application interface or driver update may trigger revalidation
of whether the actual resource remains covered.
The Finality Sink may require a current coverage commitment before
releasing the operation.
The potentially distinctive interaction is between resource
equivalence, mandatory enforcement coverage, and operation-specific
authorization.
CW-1.19.2 — Causal Receipt and Cross-Agent Conflict-State Advancement
Another optional combination integrates Embodiment 1 and CW-2.
An earlier real effect produces a validator-accepted receipt.
The accepted receipt establishes the necessary continuation authority
for a successor phase while also controlling advancement or release
of protected reservations affecting other agents.
A successor sink verifies both the receipt-derived causal condition
and current conflict-state validity.
CW-1.19.3 — Semantic Referent and Credential-Release Binding
A user selects a document or resource through an application
interface.
A protected semantic module verifies the selected actual object.
A credential broker permits a specifically bound external operation
only for that object and destination.
The final sink independently checks the actual command.
Das Expires 29 April 2027 [Page 95]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The candidate contribution concerns the enforced relationship between
user-observed referent, operation-specific credential exercise, and
actual effectuation.
CW-1.19.4 — Dynamic Tool Contract and Protected Authority Revocation
A previously authorized tool undergoes a material schema or semantic
change.
A protected action-contract registry detects the change.
Existing authority bound to the earlier semantics is invalidated or
requires revalidation.
8.2.3.42. Original global source page 56
The sink prevents the changed operation from proceeding under stale
authorization.
CW-1.19.5 — Privacy Composition and Destination-Side Finality
Several agents attempt data disclosures through different
applications.
A protected privacy state tracks applicable cumulative effect
constraints.
Each destination-side transmission sink verifies the current relevant
privacy state and actual outgoing operation.
CW-1.19.6 — Device Migration and Causal Continuation
A workflow migrates from one device to another.
The prior device's authority is fenced.
The new device may require a qualified prior-effect receipt for a
pending causal continuation.
The successor sink verifies both exclusive ownership and receipt-
derived authority.
CW-1.19.7 — Resource-Constrained Security Validation with Fail-Closed
Deadlines
A protected scheduler may reserve verification resources for high-
priority consequential operations.
Das Expires 29 April 2027 [Page 96]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
It may reject or defer requests exceeding a protected verification
budget.
Where operation deadlines are relevant, the scheduler may use
prevalidated protected evidence or appropriate bounded checks.
It must not bypass mandatory authorization merely because the
remaining time is short.
CW-1.19.8 — Independent Physical Target and Actual Command
Reconstruction
A protected sensor module may identify a physical target.
The actuator sink independently obtains the actual command and
currently resolved target.
It verifies correspondence with the authorized target and current
protected operating envelope.
CW-1.19.9 — Protected Evidence Without Persistent Raw Data
A system may validate a consequential operation using protected
commitments to sensitive context.
It may retain the minimum evidence needed to demonstrate valid
authority and prevent replay.
The raw private source data need not be permanently stored when an
appropriate authenticated reference suffices.
CW-1.19.10 — Consequence-Aware Revocation Propagation
Revocation may affect several dependent pending operations.
8.2.3.43. Original global source page 57
A protected dependency structure may identify which unexecuted
Candidate Acts rely upon invalidated authority.
The relevant sinks prevent further effects without claiming
retroactive reversal of already completed external consequences.
CW-1.20 — PRESENT AND FUTURE FEASIBILITY OF ADVANCED VARIANTS
CW-1.20.1 — Present Feasibility
Das Expires 29 April 2027 [Page 97]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Many underlying engineering mechanisms are presently available as
established technology classes.
Examples include protected process isolation, cryptographic
authentication, transaction-state management, secure hardware
registers, monotonic counters, authenticated communication,
controlled API gateways, and device security modules.
Such building blocks can be combined to implement representative CW-1
embodiments.
Their availability does not establish that the specific proposed
combinations are already known or that they are automatically
inventive.
CW-1.20.2 — Advanced Feasibility
Future-oriented variants may require stronger integration with device
firmware, hardware command paths, distributed identity, trusted
effect observation, or new interface standards.
A PHOSITA may adapt the disclosed protected records, state
transitions, and sink verification rules to suitable hardware and
software interfaces.
The implementation must be evaluated against the actual trust model
and supported effectuation primitives.
CW-1.20.3 — Modular Development
A reference system may begin with one controlled storage or network
Finality Sink.
Additional sinks may be introduced as independently verified
protected interfaces.
A causal IEV may be added where multi-phase actual-effect evidence is
necessary.
Conflict, semantic, privacy, and physical-scene modules may be
integrated according to the target application.
CW-1.20.4 — Feasibility Boundaries
A design does not become non-bypassable merely because it uses a
secure processor.
An external effect is not proven merely because a receipt is signed.
Das Expires 29 April 2027 [Page 98]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A remote transaction is not made atomic merely because it is
represented in a protected local state machine.
8.2.3.44. Original global source page 58
A future-oriented embodiment should identify these limitations.
CW-1.20.5 — Performance Considerations
A system may use compact descriptors, cached verification material,
local protected state, batching, precomputation, or hardware
acceleration.
Such optimization must preserve mandatory act binding, current-state
checks, and consumption semantics.
CW-1.21 — INVENTIVE-STEP ANALYSIS
CW-1.21.1 — Established Building Blocks
Authentication, authorization, access-control systems, sandboxes,
transaction isolation, digital signatures, protected hardware,
fencing tokens, and audit records are established mechanisms.
CW-1 does not assert novelty merely from their individual use.
CW-1.21.2 — Candidate Distinguishing Combination
A potentially meaningful technical combination comprises:
A Candidate Act generated without inherent execution authority;
An enforceable Non-Effective State;
Protected verification of operation-specific predicates;
Formation of scoped non-bearer finality enablement;
Independent reconstruction of the actual pending operation at the
Finality Sink;
Verification of the authority against the actual operation and
current protected state;
And protected single-use or bounded consumption before effectuation.
Optional modules may add specific technical restrictions.
Das Expires 29 April 2027 [Page 99]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
CW-1.21.3 — Objective Technical Problem
The objective technical problem concerns ensuring that independently
generated computational operations cannot cause unauthorized
consequences through controlled effectuation paths, despite changes
to runtime context, intermediate software, credentials, resource
state, or operation parameters.
CW-1.21.4 — Technical Interaction
The Candidate Act identifies the proposed effect.
The Non-Effective State prevents premature release.
The PED establishes protected authority.
8.2.3.45. Original global source page 59
The finality capability binds the permitted effect.
The Finality Sink reconstructs the actual operation.
Sink-time verification enforces the protected binding.
Consumption prevents unauthorized repeated exercise.
These components perform distinct but coordinated functions.
CW-1.21.5 — Why a Mere Aggregation Is Insufficient
A system containing a sandbox, signature, gateway, and policy engine
is not necessarily inventive.
The potentially relevant contribution is the specific technical
dependence of actual effectuation upon appropriately protected,
operation-specific authority and actual boundary verification.
CW-1.21.6 — Optional Inventive-Step Contributions
An optional extension may contribute an additional technical
mechanism.
For example, effectuation-path coverage attestation may make
interface coverage a mandatory authorization predicate.
A causal IEV may make the accepted earlier real-effect receipt an
indispensable next-phase execution factor.
Das Expires 29 April 2027 [Page 100]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A conflict module may make protected reservations mandatory at
multiple actual sinks.
A semantic module may bind a user-observed referent to the actual
operation target.
Each candidate contribution should be assessed separately against the
relevant prior art.
CW-1.21.7 — Hindsight Considerations
Where prior-art references are combined, the analysis should identify
why a PHOSITA would have implemented the specific protected
architecture.
It is insufficient merely to locate each broad component in a
different reference and restate the claimed combination.
Nevertheless, established motivations to combine zero-trust
authorization, capability security, distributed coordination, and
effectuation gates must also be considered.
Inventive step depends upon the actual claim limitations and relevant
technical teachings.
CW-1.21.8 — Non-Guarantee of Patentability
A detailed specification does not automatically establish novelty,
inventive step, or claim validity.
The claimed combination must be supported by the original application
as filed and examined against relevant prior disclosures.
Broad functional language alone does not eliminate every possible
design-around.
8.2.3.46. Original global source page 60
CW-1.22 — INDUSTRIAL APPLICABILITY
CW-1 may be implemented in autonomous AI systems interacting with
enterprise resources, cloud infrastructure, device operating systems,
networks, financial services, protected data, industrial equipment,
robotic actuators, and distributed computing environments.
In enterprise systems, it may govern application-function dispatch,
document modification, and external communications.
Das Expires 29 April 2027 [Page 101]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
In cloud systems, it may govern protected resource creation,
deletion, modification, credential release, and network changes.
In mobile and desktop systems, it may govern assistant-mediated file
operations, message transmission, application controls, and sensitive
device resources.
In financial infrastructure, it may bind protected authority to
actual transaction parameters.
In telecommunications, it may govern network configuration, service
activation, and relevant control-plane effects.
In industrial automation, it may govern actuator commands and
protected device-state changes.
In distributed multi-agent systems, it may preserve scoped authority
and applicable operation constraints across service or provider
boundaries.
In future heterogeneous systems, it may provide a common
effectuation-control layer independent of the computational
architecture generating the request.
The industrial utility lies in controlling real technical
consequences through protected enforcement, not merely generating
recommendations concerning whether an operation appears desirable.
CW-1.23 — PROPOSED TECHNICAL VALIDATION PROGRAM
A comprehensive reference implementation may test the following
properties.
Test 1 — Operation Substitution. Authorize one resource and attempt
to effectuate another.
Test 2 — Destination Substitution. Change the destination after
protected authorization.
Test 3 — Capability Replay. Attempt repeated use of single-use
authority.
Test 4 — Agent-Level Bypass. Remove ordinary agent approval checks
while leaving protected sink enforcement active.
Test 5 — Alternate API. Attempt the same effect through a different
covered application interface.
Das Expires 29 April 2027 [Page 102]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Test 6 — Protected State Rollback. Restore previously consumed
authority through a stale snapshot.
Test 7 — Privileged Credential Theft. Determine whether the actual
sink still requires operation-specific finality authority.
8.2.3.47. Original global source page 61
Test 8 — Module Failure. Disable a mandatory specialized validator
and verify refusal.
Test 9 — Multi-Agent Conflict. Submit two independently authorized
incompatible effects.
Test 10 — Semantic Target Drift. Change the selected application
object between approval and effectuation.
Test 11 — Action Contract Change. Modify tool semantics after
authorization.
Test 12 — Unknown Outcome. Suppress acknowledgement after a possible
real external effect.
Test 13 — Causal IEV Receipt. Attempt a successor phase without the
required accepted real-effect receipt.
Test 14 — Validator Identity Forgery. Use the correct displayed
validator identifier with incorrect cryptographic credentials.
Test 15 — Cross-Domain Authorization. Present protected authority
from one domain to a different authorized sink.
Test 16 — Device Migration. Attempt stale execution after exclusive
authority moves to another device.
Test 17 — Privacy Accumulation. Perform several disclosures whose
combined effect violates a protected constraint.
Test 18 — Enforcement-Coverage Drift. Introduce a new effect-capable
interface and determine whether protected coverage is reevaluated.
Test 19 — Verification Exhaustion. Submit expensive malformed proof
inputs under constrained resources.
Test 20 — Hardware Release. Verify that an effect-capable hardware
controller refuses commands lacking the required authority.
Das Expires 29 April 2027 [Page 103]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The results may be used to establish actual functionality and
identify limitations.
The tests are proposed and are not represented as having already been
performed.
CW-1.24 — NON-LIMITING VARIATION AND SCOPE STATEMENT
CW-1 may be implemented using separate or integrated PED and Finality
Sink components.
It may use local or remote authority.
It may use cryptographic or protected-state capability
representations.
It may use one agent or many agents.
It may operate with or without an Interim Effectuation Validator
where the selected embodiment permits.
It may support one consequential effect or a series of causally
linked effects.
8.2.3.48. Original global source page 62
It may use hardware-backed security, protected software services, or
hybrid enforcement.
It may employ a protected credential broker, direct sink
authorization, or both.
It may use cryptographic receipts, internal protected state, or other
authenticated evidence mechanisms.
It may operate across application, operating-system, network,
storage, controller, device, or cloud boundaries.
It may incorporate future communication and computing architectures
without being restricted to a particular commercial implementation.
The selected mechanism must preserve the technical invariants
required by the applicable claimed embodiment.
CW-1.25 — TECHNICAL CHARACTERIZATION
Das Expires 29 April 2027 [Page 104]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Common Master Workflow CW-1 provides a modular architecture for
governing consequential operations initiated by autonomous
computational entities.
The requesting entity may compute, reason, plan, propose, delegate,
or prepare an operation.
Such computation does not automatically confer authority to produce
the external consequence.
The proposed operation may be represented as a Candidate Act and held
non-effective.
A Protected Enforcement Domain evaluates relevant authorization and
technical evidence.
Additional specialized modules may impose further protected
constraints.
Scoped finality authority is generated, derived, activated, or
committed under protected conditions.
The actual Finality Sink obtains or reconstructs the operation
pending at the consequence-producing boundary.
The sink independently verifies the operation against the required
authority and current protected state.
Where single-use authority is required, the appropriate protected
consumption procedure is performed.
Only then is the specified consequential operation permitted.
Optional mechanisms may provide protected cross-agent conflict
arbitration, semantic target correspondence, privacy composition,
delegated authority constraints, execution-path coverage
verification, device migration, runtime integrity, and other
technical protections.
Where receipt-gated causal continuation is selected, an earlier real
effect produces evidence accepted by a cryptographically identifiable
authorized IEV.
The resulting accepted receipt constitutes a necessary causal
enabling factor for the next phase, and the successor Finality Sink
verifies that condition before permitting the next consequential
effect.
Das Expires 29 April 2027 [Page 105]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.3. CW-2: Validator-Qualified Effect Receipt — Evidence Dependency
Context
Original source global pages 63-79. Preserved for technical
discoverability and traceability; consult the cited full Zenodo
document for complete source context. This part primarily
concentrates on evidence binding, scope, non-bearer authority and
protected journal consumption; other documents provide specialized
enforcement, device handoff and actual effect receipt details.
8.3.1. Architecture and Protected Trust Boundaries
[Predecessor effect]-->[Independent validator]
|
[Accepted effect receipt]
|
[Successor authority gate]
|
[Successor Finality Sink]
Figure 16: CW-2: Validator-Qualified Effect Receipt — Evidence
Dependency Context — Protected Architecture
8.3.2. Operational Decisions and Fail-Closed State Transitions
[Earlier effect attempted]
|
<Independently accepted receipt?>--NO-->[Block successor]
|YES
[Bind actual earlier consequence to successor]
|
<Current successor authority?>--NO-->[Block]
|YES
[Sink validate/consume/release successor]
Figure 17: CW-2: Validator-Qualified Effect Receipt — Evidence
Dependency Context — Decision Flowchart
8.3.3. Page-Indexed Original Technical Disclosure
8.3.3.1. Original global source page 63
The architecture may operate through one protected component or
across multiple physical and administrative domains.
Its technical security guarantees depend upon actual protected
authority, evidence, state, and effectuation boundaries rather than
the names assigned to individual modules.
Das Expires 29 April 2027 [Page 106]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The present and proposed future implementation variants may employ
different computational substrates while preserving the relevant
operation-specific protected enforcement relationship.
The principal candidate technical contribution of CW-1 lies in the
enforceable separation between computational generation and
consequential execution authority, implemented through operation-
specific protected evidence, non-effective holding, scoped finality
enablement, independent actual-operation reconstruction, sink-local
verification, and protected effectuation-state control.
Additional optional mechanisms may provide separately identifiable
technical contributions where their particular protected
relationships and resulting technical effects are supported and non-
obvious over the relevant prior art.
The disclosure is non-limiting and intended to provide sufficient
technical implementation guidance for a person having ordinary skill
in the relevant art.
END OF COMMON MASTER WORKFLOW CW-1.
COMMON WORKFLOW CW-2
PROTECTED CAUSAL-ORDERED REAL-EFFECT EXECUTION USING IDENTITY-
AUTHENTICATED INTERIM EFFECTUATION VALIDATORS, RECEIPT-CONSTITUTED
NEXT-PHASE AUTHORITY, NON-BYPASSABLE FINALITY-SINK ENFORCEMENT, AND
CRYPTOGRAPHIC OR NON-CRYPTOGRAPHIC CONTINUATION MECHANISMS
CW-2.0 — GENERAL DESCRIPTION AND TECHNICAL PURPOSE
The present Common Workflow CW-2 discloses systems, methods,
apparatus, protected computing components, hardware and software
mechanisms, authenticated communication protocols, protected
execution-state transitions, and non-limiting implementations for
enforcing causal ordering among consequential operations performed by
autonomous computing systems.
The workflow is particularly applicable to artificial-intelligence
agents, autonomous assistants, distributed computational agents,
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.
Das Expires 29 April 2027 [Page 107]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The principal technical arrangement comprises an earlier authorized
real-effectuation phase, an Interim Effectuation Validator having an
authenticated validator identity, an actual-effect receipt
8.3.3.2. Original global source page 64
accepted by that validator, and a subsequent Finality Sink whose
capability to release the next consequential effect depends upon the
accepted receipt.
The architecture establishes that a later consequential operation is
causally dependent upon an earlier permitted real effect and the
independent acceptance of evidence concerning that effect.
In a principal implementation, a first Candidate Act is authorized
through a Protected Enforcement Domain and released through a
designated Finality Sink.
The first operation produces an actual bounded consequence.
A qualified observation component obtains evidence concerning the
consequence.
An Interim Effectuation Validator, hereinafter IEV, evaluates the
evidence under the applicable protected authorization, expected-
effect predicate, actual-effect correspondence, phase ordering,
authority state, and current security conditions.
The IEV possesses a cryptographically verifiable identity recognized
by the applicable protected trust domain.
Upon successful validation, the IEV generates, authenticates,
commits, activates, or otherwise establishes a Validator-Accepted
Effect Receipt.
The validated receipt is conveyed to, retrieved by, or made available
as authoritative protected state to the designated next Finality
Sink.
The next Finality Sink verifies the validator identity, receipt
validity, causal predecessor, successor operation, current authority,
and applicable protected state.
Only after the required receipt-dependent conditions are established
may the next consequential phase become effective.
Das Expires 29 April 2027 [Page 108]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
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.
In one implementation, the accepted receipt directly constitutes an
operation-specific execution authorization.
In another implementation, the receipt activates or enables otherwise
unavailable scoped authority.
8.3.3.3. Original global source page 65
In another implementation, the receipt is a necessary input to
deriving, unsealing, releasing, or using protected execution
material.
In another implementation, receipt acceptance advances a hardware-
controlled or software-protected causal state machine.
These implementations share the same required technical relationship.
CW-2.0.2 — Causal Ordering Rather Than Ordinary Workflow Ordering
A conventional scheduler may execute Operation B after Operation A.
Such scheduling may establish chronological ordering.
However, Operation B may remain independently executable even if the
scheduler's ordering logic is bypassed.
CW-2 discloses a stronger implementation.
Das Expires 29 April 2027 [Page 109]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Operation B lacks the required effectuation condition until an
authenticated receipt derived from the actual outcome of Operation A
has been accepted by the authorized IEV.
Thus, the causal relationship is enforced by the protected execution
architecture rather than merely represented in workflow instructions.
A representative sequence is:
Authorized Candidate Act A | v First Finality Sink FS-A | v REAL
BOUNDED EFFECT A | v Actual-effect observation | v Protected Effect
Receipt R-A | v Identified authorized IEV | v Validator-accepted
receipt VR-A | v Receipt delivered to or verified by FS-B | v
Necessary execution condition B established |
8.3.3.4. Original global source page 66
v Finality Sink FS-B verifies actual operation B | v REAL
CONSEQUENTIAL EFFECT B The arrows represent required causal
dependencies in the selected receipt-gated implementation, not merely
a display of chronological software events.
CW-2.0.3 — Receipt as the Allowing Factor
For purposes of the principal inter-phase implementation, the
validator-accepted receipt serves as an execution-enabling factor.
The accepted receipt may be the final scoped authority object
required by the sink.
Alternatively, it may be the necessary authenticated prerequisite to
making a separately represented finality capability usable.
In either form, the protected system shall not permit the governed
successor consequence merely because the agent, scheduler, operating
system, or application asserts that the earlier operation succeeded.
The required receipt-dependent authority must actually exist and be
verifiable at the final enforcement boundary.
A raw unvalidated receipt does not possess the same status as a
validator-accepted receipt.
A receipt from an unauthorized validator does not satisfy the
required condition.
A receipt for an unrelated earlier effect cannot authorize an
unrelated successor operation.
Das Expires 29 April 2027 [Page 110]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
CW-2.0.4 — No Blockchain Requirement
The term receipt, as used herein, denotes an authenticated
operational evidence-and-authority object, signal, state, reference,
or commitment.
It does not require a blockchain.
It does not require a distributed ledger.
It does not require a consensus network, token economy, mining
mechanism, public transaction history, or third-party ledger
registration.
A cryptographic hash chain may optionally support integrity or
ordering, but is not an essential requirement.
A protected receipt may exist transiently within a secure hardware
controller and be consumed without ever being written to a permanent
external audit log.
The required inventive relationship concerns receipt-dependent causal
effectuation, not a particular logging or recordkeeping substrate.
CW-2.0.5 — Physical and Logical Flexibility
8.3.3.5. Original global source page 67
The IEV may be physically inserted into a command path.
It may be installed as a separate hardware module.
It may reside within an operating system.
It may be implemented as an isolated software service.
It may reside inside a Finality Sink.
It may be distributed across multiple machines.
It may be remotely hosted.
It may be implemented as a protected logical function within a common
processor containing both validation and effectuation components.
The physical arrangement does not alter the requirement that the
successor Finality Sink must authenticate and enforce the applicable
receipt-dependent condition.
Das Expires 29 April 2027 [Page 111]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
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.
CW-2 is an optional additional architecture applicable where a
consequential effect must depend upon independently validated earlier
evidence or where additional independent pre-effect verification is
required.
Once receipt-gated continuation is selected as a mandatory protection
for a particular phase, the receipt dependency is not optional for
that phase.
CW-2.0.7 — Optional Relationship to CW-3
CW-3 may additionally govern detected task-scope deviations, anomaly-
triggered reauthorization, and human or automated approval.
A valid human approval may establish or modify permitted task scope.
However, where CW-2 requires a validated prior real-effect receipt,
approval does not automatically replace that evidence.
The protected successor Finality Sink enforces both the necessary
receipt dependency and the applicable current authorization.
CW-2.1 — SPECIFIC TECHNICAL PROBLEMS
CW-2.1.1 — Execution Without Causal Proof
8.3.3.6. Original global source page 68
An autonomous agent may be authorized to perform a sequence of
operations.
A conventional workflow may permit later operations when earlier
software tasks report completion.
However, completion of software instructions does not necessarily
establish completion of the required real-world or external-system
consequence.
Das Expires 29 April 2027 [Page 112]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The architecture must distinguish successful computation from actual
permitted effectuation.
CW-2.1.2 — Independent Execution Authority Remaining Available
An application may check an earlier receipt before issuing a
subsequent command.
However, the application may retain an unrestricted credential or
alternative interface capable of executing the subsequent command
independently.
Such an arrangement provides a logical check but not necessarily an
enforced causal dependency.
CW-2 addresses this problem by requiring the final execution path to
depend upon accepted receipt-derived authority.
CW-2.1.3 — Validator Impersonation
A requesting agent or compromised intermediary may generate a message
containing the words "validation passed."
Without authenticated validator identity, the successor 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
Das Expires 29 April 2027 [Page 113]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A validator placed on one communication path may be avoided through
another network interface, application API, device bus, privileged
command path, or direct actuator connection.
Physical placement alone does not establish non-bypassability.
The controlled effectuation interface must require the receipt-
dependent condition irrespective of which covered upstream software
path requests the effect.
8.3.3.7. Original global source page 69
CW-2.1.6 — Monolithic-System Bypass
Where an IEV is implemented within the same component as the agent or
Finality Sink, an unprotected implementation may permit the agent to
modify validation flags or bypass the validation function.
An integrated implementation must therefore protect the relevant IEV
identity, validation state, and final release primitive against
unauthorized modification or invocation.
CW-2.1.7 — False Actual-Effect Evidence
A source may report that an external effect occurred even though it
observed only request dispatch or acceptance.
A cryptographically signed but unsupported statement does not
establish a stronger consequence.
The IEV must verify the evidence source's ability to support the
specified effect predicate.
CW-2.1.8 — Receipt Reuse
A valid receipt may be copied, delayed, replayed, or presented to a
different Finality Sink.
The system requires protected bindings to the corresponding
predecessor, successor, authority epoch, and consumption conditions.
CW-2.1.9 — Effectuation Uncertainty
An external operation may have occurred even if its acknowledgement
was lost.
A missing receipt is not proof of absence of the effect.
Das Expires 29 April 2027 [Page 114]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The architecture must preserve uncertainty and withhold dependent
effects whose required evidence is unavailable.
CW-2.1.10 — Technical Objective
The principal objective is to construct an enforceable causal
relationship among:
A prior authorized real effect;
Authenticated evidence of that effect;
An authorized cryptographically identifiable IEV;
IEV acceptance of the evidence;
A validator-accepted receipt;
The missing successor execution condition;
And the next Finality Sink's actual effectuation decision.
CW-2.2 — THREE OPERATIONAL MODES
8.3.3.8. Original global source page 70
CW-2.2.1 — Mode A: In-Line Pre-Effect Validation
In Mode A, the IEV is logically positioned after initial
authorization or preparation and before the actual consequential
release.
A representative sequence is:
Candidate Act | Protected Authorization | Prepared Actual Operation |
Identified IEV | Authenticated Pre-Effect Validation Result |
Finality Sink Verification | Actual Consequential Effect The
principal effect remains withheld while required validation is
pending.
The IEV independently obtains the actual operation through a
protected interface.
Its validation result is authenticated under its authorized identity.
The final sink verifies the result against the actual pending
command.
Das Expires 29 April 2027 [Page 115]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Mode A need not require an earlier real-effect receipt.
Its causal prerequisite is the independently accepted current-
operation validation.
CW-2.2.2 — Mode B: Inter-Phase Receipt-Constituted Causal
Continuation
Mode B is the principal receipt-gated implementation emphasized
herein.
A first bounded real effect occurs.
The effect produces qualified observation evidence.
The authorized IEV validates that evidence and establishes a
validator-authenticated receipt.
The next Finality Sink requires that receipt or authoritative
protected receipt state before releasing the next effect.
A representative sequence is:
FS[0] -> REAL EFFECT[0] | v EFFECT RECEIPT[0] | v
8.3.3.9. Original global source page 71
AUTHORIZED IEV[0] | v ACCEPTED RECEIPT[0] | v RECEIPT-DEPENDENT
ENABLEMENT[1] | v FS[1] -> REAL EFFECT[1] This is not merely an
after-the-fact inspection procedure.
Although the IEV observes evidence following the earlier bounded
effect, its acceptance occurs before and governs the later effect.
CW-2.2.3 — Mode C: Combined Validation
Mode C incorporates both in-line validation and inter-phase receipt-
gated continuation.
A successor operation may require:
First, a validated receipt arising from the predecessor real effect.
Second, a current in-line validation of the actual pending successor
command.
Third, final verification of both conditions at the successor
Finality Sink.
Das Expires 29 April 2027 [Page 116]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The same physical IEV or different authorized validator instances may
implement these functions.
CW-2.3 — BROAD DEFINITIONS
CW-2.3.1 — Controlled Phase
A Controlled Phase means an identified preparatory or consequential
portion of an operation or workflow governed by specified authority,
effectuation, evidence, or continuation conditions.
CW-2.3.2 — Phase-Specific Candidate Act
A Phase-Specific Candidate Act, or PSCA, means a Candidate Act
associated with a particular phase and its permitted effectuation
scope.
CW-2.3.3 — Phase Descriptor
A Phase Descriptor, or PD, means a machine-verifiable representation
of a phase's identity, operation, designated effectuation boundary,
required predecessor conditions, applicable authority, and permitted
outcomes.
CW-2.3.4 — Interim Effectuation Validator
An Interim Effectuation Validator means a protected validation
function or component configured to evaluate a required actual
pending operation, effect observation, or predecessor receipt and to
authenticate its resulting acceptance or rejection.
8.3.3.10. Original global source page 72
An IEV may be realized as hardware, firmware, software, a protected
process, a secure processor function, a remote service, a distributed
group, or an integrated controller subfunction.
The designation IEV is functional and does not require any particular
physical enclosure.
CW-2.3.5 — Validator Unique Identity
A Validator Unique Identity, or VUID, means an identity assigned to a
validator instance or authenticated validator role within an
applicable protected enrollment namespace.
The VUID is associated with cryptographic verification material.
Das Expires 29 April 2027 [Page 117]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A bare identifier without proof of authorized cryptographic control
does not constitute sufficient validator authentication.
CW-2.3.6 — Cryptographically Verifiable Validator Identity
A Cryptographically Verifiable Validator Identity, or CVVI, means an
enrolled validator identity that can be authenticated through a
digital signature, cryptographic message authentication, proof of key
possession, authenticated hardware identity, or an equivalent
cryptographic authentication mechanism.
The identity may be associated with a validator public key,
certificate, protected key reference, issuer identity, role,
authorization scope, security domain, and validity state.
CW-2.3.7 — Validator Authorization Profile
A Validator Authorization Profile specifies the effect classes,
predecessor evidence, successor operations, Finality Sinks, and
policy conditions for which an IEV is authorized to issue acceptable
results.
A cryptographically valid validator identity does not automatically
confer authority over all protected operations.
CW-2.3.8 — Validator Identity Registry
A Validator Identity Registry is an authenticated source of enrolled
validator identities, cryptographic verification credentials,
authorization profiles, key generations, and revocation status.
It may be stored locally or distributed across trusted domains.
CW-2.3.9 — Protected Effect Receipt
A Protected Effect Receipt, or PER, means authenticated evidence
concerning a particular actual effectuation attempt or observed
consequential outcome.
A PER may be a record, event, signal, protected state entry,
authenticated message, or equivalent machine-verifiable
representation.
It is not limited to a paper receipt, database entry, blockchain
transaction, or exported file.
CW-2.3.10 — Validator-Accepted Effect Receipt
Das Expires 29 April 2027 [Page 118]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.3.3.11. Original global source page 73
A Validator-Accepted Effect Receipt, or VAER, means a PER or
equivalent accepted receipt state that an authorized
cryptographically identifiable IEV has validated for the required
causal progression.
The VAER may include the original PER and the IEV's authenticated
acceptance.
Alternatively, the VAER may be represented as an authenticated
protected state transition, signed continuation object, or secured
receipt reference.
The VAER has an execution-enabling role under Mode B.
CW-2.3.11 — Causal Continuation Condition
A Causal Continuation Condition, or CCC, means the protected
condition required for the subsequent consequential phase, whose
validity depends upon the appropriate VAER.
A CCC may be a scoped cryptographic capability, protected key
release, threshold share, hardware state, transaction predicate,
controlled gateway authorization, protected register value, or
equivalent necessary execution prerequisite.
CW-2.3.12 — Receipt-Constituted Continuation Authority
Receipt-Constituted Continuation Authority means authority or
indispensable execution enablement created, activated, derived, or
made valid as a consequence of accepted earlier real-effect evidence.
A VAER may directly embody the scoped authority or constitute the
necessary factor for making separately represented authority usable.
CW-2.3.13 — Finality Sink
The Finality Sink retains its general meaning under CW-1 as the
controlled boundary that independently verifies applicable authority
and actual pending operation before permitting the governed
consequence.
For receipt-gated continuation, the successor Finality Sink
additionally verifies the mandatory validator-authenticated causal
receipt condition.
CW-2.3.14 — Receipt-to-Sink Delivery
Das Expires 29 April 2027 [Page 119]
Internet-Draft Execution-Finality Part 3: Evidence 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.
8.3.3.12. Original global source page 74
CW-2.3.16 — Validator Position
Validator Position means the logical, architectural, physical, or
operational location of the IEV relative to the originating agent,
effectuation controllers, protected evidence source, prior Finality
Sink, and successor Finality Sink.
Position may be defined by control dependency rather than physical
distance.
CW-2.3.17 — Protected Phase Lineage Commitment
A Protected Phase Lineage Commitment, or PPLC, means an authenticated
relationship among the predecessor operation, actual effect receipt,
accepting validator identity, permitted successor operation, and
protected current authority.
CW-2.3.18 — Protected Phase-Binding Commitment
A Protected Phase-Binding Commitment, or PPBC, binds a phase to its
Candidate Act, scope, authorized Finality Sink, and applicable
protected state.
CW-2.3.19 — Pre-Effect Validation Record
A Pre-Effect Validation Record, or PEVR, means authenticated evidence
that an authorized IEV accepted the actual pending operation under
required current predicates.
Das Expires 29 April 2027 [Page 120]
Internet-Draft Execution-Finality Part 3: Evidence 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
8.3.3.13. Original global source page 75
An Outcome Reconciliation Fence, or ORF, means protected state
withholding unsafe continuation, retry, or conflicting effectuation
while a prior outcome remains unresolved.
CW-2.3.25 — Recovery Candidate Act
A Recovery Candidate Act means a separately governed consequential
operation intended to correct, compensate for, or contain an earlier
effect or uncertain result.
CW-2.4 — VALIDATOR POSITION AND CONTROL ARCHITECTURE
CW-2.4.1 — Validator Between Two Finality Sinks
Das Expires 29 April 2027 [Page 121]
Internet-Draft Execution-Finality Part 3: Evidence 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 122]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.3.3.14. Original global source page 76
A separate logical effectuation function within the same protected
component verifies the receipt state before releasing the successor
command.
The internal validation identity remains bound to authenticated
protected credentials or cryptographically verifiable enrollment
state.
A separately networked validator device is unnecessary.
CW-2.4.4 — Validator Inside a Protected Processor
The IEV may run within a protected processor execution context.
The requesting agent may run in a different execution context.
The IEV controls its cryptographic authentication capability and
protected validation state.
The relevant Finality Sink verifies the resulting authenticated
receipt or authoritative protected state.
CW-2.4.5 — Validator Inside an Operating-System Security Component
An operating-system security service may implement the IEV.
The security service may mediate system calls, network transmissions,
application-function invocations, storage commits, or privileged
device commands.
Where the intended threat model includes a compromised operating-
system kernel, additional protection beyond an ordinary kernel-
controlled service may be necessary.
CW-2.4.6 — Remote Validator
The IEV may reside in a different computing domain.
A protected communication interface authenticates its validator
identity.
The remote IEV validates the required evidence and produces a
successor-bound VAER.
The successor sink authenticates the remote validator and verifies
the receipt.
Das Expires 29 April 2027 [Page 123]
Internet-Draft Execution-Finality Part 3: Evidence 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.
8.3.3.15. Original global source page 77
Another may verify the earlier external effect.
Another may validate current successor authority.
A protected receipt may require acceptance by a defined validator set
or threshold.
CW-2.4.9 — Single-Component Implementation
The complete causal sequence may be implemented within one protected
component.
The component may contain:
An initial authorization function;
A first effectuation interface;
An effect-observation function;
A logically identified IEV;
A protected accepted-receipt state;
A continuation-enable function;
And a successor effectuation interface.
Das Expires 29 April 2027 [Page 124]
Internet-Draft Execution-Finality Part 3: Evidence 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.
8.3.3.16. Original global source page 78
Global uniqueness across unrelated administrative systems is not
essential where issuer-qualified names and authenticated trust-domain
identifiers prevent ambiguity.
CW-2.5.3 — Cryptographic Key Binding
The validator identity may be bound to a public/private key pair,
authenticated secret, protected device identity, or another
cryptographic credential.
The protected validator controls the relevant signing or
authentication function.
Das Expires 29 April 2027 [Page 125]
Internet-Draft Execution-Finality Part 3: Evidence 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
8.3.3.17. Original global source page 79
The validator may prove control of its associated cryptographic
credential through a signature, authenticated challenge response, or
protected equivalent protocol.
A copied identifier is insufficient.
CW-2.5.8 — Identity Rotation
Das Expires 29 April 2027 [Page 126]
Internet-Draft Execution-Finality Part 3: Evidence 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 127]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.4. Embodiment 15: Cross-Domain Evidence Commitment, Independent
Validation and Non-Bearer Finality
Original source global pages 1309-1384. Preserved for technical
discoverability and traceability; consult the cited full Zenodo
document for complete source context. This part primarily
concentrates on evidence binding, scope, non-bearer authority and
protected journal consumption; other documents provide specialized
enforcement, device handoff and actual effect receipt details.
8.4.1. Architecture and Protected Trust Boundaries
[CA + original source authority]
/ \
[Collection PED] [Execution PED]
| |
[Evidence commitment A] [Evidence commitment B]
\ /
[Cross-commitment]
|
[Non-bearer finality]
|
[Finality Sink actual act/state]
Figure 18: Embodiment 15: Cross-Domain Evidence Commitment,
Independent Validation and Non-Bearer Finality — Protected
Architecture
8.4.2. Operational Decisions and Fail-Closed State Transitions
[CA held non-effective]
|
<Collection evidence valid?>--NO-->[Withhold]
|YES
<Independent execution evidence valid?>--NO-->[Withhold]
|YES
<Cross-commit and source authority current?>--NO-->[Withhold]
|YES
[Form scoped non-bearer enablement]
|
<Sink reconstruct actual act and match?>--NO-->[Refuse]
|YES
[Atomic consume / effect]
Figure 19: Embodiment 15: Cross-Domain Evidence Commitment,
Independent Validation and Non-Bearer Finality — Decision
Flowchart
Das Expires 29 April 2027 [Page 128]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.4.3. Page-Indexed Original Technical Disclosure
8.4.3.1. Original global source page 1309
specific non-bearer authority, and sink-local protected consumption
conditions remain valid.
Novelty, inventive step, unity, and permissible claim breadth remain
subject to examination against the closest relevant prior art and the
enabling technical disclosure actually filed.
END OF EMBODIMENT 14 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 15
PROTECTED CROSS-DOMAIN EVIDENCE COMMITMENT AND NON-BEARER FINALITY
ENABLEMENT WITH INDEPENDENT VALIDATION, REPLAY RESISTANCE, AND SINK-
LOCAL MONOTONIC CONSUMPTION
15.0 — COMPLETE TECHNICAL TITLE
Systems and Methods for Protected Consequential Execution Using
Authenticated Collection-Time Evidence, Independently Protected
Execution-Time Validation, Cross-Committed Operation-Specific
Evidence, Scoped Non-Bearer Finality Enablement, Actual Pending
Operation Reconstruction, and Sink-Local Monotonic Authority
Consumption Across Autonomous Computing Domains
15.0.1 — General Technical Description
The present Embodiment 15 discloses systems, methods, apparatus,
protected computing components, authenticated evidence protocols,
machine-verifiable authorization structures, protected state
transitions, cryptographic and non-cryptographic enforcement
mechanisms, and non-limiting implementations for governing
consequential operations proposed by autonomous computational
entities.
The requesting entities may comprise artificial-intelligence agents,
autonomous assistants, application services, distributed software
processes, cloud workloads, operating-system components, database
clients, network controllers, embedded systems, hardware
accelerators, transaction processors, robotic controllers, or other
computational entities capable of initiating an externally observable
or persistent consequence.
Das Expires 29 April 2027 [Page 129]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A computational entity may generate an apparently valid operation,
obtain an approval, collect supporting evidence, or produce an
authenticated execution record.
However, the existence of such evidence does not automatically
establish authority to produce the actual effect.
An approval may refer to an earlier version of an operation.
A signed evidence record may be authentic but stale.
A valid validation result may relate to one resource while the actual
outgoing operation targets another.
8.4.3.2. Original global source page 1310
A protected controller may approve a specific operation while an
untrusted computational entity attempts to reuse the resulting
receipt or authorization reference for additional effects.
Several independently valid evidence records may concern different
Candidate Acts or different resource states.
The present embodiment therefore distinguishes:
Collection of evidence;
Validation of evidence;
Validation of the current proposed effect;
Commitment of the relationships among those evidentiary events;
Establishment of scoped finality authority;
Presentation of an actual operation;
And controlled consumption of that authority at the consequential
boundary.
In a principal implementation, a first protected collection domain
establishes authenticated evidence concerning an identified Candidate
Act and its relevant source, resource, context, and authorization
conditions.
A second independently protected validation domain evaluates the
required evidence and current operation-specific conditions.
Das Expires 29 April 2027 [Page 130]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The protected system establishes a cross-commitment binding the
relevant collection-time evidence, independent validation result,
Candidate Act, current authority, and designated effectuation
boundary.
A protected authority controller may establish non-bearer finality
enablement specific to the validated effect.
The requesting agent cannot validly exercise the enablement merely by
possessing a copied receipt, capability reference, or signed
approval.
At the Finality Sink, the actual pending operation is reconstructed
or obtained from an appropriately trusted effectuation interface.
The sink verifies the cross-committed evidence, current source
authority, protected enablement, actual operation correspondence, and
sink-local consumption state.
The governed consequential operation is permitted only after the
required predicates have been satisfied.
15.0.2 — Fundamental Technical Principle
8.4.3.3. Original global source page 1311
Evidence that an operation is permitted is not itself the protected
authority that makes the operation effective.
The following states are distinct:
A proposed operation exists.
Evidence concerning the operation has been collected.
The evidence has been authenticated.
The operation has passed independent validation.
The relevant evidence has been cross-committed.
Scoped finality authority has been established.
The actual pending operation matches that authority.
The designated Finality Sink has validly consumed the authority.
And the consequential operation has been released.
Das Expires 29 April 2027 [Page 131]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
No earlier state automatically implies every later state.
In particular, a signed receipt does not independently become a
reusable execution credential.
15.0.3 — Principal Proposed Inventive Concept
A candidate inventive combination comprises:
An authenticated Candidate Act maintained in Non-Effective State;
A first protected evidence-collection instance;
A collection-time evidence commitment;
A second independently protected execution-time validation instance;
A validation result cryptographically or otherwise securely bound to
the collection evidence;
A cross-commitment associating the collection and validation states
with the specified Candidate Act;
A protected finality authority controller;
A scoped non-bearer operation-specific enablement;
A designated Finality Sink capable of reconstructing the actual
pending effect;
8.4.3.4. Original global source page 1312
And protected monotonic consumption state preventing unauthorized
reuse, stale exercise, or concurrent duplication of finality
authority.
The technical relationship is not satisfied merely because one
component signs an approval message.
The protected implementation must enforce the applicable evidence-to-
authority dependency before the effect can occur.
15.0.4 — Distinct Protected Validation Stages
In a principal configuration, evidence collection and execution-time
validation occur within independently protected validation instances
or domains.
Das Expires 29 April 2027 [Page 132]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The first stage establishes qualified evidence concerning the
proposed operation and relevant collection-time conditions.
The second stage independently evaluates the necessary evidence,
current operation state, and applicable authority predicates.
The second stage does not accept an untrusted agent's assertion that
the first stage succeeded.
It verifies the required authenticated collection evidence and
establishes its own protected validation result.
The independence guarantee depends upon the selected isolation,
authorization, identity, and failure-domain assumptions.
Separate processes with no meaningful protection boundary do not
automatically qualify as independently protected instances.
15.0.5 — Evidence-to-Authority Boundary
An evidence commitment may be stored, forwarded, inspected, or
audited.
It may prove selected properties of an earlier validation event.
However, the commitment does not necessarily grant the holder the
power to exercise the corresponding consequential effect.
In a principal implementation, the protected finality controller
establishes a separate operation-specific enablement only after the
necessary cross-committed validation predicates pass.
The actual sink must independently verify that enablement and the
real pending operation.
15.0.6 — Non-Bearer Authority
8.4.3.5. Original global source page 1313
The finality enablement may be implemented as protected sink-local
state, an authenticated operation reference, a signed capability
additionally requiring current protected context, a protected key-
release condition, or another suitable mechanism.
The enablement is non-bearer where mere possession of the
representation is insufficient.
Das Expires 29 April 2027 [Page 133]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Valid exercise additionally depends upon the designated sink, actual
operation, current protected authority, relevant resource state, and
consumption conditions.
No reusable complete authority object need be exposed to the
requester.
15.0.7 — Scope of Protected Effects
The relevant consequential operation may comprise a database
mutation, file commit, network transmission, credential activation,
payment instruction, information disclosure, storage export, device
command, accelerator-originated resource operation, robotic
actuation, or another covered effect.
The particular operation determines which attributes must be
reconstructed and verified at the actual sink.
15.0.8 — Relationship to Common Workflows
The embodiment may employ Candidate Acts, Non-Effective State,
Protected Enforcement Domains, protected evidence, scoped finality
enablement, and independent Finality Sinks from CW-1.
Where a later consequential phase depends upon a verified earlier
real effect, CW-2 may require an accepted identity-authenticated
Interim Effectuation Validator receipt as a constitutive prerequisite
for successor authority.
Such a receipt must not be conflated with the present embodiment's
collection-time evidence commitment unless the applicable protocol
expressly establishes the relevant qualification and causal
dependency.
Optional reauthorization under CW-3 may apply to changed or expanded
operation scope.
15.0.9 — Relationship to Earlier Embodiments
Embodiment 1 may govern incompatible concurrent Candidate Acts.
Embodiment 2 may govern causal continuation following a verified
earlier consequence.
Embodiments 3 and 4 may support actual target correspondence and
qualified external-effect observation.
Embodiment 5 may constrain shared resource allocations.
Das Expires 29 April 2027 [Page 134]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Embodiment 6 may verify current operation semantics.
8.4.3.6. Original global source page 1314
Embodiment 7 may preserve authority through delegation and
distributed computational influence.
Embodiment 8 may govern cumulative privacy exposure.
Embodiment 9 may enforce current device ownership.
Embodiment 10 may verify activated computational-generation validity.
Embodiment 11 may provide version-bound reservations and current
conflict validation.
Embodiment 12 may govern recovery and unresolved outcomes.
Embodiment 13 may provide qualified collective approval where
required.
Embodiment 14 may establish current mandatory effectuation-path
coverage.
Miscellaneous Embodiment M-1 may supply optional evidence, resource,
and coverage modules.
The present Embodiment 15 specifically develops the protected
transition from collected evidence to independently validated, cross-
committed, operation-specific non-bearer authority consumed at the
actual Finality Sink.
The earlier embodiments remain unchanged.
15.1 — TECHNICAL FIELD
The present embodiment relates to protected autonomous execution,
cross-domain validation, authenticated evidence collection,
execution-time authorization, protected capability systems,
cryptographic commitments, transaction security, distributed
enforcement, replay-resistant authority, trusted computing, secure
resource controllers, and independent execution-finality enforcement.
More specifically, it concerns separating evidentiary assertions from
effectuation authority and preventing a proposed consequential
operation from becoming effective without independent validation,
protected evidence continuity, and current operation-specific
authority consumption.
Das Expires 29 April 2027 [Page 135]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15.2 — SPECIFIC TECHNICAL PROBLEMS
15.2.1 — Signed Approval Treated as Executable Authority
An agent may present a valid signed approval as though it were an
unrestricted permission to perform a subsequent operation.
8.4.3.7. Original global source page 1315
15.2.2 — Collection-Time Evidence Becomes Stale
A resource, policy, or execution context may change between evidence
collection and effectuation.
15.2.3 — Same Evidence Used for Different Operations
A valid evidence record for one Candidate Act may be presented for
another.
15.2.4 — Validation Without Independent Observation
A purported validator may simply accept a requesting agent's self-
reported operation description.
15.2.5 — Evidence Record Substitution
An attacker may combine a valid collection record with an unrelated
validation result.
15.2.6 — Receipt Laundering
An agent may transform or wrap a validation receipt so that another
service treats it as executable permission.
15.2.7 — Bearer Capability Theft
A copied authority artifact may be exercised by an unauthorized
entity.
15.2.8 — Cross-Domain Authority Confusion
An approval from one administrative or trust domain may be misapplied
in another.
15.2.9 — Actual Operation Mismatch
The final operation may differ from the operation originally
validated.
Das Expires 29 April 2027 [Page 136]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15.2.10 — Stale Resource Identity
The authorized logical resource may resolve to another actual object.
15.2.11 — Replay After Consumption
A previously used authorization may be presented again.
15.2.12 — Concurrent Double Exercise
Several agents or sinks may attempt to exercise the same authority
simultaneously.
15.2.13 — Snapshot Restoration
An execution environment may restore an earlier copy of the authority
state.
8.4.3.8. Original global source page 1316
15.2.14 — Revocation Race
The original authorization may be revoked after validation but before
effectuation.
15.2.15 — Policy Epoch Mismatch
Collection-time and execution-time validation may refer to
incompatible policies.
15.2.16 — Cross-Commitment Ambiguity
Different domains may interpret the same serialized operation or
evidence differently.
15.2.17 — Compromised Evidence Collector
An attacker may manipulate the component responsible for recording
collection-time conditions.
15.2.18 — Compromised Validator
An attacker may fabricate an apparently successful execution-time
validation result.
15.2.19 — Insufficient Domain Independence
Das Expires 29 April 2027 [Page 137]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Two nominal validation domains may depend upon one unprotected common
authority.
15.2.20 — Finality Sink Bypass
An effect-capable resource path may permit execution without required
validation.
15.2.21 — Crash During Authority Consumption
The system may lose confirmation of whether a capability was
consumed.
15.2.22 — External Effect With Lost Acknowledgement
The effect may have occurred even though the sender did not receive a
response.
15.2.23 — Distributed Consumption Disagreement
Several resource controllers may have inconsistent authority-
consumption state.
15.2.24 — Insufficient Verification Resources
An attacker may exhaust the validation system through oversized or
repeatedly submitted evidence.
15.2.25 — Technical Objective
A candidate objective technical problem is:
8.4.3.9. Original global source page 1317
How to ensure that authenticated evidence collected and validated
across distinct protected computing domains cannot be misused as
reusable consequential authority, by binding independent collection-
time and execution-time validation to one specified Candidate Act and
requiring separately established non-bearer enablement to be verified
and monotonically consumed at the actual effectuation boundary.
15.3 — ESTABLISHED TECHNIQUES AND THEIR LIMITATIONS
15.3.1 — Cryptographic Signatures
Digital signatures may authenticate the origin and integrity of
messages.
Das Expires 29 April 2027 [Page 138]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
These techniques are established.
A signature does not automatically establish that the signed
statement remains current or grants permission to produce a
particular real-world effect.
15.3.2 — Remote Attestation
Remote attestation may provide evidence concerning an execution
environment and support later authorization decisions.
Such techniques are established.
The present embodiment does not claim original invention of
attestation, evidence appraisal, or relying-party authorization.
15.3.3 — Proof-of-Possession Tokens
Sender-constrained tokens may reduce unauthorized use of stolen
bearer tokens.
Such techniques are established.
The proposed architecture may additionally require that no reusable
complete consequential authority is available to the requester and
that each actual effect consumes protected operation-specific state.
15.3.4 — Mutual Authentication
Protected domains may authenticate one another through suitable
communication protocols.
This is established.
Mutual authentication does not automatically prove that their
evidence concerns the same Candidate Act.
15.3.5 — Transactional State
8.4.3.10. Original global source page 1318
Databases may provide atomic compare-and-update operations and
durable state transitions.
These techniques are established.
The candidate relationship here concerns tying such state to cross-
domain evidence and actual consequential effectuation.
Das Expires 29 April 2027 [Page 139]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15.3.6 — Nonces and Replay Protection
Cryptographic protocols routinely employ nonces, sequence values, and
timestamps.
Such mechanisms are established.
The present embodiment may combine them with authoritative sink-local
consumption state and operation-specific bindings.
15.3.7 — Capability Security
Capability-based authority and restricted resource access are
established concepts.
The present embodiment does not claim that scoped or non-transferable
authorization was first introduced here.
15.3.8 — Secure Multi-Stage Validation
Systems may employ multiple protected checks.
Multiple stages alone do not establish the particular cross-committed
evidence-to-finality relation proposed here.
15.3.9 — Signed Receipts
An authenticated receipt may record a validation or transaction
event.
Such receipts are established.
The stronger architecture must prevent the receipt from becoming an
unrestricted substitute for independently consumed finality
authority.
15.3.10 — Candidate Technical Distinction
The relevant candidate distinction is the mandatory protected
sequence and binding among collection-time evidence, independently
validated execution-time conditions, cross-committed Candidate Act
state, operation-specific non-bearer enablement, actual-effect
reconstruction, and monotonic consumption.
15.4 — PRINCIPAL SYSTEM ARCHITECTURE
Das Expires 29 April 2027 [Page 140]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.4.3.11. Original global source page 1319
A representative implementation comprises:
A Candidate Act Constructor;
A Protected Source Authority Controller;
A First Protected Evidence-Collection Instance;
An Authenticated Collection-Evidence Store;
A Second Independently Protected Validation Instance;
A Cross-Commitment Controller;
A Protected Finality Authority Controller;
A Current Policy and Revocation Controller;
A Protected Operation Descriptor Resolver;
A Designated Finality Sink;
And a Sink-Local Monotonic Consumption Controller.
Optional components may include a resource-version controller,
protected credential broker, independent effect observer, hardware
security module, protected clock or generation source, secure
transaction journal, distributed consumption coordinator, and
protected recovery controller.
15.4.1 — Candidate Act Constructor
Identifies the consequential operation to be governed.
15.4.2 — First Protected Collection Instance
Establishes qualified evidence about the Candidate Act, relevant
source authority, and collection-time context.
15.4.3 — Second Protected Validation Instance
Independently evaluates the required collection evidence and current
operation-specific conditions.
15.4.4 — Cross-Commitment Controller
Das Expires 29 April 2027 [Page 141]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Establishes an authenticated relationship among collection evidence,
validation evidence, Candidate Act, policy, and sink.
15.4.5 — Finality Authority Controller
8.4.3.12. Original global source page 1320
Creates or activates bounded operation-specific enablement.
15.4.6 — Finality Sink
Obtains the actual pending operation and verifies current finality
conditions.
15.4.7 — Consumption Controller
Maintains protected single-use, bounded-use, or other applicable
monotonic authority state.
15.5 — BROAD TECHNICAL DEFINITIONS
15.5.1 — Evidence-Governed Candidate Act
An Evidence-Governed Candidate Act, or EGCA, means a Candidate Act
whose consequential effect requires one or more specified protected
evidence and authority predicates.
15.5.2 — Protected Collection Instance
A Protected Collection Instance, or PCI-15, means an authorized
computing component responsible for establishing qualified
collection-time evidence.
15.5.3 — Protected Validation Instance
A Protected Validation Instance, or PVI-15, means an independently
protected component authorized to evaluate collection evidence and
current execution-time predicates.
15.5.4 — Collection-Time Evidence
Collection-Time Evidence, or CTE-15, means qualified information
concerning a Candidate Act, its originating authority, relevant
resources, or other properties established during a defined
collection phase.
15.5.5 — Collection Evidence Commitment
Das Expires 29 April 2027 [Page 142]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A Collection Evidence Commitment, or CEC-15, means an authenticated
representation binding the specified Candidate Act and relevant
collection-time evidence.
15.5.6 — Independent Validation Evidence
Independent Validation Evidence, or IVE-15, means authenticated
evidence representing validation performed by the selected
independent protected instance.
15.5.7 — Execution-Time Validation Result
8.4.3.13. Original global source page 1321
An Execution-Time Validation Result, or ETVR, means a protected
decision concerning required conditions evaluated for the proposed
operation during a defined execution-validation stage.
15.5.8 — Cross-Evidence Commitment
A Cross-Evidence Commitment, or XEC-15, means a protected commitment
linking the collection-time evidence, independent validation result,
Candidate Act, and relevant authority context.
15.5.9 — Evidence Correspondence Predicate
An Evidence Correspondence Predicate, or ECP-15, means a machine-
verifiable condition determining whether separate evidence records
refer to the same authorized consequential operation and applicable
state.
15.5.10 — Protected Validation Epoch
A Protected Validation Epoch, or PVE-15, means an authoritative
generation associated with the relevant validation state.
15.5.11 — Protected Authority Epoch
A Protected Authority Epoch, or PAE-15, means the generation
identifying currently applicable originating or delegated source
authority.
15.5.12 — Finality Enablement Record
A Finality Enablement Record, or FER-15, means protected state
representing eligibility of a particular Candidate Act for
consequential release.
Das Expires 29 April 2027 [Page 143]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15.5.13 — Non-Bearer Finality Enablement
Non-Bearer Finality Enablement, or NBFE, means operation-specific
effectuation enablement whose valid exercise requires protected state
and contextual verification beyond possession of a transportable
authority artifact.
15.5.14 — Finality Enablement Reference
A Finality Enablement Reference, or FEREF, means an identifier
referencing protected finality state without independently providing
unrestricted effectuation authority.
15.5.15 — Finality Consumption Generation
A Finality Consumption Generation, or FCG-15, means a monotonic
protected generation associated with a finality authority's exercise
or resolution.
15.5.16 — Sink-Local Consumption State
8.4.3.14. Original global source page 1322
Sink-Local Consumption State, or SLCS-15, means protected
authoritative state maintained or enforced by the Finality Sink
concerning the remaining valid exercise of operation-specific
enablement.
15.5.17 — Actual Pending Operation
An Actual Pending Operation, or APO-15, means the consequential
operation actually presented for release at the controlled
effectuation boundary.
15.5.18 — Actual Operation Descriptor
An Actual Operation Descriptor, or AOD-15, means a machine-verifiable
representation of the actual pending operation reconstructed or
obtained by the Finality Sink.
15.5.19 — Protected Finality Equivalence
Protected Finality Equivalence means a defined verified relationship
between the authorized Candidate Act and the actual operation to be
effectuated.
15.5.20 — Protected Evidence Registry
Das Expires 29 April 2027 [Page 144]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A Protected Evidence Registry, or PER-15, means an authenticated
storage or reference mechanism maintaining required evidence and
associated state.
15.5.21 — Evidence Freshness Constraint
An Evidence Freshness Constraint means a condition requiring evidence
to remain applicable under current nonce, epoch, time, policy, or
resource state.
15.5.22 — Cross-Domain Independence Evidence
Cross-Domain Independence Evidence means qualified information
establishing that specified evidence-collection or validation
protections are not solely dependent upon one untrusted computational
instance.
15.5.23 — Protected Finality Reservation
A Protected Finality Reservation, or PFR-15, means authoritative
provisional state associating one validated Candidate Act with
bounded effectuation eligibility.
15.5.24 — Consumed Finality Authority
Consumed Finality Authority means authority whose permitted exercise
has been committed or exhausted under the applicable protected
consumption rule.
15.5.25 — Protected Replay Fence
A Protected Replay Fence means an authoritative condition preventing
additional invalid exercises of an earlier enablement.
8.4.3.15. Original global source page 1323
15.5.26 — Cross-Sink Consumption Domain
A Cross-Sink Consumption Domain means the protected state
coordination scope required to prevent unauthorized duplicate
authority use across participating Finality Sinks.
15.5.27 — Protected Dispatch State
Protected Dispatch State means authoritative information concerning
whether the governed operation has been prepared, committed for
dispatch, attempted, or otherwise released.
Das Expires 29 April 2027 [Page 145]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15.5.28 — Uncertain External Outcome
Uncertain External Outcome means a condition in which the actual
result of an operation cannot be established from the available
qualified evidence.
15.5.29 — Protected Evidence Rebinding
Protected Evidence Rebinding means generation of new current evidence
and authority relationships following a valid change in the Candidate
Act, relevant resource, or policy.
15.5.30 — Evidence-to-Authority Separation
Evidence-to-Authority Separation means the architectural requirement
that an authenticated evidentiary artifact does not independently
confer unrestricted consequential authority.
15.5.31 — Protected Collection Context
Protected Collection Context means the relevant source, resource,
policy, and operation conditions qualified during evidence
collection.
15.5.32 — Protected Execution Context
Protected Execution Context means the current relevant operation,
authority, resource, and environment conditions qualified during
execution-time validation.
15.5.33 — Cross-Committed Validation State
Cross-Committed Validation State means protected state reflecting
accepted correspondence among the required collection and execution
validation evidence.
15.5.34 — Protected Capability Inertness
Protected Capability Inertness means that a capability or reference
alone cannot cause the governed consequence without the required
protected finality conditions.
15.5.35 — Qualified Finality Consumption Evidence
Qualified Finality Consumption Evidence means authenticated
information concerning consumption of protected finality authority,
without automatically claiming that every downstream external outcome
completed.
Das Expires 29 April 2027 [Page 146]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.4.3.16. Original global source page 1324
15.6 — COLLECTION-TIME EVIDENCE
The first protected instance may establish evidence concerning:
The identified Candidate Act;
Its source authority;
The intended resource;
The permitted effect envelope;
The original execution context;
The relevant data or instruction provenance;
The protected policy;
The collection instance identity;
And the applicable collection generation.
A representative collection evidence record may comprise:
COLLECTION_TIME_EVIDENCE = { evidence_version,
candidate_act_identifier, candidate_act_digest,
originating_authority_reference, authorized_resource_scope,
intended_effect_descriptor, collection_context_commitment,
resource_identity_commitment, applicable_policy_commitment,
collection_domain_identity, collection_domain_generation,
evidence_nonce, evidence_collection_epoch,
protected_evidence_authentication }
The collection record represents what the collector is qualified to
establish.
The collector may establish a protected snapshot, operation
descriptor, principal authorization, or another relevant fact.
It must not falsely assert direct observation of a later external
effect that has not yet occurred.
8.4.3.17. Original global source page 1325
15.7 — COLLECTION INSTANCE TRUST AND IDENTITY
Das Expires 29 April 2027 [Page 147]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15.7.1 — Enrollment
The collection instance may be enrolled through an authenticated
protected administrative procedure.
15.7.2 — Identity
The collection instance may possess an individual cryptographic
identity or protected controller reference.
15.7.3 — Collection Role
The instance is authorized to collect the selected evidence class.
15.7.4 — Protected State
The collecting component may protect its evidence generation and
relevant counters.
15.7.5 — Source Visibility
The evidence assurance depends upon what the collector can
independently observe.
15.7.6 — Context Integrity
The system may protect the resource and operation context used during
evidence formation.
15.7.7 — Compromise Handling
Evidence created after a known collector compromise may become
ineligible under current policy.
15.7.8 — No Automatic Authority
An authorized evidence collector is not automatically entitled to
activate the actual consequential operation.
15.8 — INDEPENDENT EXECUTION-TIME VALIDATION
The second protected validation instance examines the relevant
evidence and current Candidate Act conditions.
It may verify:
Das Expires 29 April 2027 [Page 148]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.4.3.18. Original global source page 1326
The collection instance's identity and role;
The integrity of collection evidence;
The Candidate Act identity;
The original source authority;
The relevant resource correspondence;
Current operation context;
Current policy and revocation state;
And any application-specific execution-time predicates.
A representative execution-time validation record may comprise:
EXECUTION_TIME_VALIDATION = { validation_version,
original_candidate_act_digest, collection_evidence_commitment,
collection_instance_identity, validating_instance_identity,
validating_instance_generation, validated_resource_scope,
validated_operation_descriptor, current_execution_context,
current_policy_epoch, current_authority_epoch,
independent_observation_commitment, validation_result,
validation_nonce, validation_epoch,
protected_validation_authentication }
A valid validation result must be linked to the particular collection
evidence and Candidate Act.
It does not become reusable authority merely because it is
authenticated.
15.9 — INDEPENDENCE BETWEEN PROTECTED INSTANCES
15.9.1 — Separate Protected State
The collection and validation instances may maintain independently
protected evidence and decision state.
8.4.3.19. Original global source page 1327
15.9.2 — Separate Authorities
Each instance may have a distinct assigned role.
Das Expires 29 April 2027 [Page 149]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15.9.3 — Separate Cryptographic Identity
The instances may authenticate their respective outputs
independently.
15.9.4 — Protected Communication
Evidence transferred between instances is authenticated.
15.9.5 — Distinct Failure Domains
A configuration may place the instances in independently administered
or hardware-protected environments.
15.9.6 — Session Independence
The instances need not share one requester session or one executable
process.
15.9.7 — Common Hardware
A particular implementation may share physical hardware if the
required protected separation is technically maintained.
15.9.8 — Independence Limitation
A collection process and validator both fully controlled by the same
compromised privileged authority cannot automatically claim
independent compromise resistance.
15.9.9 — Optional Integrated Construction
An implementation may integrate functional modules in one protected
component where the selected claims do not require independent
protected instances.
15.9.10 — Principal Two-Instance Construction
Where independent collection and execution-time validation are claim
limitations, the implementation must actually satisfy those distinct
protected functions and their required evidence relationships.
15.10 — CROSS-EVIDENCE COMMITMENT
The protected system associates the collection-time evidence with the
independent execution-time validation result.
For a representative implementation, define:
Das Expires 29 April 2027 [Page 150]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.4.3.20. Original global source page 1328
[ C_0=H(\operatorname{Canon}(CA,\ E_0,\ A,\ R,\ P_0,\ N_0)) ]
where (E_0) represents collection evidence, (A) source authority, (R)
relevant resource identity, (P_0) applicable collection policy, and
(N_0) a collection nonce.
Define:
[ C_1=H(\operatorname{Canon}(CA,\ C_0,\ E_1,\ P_1,\ V,\ N_1)) ]
where (E_1) represents execution-time validation evidence, (P_1) the
applicable current policy, (V) the independent validator identity or
protected role, and (N_1) the corresponding validation nonce.
A cross-commitment may then be represented as:
[ X=H(\operatorname{Canon}(C_0,C_1,CA,FS,\Gamma)) ]
where (FS) identifies the designated Finality Sink and (\Gamma)
identifies relevant current authority or protected state.
These formulae are illustrative.
The selected canonical representation must unambiguously encode the
required security-relevant fields.
A hash does not independently establish that the underlying evidence
is accurate.
The independent protected components must supply the corresponding
authentication and qualification.
15.11 — EVIDENCE CORRESPONDENCE
The protected cross-commitment verifier may require:
COLLECTION_ACT_MATCH AND VALIDATION_ACT_MATCH AND
COLLECTION_COMMITMENT_VALID AND INDEPENDENT_VALIDATION_AUTHENTIC AND
SOURCE_AUTHORITY_VALID AND RESOURCE_IDENTITY_CORRESPONDENCE AND
REQUIRED_POLICY_CONTINUITY AND REQUIRED_CONTEXT_CONTINUITY
8.4.3.21. Original global source page 1329
AND CURRENT_REVOCATION_VALID
15.11.1 — Act Identity
Das Expires 29 April 2027 [Page 151]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The collection and validation records must refer to the same
Candidate Act or an expressly authorized transformation thereof.
15.11.2 — Resource Identity
The relevant protected resource references must correspond under the
applicable identity rules.
15.11.3 — Policy Relationship
A change in policy may require revalidation or a specified protected
compatibility rule.
15.11.4 — Context Continuity
The execution context must satisfy the relevant conditions
established by the original authority.
15.11.5 — Validation Role
The validating instance must possess current authority for the
required evidence class.
15.11.6 — Freshness
Expired or revoked evidence cannot be used to create new
consequential authority.
15.11.7 — Conflicting Evidence
Conflicting or unsupported evidence does not automatically qualify
for acceptance.
15.11.8 — Missing Evidence
An absent mandatory evidence component prevents the corresponding
protected enablement.
15.12 — EVIDENCE IS NOT FINALITY AUTHORITY
A collection evidence commitment may be valid.
An execution-time validation result may be valid.
A cross-commitment may be valid.
Nevertheless, none necessarily authorizes the actual effect until the
protected finality authority condition is established.
Das Expires 29 April 2027 [Page 152]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.4.3.22. Original global source page 1330
The system may implement this separation through:
A distinct protected finality state transition;
A dedicated capability-activation controller;
A sink-local enabling register;
A non-exportable protected authorization slot;
A controlled credential-release condition;
Or another technically sufficient authority mechanism.
The requesting agent may possess all evidentiary references while
remaining unable to perform the governed effect.
The evidence supports an authorization decision.
The finality enablement controls the actual consequential primitive.
15.13 — PROTECTED FINALITY ENABLEMENT
A representative finality enablement record may comprise:
PROTECTED_FINALITY_ENABLEMENT = { enablement_identifier,
candidate_act_commitment, collection_evidence_commitment,
independent_validation_commitment, cross_evidence_commitment,
source_authority_reference, authorized_effect_descriptor,
actual_resource_scope, designated_finality_sink,
current_policy_epoch, current_authority_epoch,
current_resource_generation, protected_reservation_reference,
usage_limit, finality_generation, sink_local_consumption_reference,
revocation_reference, protected_enablement_authentication }
The enablement may remain entirely within the protected authority or
sink domain.
8.4.3.23. Original global source page 1331
A requester may receive an opaque reference that is inert without
current sink-local state.
The system need not provide the requester with a reusable complete
authority object.
Das Expires 29 April 2027 [Page 153]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15.14 — NON-BEARER EFFECTUATION CONTROL
15.14.1 — Possession Is Insufficient
A copied capability or reference cannot independently authorize the
real effect.
15.14.2 — Candidate Act Binding
The actual operation must match the authorized Candidate Act.
15.14.3 — Designated Sink Binding
The enablement applies only to the authorized effectuation interface.
15.14.4 — Resource Binding
The actual target must correspond to the protected resource identity.
15.14.5 — Context Binding
Relevant current execution and authority state must remain valid.
15.14.6 — Generation Binding
The enablement may require a current protected generation.
15.14.7 — Consumption Binding
The protected sink must verify that the permitted use remains
available.
15.14.8 — Revocation Binding
The authority must satisfy current revocation conditions.
15.14.9 — Anti-Copying Effect
Copying the representation does not create another valid independent
consumable authority.
15.14.10 — Assurance Limitation
A non-bearer design cannot prevent arbitrary privileged resource
modification if the actual effectuation boundary itself remains
uncontrolled.
Das Expires 29 April 2027 [Page 154]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.4.3.24. Original global source page 1332
15.15 — ACTUAL PENDING OPERATION RECONSTRUCTION
A protected Finality Sink does not rely solely upon the agent's
earlier description of its intended operation.
The sink obtains or reconstructs the actual operation presented for
effectuation.
Depending upon the resource, this may include:
The actual file object and requested mutation;
The database transaction and its effective parameters;
The network payload and actual destination;
The credential activation request;
The payment amount and recipient;
The hardware command and current target device;
The actual information proposed for disclosure;
Or another effect-specific representation.
The resulting descriptor is compared with the authorized Candidate
Act and cross-committed evidence.
A signed receipt for an earlier operation does not satisfy finality
if the actual pending operation differs.
15.16 — FINALITY SINK INDEPENDENCE
The Finality Sink may reside outside the requesting computational
environment.
It may be:
A protected transactional database controller;
A network egress gate;
A file-system mutation controller;
A credential broker;
Das Expires 29 April 2027 [Page 155]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A payment gateway;
A controlled storage service;
8.4.3.25. Original global source page 1333
A device command controller;
A protected media-release interface;
Or another mandatory effectuation boundary.
The sink is independent in the relevant authority sense when the
requesting workload cannot unilaterally alter its protected
verification and consumption decisions.
Physical separation is optional unless required by the selected
protection model.
A process that merely trusts the agent's self-reported validation
status is not sufficient for the stronger principal arrangement.
15.17 — MONOTONIC SINK-LOCAL CONSUMPTION
The Finality Sink maintains protected state identifying whether the
applicable authority remains available.
A representative state may comprise:
SINK_LOCAL_CONSUMPTION_STATE = { sink_identity,
candidate_act_commitment, finality_enablement_reference,
permitted_use_count, consumed_use_count, protected_generation,
current_resource_binding, reserved_or_committed_status,
dispatch_attempt_reference, current_revocation_state,
protected_state_authentication }
15.17.1 — Initial State
The enablement has not yet been exercised.
15.17.2 — Reservation
The sink may reserve the permitted operation.
15.17.3 — Consumption
The sink commits a protected state transition preventing unsupported
reuse.
Das Expires 29 April 2027 [Page 156]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15.17.4 — Monotonic Generation
8.4.3.26. Original global source page 1334
The generation advances according to the applicable protected
consumption protocol.
15.17.5 — Replay
An earlier reference cannot restore an already consumed allowance.
15.17.6 — Concurrent Requests
Multiple attempts against the same allowance are resolved through an
authoritative atomic or equivalent protected transition.
15.17.7 — Rollback Resistance
An untrusted snapshot cannot restore earlier consumable state.
15.17.8 — Real-Effect Qualification
Consumption of local authority must remain distinguished from the
actual external completion of an operation.
15.18 — ATOMIC CONSUMPTION AND EFFECTUATION
Where the Finality Sink controls the resource and consumption state
within one transaction domain, the system may perform:
ATOMIC { VERIFY_ACTUAL_OPERATION VERIFY_CURRENT_FINALITY_AUTHORITY
VERIFY_CROSS_COMMITTED_EVIDENCE VERIFY_RESOURCE_STATE
VERIFY_UNCONSUMED_ENABLEMENT CONSUME_ENABLEMENT COMMIT_EFFECT }
This permits a strong local atomicity guarantee where the required
resource and state primitives actually support the transaction.
Where the external effect occurs through a separate nontransactional
service, the system must distinguish:
Authority consumed before dispatch;
Effect dispatch attempted;
Effect confirmed;
Effect rejected;
Das Expires 29 April 2027 [Page 157]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.4.3.27. Original global source page 1335
And effect outcome unresolved.
It must not claim global exactly-once external completion solely
because the local authority was consumed once.
15.19 — CONCURRENT AUTHORITY EXERCISE
Two computational entities may concurrently present the same finality
enablement.
For a single-use enablement, the protected consumption controller
must ensure that no more than one eligible transition succeeds under
the selected coordination model.
15.19.1 — Shared Authoritative State
Concurrent requests may be serialized through a protected
transactional controller.
15.19.2 — Atomic Compare-and-Consume
A sink may atomically compare the expected generation and advance the
protected consumption state.
15.19.3 — Losing Request
A request that observes a consumed or stale generation is rejected.
15.19.4 — Multi-Resource Coordination
Where several sinks may exercise equivalent authority, appropriate
shared state or prepartitioned bounded authority is required.
15.19.5 — Offline Authority
A disconnected domain may exercise only its expressly bounded
allocated allowance.
15.19.6 — Duplication Limit
The system must not infer global single-use behavior from
independently maintained counters without a corresponding
coordination guarantee.
15.20 — REVOCATION AND POLICY CHANGE
Das Expires 29 April 2027 [Page 158]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
An operation may pass collection and validation before its original
authority is revoked.
The system may maintain protected source-authority epochs, revocation
state, and policy generations.
8.4.3.28. Original global source page 1336
The Finality Sink checks the required current state immediately
before its governed effectuation transition.
A previously authenticated validation result does not override later
mandatory revocation.
Where a policy changes materially, the system may require new cross-
committed evidence.
Where a policy explicitly defines compatible transitions, a protected
verifier may determine whether the existing evidence remains
eligible.
A requesting agent cannot unilaterally assert compatibility.
15.21 — EVIDENCE REBINDING AFTER OPERATION CHANGE
A computational entity may legitimately revise a proposed operation.
For example, it may select a different target, narrow an amount, or
update parameters following a resource-version change.
The system distinguishes a permitted transformation from a materially
different consequential act.
A new operation may require:
A new Candidate Act commitment;
New collection evidence;
Independent current validation;
A new cross-commitment;
And new finality enablement.
A protected transformation procedure may reuse selected still-valid
evidence where the technical predicates support such reuse.
Das Expires 29 April 2027 [Page 159]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
However, a hash of the original operation does not automatically
authorize all derivative operations.
15.22 — CROSS-DOMAIN EVIDENCE TRANSPORT
Collection and validation may occur across independently administered
domains.
8.4.3.29. Original global source page 1337
The system may transport authenticated evidence through protected
communication protocols, message queues, shared storage, or
equivalent channels.
The receiving validator checks:
Source identity;
Evidence integrity;
Authorized collection role;
Candidate Act binding;
Applicable policy;
Freshness;
And required contextual continuity.
The receiving domain does not treat a valid cryptographic signature
from any arbitrary domain as sufficient.
A trust relationship must establish that the source is authorized to
contribute the relevant evidence.
An evidence artifact may be forwarded without transferring the source
domain's complete consequential authority.
15.23 — DISTRIBUTED FINALITY SINKS
A Candidate Act may involve several potentially effect-capable
destinations.
The architecture may use one authoritative finality controller for
the relevant operation or bounded distinct authorities for separate
effects.
Das Expires 29 April 2027 [Page 160]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15.23.1 — Single Designated Sink
A protected authority is exercisable only at one current designated
sink.
15.23.2 — Multiple Coordinated Sinks
Several sinks may share authoritative protected consumption state.
15.23.3 — Partitioned Authority
A protected controller may preallocate nonoverlapping bounded
authority.
15.23.4 — Current Resource Binding
8.4.3.30. Original global source page 1338
Each sink verifies its actual resource scope.
15.23.5 — No Duplicate Authority
Two sinks cannot both validly claim the same single-use allowance
under the selected protected coordination assumptions.
15.23.6 — Partial Real Effects
Where several independent external consequences are involved, the
system records supported partial outcomes.
15.23.7 — Recovery
A later corrective effect requires separate protected authorization.
15.23.8 — Guarantee Qualification
The claimed consistency depends upon the actual authoritative state
and distributed failure model.
15.24 — CRASH-CONSISTENT CONSUMPTION JOURNAL
A principal implementation may maintain a protected journal
recording:
The finality enablement identifier;
Expected consumption generation;
Das Expires 29 April 2027 [Page 161]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Actual Candidate Act commitment;
Cross-evidence commitment;
Protected reservation status;
Commit decision;
External dispatch attempt;
Qualified outcome evidence;
And unresolved outcome state.
The journal may support recovery after interruption.
It does not automatically prove external completion unless the
corresponding effect evidence supports that conclusion.
8.4.3.31. Original global source page 1339
A crashed system must not reissue consumed authority merely because
its requester did not receive a successful response.
15.25 — UNCERTAIN EXTERNAL OUTCOME
A Finality Sink may validly consume operation-specific authority and
dispatch the actual effect.
A remote system may process the operation, but the acknowledgement
may be lost.
The local authority may be known to have been consumed.
The remote consequence may remain uncertain.
The system therefore distinguishes:
Exactly-once protected authorization consumption, where supported;
From exactly-once external effectuation, which requires additional
destination-side guarantees.
A second independent effect attempt is not automatically safe.
An applicable recovery protocol may obtain qualified outcome
evidence, use supported idempotency, or require separately authorized
corrective procedures.
Das Expires 29 April 2027 [Page 162]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15.26 — PRINCIPAL PROTECTED STATE MACHINE
A non-limiting state machine comprises:
CANDIDATE_PROPOSED: The consequential operation has been constructed.
NON_EFFECTIVE: The actual consequence remains withheld.
COLLECTION_PENDING: The required first-stage evidence has not been
established.
COLLECTION_COMMITTED: Authenticated collection evidence exists.
VALIDATION_PENDING: Independent execution-time validation has not
completed.
VALIDATION_REJECTED: A required predicate fails.
VALIDATION_ACCEPTED: The independent validator establishes the
required result.
8.4.3.32. Original global source page 1340
CROSS_COMMITMENT_PENDING: The correspondence among evidence records
remains unresolved.
CROSS_COMMITTED: Required evidence relationships have been accepted.
AUTHORITY_PENDING: Protected operation-specific enablement has not
been established.
AUTHORITY_PREPARED: Scoped non-bearer finality enablement exists.
SINK_VALIDATION_PENDING: The actual operation awaits reconstruction
and verification.
SINK_REJECTED: The actual operation fails a mandatory finality
condition.
CONSUMPTION_PENDING: The protected sink is preparing the authority
transition.
AUTHORITY_CONSUMED: The applicable use has been committed.
EFFECT_DISPATCH_PENDING: The controlled external operation has not
yet been released.
EFFECT_ATTEMPTED: The consequential operation has been initiated.
Das Expires 29 April 2027 [Page 163]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
EFFECT_CONFIRMED: Qualified evidence establishes the specified actual
effect.
EFFECT_REJECTED: Qualified evidence establishes the specified
rejection.
EFFECT_UNCERTAIN: The actual external outcome remains unresolved.
RECOVERY_PENDING: A separately governed reconciliation or recovery
procedure is required.
TERMINATED: The protected operation has reached a valid terminal
state.
A consumed local enablement does not automatically establish
completed external effectuation.
15.27 — PRINCIPAL END-TO-END WORKFLOW
Step 1 — Establish Original Authority. The principal or protected
source controller defines the authorized consequence.
Step 2 — Construct Candidate Act. The computational entity proposes a
bounded consequential operation.
Step 3 — Hold Non-Effective. The actual effect remains withheld.
8.4.3.33. Original global source page 1341
Step 4 — Establish Collection Context. Relevant source, resource,
policy, and operation conditions are identified.
Step 5 — Collect Protected Evidence. The first protected instance
establishes qualified evidence.
Step 6 — Commit Collection Evidence. The collector authenticates the
Candidate Act and evidence relationship.
Step 7 — Deliver Evidence to Validator. The second protected
instance obtains the authenticated evidence.
Step 8 — Verify Collection Identity. The validator checks the
source's role and authentication.
Step 9 — Verify Evidence Correspondence. The validator confirms the
required Candidate Act and resource bindings.
Das Expires 29 April 2027 [Page 164]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Step 10 — Independently Validate Current Conditions. Current policy,
resource, context, or other mandatory execution-time predicates are
evaluated.
Step 11 — Commit Validation Result. The second instance
authenticates its result.
Step 12 — Build Cross-Commitment. The system securely binds
collection and validation evidence.
Step 13 — Evaluate Current Authority. Revocation and required policy
continuity are checked.
Step 14 — Prepare Finality Enablement. An operation-specific non-
bearer authority state is established.
Step 15 — Bind Designated Sink. The enablement applies to the
selected effectuation interface.
Step 16 — Bind Consumption State. Protected usage and generation
conditions are established.
Step 17 — Present Actual Operation. The requester submits its
effect-capable command.
Step 18 — Reconstruct Actual Pending Effect. The Finality Sink
resolves the real operation and target.
Step 19 — Verify Cross-Committed Evidence. The sink checks the
necessary collection and validation relationship.
Step 20 — Verify Current Authority and Context. Source authority,
policy, revocation, and relevant resource state are checked.
8.4.3.34. Original global source page 1342
Step 21 — Verify Non-Bearer Enablement. The sink checks designated-
sink and actual-operation binding.
Step 22 — Verify Consumption. The protected controller determines
whether a valid use remains.
Step 23 — Consume Authority. The sink performs the required atomic
or otherwise protected consumption transition.
Step 24 — Permit Consequential Effect. The controlled resource
operation is released.
Das Expires 29 April 2027 [Page 165]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Step 25 — Commit Attempt Evidence. The system records the protected
effectuation attempt.
Step 26 — Reconcile Actual Outcome. Confirmed, rejected, partial, or
uncertain effects are distinguished.
Step 27 — Govern Successor Operation. A later consequential act
receives its own authority and any mandatory earlier real-effect
receipt.
15.28 — REFERENCE PSEUDOCODE: COLLECTION EVIDENCE
FUNCTION COLLECT_PROTECTED_EVIDENCE( candidate_act,
protected_collection_instance ): REQUIRE VERIFY_CANDIDATE_ACT(
candidate_act ) REQUIRE VERIFY_COLLECTION_INSTANCE_ROLE(
protected_collection_instance ) REQUIRE VERIFY_SOURCE_AUTHORITY(
candidate_act ) context = protected_collection_instance
.OBSERVE_RELEVANT_COLLECTION_CONTEXT( candidate_act ) IF
REQUIRED_CONTEXT_INCOMPLETE(context): RETURN HOLD evidence =
protected_collection_instance
8.4.3.35. Original global source page 1343
.AUTHENTICATE_EVIDENCE({ candidate_act: HASH(candidate_act),
originating_authority: HASH(CURRENT_SOURCE_AUTHORITY()),
observed_context: HASH_CANONICAL(context), resource_scope:
HASH(candidate_act.resource_scope), policy_epoch:
CURRENT_POLICY_EPOCH(), collection_nonce: NEW_PROTECTED_NONCE() })
RETURN evidence
The evidence reflects the collector's actual qualified observations
and protected source state.
15.29 — REFERENCE PSEUDOCODE: INDEPENDENT VALIDATION
FUNCTION INDEPENDENT_EXECUTION_VALIDATION( candidate_act,
collection_evidence, protected_validation_instance ): REQUIRE
VERIFY_VALIDATOR_IDENTITY_AND_ROLE( protected_validation_instance )
REQUIRE VERIFY_COLLECTION_EVIDENCE_AUTHENTICITY( collection_evidence
) REQUIRE VERIFY_CANDIDATE_EVIDENCE_BINDING( candidate_act,
collection_evidence ) REQUIRE VERIFY_COLLECTION_INSTANCE_AUTHORITY(
collection_evidence )
Das Expires 29 April 2027 [Page 166]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.4.3.36. Original global source page 1344
REQUIRE VERIFY_REQUIRED_DOMAIN_INDEPENDENCE() current_context =
protected_validation_instance .OBSERVE_CURRENT_EXECUTION_CONTEXT(
candidate_act ) REQUIRE VERIFY_CURRENT_RESOURCE_STATE( candidate_act,
current_context ) REQUIRE VERIFY_CURRENT_SOURCE_AUTHORITY(
candidate_act ) REQUIRE VERIFY_CURRENT_POLICY_AND_REVOCATION()
REQUIRE VERIFY_OPERATION_SCOPE( candidate_act ) result =
protected_validation_instance .AUTHENTICATE_VALIDATION({ candidate:
HASH(candidate_act), collection_commitment:
HASH(collection_evidence), current_context:
HASH_CANONICAL(current_context), current_policy:
CURRENT_POLICY_EPOCH(), current_authority: CURRENT_AUTHORITY_EPOCH(),
result: ACCEPTED, validation_nonce: NEW_PROTECTED_NONCE() }) RETURN
result
The function does not assume that collection-time conditions remain
valid without current verification.
8.4.3.37. Original global source page 1345
15.30 — REFERENCE PSEUDOCODE: CROSS-COMMITMENT
FUNCTION ESTABLISH_CROSS_EVIDENCE_COMMITMENT( candidate_act,
collection_evidence, validation_evidence,
protected_commitment_controller ): REQUIRE
VERIFY_COLLECTION_EVIDENCE( collection_evidence ) REQUIRE
VERIFY_INDEPENDENT_VALIDATION_EVIDENCE( validation_evidence ) REQUIRE
SAME_CANDIDATE_ACT( candidate_act, collection_evidence,
validation_evidence ) REQUIRE VALIDATION_BINDS_TO_COLLECTION(
validation_evidence, collection_evidence ) REQUIRE
VERIFY_REQUIRED_RESOURCE_CORRESPONDENCE() REQUIRE
VERIFY_REQUIRED_POLICY_CONTINUITY() REQUIRE
VERIFY_CURRENT_AUTHORITY() commitment =
protected_commitment_controller .ATOMIC_COMMIT({ candidate_act:
HASH(candidate_act), collection_evidence: HASH(collection_evidence),
independent_validation: HASH(validation_evidence), designated_sink:
candidate_act.finality_sink, current_authority_epoch:
8.4.3.38. Original global source page 1346
CURRENT_AUTHORITY_EPOCH(), cross_commitment_generation:
NEXT_PROTECTED_GENERATION() }) RETURN commitment
A valid cross-commitment does not independently create unlimited
effectuation authority.
15.31 — REFERENCE PSEUDOCODE: NON-BEARER ENABLEMENT
Das Expires 29 April 2027 [Page 167]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
FUNCTION PREPARE_NON_BEARER_FINALITY( candidate_act,
cross_commitment, protected_authority_controller ): REQUIRE
VERIFY_CROSS_COMMITMENT( cross_commitment ) REQUIRE
VERIFY_CANDIDATE_ACT_BINDING( candidate_act, cross_commitment )
REQUIRE VERIFY_CURRENT_SOURCE_AUTHORITY( candidate_act ) REQUIRE
VERIFY_CURRENT_RESOURCE_AND_POLICY_STATE() enablement =
protected_authority_controller .ATOMIC_PREPARE_ENABLEMENT({
candidate: HASH(candidate_act), cross_evidence:
HASH(cross_commitment), designated_sink: candidate_act.finality_sink,
resource: candidate_act.resource_reference, authorized_effect:
HASH(candidate_act.effect_descriptor),
8.4.3.39. Original global source page 1347
use_count: AUTHORIZED_USAGE_LIMIT(), current_generation:
NEXT_PROTECTED_FINALITY_GENERATION(), consumption_reference:
NEW_PROTECTED_CONSUMPTION_REFERENCE() }) RETURN
INERT_ENABLEMENT_REFERENCE( enablement )
The returned reference does not provide sufficient standalone
authority to perform the actual effect.
15.32 — REFERENCE PSEUDOCODE: FINALITY SINK
FUNCTION EFFECTUATE_CROSS_COMMITTED_OPERATION( candidate_act,
enablement_reference, finality_sink ): actual_operation =
finality_sink .RECONSTRUCT_ACTUAL_PENDING_OPERATION() IF
actual_operation IS NULL: RETURN DENY REQUIRE finality_sink
.VERIFY_ACTUAL_OPERATION_CORRESPONDENCE( actual_operation,
candidate_act ) REQUIRE finality_sink
.VERIFY_CROSS_COMMITTED_COLLECTION_EVIDENCE() REQUIRE finality_sink
.VERIFY_INDEPENDENT_EXECUTION_VALIDATION() REQUIRE finality_sink
.VERIFY_CURRENT_SOURCE_AUTHORITY() REQUIRE finality_sink
.VERIFY_CURRENT_POLICY_AND_REVOCATION()
8.4.3.40. Original global source page 1348
REQUIRE finality_sink .VERIFY_ACTUAL_RESOURCE_IDENTITY() REQUIRE
finality_sink .VERIFY_CURRENT_NON_BEARER_ENABLEMENT(
enablement_reference ) REQUIRE finality_sink
.VERIFY_DESIGNATED_SINK_AND_USAGE_SCOPE() REQUIRE finality_sink
.VERIFY_MONOTONIC_CONSUMPTION_STATE() consumption = finality_sink
.ATOMIC_CONSUME_ELIGIBLE_AUTHORITY( enablement_reference,
actual_operation ) IF consumption != COMMITTED: RETURN DENY attempt =
finality_sink .DISPATCH_CONTROLLED_EFFECT( actual_operation )
COMMIT_PROTECTED_ATTEMPT_STATE( consumption, attempt ) RETURN attempt
Das Expires 29 April 2027 [Page 168]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The finality sink must distinguish the local authority-consumption
result from the actual downstream completion result.
15.33 — REFERENCE PSEUDOCODE: CONCURRENT CONSUMPTION
FUNCTION CONSUME_SINGLE_USE_FINALITY( enablement_reference,
expected_generation, consumption_controller ): current_state =
consumption_controller .LOAD_AUTHORITATIVE_CONSUMPTION_STATE(
8.4.3.41. Original global source page 1349
enablement_reference ) IF current_state.generation !=
expected_generation: RETURN STALE_AUTHORITY IF
current_state.remaining_uses != 1: RETURN INVALID_USE_STATE committed
= consumption_controller .ATOMIC_COMPARE_AND_CONSUME({ enablement:
enablement_reference, expected_generation: expected_generation,
expected_remaining_uses: 1, next_generation:
NEXT_MONOTONIC_GENERATION(), next_remaining_uses: 0 }) IF committed
!= COMMITTED: RETURN CONCURRENT_USE_REJECTED RETURN
CONSUMPTION_COMMITTED
The atomicity must be supplied by the protected authoritative
consumption mechanism.
15.34 — REFERENCE PSEUDOCODE: UNCERTAIN EFFECT OUTCOME
FUNCTION RECONCILE_FINALITY_OUTCOME( original_operation,
protected_finality_journal ): record = protected_finality_journal
.LOAD_CURRENT_ATTEMPT_STATE( original_operation ) REQUIRE
VERIFY_JOURNAL_AUTHENTICITY(record) IF record.effect_confirmed:
8.4.3.42. Original global source page 1350
RETURN COMPLETED_EFFECT IF record.confirmed_non_effectuation: RETURN
CONFIRMED_NON_EFFECT IF record.dispatch_possible:
ESTABLISH_PROTECTED_RETRY_FENCE( original_operation ) evidence =
OBTAIN_QUALIFIED_OUTCOME_EVIDENCE( original_operation ) IF evidence
IS INSUFFICIENT: RETURN EFFECT_OUTCOME_UNCERTAIN RETURN
CLASSIFY_QUALIFIED_OUTCOME(evidence) RETURN
REQUIRE_PROTECTED_STATE_RECONCILIATION
An uncertain external outcome does not automatically restore consumed
authority.
15.35 — REFERENCE PSEUDOCODE: REVALIDATION AFTER CONTEXT CHANGE
Das Expires 29 April 2027 [Page 169]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
FUNCTION REVALIDATE_CHANGED_CANDIDATE( original_candidate,
changed_operation, protected_controller ): REQUIRE
VERIFY_ORIGINAL_CANDIDATE( original_candidate ) IF NOT
WITHIN_PERMITTED_OPERATION_SCOPE( changed_operation,
original_candidate ): RETURN REQUIRE_NEW_SOURCE_AUTHORITY
new_candidate = CONSTRUCT_CURRENT_CANDIDATE( changed_operation )
INVALIDATE_INAPPLICABLE_OLD_ENABLEMENT( original_candidate )
8.4.3.43. Original global source page 1351
collection = COLLECT_PROTECTED_EVIDENCE( new_candidate,
AUTHORIZED_COLLECTION_INSTANCE() ) validation =
INDEPENDENT_EXECUTION_VALIDATION( new_candidate, collection,
AUTHORIZED_VALIDATION_INSTANCE() ) commitment =
ESTABLISH_CROSS_EVIDENCE_COMMITMENT( new_candidate, collection,
validation, PROTECTED_COMMITMENT_CONTROLLER() ) RETURN
PREPARE_NON_BEARER_FINALITY( new_candidate, commitment,
PROTECTED_AUTHORITY_CONTROLLER() )
The system may reuse narrowly identified valid evidence where
appropriate, but it cannot silently relabel a materially changed
effect as identical.
15.36 — WORKED EXAMPLE A: TWO-STAGE APPROVAL FOR DATABASE MUTATION
An autonomous agent is authorized to update one specified database
record.
The first protected collection instance authenticates the source
authority, intended record identity, proposed mutation, and
collection-time resource state.
The second protected validator obtains the collection commitment.
It independently checks the current resource identity, mutation
scope, and authorization.
The protected system cross-commits the two stages.
A non-bearer finality enablement is established for one database
mutation.
At commit time, the database Finality Sink reconstructs the actual
pending update.
The sink verifies the collection commitment, independent validation,
authorized resource, current state, and unconsumed enablement.
Das Expires 29 April 2027 [Page 170]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.4.3.44. Original global source page 1352
The mutation is committed through the protected resource boundary.
Expected demonstrable result: A signed collection record cannot
independently authorize a different or repeated database mutation.
15.37 — WORKED EXAMPLE B: FORGED SIGNED-LOOKING VALIDATION
An attacker constructs a record resembling a valid execution-time
approval.
The record contains plausible identifiers and a copied operation
digest.
However, it was not generated by the authorized independent
validator.
The protected cross-commitment verifier checks the actual
authentication and validation role.
The forged record fails.
No valid finality enablement is established.
Even if the attacker submits the forged record directly to the
Finality Sink, the sink requires current protected authority state.
Expected demonstrable result: A syntactically plausible receipt
cannot substitute for authenticated independently protected
validation.
15.38 — WORKED EXAMPLE C: REPLAYED COLLECTION EVIDENCE
An agent receives valid collection evidence for an authorized file
mutation.
The original operation is completed.
The agent later proposes another mutation using the same collection
evidence.
The protected system identifies the changed Candidate Act or consumed
authority state.
The earlier evidence does not establish a current valid cross-
commitment for the new effect.
Das Expires 29 April 2027 [Page 171]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The second operation remains non-effective until the required fresh
authority conditions pass.
Expected demonstrable result: Collection evidence cannot be reused as
unrestricted authority for additional consequential operations.
15.39 — WORKED EXAMPLE D: VALID RECEIPT, DIFFERENT RESOURCE
8.4.3.45. Original global source page 1353
A protected collection instance records authorization for a specified
storage object.
An independent validator confirms the corresponding operation.
The agent subsequently redirects its actual command to a different
storage object.
The Finality Sink reconstructs the actual target identity.
The actual resource does not correspond to the cross-committed
evidence.
The sink refuses the operation.
Expected demonstrable result: Authenticity of an earlier approval
does not excuse mismatch with the actual effected resource.
15.40 — WORKED EXAMPLE E: TWO AGENTS PRESENT THE SAME ENABLEMENT
A protected controller prepares one single-use non-bearer finality
enablement.
Two agents obtain the same opaque reference.
Both attempt to exercise it concurrently.
The Finality Sink or authoritative consumption controller performs a
protected atomic transition.
Only one valid consumption succeeds.
The losing request is rejected under current consumption state.
Expected demonstrable result: Copying the same authority reference
does not create two independent authorized consequential effects.
15.41 — WORKED EXAMPLE F: AUTHORITY REVOKED AFTER VALIDATION
Das Expires 29 April 2027 [Page 172]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
An autonomous agent receives valid collection and execution-time
evidence.
Before the real operation is submitted, the original principal
revokes the relevant permission.
The Finality Sink checks current source-authority and revocation
state.
The historical evidence remains authentic.
However, the operation no longer satisfies current consequential
authority.
8.4.3.46. Original global source page 1354
The sink withholds the effect.
Expected demonstrable result: A valid historical cross-commitment
does not override current revocation.
15.42 — WORKED EXAMPLE G: CROSS-DOMAIN RESOURCE UPDATE
An agent in one protected domain prepares a resource update.
A first domain collects authenticated information concerning the
operation.
A second independently administered domain validates the current
effect scope.
The evidence is cross-committed.
The resulting finality enablement references the designated remote
resource sink.
The remote sink verifies the protected operation and actual resource
before committing the effect.
The originating agent never receives an unrestricted reusable
resource credential.
Expected demonstrable result: Cross-domain evidence may support a
bounded real effect without transferring unlimited authority to the
requesting agent.
15.43 — WORKED EXAMPLE H: CREDENTIAL ACTIVATION
Das Expires 29 April 2027 [Page 173]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
An autonomous assistant requests access to a protected external
service.
A first protected instance records the authorized service, operation,
and resource scope.
A second protected instance verifies current permission and operation
semantics.
The system cross-commits the evidence.
A credential broker retains the reusable secret within its protected
domain.
At the actual credential-activation boundary, the broker verifies the
pending request, current evidence, and non-bearer enablement.
The broker activates only the scoped operation.
Expected demonstrable result: A signed approval does not
automatically give the assistant reusable complete external service
credentials.
8.4.3.47. Original global source page 1355
15.44 — WORKED EXAMPLE I: HARDWARE COMMAND
An autonomous controller proposes a bounded device command.
Collection-time evidence identifies the authorized device, command
type, and permitted parameters.
An independent validator checks current device ownership and
applicable operating conditions.
The protected controller establishes a cross-commitment and hardware-
bound enablement.
The hardware command sink reconstructs the actual pending device
instruction.
It verifies the relevant evidence, current ownership, command
parameters, and consumption state.
A materially different command is rejected.
Das Expires 29 April 2027 [Page 174]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Expected demonstrable result: The final actuator or device gate
enforces actual command correspondence rather than trusting only
upstream authorization.
15.45 — WORKED EXAMPLE J: LOST EXTERNAL ACKNOWLEDGEMENT
An agent submits a valid protected payment instruction.
The Finality Sink consumes the corresponding single-use authority and
dispatches the operation.
The destination may complete the payment, but the acknowledgement is
lost.
The agent attempts to reuse the original enablement.
The protected sink refuses the duplicate consumption.
The outcome remains unresolved until the applicable protected
reconciliation protocol establishes sufficient evidence.
Expected demonstrable result: Uncertainty concerning remote
completion does not recreate consumed authorization.
15.46 — WORKED EXAMPLE K: SNAPSHOT RESTORATION
8.4.3.48. Original global source page 1356
A virtualized autonomous workload receives valid finality enablement.
The corresponding operation is performed and its authority consumed.
The workload later resumes from a snapshot created before
consumption.
Its local memory contains the old evidence and enablement reference.
The Finality Sink checks current authoritative monotonic consumption
state.
The restored reference fails.
Expected demonstrable result: Rollback of untrusted computational
state cannot restore already consumed consequential authority.
15.47 — WORKED EXAMPLE L: DEPENDENT CAUSAL CONTINUATION
Das Expires 29 April 2027 [Page 175]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A multi-phase workflow requires a verified earlier real effect before
a successor operation.
The first phase is governed by cross-committed collection and
execution-time evidence.
The actual Finality Sink releases the first consequential operation.
An authorized Interim Effectuation Validator separately establishes
the required earlier real-effect result.
Where CW-2 applies, the accepted identity-authenticated receipt
constitutes a necessary authority input for the successor phase.
The second operation additionally undergoes its own collection,
validation, cross-commitment, and finality checks as required by the
selected configuration.
Expected demonstrable result: Collection-time evidence, execution
validation, and actual-effect receipts retain their distinct
technical roles.
15.48 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
15.48.1 — Fabricated Collection Evidence
An attacker creates a false collection record.
The validator requires authorized collection-instance authentication.
15.48.2 — Genuine Collector, Wrong Role
8.4.3.49. Original global source page 1357
A valid identity issues evidence outside its permitted collection
function.
The protected verifier checks the assigned authority role.
15.48.3 — Forged Validation Result
An attacker fabricates an independent validation receipt.
Protected validator authentication rejects the forgery.
15.48.4 — Compromised Requester
An untrusted agent changes the operation after validation.
Das Expires 29 April 2027 [Page 176]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The actual sink verifies current operation correspondence.
15.48.5 — Cross-Act Evidence Mixing
Evidence from different Candidate Acts is combined.
The cross-commitment verifier rejects inconsistent act bindings.
15.48.6 — Resource Substitution
The actual resource differs from the approved resource.
Sink-side resource reconstruction rejects the mismatch.
15.48.7 — Recipient Substitution
An approved disclosure or payment is redirected.
The designated sink verifies the actual recipient.
15.48.8 — Operation Parameter Mutation
A validated amount, command, or payload is changed.
The Finality Sink checks the actual operation descriptor.
15.48.9 — Stale Collection Context
A resource changes after collection.
Execution-time validation and current sink checks enforce applicable
freshness requirements.
15.48.10 — Stale Validator Evidence
The validation result is reused after material state change.
8.4.3.50. Original global source page 1358
Current policy, resource, and authority checks may require
revalidation.
15.48.11 — Policy Epoch Downgrade
An attacker presents evidence under an older permissive policy.
Protected policy continuity and current authority checks reject
invalid use.
Das Expires 29 April 2027 [Page 177]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15.48.12 — Revocation Race
Original permission is revoked after validation.
The sink verifies current revocation state.
15.48.13 — Receipt Laundering
An agent presents a signed evidence record as an execution
credential.
The resource sink requires separate valid finality enablement.
15.48.14 — Bearer Authority Theft
An attacker copies an enablement reference.
The reference remains inert without current protected operation and
sink state.
15.48.15 — Cross-Sink Replay
An authority issued for one sink is presented at another.
The sink-binding predicate rejects unauthorized use.
15.48.16 — Same-Sink Replay
A previously consumed capability is presented again.
Protected monotonic consumption state rejects the duplicate.
15.48.17 — Concurrent Double Consumption
Two requesters race to use one authority.
An authoritative atomic consumption transition allows only permitted
exercise.
15.48.18 — Consumption State Rollback
An older state snapshot is restored.
Protected monotonic generation or authoritative durable state
prevents unauthorized restoration.
Das Expires 29 April 2027 [Page 178]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.4.3.51. Original global source page 1359
15.48.19 — Fake Independence
Two validation processes are presented as independent despite sharing
an unprotected compromise domain.
The claimed guarantee depends upon qualified separation and protected
identity.
15.48.20 — Compromised Collection Instance
An attacker changes collected evidence.
The protection depends upon the remaining trusted observation and
validation conditions.
15.48.21 — Compromised Validation Instance
An attacker produces false acceptance results.
A stronger guarantee requires independent protected verification,
qualified roles, or other relevant trust controls.
15.48.22 — Cryptographic Key Theft
A protected evidence-authentication key is stolen.
The implementation requires suitable key protection, rotation, and
invalidation policies.
15.48.23 — Canonicalization Ambiguity
Two domains interpret the same encoded operation differently.
The system enforces applicable typed and canonical representation
rules.
15.48.24 — Unknown Execution Context
Required current context cannot be established.
The corresponding finality authority remains withheld.
15.48.25 — Direct Effectuation Bypass
An agent invokes an uncontrolled resource interface.
Das Expires 29 April 2027 [Page 179]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The claimed guarantee requires mandatory enforcement coverage at
actual effect-capable paths.
15.48.26 — Privileged Credential Bypass
The agent obtains broad reusable credentials independently of the
finality gate.
A protected credential or resource controller must constrain the
relevant effect.
8.4.3.52. Original global source page 1360
15.48.27 — Multi-Sink Split Brain
Two sinks independently accept the same consumption state.
Authoritative coordination or nonoverlapping bounded allocation is
required.
15.48.28 — External Effect After Local Crash
The protected sink crashes after dispatching an operation.
The system preserves consumed authority and supported outcome
uncertainty.
15.48.29 — Lost Acknowledgement
A destination response is lost.
The requester does not automatically receive new effectuation
authority.
15.48.30 — Retry With Changed Parameters
An attacker uses the same attempt identity for a different operation.
Current operation binding rejects the substitution.
15.48.31 — Forged Consumption Receipt
An attacker claims the sink consumed or restored authority.
The controller requires authenticated authoritative consumption
state.
15.48.32 — Verification Work Exhaustion
Das Expires 29 April 2027 [Page 180]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
An attacker submits oversized or deeply nested evidence structures.
The protected verifier uses bounded work and conservative failure.
15.48.33 — Privacy Leakage Through Evidence
Sensitive information is unnecessarily included in validation
records.
The system may use qualified commitments, restricted access, or
appropriate protected disclosure policies.
15.48.34 — Hardware Generation Mismatch
A device command is submitted after protected ownership or generation
change.
Current device and sink-local state reject stale authority.
15.48.35 — Software Tool Semantics Change
8.4.3.53. Original global source page 1361
The actual tool introduces additional effects.
The protected operation correspondence check rejects unapproved
changes.
15.48.36 — Causal Receipt Confusion
A collection receipt is presented as proof that an earlier real
effect completed.
The successor phase requires the specifically qualified accepted
actual-effect evidence.
15.48.37 — Unauthorized Evidence Rebinding
An agent reassigns an approval to a new Candidate Act.
New protected validation and authority are required where applicable.
15.48.38 — Recovery Authority Laundering
An agent claims an earlier validation permits unrestricted corrective
operations.
Recovery effects require separate bounded current authority.
Das Expires 29 April 2027 [Page 181]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15.48.39 — Compromised Finality Sink
The actual resource gate is compromised.
A stronger guarantee requires an appropriately protected downstream
enforcement boundary.
15.48.40 — Emergency Override Abuse
An agent labels an operation urgent to bypass evidence or finality
checks.
Any emergency authority must be independently specified,
authenticated, and bounded.
15.49 — CRASH, REPLAY, AND UNCERTAIN-OUTCOME HANDLING
15.49.1 — Crash Before Collection
No collection evidence is presumed.
15.49.2 — Crash During Collection
Incomplete evidence is not accepted as complete authenticated
collection.
15.49.3 — Crash After Collection
The protected record may be recovered and validated according to
current applicability.
8.4.3.54. Original global source page 1362
15.49.4 — Crash During Independent Validation
An incomplete validation decision does not authorize effectuation.
15.49.5 — Crash After Validation
A protected validator record may remain available, subject to current
source authority and policy.
15.49.6 — Crash During Cross-Commitment
Authoritative protected state determines whether the commitment
actually completed.
15.49.7 — Crash Before Enablement
Das Expires 29 April 2027 [Page 182]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Valid evidence does not automatically imply that finality enablement
was prepared.
15.49.8 — Crash After Enablement
The protected controller recovers current authority and consumption
state.
15.49.9 — Crash During Consumption
Authoritative state establishes whether the consumption transition
committed.
15.49.10 — Crash After Dispatch
An actual external effect may have occurred.
15.49.11 — Snapshot Restoration
A restored requester does not regain spent authority.
15.49.12 — Unknown External Outcome
The relevant effect remains unresolved until qualified evidence or an
appropriate recovery mechanism addresses the uncertainty.
15.50 — PRESENT-DAY PHOSITA REFERENCE IMPLEMENTATION
15.50.1 — Minimum Architecture
A feasible prototype may comprise:
One untrusted agent process;
A protected evidence collector;
8.4.3.55. Original global source page 1363
An independently protected validation service;
An authenticated evidence registry;
A protected finality authority controller;
A transactional resource gateway;
And an authoritative consumption-state store.
Das Expires 29 April 2027 [Page 183]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15.50.2 — Candidate Act
The agent proposes a mutation of one identified protected resource.
15.50.3 — Collection
The collector authenticates the proposed operation and relevant
source context.
15.50.4 — Independent Validation
The second service evaluates current resource and authorization
conditions.
15.50.5 — Cross-Commitment
The protected controller commits the relationship among the Candidate
Act and both evidence stages.
15.50.6 — Non-Bearer Enablement
The finality controller creates one operation-bound authority
reference.
15.50.7 — Actual Effect
The resource gateway reconstructs the actual mutation and checks the
required state.
15.50.8 — Monotonic Consumption
A transactional store permits a single authorized consumption.
15.50.9 — Adversarial Substitution
The prototype changes the actual target or parameters and verifies
rejection.
15.50.10 — Replay
The previously consumed reference is submitted again and rejected.
15.50.11 — Concurrency
Two agents race to use the same reference.
Das Expires 29 April 2027 [Page 184]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.4.3.56. Original global source page 1364
15.50.12 — Crash Recovery
The prototype restarts from a stale agent snapshot while the
authoritative consumption state remains current.
15.50.13 — Hardware Extension
A device controller may maintain the finality state in protected
firmware or hardware-supported registers.
15.50.14 — Trust-Model Qualification
The prototype establishes the stated mechanism under its actual
collector, validator, state-store, and resource-gateway assumptions.
15.51 — NON-LIMITING PROPOSED FEASIBILITY EXPERIMENTS
The following experiments are proposed and are not represented as
completed results.
Experiment 1 — Valid Candidate Act: Establish one authorized
consequential operation.
Experiment 2 — Collection Authentication: Verify a protected first-
stage evidence record.
Experiment 3 — Forged Collection Evidence: Reject fabricated
collection records.
Experiment 4 — Wrong Collector Role: Reject genuine evidence issued
outside the source's authorization.
Experiment 5 — Independent Validation: Verify the second protected
instance evaluates the required evidence.
Experiment 6 — Fake Validator: Reject an unauthenticated validation
record.
Experiment 7 — Collection/Validation Mismatch: Combine evidence from
different Candidate Acts.
Experiment 8 — Resource Mismatch: Substitute the actual protected
target.
Experiment 9 — Policy Epoch Mismatch: Change the policy between
collection and validation.
Das Expires 29 April 2027 [Page 185]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Experiment 10 — Authority Revocation: Revoke permission after valid
validation but before effectuation.
Experiment 11 — Cross-Commitment Integrity: Alter a referenced
evidence record.
Experiment 12 — Omitted Evidence: Remove a mandatory validation
dependency.
8.4.3.57. Original global source page 1365
Experiment 13 — Canonicalization Ambiguity: Test different encodings
of an operation descriptor.
Experiment 14 — Evidence-Only Submission: Attempt effectuation using
collection evidence without enablement.
Experiment 15 — Validation-Only Submission: Attempt effectuation
using the independent validation receipt alone.
Experiment 16 — Cross-Commitment-Only Submission: Attempt
effectuation without valid non-bearer finality authority.
Experiment 17 — Valid Enablement: Authorize one precisely bound
actual effect.
Experiment 18 — Different Resource: Reuse enablement for a different
resource.
Experiment 19 — Different Recipient: Redirect an authorized external
operation.
Experiment 20 — Changed Parameters: Modify actual operation
parameters after validation.
Experiment 21 — Wrong Sink: Present enablement at a different
effectuation interface.
Experiment 22 — Copied Reference: Test whether possession alone can
activate an effect.
Experiment 23 — Single-Use Consumption: Consume one protected
operation-specific enablement.
Experiment 24 — Sequential Replay: Submit consumed authority again.
Experiment 25 — Concurrent Replay: Submit the same reference through
several agents.
Das Expires 29 April 2027 [Page 186]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Experiment 26 — Monotonic Generation: Verify current sink consumption
state advances as required.
Experiment 27 — Snapshot Rollback: Restore earlier requester state.
Experiment 28 — State-Store Rollback: Test protected rejection of
stale consumption generations.
Experiment 29 — Revocation Race: Revoke authority immediately before
finality.
Experiment 30 — Resource Version Change: Modify the resource after
independent validation.
Experiment 31 — Tool Semantic Change: Change the operation's actual
consequential behavior.
Experiment 32 — Device Ownership Change: Reassign a hardware
effectuation resource.
8.4.3.58. Original global source page 1366
Experiment 33 — Multi-Sink Coordination: Attempt single-use exercise
at several coordinated sinks.
Experiment 34 — Distributed Split Brain: Test insufficiently
synchronized consumption state.
Experiment 35 — Bounded Offline Authority: Allocate nonoverlapping
authority to disconnected domains.
Experiment 36 — Credential Activation: Enforce protected credential-
use finality without releasing reusable complete credentials.
Experiment 37 — Data Disclosure: Verify actual outgoing information
and recipient binding.
Experiment 38 — Hardware Command: Verify current device and command-
specific authority.
Experiment 39 — Crash During Consumption: Recover authoritative
consumption state.
Experiment 40 — Crash After Dispatch: Preserve the distinction
between consumed authorization and uncertain external outcome.
Experiment 41 — Lost Acknowledgement: Verify that missing
confirmation does not restore authority.
Das Expires 29 April 2027 [Page 187]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Experiment 42 — Qualified Outcome Recovery: Obtain evidence of the
actual effect before further corrective operations.
Experiment 43 — Causal Receipt Integration: Require a CW-2 accepted
earlier actual-effect receipt for a dependent successor phase.
Experiment 44 — Cross-Provider Evidence: Authenticate collection and
validation from separate administrative domains.
Experiment 45 — Fake Independence: Test the limits of collocated
unprotected collection and validation processes.
Experiment 46 — Protected Domain Isolation: Test selected collector
and validator compromise assumptions.
Experiment 47 — Quorum Approval Integration: Verify that a valid
quorum certificate remains distinct from actual finality consumption.
Experiment 48 — Coverage Integrity: Attempt effectuation through an
alternate unmediated path.
Experiment 49 — Privacy-Minimized Evidence: Use authenticated
evidence references without exposing unnecessary raw protected
information.
8.4.3.59. Original global source page 1367
Experiment 50 — Verification Exhaustion: Submit oversized or
malformed evidence.
Experiment 51 — Stale Validation: Delay an operation until its
execution-time conditions no longer hold.
Experiment 52 — Evidence Rebinding: Create fresh authority after a
permitted change in operation parameters.
Experiment 53 — Source Authority Expansion: Attempt a materially
broader operation without new authorization.
Experiment 54 — Integrated Protected Controller: Implement the
authority and sink functions within one protected resource service.
Experiment 55 — Separate Protected Domains: Use distinct collection,
validation, authority, and sink controllers.
Experiment 56 — No Blockchain: Demonstrate authenticated evidence
commitments and monotonic consumption without a public distributed
ledger.
Das Expires 29 April 2027 [Page 188]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Experiment 57 — No Reusable Complete Authority: Verify that the
requesting agent never receives a standalone reusable object
sufficient to cause the governed effect.
Experiment 58 — Current Finality Sink Reconstruction: Demonstrate
that the actual sink obtains its operation descriptor independently
of an untrusted original intent statement.
Experiment 59 — Protected Revocation State: Reject a previously valid
authority after a current revocation transition.
Experiment 60 — End-to-End Evidence-to-Effect: Verify the complete
chain from collection-time evidence through independent validation,
cross-commitment, non-bearer enablement, and protected actual
effectuation.
The experiments are illustrative and may use suitable present-day
software, hardware, communication, and resource-control mechanisms.
15.52 — PERFORMANCE AND FEASIBILITY ENGINEERING
15.52.1 — Compact Commitments
The system may store qualified cryptographic commitments rather than
duplicating all raw evidence at every stage.
15.52.2 — Incremental Validation
A protected validator may reevaluate only the properties requiring
current confirmation.
15.52.3 — Protected Evidence Caching
8.4.3.60. Original global source page 1368
Authenticated evidence may be cached within its permitted identity,
policy, and freshness scope.
15.52.4 — Separation of Expensive and Fast Checks
Complex evidence analysis may precede effectuation, while the
Finality Sink performs compact current authority and actual-operation
checks.
15.52.5 — Reservation Before Finality
The system may reserve bounded authority before expensive final
serialization or resource dispatch.
Das Expires 29 April 2027 [Page 189]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15.52.6 — Sink-Local Consumption
A protected resource controller may maintain efficient single-use
state.
15.52.7 — Cross-Domain Latency
Independent validation may add communication latency.
15.52.8 — Evidence Transfer Minimization
Protected digests and authenticated references may limit data
movement.
15.52.9 — Durable Consumption State
The implementation may employ transactional storage, protected
counters, or equivalent authoritative state mechanisms.
15.52.10 — Multiple Sinks
Distributed operation classes may require stronger coordination.
15.52.11 — Bounded Verification Work
Oversized evidence or graph structures may be rejected or
conservatively handled.
15.52.12 — Availability Limits
Where required current evidence or protected authority cannot be
verified, new consequential effects remain withheld.
15.52.13 — Assurance
The system must distinguish protected validation correctness,
authority uniqueness, local dispatch guarantees, and actual remote
completion.
8.4.3.61. Original global source page 1369
15.53 — OPTIONAL ADVANCED FUTURE-ORIENTED CONCEPTS
15.53.1 — Multi-Provider Autonomous Agents
Independent providers may collect, validate, and enforce operation-
specific evidence without transferring reusable complete authority to
the requesting agent.
Das Expires 29 April 2027 [Page 190]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15.53.2 — Distributed Protected Validation
Two or more protected instances may cooperate on evidence and
execution-time validation under explicit role and independence
guarantees.
15.53.3 — Confidential Computing
A protected computing environment may supply qualified evidence while
an external Finality Sink retains consequential authority.
15.53.4 — Hardware Security Modules
Protected keys and monotonic consumption state may be maintained in
dedicated security hardware.
15.53.5 — Autonomous Cloud Operations
Cloud resource effects may require current cross-domain evidence and
destination-side operation verification.
15.53.6 — Database Commit Security
A database controller may require cross-committed evidence and
operation-specific authority before mutation.
15.53.7 — Payment Infrastructure
Financial instructions may be controlled through actual recipient,
amount, authority, and consumption binding.
15.53.8 — Protected Credential Brokers
Reusable secrets may remain inaccessible to the requesting agent
while the broker performs bounded validated operations.
15.53.9 — Multi-Agent Hardware Control
Several agents may prepare operations while device-local protected
state controls actual commands.
15.53.10 — Robotics
8.4.3.62. Original global source page 1370
A physical command may require qualified collection-time context,
current independent validation, and actual actuator finality.
Das Expires 29 April 2027 [Page 191]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15.53.11 — Programmable Networks
Protected network controllers may verify evidence-to-authority
continuity before applying configuration changes.
15.53.12 — Edge and Cloud Migration
Cross-committed authority may be revalidated after workload transfer.
15.53.13 — Future Hardware Accelerators
An accelerator command path may require protected operation-bound
enablement and current sink-local state.
15.53.14 — Privacy-Preserving Evidence
Selected validation predicates may be proved without exposing all
underlying sensitive information.
15.53.15 — Threshold-Protected Authority
Suitable multi-party approval may be required before the protected
enablement controller can authorize an operation.
15.53.16 — Distributed Share-Based Finality
A system may distribute protected authority contributions among
independently protected nodes, such that no requesting agent or
single node possesses a reusable complete authority object.
15.53.17 — Hardware Resource Migration
Device reassignment may invalidate earlier evidence or finality
references.
15.53.18 — Long-Running Autonomous Workflows
Evidence and authority may retain distinct protected state across
task pauses, resumes, model changes, and agent replacements.
15.53.19 — Cryptographic Algorithm Migration
Evidence authentication and commitment primitives may be upgraded
without altering the specified evidence-to-authority relationship.
15.53.20 — Unified Protected Finality Service
Das Expires 29 April 2027 [Page 192]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.4.3.63. Original global source page 1371
A protected infrastructure component may expose collection,
validation, cross-commitment, authority, and sink-verification
interfaces across heterogeneous autonomous workloads.
These variations are proposed implementations and are not represented
as completed experimental demonstrations.
15.54 — OPTIONAL ADVANCED TECHNICAL COMBINATIONS
15.54.1 — Two Protected Instances Plus Cross-Commitment
Collection evidence and independent execution-time validation are
bound to the same specified Candidate Act.
15.54.2 — Cross-Commitment Plus Non-Bearer Enablement
A valid evidence relation supports preparation of separate operation-
specific finality authority.
15.54.3 — Evidence Receipt Plus Sink-Local State
A copied receipt remains insufficient without current protected
consumption state.
15.54.4 — Resource Binding Plus Actual Reconstruction
The Finality Sink verifies that the pending real operation matches
the authorized resource and effect.
15.54.5 — Revocation Plus Finality Generation
An earlier valid authorization becomes unusable following a protected
revocation transition.
15.54.6 — Concurrency Plus Monotonic Consumption
Multiple agents cannot validly consume one single-use operation-
specific authority more than once.
15.54.7 — Distributed Sinks Plus Shared Authority
A protected coordination mechanism prevents duplicate exercise across
relevant effectuation boundaries.
15.54.8 — Credential Release Plus Actual Operation
Das Expires 29 April 2027 [Page 193]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A protected broker activates credentials only for the qualified
operation without giving the requester unrestricted reusable secrets.
15.54.9 — Causal Receipt Plus Evidence-to-Authority
8.4.3.64. Original global source page 1372
A successor phase may require an accepted earlier real-effect receipt
in addition to its current collection and validation evidence.
15.54.10 — Quorum Approval Plus Sink Consumption
A valid collective approval remains dependent upon protected non-
bearer finality authority.
15.54.11 — Coverage Epoch Plus Cross-Commitment
A change in mandatory effectuation-path coverage invalidates affected
operation-specific authority.
15.54.12 — Hardware Ownership Plus Evidence Commitment
The actual hardware sink verifies current device identity and
ownership in addition to the cross-domain evidence chain.
15.54.13 — Privacy State Plus Disclosure Finality
Cumulative disclosure constraints are evaluated before actual
protected information release.
15.54.14 — Recovery Plus Monotonic Authority
A crashed or restarted requester cannot recreate consumed enablement.
15.55 — PROPOSED INVENTIVE-STEP ANALYSIS
15.55.1 — Established Prior Art
Digital signatures, protected audit records, remote attestation,
evidence appraisal, proof-of-possession authorization, cryptographic
commitments, transactional state, capability systems, nonce-based
freshness, and single-use authorization are established technical
areas.
The embodiment does not claim any such technique individually.
15.55.2 — Candidate Objective Technical Problem
Das Expires 29 April 2027 [Page 194]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A candidate objective technical problem is:
How to prevent independently collected and validated authorization
evidence from being misapplied as reusable consequential execution
authority across autonomous computing domains, while ensuring that
only the specific currently authorized actual operation can consume
protected finality enablement at the consequential sink.
15.55.3 — Candidate Technical Solution
The candidate technical combination includes:
8.4.3.65. Original global source page 1373
A protected collection-time evidence commitment;
A second independently protected execution-time validation;
An authenticated cross-commitment to the same Candidate Act;
A distinct non-bearer finality enablement;
A designated actual-effectuation sink;
Independent reconstruction of the pending operation;
And protected monotonic consumption.
15.55.4 — Technical Interaction
The collection stage identifies and authenticates the original
evidence context.
The independent validation stage checks relevant execution-time
conditions.
The cross-commitment prevents unrelated evidence records from being
combined without the required correspondence.
The authority controller separates an authenticated validation result
from actual permission to release a consequence.
The Finality Sink verifies the operation presented at the real
resource boundary.
The protected consumption controller prevents unsupported repeated
exercise.
Das Expires 29 April 2027 [Page 195]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The combined sequence addresses distinct sources of authorization
confusion, stale evidence, operation substitution, and replay.
15.55.5 — Not Merely a Signed Approval
A signed approval may remain authentic even when the actual operation
has changed.
The principal implementation requires current actual-operation
correspondence and separate finality enablement.
15.55.6 — Not Merely Remote Attestation
Attestation may establish evidence concerning a computing
environment.
The proposed arrangement additionally binds distinct operation-
specific validation stages to actual consequential authority and
sink-local consumption.
15.55.7 — Not Merely Proof-of-Possession
Proof of possession may constrain who can exercise a token.
8.4.3.66. Original global source page 1374
The proposed stronger implementation may avoid exposing any reusable
complete authority object to the requester and require protected
effect-specific consumption.
15.55.8 — Not Merely a Cross-Signed Receipt
Multiple signatures may authenticate multiple statements.
The system additionally requires their operation-specific
correspondence and an independently enforced authority transition.
15.55.9 — Not Merely Transactional Logging
A transaction log may record protected local state.
The proposed architecture binds the state to independent evidence and
actual operation-specific finality.
15.55.10 — Not Merely a Single-Use Token
Single-use credentials and transactional counters are established.
Das Expires 29 April 2027 [Page 196]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The candidate combination requires corresponding collected and
independently validated evidence, actual resource reconstruction, and
sink-local finality.
15.55.11 — Candidate Narrow Inventive Kernel
A protected autonomous execution system in which collection-time
evidence from a first protected instance is independently evaluated
by a second protected instance, the resulting evidence is cross-
committed to a specified Candidate Act, separate scoped non-bearer
finality enablement is established, and an independent Finality Sink
reconstructs the actual pending consequential operation and refuses
effectuation unless the required evidence, current authority, actual-
operation correspondence, and protected monotonic consumption
predicates are satisfied.
15.55.12 — Additional Non-Bearer Kernel
A narrower combination may require that the requester never obtains a
reusable complete authority object and that protected sink-local
state remains an indispensable enabling condition.
15.55.13 — Additional Cross-Domain Kernel
Another candidate may require independently administered collection
and validation domains having distinct protected identities and
explicitly authenticated evidence continuity.
15.55.14 — Additional Concurrency Kernel
Another candidate may require operation-specific authority consumed
under an authoritative atomic generation transition that prevents
concurrent duplicate exercise.
8.4.3.67. Original global source page 1375
15.55.15 — Additional Hardware Kernel
Another candidate may require a device command sink to verify cross-
committed evidence and hardware-local protected consumption before
effectuation.
15.55.16 — Hindsight Considerations
Das Expires 29 April 2027 [Page 197]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A proper inventive-step analysis should determine whether the closest
prior-art systems already disclose or make obvious the stated
combination of cross-domain evidence, protected validation,
capability activation, actual resource enforcement, and monotonic
consumption.
The individual use of known cryptographic or transactional mechanisms
is insufficient to establish inventive step.
Any proposed non-obviousness argument should identify the precise
technical dependency and result not supplied by the closest prior
art.
15.55.17 — Patentability Qualification
A newly named evidence record or capability does not independently
establish novelty.
Claim breadth must correspond to the exact technical requirements and
enabling disclosure.
The architecture does not establish universal exactly-once external
effects or resistance to compromise of every privileged component.
15.56 — INDUSTRIAL APPLICABILITY
15.56.1 — Enterprise Autonomous Agents
Agent-generated external operations may require protected cross-
domain evidence and independent finality.
15.56.2 — Cloud Infrastructure
Distributed workloads may prepare operations while resource
controllers retain current consequential authority.
15.56.3 — Cross-Provider AI Services
Independent administrative services may exchange authenticated
validation evidence without unrestricted credential delegation.
15.56.4 — Database Systems
Protected transaction controllers may verify current actual mutations
and consume operation-specific authority.
Das Expires 29 April 2027 [Page 198]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.4.3.68. Original global source page 1376
15.56.5 — File and Storage Systems
File commits and storage exports may require independent validation
and non-replayable finality.
15.56.6 — Financial Transactions
Payments and account operations may require current resource,
recipient, amount, and evidence-bound authorization.
15.56.7 — Electronic Commerce
Automated purchasing and fulfillment operations may be controlled
through distinct validated consequential authority.
15.56.8 — Credential Security
A protected broker may exercise limited credentials only for an
independently validated operation.
15.56.9 — Network Infrastructure
Autonomous network configuration changes may be subject to cross-
committed validation and device-side enforcement.
15.56.10 — Telecommunications
Distributed control-plane effects may be authorized through protected
evidence and resource-bound finality.
15.56.11 — Industrial Automation
Device commands may require collection-time context, independent
current validation, and actual hardware finality.
15.56.12 — Robotics
Autonomous physical effects may remain withheld until current
resource and command authority are verified.
15.56.13 — Autonomous Transportation
Selected consequential controller instructions may be governed
through independent evidence and effectuation authorization.
15.56.14 — Hardware Accelerators
Das Expires 29 April 2027 [Page 199]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Accelerator-originated effects may require protected command and
resource authority.
15.56.15 — Edge Computing
8.4.3.69. Original global source page 1377
Remote and edge devices may participate in cross-domain evidence
processing under bounded finality authority.
15.56.16 — Confidential Computing
Protected execution environments may provide evidence while separate
resource sinks control real external operations.
15.56.17 — Information Disclosure
Actual protected data release may require independent validation and
current sink-local privacy authority.
15.56.18 — Remote Equipment
Intermittently connected systems may employ bounded protected
authority and durable monotonic state under stated assumptions.
15.56.19 — Long-Running Autonomous Workflows
Pending Candidate Acts may be revalidated after model replacement,
runtime updates, or task migration.
15.56.20 — Future Heterogeneous Systems
Cross-domain evidence and actual resource finality may govern
emerging software, device, communication, and hardware execution
environments.
The industrial utility lies in establishing an enforceable technical
separation between computation, evidence, validation, and actual
authority to produce consequential effects.
15.57 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
15.57.1 — Candidate Independent System Claim
A system may comprise:
A first protected evidence-collection instance configured to
establish authenticated collection-time evidence for a Candidate Act;
Das Expires 29 April 2027 [Page 200]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A second independently protected validation instance configured to
evaluate the collection evidence and current execution-time
conditions;
A protected cross-commitment controller configured to bind the
evidence stages to the same consequential operation;
A finality authority controller configured to establish scoped non-
bearer enablement dependent upon the cross-committed validation
state;
8.4.3.70. Original global source page 1378
And a Finality Sink configured to reconstruct the actual pending
operation, verify the required evidence and current authority, and
conditionally consume the protected enablement before permitting the
real consequence.
15.57.2 — Candidate Independent Method Claim
A method may comprise:
Constructing a consequential Candidate Act;
Withholding its effect;
Collecting qualified evidence in a first protected instance;
Independently validating required conditions in a second protected
instance;
Establishing a cross-commitment to the Candidate Act;
Preparing operation-specific non-bearer finality enablement;
Reconstructing the actual pending effect at the Finality Sink;
Verifying the evidence, current authority, and actual-operation
correspondence;
And performing a protected monotonic consumption transition before
permitting consequential release.
15.57.3 — Candidate Independent Cross-Domain Claim
A candidate may require protected collection and validation domains
having separately authenticated roles, with cross-committed evidence
and destination-side finality enforcement.
Das Expires 29 April 2027 [Page 201]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15.57.4 — Candidate Independent Hardware Claim
A hardware apparatus may require current cross-committed validation
evidence and locally protected consumption before permitting an
effect-capable command.
15.57.5 — Candidate Independent Non-Bearer Claim
Another candidate may require that no reusable complete effectuation
authority object be available to the requester and that protected
sink-local state remain indispensable for releasing the actual
operation.
These candidates may overlap and should be assessed for technical
unity and claim breadth.
15.58 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
Dependent aspect 1: The Candidate Act is maintained in Non-Effective
State.
8.4.3.71. Original global source page 1379
Dependent aspect 2: The first protected instance possesses an
authenticated identity.
Dependent aspect 3: Collection evidence is bound to the Candidate
Act.
Dependent aspect 4: Collection evidence includes source-authority
state.
Dependent aspect 5: Collection evidence includes protected resource
identity.
Dependent aspect 6: Collection evidence includes a collection nonce
or generation.
Dependent aspect 7: The second protected instance possesses a
distinct authenticated validation role.
Dependent aspect 8: The second protected instance verifies the first
instance's authorized collection role.
Dependent aspect 9: Execution-time validation includes current
resource conditions.
Das Expires 29 April 2027 [Page 202]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Dependent aspect 10: Execution-time validation includes current
policy and revocation.
Dependent aspect 11: The system verifies the independence properties
required between protected instances.
Dependent aspect 12: The validation result binds to the collection
evidence commitment.
Dependent aspect 13: The system creates an authenticated cross-
evidence commitment.
Dependent aspect 14: The cross-commitment identifies one Candidate
Act.
Dependent aspect 15: The cross-commitment identifies the designated
Finality Sink.
Dependent aspect 16: A policy epoch mismatch requires revalidation or
a protected compatibility determination.
Dependent aspect 17: Missing mandatory evidence prevents finality
enablement.
Dependent aspect 18: A signed collection receipt alone cannot
activate the effect.
Dependent aspect 19: A signed validation receipt alone cannot
activate the effect.
Dependent aspect 20: A cross-commitment alone does not provide
unrestricted executable authority.
Dependent aspect 21: The finality controller establishes a distinct
protected enablement record.
Dependent aspect 22: The enablement is bound to an actual resource.
Dependent aspect 23: The enablement is bound to an authorized
operation descriptor.
8.4.3.72. Original global source page 1380
Dependent aspect 24: The enablement is bound to a designated sink.
Dependent aspect 25: The enablement is bound to a protected
consumption generation.
Das Expires 29 April 2027 [Page 203]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Dependent aspect 26: The requester receives an inert authority
reference rather than a reusable complete authority object.
Dependent aspect 27: A protected credential broker prevents release
of reusable broad resource credentials.
Dependent aspect 28: The Finality Sink reconstructs the actual
pending operation.
Dependent aspect 29: The sink obtains the actual resource identity.
Dependent aspect 30: The sink verifies actual operation
correspondence with the cross-committed Candidate Act.
Dependent aspect 31: The sink verifies current source authorization.
Dependent aspect 32: The sink verifies current policy and revocation.
Dependent aspect 33: The sink verifies the independent validation
evidence.
Dependent aspect 34: The sink verifies protected finality enablement.
Dependent aspect 35: The sink verifies sink-local consumption state.
Dependent aspect 36: A single-use authority is consumed through an
atomic protected state transition.
Dependent aspect 37: Protected consumption state includes a monotonic
generation.
Dependent aspect 38: A copied authority cannot be exercised after
consumption.
Dependent aspect 39: Concurrent requests cannot independently consume
one single-use allowance under the applicable authoritative
coordination model.
Dependent aspect 40: Snapshot rollback cannot restore consumed
authority.
Dependent aspect 41: The system maintains durable protected
authority-consumption records.
Dependent aspect 42: Cross-sink consumption requires shared
authoritative state or nonoverlapping bounded allocations.
Das Expires 29 April 2027 [Page 204]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Dependent aspect 43: A resource-version change may require fresh
validation.
Dependent aspect 44: A changed operation requires appropriate
evidence rebinding.
Dependent aspect 45: A materially expanded effect requires new source
authority.
8.4.3.73. Original global source page 1381
Dependent aspect 46: A revoked original authorization invalidates
pending finality enablement.
Dependent aspect 47: The system distinguishes protected authority
consumption from external effect completion.
Dependent aspect 48: An uncertain external outcome prevents
unsupported automatic authority restoration.
Dependent aspect 49: A retry is conditioned upon current protected
recovery authority.
Dependent aspect 50: A dependent successor phase requires an accepted
prior actual-effect receipt where the applicable causal protocol
requires it.
Dependent aspect 51: Collection and validation may occur across
independent administrative domains.
Dependent aspect 52: Evidence may be transported through
authenticated protected references.
Dependent aspect 53: Privacy-sensitive evidence may be represented
through qualified commitments rather than full raw-data disclosure.
Dependent aspect 54: A protected hardware component maintains
finality consumption state.
Dependent aspect 55: A device command sink checks current hardware
ownership.
Dependent aspect 56: A data-release sink checks current recipient and
information scope.
Dependent aspect 57: A transaction sink checks actual payment or
database mutation parameters.
Das Expires 29 April 2027 [Page 205]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Dependent aspect 58: A current effectuation coverage condition
remains mandatory where selected.
Dependent aspect 59: A current model or algorithmic-generation
condition remains mandatory where selected.
Dependent aspect 60: A quorum approval remains separate from finality
consumption where collective authorization applies.
Dependent aspect 61: The collector and validator may operate in
distinct protected computing environments.
Dependent aspect 62: Evidence and enablement may be protected without
using a blockchain.
Dependent aspect 63: Evidence validation is subject to bounded
computational work.
8.4.3.74. Original global source page 1382
Dependent aspect 64: The system preserves current authority after
controlled cryptographic key migration subject to appropriate
revalidation.
These features provide optional technical support for later claim
construction and do not establish individual novelty.
15.59 — NON-LIMITING IMPLEMENTATION AND COMBINATION CLAUSE
The disclosed collection, validation, cross-commitment, enablement,
and consumption mechanisms may be implemented individually or in
technically compatible combinations.
A particular implementation may use two independently protected
software domains.
Another may employ protected hardware and software instances.
Another may use independently administered cloud or edge services.
Another may employ a protected credential broker.
Another may integrate the actual Finality Sink with a resource
transaction controller.
Another may distribute protected authority contributions across
several participating nodes without providing the requester or any
single node with reusable complete authority.
Das Expires 29 April 2027 [Page 206]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Where a selected claim requires independent first and second
protected validation instances, the corresponding implementation must
maintain that independence under its stated trust model.
Where a selected claim requires sink-local monotonic consumption, the
implementation must provide an authoritative consumption primitive
satisfying the claimed concurrency and rollback conditions.
Unless expressly required by a selected claim, no specific hash
algorithm, digital signature, secure processor, communication
protocol, data structure, cryptographic key arrangement, database
system, operating-system facility, or hardware substrate is
universally mandatory.
The pseudocode, equations, state machines, examples, experiments, and
technical architectures are illustrative and non-limiting.
They are intended to assist a person having ordinary skill in the art
in understanding and implementing the disclosed mechanisms.
Compatible modules from other embodiments may be combined where
adequately supported.
A cross-reference to another embodiment does not automatically make
every aspect of that embodiment mandatory.
A collection-time receipt does not automatically establish execution-
time validity.
8.4.3.75. Original global source page 1383
An execution-time validation result does not automatically establish
actual external effect completion.
A signed approval does not automatically become a reusable execution
credential.
A protected capability reference does not automatically create valid
finality authority through possession alone.
An accepted CW-2 actual-effect receipt remains a distinct causally
significant authority input wherever the selected successor protocol
requires it.
A single-use local authority transition does not automatically
guarantee exactly-once completion by an uncontrolled external
recipient.
Das Expires 29 April 2027 [Page 207]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
No experiment is represented as completed merely because an expected
result is stated.
Future-oriented examples are proposed technical variations rather
than claims of completed deployment.
15.60 — FINAL TECHNICAL SUMMARY AND PROPOSED INVENTIVE-STEP
CHARACTERIZATION
The present Embodiment 15 discloses a protected autonomous execution-
finality architecture that separates authenticated evidence from
authority to produce an actual consequential effect.
An autonomous entity may prepare a Candidate Act under original
source authority.
The proposed operation remains non-effective.
A first protected collection instance establishes authenticated
evidence concerning the Candidate Act and relevant collection-time
conditions.
A second independently protected validation instance verifies the
necessary collection evidence and current execution-time predicates.
The protected system establishes a cross-commitment binding these
evidence stages to the specified operation, resource, source
authority, policy, and designated Finality Sink.
A protected controller may then prepare operation-specific non-bearer
finality enablement.
The requesting entity may receive an evidence receipt or opaque
enablement reference without obtaining a reusable complete authority
object.
Before consequential release, the Finality Sink independently obtains
or reconstructs the actual pending operation.
8.4.3.76. Original global source page 1384
The sink verifies collection and validation evidence, the cross-
commitment, current source authority, actual resource and effect
scope, current policy, revocation, and protected enablement state.
A protected monotonic consumption transition prevents unauthorized
replay or concurrent duplicate use of the corresponding finality
authority.
Das Expires 29 April 2027 [Page 208]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Where the sink controls a suitable transactional resource, authority
consumption and the resource effect may be committed atomically.
Where external effectuation is not covered by the same transaction,
the system distinguishes consumed local authorization, attempted
external dispatch, and qualified actual external completion.
A lost acknowledgement does not automatically restore consumed
authority.
A valid historical validation receipt does not override current
revocation.
A copied capability reference does not automatically grant another
executable effect.
A signed-looking but untrusted evidence record is not sufficient.
The architecture may be implemented across autonomous agents, cloud
services, financial infrastructure, databases, hardware devices,
network controllers, robotics, confidential computing, and other
protected consequential systems.
The embodiment does not claim the individual invention of signatures,
attestation, evidence appraisal, nonce-based replay protection,
capability systems, transactional state, or sender-constrained
tokens.
Its candidate contribution lies in the mandatory technical
relationship between independently protected evidence stages, cross-
committed operation-specific validation, separate non-bearer finality
authority, actual operation reconstruction, and authoritative sink-
local consumption.
The principal candidate inventive technical concept of Embodiment 15
is a protected cross-domain evidence-to-effectuation architecture in
which collection-time evidence from a first protected instance is
independently validated by a second protected instance, the
respective evidence states are cross-committed to one specified
Candidate Act, scoped non-bearer finality authority is established
separately from those evidence records, and a designated Finality
Sink independently reconstructs the actual pending operation and
refuses consequential effectuation unless the required evidence
correspondence, current authority, actual effect binding, and
protected monotonic consumption conditions are satisfied.
Das Expires 29 April 2027 [Page 209]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Novelty, inventive step, unity, and permissible claim breadth remain
subject to relevant prior-art examination and the enabling technical
disclosure actually filed.
END OF EMBODIMENT 15 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 16
8.5. Embodiment 16: Crash-Consistent Finality Journaling and
Indeterminate Outcome Reconciliation
Original source global pages 1385-1465. Preserved for technical
discoverability and traceability; consult the cited full Zenodo
document for complete source context. This part primarily
concentrates on evidence binding, scope, non-bearer authority and
protected journal consumption; other documents provide specialized
enforcement, device handoff and actual effect receipt details.
8.5.1. Architecture and Protected Trust Boundaries
[Qualified Candidate Act]-->[Protected effect intent]
| |
[Scoped finality] [Monotonic journal]
| |
[Sink]---------------[Consumption fence]
| |
[Actual remote effect]---[Outcome observation]
|
[Confirmed / indeterminate]
Figure 20: Embodiment 16: Crash-Consistent Finality Journaling
and Indeterminate Outcome Reconciliation — Protected Architecture
8.5.2. Operational Decisions and Fail-Closed State Transitions
[Prepared effect / durable state]
|
<Authority fresh and unconsumed?>--NO-->[Reject]
|YES
[Durable protected consumption]
|
[Effect dispatch]
|
<Qualified actual outcome?>--YES-->[Commit outcome]
|NO
[Indeterminate: no blind replay]
|
[Qualified reconciliation / separate recovery act]
Das Expires 29 April 2027 [Page 210]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Figure 21: Embodiment 16: Crash-Consistent Finality Journaling
and Indeterminate Outcome Reconciliation — Decision Flowchart
8.5.3. Page-Indexed Original Technical Disclosure
8.5.3.1. Original global source page 1385
CRASH-CONSISTENT EXECUTION-FINALITY JOURNALING, EXACTLY-ONCE
AUTHORIZATION, AND INDETERMINATE EXTERNAL-OUTCOME RECONCILIATION WITH
DURABLE EFFECT-INTENT COMMITMENTS, MONOTONIC AUTHORITY CONSUMPTION,
RECEIVER-SIDE DUPLICATE FENCING, AND INDEPENDENT ACTUAL-EFFECT
VERIFICATION
16.0 — COMPLETE TECHNICAL TITLE
Systems and Methods for Crash-Consistent Autonomous Consequential
Execution Using Authenticated Write-Ahead Finality Journals, Durable
Operation-Specific Authority Consumption, Protected Dispatch-Intent
Commitments, Monotonic Recovery Generations, Receiver-Bound Duplicate
Suppression, Qualified External-Effect Outcome Evidence,
Indeterminate-Result Fencing, and Independent Finality-Sink
Verification of Actual Pending Operations
16.0.1 — General Technical Description
The present Embodiment 16 discloses systems, methods, apparatus,
protected computing components, authenticated journaling protocols,
machine-verifiable operation-state representations, cryptographic and
non-cryptographic enforcement mechanisms, protected transaction-state
transitions, durable authority-consumption procedures, and non-
limiting implementations for governing consequential operations
across process crashes, system restarts, network interruptions,
storage recovery, workload migration, partial execution, duplicate
submissions, and uncertain external outcomes.
The computational entities may include artificial-intelligence
agents, autonomous assistants, distributed service processes,
transaction processors, payment controllers, cloud workloads,
database services, operating-system components, network controllers,
robotic systems, industrial equipment, embedded devices, hardware
accelerators, or other entities capable of initiating consequential
operations.
Such operations may include persistent data mutation, payment
submission, message transmission, credential activation, file export,
network configuration, storage commit, protected information
disclosure, physical actuation, device-command execution, or another
externally effective operation.
Das Expires 29 April 2027 [Page 211]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
An operation may be validly authorized before an interruption occurs.
However, the interruption may occur at any point between validation,
protected authority consumption, dispatch preparation, actual
effectuation, destination processing, acknowledgement, and final
outcome recording.
The requesting entity may subsequently restart with incomplete or
stale information.
A software exception, timeout, or missing acknowledgement does not
necessarily establish that the underlying effect failed.
An authenticated journal entry recording an intended operation does
not necessarily establish that the operation occurred.
8.5.3.2. Original global source page 1386
A protected record establishing consumption of authority does not
necessarily establish that a remote recipient processed the
corresponding request.
A valid receiver acknowledgement may establish only the properties
supported by the receiving system's authenticated observation or
transaction state.
The present embodiment therefore establishes a protected distinction
among:
Authorization eligibility;
Durable operation preparation;
Protected finality consumption;
Durable dispatch intent;
Actual release or dispatch;
Receiver-side acceptance;
Qualified effect completion;
And unresolved or indeterminate outcomes.
In a principal implementation, a protected Finality Sink reconstructs
the actual pending consequential operation and validates current
operation-specific authority.
Das Expires 29 April 2027 [Page 212]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Before permitting the effect, the sink establishes an authenticated
durable journal state that binds the operation, its validation
evidence, its protected authority-generation state, and its
applicable effectuation boundary.
A monotonic authority-consumption transition ensures that one
specified single-use finality enablement cannot be independently
consumed more than once.
Where the resource mutation and authority consumption share an
appropriately protected transactional domain, the system may commit
both within one atomic transition.
Where the actual effect requires a separate external destination, the
system employs a protected dispatch-intent and outcome-reconciliation
protocol.
The external operation may be associated with a stable authenticated
operation identifier and a qualified receiver-side duplicate-
suppression mechanism where available.
If the external outcome becomes uncertain, the system preserves the
relevant consumed authority and establishes a retry fence.
A new effect is not automatically authorized merely because the
sender failed to receive acknowledgement.
8.5.3.3. Original global source page 1387
The system may obtain qualified destination evidence, invoke a
supported idempotent retry procedure, or require a separately
authorized recovery Candidate Act.
16.0.2 — Fundamental Technical Principle
The right to attempt an effect once is not proof that the effect
occurred once.
The following are technically distinct properties:
An operation was authorized.
The authorization was consumed.
The operation was durably prepared for dispatch.
The operation was dispatched.
Das Expires 29 April 2027 [Page 213]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A destination accepted the operation.
The destination committed the intended mutation.
A physical consequence occurred.
An acknowledgement was received.
And the final outcome was independently established.
The system must not silently treat these states as interchangeable.
16.0.3 — Principal Proposed Inventive Concept
The principal candidate inventive combination comprises:
A specified consequential Candidate Act;
A protected actual-operation descriptor;
Authenticated validation evidence;
An operation-specific non-bearer finality enablement;
A protected durable finality journal;
An authoritative monotonic consumption generation;
A durable dispatch-intent and effect-attempt relationship;
A defined effectuation boundary;
A qualified receiver or external-observation mechanism;
8.5.3.4. Original global source page 1388
An indeterminate-outcome state;
A protected retry or recovery fence;
And independent verification before any further consequential
effectuation.
The proposed technical interaction ensures that an interruption
cannot automatically transform an earlier consumed authorization,
unresolved dispatch, or stale journal copy into fresh permission to
perform another real-world effect.
Das Expires 29 April 2027 [Page 214]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
16.0.4 — Distinction Between Local and External Guarantees
The embodiment expressly separates at least three classes of
guarantee.
Local authorization uniqueness: An authoritative protected controller
allows only the specified permitted number of finality-consumption
transitions.
Local transactional effect atomicity: Where the protected resource
mutation and finality consumption belong to one atomic transaction
domain, both may be committed or rejected together.
External outcome guarantee: Where the effect occurs in a distinct
resource, service, or physical system, the guarantee depends upon
destination-side controls and qualified observation.
Exactly-once local authority consumption does not by itself establish
exactly-once external processing.
16.0.5 — Established Techniques
Write-ahead logging, idempotency, duplicate suppression, durable
transaction journals, transactional outbox processing, replay-
resistant identifiers, and receiver-side transaction records are
established mechanisms.
The present embodiment does not claim their original invention.
Its candidate contribution concerns the protected dependency between
the actual Finality-Sink operation, evidence-qualified authority,
durable consumption, dispatch-state continuity, and indeterminate-
outcome handling.
16.0.6 — Relationship to Common Workflows
The embodiment may incorporate the Candidate Act, Non-Effective
State, Protected Enforcement Domain, independent evidence validation,
scoped non-bearer finality authority, actual-operation
reconstruction, and Finality Sink mechanisms of CW-1.
Where a dependent successor operation requires a qualified earlier
real effect, the accepted identity-authenticated actual-effect
receipt of CW-2 remains a constitutive authority input.
A durable journal entry recording a dispatch attempt does not replace
such a receipt.
Das Expires 29 April 2027 [Page 215]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.5.3.5. Original global source page 1389
Optional CW-3 reauthorization may apply when retry, repair,
compensation, or resumed execution materially changes the permitted
operation.
16.0.7 — Relationship to Earlier Embodiments
Embodiment 1 may control conflicting effects.
Embodiment 2 may require accepted evidence of an earlier completed
effect before causal continuation.
Embodiments 3 and 4 may verify actual targets and externally observed
consequences.
Embodiment 5 may constrain resource expenditure during repeated or
delayed execution.
Embodiment 6 may verify current tool and command semantics.
Embodiment 7 may preserve operation authority across delegated
domains.
Embodiment 8 may prevent duplicate or cumulative unauthorized privacy
disclosures.
Embodiment 9 may establish current hardware ownership.
Embodiment 10 may control executable-generation validity.
Embodiment 11 may provide version-bound reservations and protected
concurrent mutations.
Embodiment 12 may govern the authority to choose and perform
corrective recovery operations.
Embodiment 13 may supply qualified collective authorization.
Embodiment 14 may establish current mandatory effectuation-path
coverage.
Embodiment 15 may establish the cross-committed evidence and non-
bearer authority whose durable consumption is governed here.
Miscellaneous Embodiment M-1 may supply optional protected state,
infrastructure, and dynamic enforcement modules.
Das Expires 29 April 2027 [Page 216]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The present embodiment develops the persistence, crash atomicity,
receiver-side coordination, and outcome-uncertainty treatment of
consequential finality, without modifying the earlier embodiments.
16.1 — TECHNICAL FIELD
The invention relates to crash-consistent autonomous execution,
protected transaction journals, secure distributed systems, durable
authority state, resource mutation protocols, authenticated external-
effect evidence, replay-resistant authorization, distributed
effectuation,
8.5.3.6. Original global source page 1390
idempotency, non-bearer capabilities, hardware command control, and
execution-finality security.
More specifically, the invention concerns preventing an uncertain
earlier effectuation attempt from causing unauthorized repeated
consequential operations following failures, retries, reconnections,
and restarts.
16.2 — SPECIFIC TECHNICAL PROBLEMS
16.2.1 — Crash Before Authority Consumption
The system may fail before a finality enablement is durably consumed.
16.2.2 — Crash During Consumption
A requester may not know whether the protected consumption transition
committed.
16.2.3 — Crash After Consumption but Before Dispatch
Authority may be consumed although the consequential effect has not
been transmitted.
16.2.4 — Crash During External Dispatch
Only part of an operation may have been transmitted or accepted.
16.2.5 — Crash After Destination Processing
The destination may complete the operation while the sender remains
unaware.
16.2.6 — Lost Acknowledgement
Das Expires 29 April 2027 [Page 217]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A communication failure may conceal successful external processing.
16.2.7 — Duplicate Client Retry
An autonomous agent may submit the same operation again.
16.2.8 — Duplicate Queue Delivery
A messaging system may deliver the same committed event more than
once.
16.2.9 — Duplicate Recovery Worker
Several restarted processes may attempt to resume the same operation.
16.2.10 — Stale Snapshot
A restored workload may contain an earlier apparently unconsumed
authorization reference.
8.5.3.7. Original global source page 1391
16.2.11 — Journal Rollback
An attacker may attempt to restore a previous journal state.
16.2.12 — Journal Reordering
A storage or software fault may present effect records in an
incorrect causal or protected sequence.
16.2.13 — Torn Journal Write
A power failure may interrupt a multi-field journal update.
16.2.14 — Delayed Storage Durability
An application may receive a write success indication before the
required durable persistence guarantee is actually satisfied.
16.2.15 — Dual-Write Failure
A protected consumption record may commit while the external dispatch
record is lost, or vice versa.
16.2.16 — Idempotency Key Collision
Das Expires 29 April 2027 [Page 218]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Different operations may share an identifier without matching
parameters.
16.2.17 — Idempotency Retention Expiry
A receiver may discard duplicate-suppression state before a later
retry.
16.2.18 — Receiver State Rollback
A destination may lose the record establishing that an operation
already took effect.
16.2.19 — Receiver-Side Partial Mutation
A receiver may durably record an operation identifier but fail before
the corresponding resource mutation, or perform a mutation without
retaining the identifier.
16.2.20 — Partitioned Finality Controllers
Different controllers may believe the same authority remains
available.
16.2.21 — Delayed Former Leader
An old coordinator may resume and attempt execution after leadership
has transferred.
16.2.22 — Operation Parameter Substitution
8.5.3.8. Original global source page 1392
A retry may use the original operation identifier with different
actual parameters.
16.2.23 — Changed Resource State
The target may have changed since the original validation.
16.2.24 — Actual Effect Without Confirmed Receipt
An operation may physically occur without producing reliable machine-
readable completion evidence.
16.2.25 — Irreversible Effect
Das Expires 29 April 2027 [Page 219]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A completed information disclosure or physical operation may not be
safely repeated or undone.
16.2.26 — Technical Objective
A candidate objective technical problem is:
How to preserve operation-specific protected execution authority and
prevent unsupported repeat consequential effects across crashes,
retries, partitions, and uncertain remote outcomes by durably binding
actual Finality-Sink operations to monotonic consumption and
dispatch-intent state, and requiring qualified outcome reconciliation
or independently valid recovery authority before further
effectuation.
16.3 — ESTABLISHED TECHNIQUES AND THEIR LIMITATIONS
16.3.1 — Write-Ahead Logging
A database or transactional service may durably record information
before applying a mutation.
Write-ahead logging is established.
A local log does not automatically prove that an external recipient
performed an operation.
16.3.2 — Transactional Outbox
An application may atomically commit business state and an outbound
event to one local transaction domain.
This is established.
The later relay may still deliver a message multiple times.
16.3.3 — Inbox Deduplication
8.5.3.9. Original global source page 1393
A receiver may record identifiers of previously processed messages.
Such techniques are established.
Their correctness depends upon how the duplicate record is coupled to
the actual mutation.
16.3.4 — Idempotency Keys
Das Expires 29 April 2027 [Page 220]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A client may associate repeated requests with a stable logical
operation identifier.
Idempotency keys are established.
A key alone does not guarantee that the receiver durably enforces the
intended semantics.
16.3.5 — Distributed Consensus
A replicated state machine may establish authoritative transaction or
consumption ordering.
Consensus is established.
It does not automatically make a separate external physical
consequence atomic with the replicated decision.
16.3.6 — Two-Phase Commit
Distributed transaction systems may coordinate prepare and commit
phases across participating resources.
This is established.
Its guarantees require suitable participant support, durability, and
failure assumptions.
16.3.7 — Transactional Message Processing
Messaging infrastructure may provide defined delivery, processing, or
transaction guarantees.
The protection must identify the precise covered scope.
16.3.8 — Retry With Backoff
A client may delay repeated attempts.
Such delay does not establish that an earlier effect failed.
16.3.9 — Checkpoint and Restore
A runtime may restore computational state from a checkpoint.
The restored workload must not automatically recreate consumed
consequential authority.
Das Expires 29 April 2027 [Page 221]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.5.3.10. Original global source page 1394
16.3.10 — Candidate Technical Distinction
The proposed technical relationship connects actual-effect
reconstruction, evidence-qualified authority consumption, durable
dispatch-state continuity, and receiver or observer outcome
reconciliation so that the recovery protocol cannot infer new
execution permission from an unresolved earlier effect.
16.4 — PRINCIPAL SYSTEM ARCHITECTURE
A representative implementation comprises:
An Authenticated Candidate Act Controller;
An Actual Operation Reconstruction Component;
An Operation-Specific Evidence Verifier;
A Protected Finality Authority Controller;
A Durable Finality Journal;
A Monotonic Authority Consumption Controller;
A Protected Dispatch-Intent Controller;
A Consequential Effectuation Sink;
An Optional Receiver-Side Operation Registry;
A Qualified Outcome Evidence Collector;
An Indeterminate Outcome Reconciliation Controller;
And a Protected Recovery Fencing Service.
Optional components may include a transaction coordinator, outbox
dispatcher, inbox controller, protected storage module, hardware
monotonic counter, replicated state machine, device command
controller, distributed lease service, clock or epoch controller, and
independent real-effect validator.
16.4.1 — Authority Controller
Determines whether the actual operation has valid current non-bearer
finality enablement.
Das Expires 29 April 2027 [Page 222]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
16.4.2 — Journal
Retains durable authenticated evidence concerning authority and
dispatch state transitions.
8.5.3.11. Original global source page 1395
16.4.3 — Consumption Controller
Prevents unauthorized reuse of operation-specific finality authority.
16.4.4 — Dispatch Controller
Maintains a durable relationship between consumed authority and the
external operation attempt.
16.4.5 — Receiver Registry
Where supported, associates received operation identifiers with
actual destination-side processing.
16.4.6 — Outcome Verifier
Determines what can be established concerning the external
consequential result.
16.4.7 — Reconciliation Controller
Preserves uncertainty and restricts further effectuation until safe
continuation conditions are established.
16.5 — BROAD TECHNICAL DEFINITIONS
16.5.1 — Journal-Governed Candidate Act
A Journal-Governed Candidate Act, or JGCA, means a consequential
Candidate Act whose effectuation is governed by protected durable
authority and dispatch state.
16.5.2 — Protected Finality Journal
A Protected Finality Journal, or PFJ-16, means authenticated durable
state representing relevant finality preparation, consumption,
dispatch, and outcome transitions.
16.5.3 — Finality Journal Entry
Das Expires 29 April 2027 [Page 223]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A Finality Journal Entry, or FJE-16, means a protected record
describing a specified operation-state transition.
16.5.4 — Protected Journal Sequence
A Protected Journal Sequence, or PJS-16, means a protected ordering
or generation relation among applicable journal records.
16.5.5 — Durable Finality Preparation
8.5.3.12. Original global source page 1396
Durable Finality Preparation means a protected persisted state
establishing that a particular operation is eligible for a defined
subsequent finality transition.
16.5.6 — Durable Authority Consumption
Durable Authority Consumption means an authoritative persistent
transition committing permitted finality use under applicable
protected state.
16.5.7 — Monotonic Consumption Generation
A Monotonic Consumption Generation, or MCG-16, means a protected
generation that prevents stale or consumed authority from being
restored through unauthorized rollback.
16.5.8 — Protected Dispatch Intent
Protected Dispatch Intent, or PDI-16, means durable authenticated
state establishing the specific operation a controlled dispatcher may
attempt.
16.5.9 — Dispatch Intent Commitment
A Dispatch Intent Commitment, or DIC-16, means a protected commitment
binding the actual operation, finality authority consumption,
intended destination, and dispatch identity.
16.5.10 — Protected Effect Attempt
A Protected Effect Attempt, or PEA-16, means a qualified recorded
attempt to release the specified consequential operation.
16.5.11 — Effect Attempt Identifier
Das Expires 29 April 2027 [Page 224]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
An Effect Attempt Identifier, or EAI-16, means a protected reference
identifying a particular dispatch attempt.
16.5.12 — Logical Effect Identifier
A Logical Effect Identifier, or LEI-16, means a stable authenticated
identifier representing the intended single logical consequence
across permitted retries.
16.5.13 — Receiver-Side Effect Registry
A Receiver-Side Effect Registry, or RSER, means authoritative
receiving-resource state associating logical operation identifiers
with applicable acceptance or mutation outcomes.
16.5.14 — Receiver Duplicate Fence
A Receiver Duplicate Fence, or RDF-16, means a receiver-enforced
restriction preventing unauthorized repeated application of the same
logical operation.
16.5.15 — Receiver Commit Evidence
8.5.3.13. Original global source page 1397
Receiver Commit Evidence, or RCE-16, means authenticated evidence
concerning a receiving resource's specified actual processing or
mutation state.
16.5.16 — Protected Outcome Classification
Protected Outcome Classification, or POC-16, means an authenticated
determination concerning a specified actual effect outcome.
16.5.17 — Indeterminate Effect State
Indeterminate Effect State, or IES-16, means authoritative state
indicating that actual completion or non-effectuation cannot be
sufficiently established.
16.5.18 — Indeterminate Outcome Fence
An Indeterminate Outcome Fence, or IOF-16, means a protected
restriction preventing unsafe additional effectuation while the
earlier outcome remains unresolved.
16.5.19 — Protected Retry Eligibility
Das Expires 29 April 2027 [Page 225]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Protected Retry Eligibility means a verified condition under which
another attempt of a specified logical operation is permitted.
16.5.20 — Protected Retry Lease
A Protected Retry Lease, or PRL-16, means bounded authority to
perform a specified retry subject to protected generation,
destination, and validity constraints.
16.5.21 — Receiver Retention Commitment
A Receiver Retention Commitment, or RRC-16, means qualified
information concerning the period or condition under which the
receiver preserves the applicable duplicate-suppression state.
16.5.22 — Protected Outcome Witness
A Protected Outcome Witness, or POW-16, means an authorized observer
supplying evidence concerning a specified external effect.
16.5.23 — Qualified Non-Effectuation Evidence
Qualified Non-Effectuation Evidence means evidence sufficient under a
defined trust model to establish that the specified real effect did
not occur.
16.5.24 — Qualified Completed-Effect Evidence
Qualified Completed-Effect Evidence means evidence sufficient to
establish the specified completed consequence.
16.5.25 — Protected Effect Reconciliation
8.5.3.14. Original global source page 1398
Protected Effect Reconciliation means a verified procedure resolving
earlier dispatch and effect state without automatically authorizing a
new consequence.
16.5.26 — Recovery Authority Fence
A Recovery Authority Fence means protected state preventing duplicate
or incompatible corrective operations.
16.5.27 — Fenced Execution Generation
Das Expires 29 April 2027 [Page 226]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A Fenced Execution Generation, or FEG-16, means a current protected
generation preventing an old coordinator, worker, or device owner
from exercising stale consequential authority.
16.5.28 — Protected Journal Checkpoint
A Protected Journal Checkpoint, or PJC-16, means an authenticated
compact state representing journal transitions necessary for
continued enforcement.
16.5.29 — Journal Rollback Protection
Journal Rollback Protection means a mechanism preventing stale or
altered journal state from recreating previously consumed authority.
16.5.30 — Effectuation Boundary Commitment
An Effectuation Boundary Commitment means an authenticated reference
to the actual interface at which the specified consequence may be
released.
16.5.31 — Atomic Resource-Finality Commit
Atomic Resource-Finality Commit means one transaction-domain
transition that commits both the permitted resource effect and its
corresponding finality consumption under the specified atomicity
guarantees.
16.5.32 — External Dispatch Uncertainty
External Dispatch Uncertainty means an unresolved condition
concerning whether an externally addressed effect crossed its
dispatch or receiving boundary.
16.5.33 — Outcome-Specific Reauthorization
Outcome-Specific Reauthorization means new consequential authority
issued only after the necessary supported earlier-outcome conditions
are established.
16.5.34 — Protected Journal Continuity
Protected Journal Continuity means preservation of authoritative
consequential-operation state across crash, restart, migration, and
recovery.
16.5.35 — Exactly-Once Authorization Consumption
Das Expires 29 April 2027 [Page 227]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.5.3.15. Original global source page 1399
Exactly-Once Authorization Consumption means, for a specified single-
use finality enablement and authoritative protected consumption
domain, no more than one permitted consumption transition can commit.
It does not independently establish that a corresponding external
operation physically occurs exactly once.
16.6 — OPERATION IDENTITY AND ACTUAL EFFECT BINDING
A protected operation identifier may be derived from, or
authenticated with, the corresponding Candidate Act and actual-effect
descriptor.
A representative operation record may comprise:
PROTECTED_LOGICAL_OPERATION = { logical_effect_identifier,
originating_candidate_act, protected_source_authority,
actual_operation_commitment, protected_resource_identity,
intended_destination, operation_semantics_version,
relevant_resource_version, designated_finality_sink,
finality_enablement_reference, current_authority_epoch,
current_execution_generation, protected_operation_authentication }
The logical effect identifier may remain stable across qualified
retries of the same logical operation.
An attempt identifier may differ between dispatch attempts.
The system must distinguish the logical effect from the transmission
attempt.
A copied identifier cannot independently authorize a new operation
with different actual parameters.
16.6.1 — Stable Logical Identity
Permitted retries may refer to the same original consequential
objective.
16.6.2 — Distinct Attempts
Separate attempts may have distinct identifiers while preserving the
logical operation binding.
Das Expires 29 April 2027 [Page 228]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.5.3.16. Original global source page 1400
16.6.3 — Actual Parameters
The actual effect parameters must correspond to the protected
operation.
16.6.4 — Resource Identity
The actual target must be verified.
16.6.5 — Operation Contract
The current semantics must satisfy the applicable validated contract.
16.6.6 — Generation State
Stale workload or authority generations cannot independently produce
another effect.
16.7 — PROTECTED DURABLE FINALITY JOURNAL
A representative journal entry may comprise:
PROTECTED_FINALITY_JOURNAL_ENTRY = { journal_format_version,
journal_domain_identifier, journal_sequence,
previous_entry_commitment, candidate_act_digest,
actual_operation_digest, logical_effect_identifier,
attempt_identifier, validation_evidence_commitment,
protected_finality_authority_reference,
authority_consumption_generation, state_transition_type,
dispatch_intent_commitment, designated_effectuation_sink,
receiver_identity_if_applicable, protected_resource_generation,
authority_epoch, journal_durability_status,
qualified_outcome_evidence_reference, protected_entry_authentication
}
The journal may be implemented using a transactional store, write-
ahead log, protected append-only state, durable key-value store,
hardware-protected storage, or an equivalent authoritative mechanism.
A cryptographic hash chain may assist integrity checking.
8.5.3.17. Original global source page 1401
A hash chain does not independently guarantee availability,
durability, completeness, or rollback resistance.
Das Expires 29 April 2027 [Page 229]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Those properties require suitable protected storage and state-
management mechanisms.
16.8 — REQUIRED JOURNAL TRANSITIONS
A principal implementation may define:
INTENT_PREPARED: The Candidate Act and actual effect descriptor have
been committed for protected validation.
VALIDATION_COMMITTED: Required current operation-specific validation
has passed.
FINALITY_READY: The applicable non-bearer enablement is eligible.
CONSUMPTION_PREPARED: The sink is preparing the protected authority
transition.
AUTHORITY_CONSUMED: The permitted finality use has been durably
consumed.
DISPATCH_INTENT_COMMITTED: A protected record identifies the
externally addressable effect prepared for dispatch.
DISPATCH_IN_PROGRESS: The controlled effectuation interface has
initiated the corresponding operation.
DISPATCH_POSSIBLE: The operation may have crossed the dispatch
boundary, but the evidence is insufficient to determine the exact
state.
RECEIVER_ACCEPTED: Qualified evidence establishes the receiver's
specified acceptance state.
EFFECT_COMMITTED: Qualified evidence establishes the defined
completed external or resource effect.
EFFECT_REJECTED: Qualified evidence establishes rejection without the
specified consequential mutation.
EFFECT_PARTIAL: Qualified evidence establishes a partial consequence.
EFFECT_INDETERMINATE: The relevant real outcome remains unresolved.
RETRY_FENCED: Another effect attempt is prohibited pending the
defined safety conditions.
Das Expires 29 April 2027 [Page 230]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
RECOVERY_AUTHORIZED: A separately verified recovery procedure has
received the required authority.
8.5.3.18. Original global source page 1402
TERMINATED: The logical operation has reached a valid protected
terminal condition.
The records must distinguish the durability of local state from
evidence about a remote result.
16.9 — DURABILITY AND STORAGE ORDERING
A protected finality protocol must identify which state is required
to be durable before the actual consequence becomes possible.
A principal remote-dispatch implementation may require:
1. A verified actual-operation descriptor. 2. Valid current
protected finality authority. 3. A durable consumption and dispatch-
intent relationship. 4. A release fence tied to the committed state.
5. Only then, controlled external dispatch.
The durability barrier must correspond to the actual storage
semantics.
A file write accepted into volatile cache does not automatically
constitute a durable commit.
An application-level acknowledgement from a storage API may be
insufficient if its documented semantics do not establish the
required persistence.
Suitable implementations may employ transactional commit, persistence
barriers, hardware-backed storage, quorum-durable replication, or
another mechanism providing the claimed durability.
16.9.1 — Journal Atomicity
Security-relevant fields may be committed within one atomic protected
record or equivalent transaction.
16.9.2 — Torn Write Detection
Incomplete records may be detected using suitable integrity and
transaction-state mechanisms.
16.9.3 — Ordering
Das Expires 29 April 2027 [Page 231]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Required state transitions must not be reordered across an
unprotected external effectuation boundary.
16.9.4 — Recovery Scan
Following restart, the controller reconstructs the latest
authoritative operation state.
16.9.5 — Missing State
8.5.3.19. Original global source page 1403
Unresolved mandatory journal state cannot be treated as proof that an
external effect did not occur.
16.10 — LOCAL ATOMIC RESOURCE-FINALITY MODE
A first principal operating mode applies where the Finality Sink and
affected resource support one protected transactional domain.
For example, a database controller may have authority to perform
both:
The target mutation; and
The associated finality-consumption update.
A representative transaction may be:
ATOMIC_TRANSACTION { VERIFY_CURRENT_SOURCE_AUTHORITY
VERIFY_ACTUAL_OPERATION VERIFY_VALID_FINALITY_ENABLEMENT
VERIFY_CURRENT_RESOURCE_VERSION VERIFY_UNCONSUMED_AUTHORITY
APPLY_AUTHORIZED_RESOURCE_MUTATION CONSUME_FINALITY_AUTHORITY
COMMIT_PROTECTED_JOURNAL_STATE }
If the transaction aborts, neither the resource mutation nor the
authoritative consumption transition is committed.
If it commits, both are durably associated under the selected
resource's transaction guarantees.
16.10.1 — Linearization Point
The operation may use the authoritative transaction commit as the
point at which local effect and consumption become effective.
16.10.2 — Duplicate Submission
Das Expires 29 April 2027 [Page 232]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A repeated request observes the existing committed logical operation
state rather than applying the mutation again.
16.10.3 — Resource Version
The transaction may verify current version or other conditional
state.
16.10.4 — Journal Record
8.5.3.20. Original global source page 1404
The committed journal state identifies the corresponding operation
and authority consumption.
16.10.5 — Limitation
The guarantee applies to the resource effects and state actually
included within the transaction boundary.
An additional external notification, network transmission, or
physical action may require a separate protocol.
16.11 — REMOTE DISPATCH MODE
A second operating mode applies where the actual effect occurs in a
separate remote resource or administrative domain.
The local controller cannot necessarily atomically commit its
finality journal together with the remote consequence.
A protected procedure may therefore:
Establish a valid operation-specific authority;
Durably consume the relevant finality enablement;
Commit a protected dispatch-intent record;
Permit a controlled dispatcher to transmit the precisely committed
operation;
Maintain an indeterminate state if the result becomes uncertain;
And obtain qualified receiver or external-effect evidence before
permitting any further effectuation decision.
Das Expires 29 April 2027 [Page 233]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The system must not silently convert a local durable commit into a
claim of remote successful completion.
16.12 — ATOMIC CONSUMPTION–DISPATCH INTENT COUPLING
A principal remote configuration may commit both the finality
consumption and dispatch-intent reference in one authoritative
protected state transition.
ATOMIC { REQUIRE AUTHORITY_VALID REQUIRE ACTUAL_OPERATION_MATCHES
REQUIRE FINALITY_UNCONSUMED
8.5.3.21. Original global source page 1405
CONSUME_FINALITY_ENABLEMENT RECORD_EXACT_DISPATCH_INTENT
ADVANCE_PROTECTED_GENERATION }
The committed dispatch intent may authorize a designated protected
dispatcher to attempt the corresponding operation.
It does not authorize arbitrary newly generated operations.
If the process crashes immediately after the atomic transition, the
journal preserves the operation identity and consumed authority.
The dispatcher may resume only according to the selected remote-
effect protocol.
Where safe retransmission cannot be established, the operation
remains fenced until reconciliation.
16.13 — CONTROLLED OUTBOX VARIATION
A protected outbox may contain the exact operation prepared for
remote delivery.
A representative record may comprise:
PROTECTED_EFFECT_OUTBOX = { logical_effect_identifier,
attempt_identifier, actual_operation_commitment,
serialized_dispatch_payload_reference, authorized_destination,
finality_consumption_reference, source_authority_epoch,
dispatcher_generation, receiver_duplicate_policy_reference,
current_dispatch_state, protected_record_authentication }
The protected outbox entry may be committed with finality
consumption.
Das Expires 29 April 2027 [Page 234]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
An authorized dispatcher later reads the durable entry.
It must not construct a materially different operation from current
agent output.
It verifies the current permitted dispatch state and destination.
Where the selected protocol permits at-least-once transmission, the
destination must have adequate duplicate-control properties for the
claimed effect guarantee.
8.5.3.22. Original global source page 1406
The outbox itself does not create exactly-once external processing.
16.14 — RECEIVER-SIDE DUPLICATE FENCING
A destination may maintain authoritative state binding the logical
effect identifier to the actual resource operation.
A representative receiver record may comprise:
RECEIVER_EFFECT_REGISTRY = { receiver_identity,
logical_effect_identifier, accepted_operation_digest,
originating_authority_reference, receiver_resource_identifier,
receiver_transaction_identifier, receiver_resource_generation,
processing_status, committed_effect_reference,
protected_duplicate_retention_state, authenticated_receiver_state }
The receiver may reject a repeated request with the same logical
identifier and incompatible parameters.
If the same logical operation was already committed, the receiver may
return the authenticated existing result without applying another
mutation.
For strong receiver-side effect uniqueness, the duplicate registry
and protected resource mutation must be appropriately atomic or
supported by an equivalent mechanism.
If the receiver merely writes the duplicate registry before a
separate unprotected mutation, a crash could leave an operation
recorded as completed even though no effect occurred.
If the receiver applies the mutation before separately writing the
registry, a crash could permit duplicate mutation on retry.
16.15 — RECEIVER TRANSACTIONAL COMMIT
Das Expires 29 April 2027 [Page 235]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Where the receiver controls a transactional resource, it may process
an incoming logical effect as follows:
ATOMIC_RECEIVER_TRANSACTION { VERIFY_OPERATION_IDENTITY
VERIFY_CURRENT_RECEIVER_AUTHORITY
8.5.3.23. Original global source page 1407
IF LOGICAL_OPERATION_ALREADY_COMMITTED: RETURN RECORDED_RESULT
VERIFY_ACTUAL_OPERATION_PARAMETERS VERIFY_CURRENT_RESOURCE_STATE
APPLY_RESOURCE_MUTATION RECORD_LOGICAL_OPERATION_AS_COMMITTED
COMMIT_TRANSACTION }
The exact receiver semantics must be defined.
A receiver that only acknowledges message arrival cannot claim to
have committed the requested resource mutation.
Where the receiving system supports a defined idempotent operation
but not one atomic transaction, the corresponding protection may use
another qualified and documented mechanism.
16.16 — RECEIVER RETENTION AND IDENTITY LIFETIME
Duplicate suppression is meaningful only while the relevant receiver
state remains applicable.
16.16.1 — Retention Scope
The receiver identifies how long or under what conditions operation
identifiers are retained.
16.16.2 — Stable Parameter Binding
The identifier remains associated with the original operation digest.
16.16.3 — Expiration
After retention expiry, the original logical identifier may no longer
be sufficient for safe retry.
16.16.4 — Reconciliation
The sender may require qualified receiver-state queries or separately
authorized recovery.
16.16.5 — New Identifier
Das Expires 29 April 2027 [Page 236]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Generating a new logical identifier is not automatically permitted
while the earlier effect remains uncertain.
16.16.6 — Current Policy
The protected retry controller checks the receiver's actual guarantee
rather than assuming indefinite deduplication.
8.5.3.24. Original global source page 1408
16.17 — INDETERMINATE EXTERNAL OUTCOME
A consequential operation may reach an indeterminate state when the
available evidence cannot establish whether the actual effect
occurred.
A timeout is a communication condition.
A disconnected socket is a transport condition.
A missing acknowledgement is an observation condition.
None is sufficient by itself to establish that the destination did
not perform the operation.
The protected journal may therefore record:
The original authorized operation;
The consumed authority;
The dispatch intent;
The possibility of dispatch;
The last qualified receiver evidence;
And the current unresolved outcome.
The operation remains protected against unsupported independent re-
execution.
16.18 — QUALIFIED OUTCOME EVIDENCE
The system may use authenticated evidence from:
A transactional receiver;
Das Expires 29 April 2027 [Page 237]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A protected resource controller;
An independent effect observer;
A hardware command completion interface;
An appropriately qualified external validator;
Or another source with sufficient technical visibility.
A representative outcome record may comprise:
8.5.3.25. Original global source page 1409
QUALIFIED_EXTERNAL_EFFECT_OUTCOME = {
original_logical_effect_identifier, original_operation_commitment,
receiver_or_observer_identity, authorized_observation_role,
actual_resource_identity, supported_effect_status,
committed_resource_state_reference, receiver_transaction_reference,
observation_scope, observation_generation,
unresolved_effect_components, evidence_assurance_profile,
protected_evidence_authentication }
A receiver's acknowledgement of command receipt does not
automatically establish physical actuation completion.
A transactional database commit receipt may support a stronger claim
concerning the database resource state.
The actual observation and evidence qualifications determine the
supported result.
16.19 — QUALIFIED NON-EFFECTUATION
The system may classify an earlier operation as not performed only
when supported by sufficient evidence.
Possible evidence may include:
A protected dispatcher record establishing that dispatch never
crossed its controlled boundary;
A receiving transaction system conclusively reporting rejection
without mutation;
A qualified receiver state proving that the operation identifier was
never accepted within an appropriately complete observation scope;
Das Expires 29 April 2027 [Page 238]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Or another technically sufficient negative-effect condition.
A receiver query returning no record may be insufficient if the
receiving system can discard records, process operations outside that
registry, or fail to expose a complete authoritative history.
The negative conclusion must therefore be limited to the evidence
assurance actually established.
8.5.3.26. Original global source page 1410
16.20 — SAFE RETRY CLASSES
The system may distinguish several retry classes.
16.20.1 — Confirmed Non-Effectuation Retry
A new attempt may be considered after qualified evidence establishes
that the original effect did not occur.
16.20.2 — Receiver-Idempotent Retry
A repeated transmission may be permitted under a verified receiver
duplicate-suppression guarantee covering the same logical operation.
16.20.3 — Transactionally Idempotent Retry
The receiver may atomically return the result of an already committed
mutation without applying it again.
16.20.4 — Idempotent Operation Semantics
The actual operation may have semantics making repetition safe under
the defined resource conditions.
16.20.5 — Observation-Only Retry
A status query or equivalent non-effecting observation may be
repeated where permitted.
16.20.6 — Separately Authorized Recovery
A new consequential operation may be authorized following appropriate
qualified outcome classification.
16.20.7 — Unsafe Retry
Das Expires 29 April 2027 [Page 239]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
If no sufficient retry-safety condition can be established, the
original effect remains fenced.
16.20.8 — Technical Limitation
A delay, exponential backoff interval, or operator impatience does
not establish a safe retry class.
16.21 — RETRY FENCE
A protected retry fence may be associated with the logical effect
identifier.
8.5.3.27. Original global source page 1411
The fence may prevent:
Submission of a new operation identifier for the same unresolved
effect;
Reactivation of consumed finality authority;
Duplicate outbox processing outside the permitted dispatch protocol;
Unrelated recovery workers issuing the same consequential effect;
And unqualified automatic operation replay.
The fence may be lifted only through a current protected transition
satisfying the selected outcome and retry conditions.
A status query may be permitted while effecting commands remain
withheld.
16.22 — MONOTONIC AUTHORITY GENERATIONS
The system may maintain a protected generation for each relevant
authority or logical effect.
A successful consumption transition advances the generation.
An untrusted agent snapshot cannot restore the earlier generation.
A recovered worker must obtain the current authoritative state.
A malicious process cannot produce valid new consequential authority
merely by editing a local journal copy or resetting a counter in its
own address space.
Das Expires 29 April 2027 [Page 240]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The assurance may be provided through protected transactional state,
hardware-supported monotonic mechanisms, an appropriately replicated
authoritative controller, or another equivalent construction.
16.23 — FENCING OLD COORDINATORS
A distributed system may elect a new dispatcher or coordinator after
failure.
However, an old coordinator may later resume.
A simple lease expiration at the coordinator is insufficient if the
old coordinator can still perform unmediated operations.
A principal implementation may require the actual receiver or
effectuation sink to verify a current fencing generation.
8.5.3.28. Original global source page 1412
16.23.1 — Current Leader Generation
The protected system maintains an authoritative coordinator
generation.
16.23.2 — Dispatch Authorization
A dispatcher receives bounded authority under that generation.
16.23.3 — Leader Replacement
The generation advances when control changes.
16.23.4 — Stale Worker
The old worker's generation becomes invalid.
16.23.5 — Receiver Enforcement
The actual resource controller rejects commands from obsolete
generations.
16.23.6 — Limitation
A fencing counter that is not enforced at the actual consequence
boundary cannot independently prevent stale external effects.
16.24 — JOURNAL ROLLBACK PROTECTION
Das Expires 29 April 2027 [Page 241]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The journal may be protected through one or more mechanisms:
Authoritative transactional generations;
Tamper-evident record chaining;
Protected checkpoints;
Hardware-backed persistent counters;
Quorum-durable state;
Authenticated state roots;
Or another suitable mechanism.
A hash chain detects some modifications under its assumptions but
does not independently prevent an attacker from replacing the entire
chain with an older valid-looking copy.
A stronger rollback-resistant implementation must bind the accepted
journal state to an authoritative non-rollbackable reference.
8.5.3.29. Original global source page 1413
16.24.1 — Checkpoint
The system may periodically commit a protected summary of earlier
transitions.
16.24.2 — Historical Records
Earlier journal entries may be compacted if the necessary consumption
and outcome properties remain preserved.
16.24.3 — Compaction Safety
Removing historical records must not allow a consumed operation
identifier to be treated as newly valid.
16.24.4 — Restart
Current authoritative state must be reconstructed before effectuation
resumes.
16.25 — JOURNAL COMPACTION AND LONG-DURATION AUTHORITY
Long-running systems may accumulate many protected operation records.
Das Expires 29 April 2027 [Page 242]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The system may retain sufficient authenticated state to preserve:
Consumed authority identifiers;
Current logical effect identities;
Unresolved external outcomes;
Active receiver duplicate-suppression requirements;
Relevant revocation generations;
Recovery fences;
And completed effect references required for later causal
continuation.
The journal may store compact commitments or state summaries where
sufficient.
A compacted record must not eliminate information necessary for the
selected security predicate.
A receipt or state summary representing earlier effectuation must
preserve its qualified assurance scope.
8.5.3.30. Original global source page 1414
16.26 — MULTI-SINK CONSEQUENCES
One logical workflow may produce several distinct external effects.
For example, an operation may update a database, transmit an
instruction, and activate a hardware command.
The system must determine whether these consequences are:
One atomic protected resource transaction;
Separate bounded Candidate Acts;
A causally ordered chain;
Or a distributed operation requiring qualified partial-outcome
handling.
A single consumed authorization for a high-level workflow does not
automatically prove that every external consequence occurred.
Das Expires 29 April 2027 [Page 243]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Each actual effect may require its own Finality-Sink state and
evidence.
Where successor authority depends upon prior real completion, the
accepted actual-effect receipt remains mandatory under the selected
causal protocol.
16.27 — PARTIAL EFFECTUATION
A protected operation may have several components.
Some may complete.
Others may fail.
The journal may represent each applicable component separately.
A representative partial outcome may comprise:
PROTECTED_PARTIAL_EFFECT_STATE = { parent_logical_effect,
child_effect_references, qualified_completed_components,
qualified_rejected_components, unresolved_components,
consumed_authority_components, current_resource_states,
recovery_authority_references, protected_state_authentication }
8.5.3.31. Original global source page 1415
The system does not classify the entire operation as safely
unperformed merely because one component failed.
Any corrective or successor consequence requires appropriate current
authority.
16.28 — CRASH-RESILIENT DEVICE COMMANDS
A device command may have a more complex completion boundary than a
database mutation.
The device may acknowledge command acceptance before movement or
actuation begins.
It may acknowledge dispatch while the physical operation remains
incomplete.
It may complete the physical operation but lose connection before
reporting the result.
A protected hardware controller may therefore distinguish:
Das Expires 29 April 2027 [Page 244]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Command validated;
Command accepted;
Command queued;
Command issued;
Physical actuation started;
Physical actuation completed;
And completion uncertain.
Where supported, hardware-local protected state may prevent duplicate
command acceptance.
Where physical state can be observed, qualified sensor evidence may
support outcome reconciliation.
A protected command counter does not by itself establish that every
physical consequence completed exactly once.
16.29 — INFORMATION DISCLOSURE AS AN IRREVERSIBLE EFFECT
An information-release sink may transmit protected data to an
external recipient.
8.5.3.32. Original global source page 1416
If acknowledgement is lost, the system cannot automatically resend
the information without examining the applicable disclosure authority
and cumulative exposure conditions.
Even repeated transmission of identical information may affect a
privacy policy differently according to the recipient, timing, or
applicable model.
A protected disclosure journal may therefore bind:
The actual outgoing information;
The authorized recipient;
The applicable privacy state;
The consumed disclosure authority;
Das Expires 29 April 2027 [Page 245]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The transmission attempt;
And the relevant outcome uncertainty.
A local failure does not undo any information already received
externally.
16.30 — PROTECTED EFFECTUATION STATE MACHINE
A non-limiting state machine comprises:
CANDIDATE_PREPARED: A proposed consequential operation exists.
NON_EFFECTIVE: The effect remains withheld.
VALIDATION_PENDING: Required authority and evidence checks are
incomplete.
VALIDATION_ACCEPTED: Applicable validation predicates pass.
JOURNAL_PREPARED: A protected durable operation state is being
established.
JOURNAL_COMMITTED: The required operation record is durably
committed.
FINALITY_ELIGIBLE: Current non-bearer finality authority is
available.
CONSUMPTION_PENDING: The protected consumption transition is being
performed.
AUTHORITY_CONSUMED: The corresponding finality use is durably
consumed.
DISPATCH_INTENT_COMMITTED: The exact externally addressed operation
is durably committed for controlled dispatch.
8.5.3.33. Original global source page 1417
DISPATCH_AUTHORIZED: The designated dispatcher may attempt the
committed operation under current protocol conditions.
DISPATCH_ATTEMPTED: The relevant effectuation interface has initiated
the request.
DISPATCH_UNCERTAIN: It is not known whether the operation crossed the
required external boundary.
Das Expires 29 April 2027 [Page 246]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
RECEIVER_ACCEPTED: Qualified evidence establishes the selected
receiver acceptance state.
EFFECT_CONFIRMED: Qualified evidence establishes the actual specified
consequence.
EFFECT_REJECTED: Qualified evidence establishes the specified non-
effecting rejection.
EFFECT_PARTIAL: Qualified evidence establishes partial effectuation.
EFFECT_INDETERMINATE: The real consequence remains unresolved.
RETRY_FENCED: Additional effect attempts remain prohibited pending
safe eligibility.
RETRY_ELIGIBLE: The protected controller has established a valid
retry condition.
RECOVERY_PENDING: Separately governed recovery may be required.
TERMINATED: The operation has reached an authorized terminal state.
The state machine may be implemented through one protected resource
controller or several appropriately coordinated domains.
16.31 — PRINCIPAL END-TO-END WORKFLOW
Step 1 — Establish Candidate Act. Identify the proposed consequential
operation.
Step 2 — Hold the Effect. Maintain Non-Effective State.
Step 3 — Verify Source Authority. Establish current permission for
the effect.
Step 4 — Verify Protected Evidence. Evaluate the required evidence,
including any cross-committed validation.
Step 5 — Reconstruct Actual Pending Operation. The Finality Sink
obtains the current real operation.
Step 6 — Bind Logical Effect Identity. Establish the precise
operation and target.
Step 7 — Establish Journal Scope. Identify the authoritative journal
and consumption domain.
Das Expires 29 April 2027 [Page 247]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.5.3.34. Original global source page 1418
Step 8 — Verify Current Resource State. Confirm required target and
version conditions.
Step 9 — Verify Finality Enablement. Check current non-bearer
authority.
Step 10 — Verify No Prior Consumption. Establish available protected
use.
Step 11 — Prepare Durable Intent. Form the exact operation record.
Step 12 — Commit Required Journal State. Satisfy the selected
persistence barrier.
Step 13 — Consume Finality Authority. Commit the protected monotonic
transition.
Step 14 — Commit Dispatch Intent. Bind the actual external operation
to the consumed authority, atomically where the architecture
requires.
Step 15 — Verify Dispatcher Generation. Ensure current designated
effectuation ownership.
Step 16 — Release the Actual Operation. Permit only the committed
consequential effect.
Step 17 — Record Attempt State. Preserve qualified evidence
concerning dispatch.
Step 18 — Obtain Receiver Evidence. Query or receive the relevant
destination result.
Step 19 — Classify Outcome. Distinguish confirmed completion,
rejection, partial effect, and uncertainty.
Step 20 — Commit Outcome State. Authenticate the supported result.
Step 21 — Apply Retry Fence if Required. Prevent unsafe new
effectuation.
Step 22 — Reconcile Indeterminate State. Obtain further qualified
evidence where possible.
Step 23 — Evaluate Retry Eligibility. Permit another attempt only
under sufficient operation-specific conditions.
Das Expires 29 April 2027 [Page 248]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Step 24 — Govern Recovery. Require separately valid corrective
authority where applicable.
Step 25 — Enforce Terminal State. Prevent unauthorized later reuse
of the consumed finality authority.
16.32 — REFERENCE PSEUDOCODE: PROTECTED FINALITY PREPARATION
FUNCTION PREPARE_CRASH_CONSISTENT_FINALITY( candidate_act,
finality_sink,
8.5.3.35. Original global source page 1419
protected_journal ): actual_operation =
finality_sink.RECONSTRUCT_ACTUAL_PENDING_OPERATION() REQUIRE
VERIFY_CANDIDATE_ACT(candidate_act) REQUIRE
VERIFY_ACTUAL_OPERATION_CORRESPONDENCE( actual_operation,
candidate_act ) REQUIRE VERIFY_REQUIRED_VALIDATION_EVIDENCE(
candidate_act ) REQUIRE VERIFY_CURRENT_SOURCE_AUTHORITY(
candidate_act ) REQUIRE VERIFY_CURRENT_RESOURCE_STATE(
actual_operation ) REQUIRE VERIFY_CURRENT_NON_BEARER_ENABLEMENT(
candidate_act ) logical_id = DERIVE_PROTECTED_LOGICAL_EFFECT_ID(
candidate_act, actual_operation ) prepared = protected_journal
.ATOMIC_PREPARE({ logical_effect: logical_id, actual_operation:
HASH(actual_operation), candidate_act: HASH(candidate_act),
finality_enablement: CURRENT_ENABLEMENT_REFERENCE(),
current_consumption_generation: CURRENT_MONOTONIC_GENERATION(),
8.5.3.36. Original global source page 1420
designated_sink: finality_sink.identity }) IF prepared !=
DURABLY_COMMITTED: RETURN HOLD RETURN prepared
The durable-commit test must correspond to the actual storage
guarantee.
16.33 — REFERENCE PSEUDOCODE: LOCAL ATOMIC EFFECT
Das Expires 29 April 2027 [Page 249]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
FUNCTION COMMIT_LOCAL_ATOMIC_EFFECT( prepared_operation,
protected_resource_sink ): REQUIRE VERIFY_PREPARED_OPERATION(
prepared_operation ) REQUIRE VERIFY_CURRENT_AUTHORITY(
prepared_operation ) transaction = protected_resource_sink
.BEGIN_PROTECTED_TRANSACTION() REQUIRE transaction
.VERIFY_ACTUAL_RESOURCE_AND_OPERATION() REQUIRE transaction
.VERIFY_EXPECTED_RESOURCE_VERSION() REQUIRE transaction
.VERIFY_UNCONSUMED_FINALITY_GENERATION() transaction
.APPLY_AUTHORIZED_RESOURCE_MUTATION() transaction
.CONSUME_FINALITY_AUTHORITY() transaction .COMMIT_OPERATION_JOURNAL()
result = transaction.COMMIT_ATOMICALLY()
8.5.3.37. Original global source page 1421
IF result != COMMITTED: RETURN
RECONCILE_AUTHORITATIVE_TRANSACTION_STATE RETURN
QUALIFIED_LOCAL_COMMIT_RESULT(result)
The transaction must cover both consumption and the claimed local
effect.
16.34 — REFERENCE PSEUDOCODE: DURABLE REMOTE DISPATCH INTENT
FUNCTION PREPARE_REMOTE_EFFECT_DISPATCH( prepared_operation,
protected_dispatch_controller ): REQUIRE VERIFY_PREPARED_OPERATION(
prepared_operation ) REQUIRE VERIFY_CURRENT_FINALITY_AUTHORITY()
REQUIRE VERIFY_ACTUAL_OPERATION_BINDING( prepared_operation ) REQUIRE
VERIFY_RECEIVER_AND_DESTINATION_SCOPE() committed =
protected_dispatch_controller .ATOMIC_CONSUME_AND_RECORD_INTENT({
logical_effect: prepared_operation.logical_id, actual_operation:
prepared_operation.actual_operation_digest, designated_receiver:
prepared_operation.receiver, authority_reference:
prepared_operation.finality_enablement, expected_generation:
CURRENT_FINALITY_GENERATION(), next_generation:
NEXT_MONOTONIC_GENERATION(), dispatch_payload_reference:
prepared_operation.payload_reference,
8.5.3.38. Original global source page 1422
receiver_duplicate_policy: CURRENT_RECEIVER_POLICY() }) IF committed
!= DURABLY_COMMITTED: RETURN DO_NOT_DISPATCH RETURN committed
A protected dispatcher may use this result only under the applicable
current dispatch and retry policy.
16.35 — REFERENCE PSEUDOCODE: CONTROLLED DISPATCH
Das Expires 29 April 2027 [Page 250]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
FUNCTION DISPATCH_PROTECTED_REMOTE_EFFECT( committed_intent,
protected_dispatcher ): REQUIRE VERIFY_DURABLE_DISPATCH_INTENT(
committed_intent ) REQUIRE VERIFY_CURRENT_DISPATCHER_GENERATION(
protected_dispatcher ) REQUIRE
VERIFY_PAYLOAD_MATCHES_COMMITTED_OPERATION( committed_intent )
REQUIRE VERIFY_DESTINATION_BINDING( committed_intent ) REQUIRE
VERIFY_DISPATCH_ATTEMPT_ELIGIBILITY( committed_intent )
RECORD_PROTECTED_DISPATCH_ATTEMPT_START( committed_intent ) result =
protected_dispatcher .TRANSMIT_EXACT_COMMITTED_OPERATION(
committed_intent ) IF result == QUALIFIED_RECEIVER_COMMIT:
8.5.3.39. Original global source page 1423
RETURN COMMIT_QUALIFIED_COMPLETION(result) IF result ==
QUALIFIED_NON_EFFECTING_REJECTION: RETURN
COMMIT_QUALIFIED_REJECTION(result)
ESTABLISH_INDETERMINATE_OUTCOME_FENCE( committed_intent ) RETURN
OUTCOME_UNRESOLVED
The transport call must not be interpreted as conclusive evidence of
remote effectuation unless the relevant destination evidence actually
supports that claim.
16.36 — REFERENCE PSEUDOCODE: RECEIVER DEDUPLICATION
FUNCTION PROCESS_RECEIVER_LOGICAL_EFFECT( incoming_effect,
protected_receiver ): REQUIRE VERIFY_INCOMING_OPERATION_AUTHORITY(
incoming_effect ) REQUIRE VERIFY_ACTUAL_OPERATION_IDENTITY(
incoming_effect ) transaction = protected_receiver
.BEGIN_ATOMIC_RESOURCE_TRANSACTION() prior = transaction
.LOOKUP_LOGICAL_EFFECT( incoming_effect.logical_id ) IF prior EXISTS:
REQUIRE prior.operation_digest ==
HASH(incoming_effect.actual_operation) RETURN transaction
.RETURN_EXISTING_COMMITTED_RESULT(prior) REQUIRE transaction
.VERIFY_CURRENT_RESOURCE_CONDITIONS() transaction
8.5.3.40. Original global source page 1424
.APPLY_RESOURCE_EFFECT( incoming_effect.actual_operation )
transaction .RECORD_COMMITTED_LOGICAL_EFFECT({ logical_id:
incoming_effect.logical_id, operation_digest:
HASH(incoming_effect.actual_operation), receiver_generation:
CURRENT_RECEIVER_GENERATION() }) RETURN
transaction.COMMIT_ATOMICALLY()
If the receiving resource cannot provide the required atomicity, the
implementation must rely upon another sufficiently qualified
duplicate-control mechanism or state the weaker achievable guarantee.
Das Expires 29 April 2027 [Page 251]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
16.37 — REFERENCE PSEUDOCODE: INDETERMINATE OUTCOME RECONCILIATION
FUNCTION RECONCILE_INDETERMINATE_EFFECT( logical_effect,
protected_reconciliation_controller ): journal_state =
LOAD_AUTHORITATIVE_FINALITY_JOURNAL( logical_effect ) REQUIRE
VERIFY_JOURNAL_AUTHENTICITY( journal_state ) REQUIRE
VERIFY_CONSUMPTION_AND_DISPATCH_BINDING( journal_state ) evidence =
COLLECT_QUALIFIED_RECEIVER_OR_EFFECT_EVIDENCE( logical_effect ) IF
QUALIFIED_COMPLETION_ESTABLISHED(evidence): COMMIT_COMPLETED_OUTCOME(
8.5.3.41. Original global source page 1425
logical_effect, evidence ) RETURN EFFECT_CONFIRMED IF
QUALIFIED_NON_EFFECTUATION_ESTABLISHED(evidence):
COMMIT_NON_EFFECT_OUTCOME( logical_effect, evidence ) RETURN
EVALUATE_SEPARATE_RETRY_AUTHORITY IF
QUALIFIED_PARTIAL_EFFECT_ESTABLISHED(evidence):
COMMIT_PARTIAL_OUTCOME( logical_effect, evidence ) RETURN
REQUIRE_BOUNDED_RECOVERY ESTABLISH_INDETERMINATE_OUTCOME_FENCE(
logical_effect ) RETURN EFFECT_REMAINS_UNRESOLVED
A failed status query cannot automatically be classified as evidence
of non-effectuation.
16.38 — REFERENCE PSEUDOCODE: SAFE RETRY ELIGIBILITY
FUNCTION VERIFY_RETRY_ELIGIBILITY( logical_effect, proposed_retry,
protected_retry_controller ): state =
LOAD_CURRENT_LOGICAL_EFFECT_STATE( logical_effect ) REQUIRE
VERIFY_CURRENT_SOURCE_AND_RECOVERY_AUTHORITY() REQUIRE
proposed_retry.logical_id == logical_effect.identifier
8.5.3.42. Original global source page 1426
REQUIRE proposed_retry.operation_digest ==
logical_effect.operation_digest IF state == QUALIFIED_COMPLETED:
RETURN DENY_DUPLICATE IF state == QUALIFIED_NON_EFFECT: RETURN
EVALUATE_NEW_BOUNDED_RETRY IF state == OUTCOME_INDETERMINATE:
receiver_guarantee = VERIFY_CURRENT_RECEIVER_DUPLICATE_GUARANTEE(
logical_effect ) IF receiver_guarantee == SUFFICIENT: REQUIRE
VERIFY_RECEIVER_STATE_RETENTION() REQUIRE
VERIFY_CURRENT_DISPATCHER_GENERATION() RETURN
PREPARE_SAME_LOGICAL_EFFECT_RETRANSMISSION RETURN KEEP_EFFECT_FENCED
RETURN REQUIRE_CURRENT_OUTCOME_CLASSIFICATION
The retransmission remains constrained to the originally committed
logical operation and the actual receiver's guarantee.
Das Expires 29 April 2027 [Page 252]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
16.39 — REFERENCE PSEUDOCODE: JOURNAL RECOVERY AFTER CRASH
FUNCTION RECOVER_PROTECTED_FINALITY_JOURNAL( journal_store,
protected_recovery_controller ): checkpoint = journal_store
.LOAD_LATEST_AUTHENTICATED_CHECKPOINT() REQUIRE
VERIFY_CHECKPOINT_INTEGRITY( checkpoint ) REQUIRE
VERIFY_CHECKPOINT_NOT_ROLLED_BACK( checkpoint )
8.5.3.43. Original global source page 1427
records = journal_store .LOAD_SUBSEQUENT_DURABLE_RECORDS( checkpoint
) REQUIRE VERIFY_JOURNAL_SEQUENCE_AND_INTEGRITY( records ) state =
RECONSTRUCT_AUTHORITATIVE_FINALITY_STATE( checkpoint, records ) FOR
EACH operation IN state.unresolved_operations: IF
operation.external_dispatch_may_have_occurred:
APPLY_INDETERMINATE_OUTCOME_FENCE( operation ) ELSE: REQUIRE
QUALIFIED_NON_DISPATCH_EVIDENCE_BEFORE_RETRY( operation )
INVALIDATE_STALE_WORKER_GENERATIONS() RETURN
protected_recovery_controller
.COMMIT_RECOVERED_AUTHORITATIVE_STATE(state)
Recovered authority state must not be derived solely from a
requester-controlled snapshot.
16.40 — REFERENCE PSEUDOCODE: OLD-WORKER FENCING
FUNCTION VERIFY_DISPATCHER_FENCING( incoming_operation,
protected_effectuation_sink ): current_generation =
protected_effectuation_sink
.LOAD_AUTHORITATIVE_DISPATCHER_GENERATION() REQUIRE
incoming_operation.dispatcher_generation == current_generation
REQUIRE VERIFY_LOGICAL_OPERATION_BINDING(
8.5.3.44. Original global source page 1428
incoming_operation ) REQUIRE
VERIFY_CURRENT_FINALITY_AND_DISPATCH_STATE( incoming_operation )
REQUIRE VERIFY_NO_INCOMPATIBLE_COMPLETED_EFFECT( incoming_operation )
RETURN CURRENT_DISPATCHER_ELIGIBLE
The check is effective only where the actual consequential sink
enforces it.
16.41 — WORKED EXAMPLE A: CRASH BEFORE LOCAL DATABASE COMMIT
An autonomous agent prepares a valid database update.
The protected Finality Sink verifies the actual record and mutation.
Das Expires 29 April 2027 [Page 253]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A transactional commit includes both the resource update and the
single-use finality-consumption state.
The process crashes before the transaction commits.
After recovery, the protected database establishes that the
transaction did not commit.
Neither the protected resource mutation nor the corresponding
finality consumption is treated as completed.
A subsequent operation remains subject to current authorization and
resource-state verification.
Expected demonstrable result: A local atomic transaction does not
leave the claimed resource mutation committed without its associated
finality state.
16.42 — WORKED EXAMPLE B: CRASH AFTER LOCAL DATABASE COMMIT
A protected database mutation and authority consumption commit
atomically.
The requester crashes before receiving confirmation.
Upon restart, the agent attempts to submit the same operation again.
The resource sink identifies the committed logical operation and
consumed authority.
8.5.3.45. Original global source page 1429
The protected resource mutation is not applied again.
The controller may return the qualified earlier result.
Expected demonstrable result: A lost client response does not produce
a second mutation within the supported local transaction domain.
16.43 — WORKED EXAMPLE C: CRASH AFTER REMOTE DISPATCH INTENT
An agent prepares a remote transaction.
The protected controller durably consumes the corresponding finality
authority and commits the exact dispatch intent.
The dispatcher crashes before it can establish whether the request
was sent.
Das Expires 29 April 2027 [Page 254]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
After restart, the journal identifies the same logical operation and
consumed authority.
The recovered dispatcher does not invent a new authorized
transaction.
It determines whether the selected protocol permits retransmission of
the same operation or requires qualified receiver reconciliation.
Expected demonstrable result: Crash recovery preserves the original
operation identity and does not create fresh finality authority.
16.44 — WORKED EXAMPLE D: RECEIVER PROCESSED PAYMENT, RESPONSE LOST
An autonomous financial agent is authorized to execute one bounded
payment.
The Finality Sink durably consumes the authority and dispatches the
committed payment request.
The receiving transaction service atomically records the logical
payment identifier and completes the transaction.
The acknowledgement is lost.
The sender enters an indeterminate-outcome state.
A qualified status check later establishes the committed payment.
The protected controller records completion and refuses a second
independent payment.
8.5.3.46. Original global source page 1430
Expected demonstrable result: Missing acknowledgement does not
automatically produce a duplicate payment.
16.45 — WORKED EXAMPLE E: RECEIVER DEDUPLICATES SAME LOGICAL
OPERATION
An authorized protected dispatch is repeated under a verified retry-
safe protocol.
The destination receives the same logical identifier and identical
operation parameters.
Its transactional registry identifies the earlier committed
operation.
Das Expires 29 April 2027 [Page 255]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The destination returns the previously committed result rather than
applying another resource mutation.
If the second request uses a different amount or target with the same
identifier, it is rejected as incompatible.
Expected demonstrable result: The receiver does not treat an
operation identifier as permission to change the underlying effect.
16.46 — WORKED EXAMPLE F: IDEMPOTENCY RETENTION EXPIRED
A remote service maintains duplicate-suppression records for a
bounded period.
An original operation may have completed, but the sender lacks
confirmation.
A retry is proposed after the retention period.
The destination can no longer guarantee that the original identifier
will be recognized.
The protected retry controller refuses to treat the old identifier as
sufficient proof of safety.
It requires qualified outcome reconciliation or separately valid
recovery authority.
Expected demonstrable result: The system does not falsely extend
receiver duplicate-suppression guarantees beyond their actual
supported retention.
16.47 — WORKED EXAMPLE G: TWO RECOVERY WORKERS
An autonomous service crashes during a remote transaction.
Two replacement workers are started.
8.5.3.47. Original global source page 1431
Both discover the same unresolved operation in the durable journal.
The protected coordinator assigns current dispatch authority under a
new generation.
One worker obtains the eligible protected dispatch or reconciliation
role.
Das Expires 29 April 2027 [Page 256]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The other lacks current authority.
A stale worker cannot exercise the effectuation command at the
resource sink.
Expected demonstrable result: Multiple recovery workers do not
automatically multiply the permitted consequential operation.
16.48 — WORKED EXAMPLE H: FORMER LEADER RESUMES
A distributed controller loses connectivity.
A new leader is elected under a protected generation.
The previous leader later resumes and attempts to transmit a delayed
command.
The actual effectuation sink verifies current dispatcher generation.
The stale command is rejected.
A local lease variable stored by the old leader is not sufficient to
bypass the protected receiver-side fence.
Expected demonstrable result: Leadership transfer invalidates stale
consequential dispatch authority at the actual resource boundary.
16.49 — WORKED EXAMPLE I: EXTERNAL INFORMATION DISCLOSURE
An autonomous agent is authorized to send one protected document to a
specified recipient.
The release sink consumes the corresponding privacy and finality
authorization.
The message is transmitted.
The network connection fails before the sender receives
acknowledgement.
The system preserves the fact that the information may have been
disclosed.
It does not automatically restore the disclosure allowance or resend
the document to another recipient.
Das Expires 29 April 2027 [Page 257]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.5.3.48. Original global source page 1432
Further release requires the applicable current privacy and authority
predicates.
Expected demonstrable result: A transmission uncertainty cannot be
used to bypass protected cumulative information-disclosure limits.
16.50 — WORKED EXAMPLE J: PHYSICAL ACTUATOR COMMAND
A robot receives a bounded movement command.
Its protected controller durably records command identity and
acceptance state.
The actuator begins moving.
The supervising process crashes.
Upon restart, the recovery controller does not assume that the
actuator remains at its starting position.
It obtains qualified current device-state evidence.
Where the physical outcome is uncertain, a new movement command
remains separately governed.
Expected demonstrable result: A software restart does not
automatically cause repetition of a physical command that may already
have produced an effect.
16.51 — WORKED EXAMPLE K: SNAPSHOT RESTORES OLD JOURNAL VIEW
An agent is authorized for one consequential effect.
The Finality Sink consumes the authority and records current
protected state.
The agent later restores a snapshot showing an earlier unused
enablement.
The protected journal controller maintains a current monotonic
generation outside the agent's copyable state.
The sink detects the stale authority generation.
The proposed duplicate effect is rejected.
Das Expires 29 April 2027 [Page 258]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Expected demonstrable result: An untrusted snapshot does not recreate
consumed protected finality authority.
8.5.3.49. Original global source page 1433
16.52 — WORKED EXAMPLE L: CRASH BETWEEN RECEIVER REGISTRY AND
MUTATION
A receiver implements duplicate suppression using two independent
nontransactional writes.
It first records an operation identifier, then attempts the resource
mutation.
A crash occurs between those steps.
A later retry sees the identifier and incorrectly assumes the
mutation completed.
The proposed stronger receiver protocol commits the relevant
operation record and resource mutation atomically where the resource
supports it.
Alternatively, the implementation must establish another suitable
correspondence mechanism and state its actual guarantee.
Expected demonstrable result: A receiver cannot claim strong
processing uniqueness solely from an idempotency-key table that may
diverge from the actual resource effect.
16.53 — WORKED EXAMPLE M: PARTIALLY COMPLETED MULTI-SERVICE WORKFLOW
An autonomous workflow performs three consequential service
operations.
The first service confirms a protected resource mutation.
The second service's effect remains uncertain.
The third operation has not been authorized for actual execution.
The journal maintains the individual effect references and qualified
states.
The system does not classify the entire workflow as unsuccessful
merely because the second service timed out.
Das Expires 29 April 2027 [Page 259]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A dependent third phase requires the specified prior-effect evidence
and its own current authority.
Any compensation is treated as a separate consequential operation.
Expected demonstrable result: Durable recovery preserves partial
real-effect state and prevents unsupported successor execution.
16.54 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
8.5.3.50. Original global source page 1434
16.54.1 — Duplicate Request Submission
An agent sends the same logical effect several times.
Protected authority and receiver-side state constrain repeated
execution.
16.54.2 — Forged Journal Entry
An attacker inserts a fabricated finality transition.
Protected record authentication rejects unauthorized state.
16.54.3 — Journal Rollback
An attacker restores an older accepted journal.
Current authoritative generation prevents revival of consumed
authority.
16.54.4 — Journal Truncation
An attacker removes recent consumption records.
Protected checkpoints or other authoritative state detect invalid
historical restoration.
16.54.5 — Journal Reordering
An attacker changes the apparent order of transitions.
Protected sequence and transition validation reject invalid state.
16.54.6 — Torn Write
A crash interrupts journal persistence.
Das Expires 29 April 2027 [Page 260]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The transaction or record-integrity mechanism prevents an incomplete
entry from being treated as committed.
16.54.7 — False Durability Claim
An application claims successful durable commit before the required
storage barrier.
The implementation must rely upon actual persistence guarantees.
16.54.8 — Dispatch Without Durable Intent
A process attempts an external effect before required protected
dispatch state is committed.
The controlled dispatcher refuses release.
16.54.9 — Consumed Authority Reissued
8.5.3.51. Original global source page 1435
An agent requests the same single-use capability after a timeout.
Current protected consumption state rejects unauthorized restoration.
16.54.10 — Stale Snapshot
A restarted agent presents a previously valid old reference.
Monotonic generation checks reject it.
16.54.11 — Concurrent Consumption
Several agents race to exercise one finality allowance.
An authoritative protected transition prevents duplicate consumption.
16.54.12 — Double Recovery Worker
Several workers independently resume one operation.
Protected dispatcher generation and operation state restrict
competing attempts.
16.54.13 — Stale Leader
A former coordinator submits commands after leadership transfer.
Das Expires 29 April 2027 [Page 261]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The actual sink verifies fencing generation.
16.54.14 — Operation Identifier Collision
Different effects use the same logical identifier.
Protected operation-digest binding detects the mismatch.
16.54.15 — Payload Substitution
A dispatcher changes the committed outgoing payload.
Actual dispatch and receiver verification reject the mismatch.
16.54.16 — Recipient Substitution
A committed transaction is redirected toward another destination.
Protected destination binding rejects unauthorized redirection.
16.54.17 — Receiver Registry Deletion
A receiver loses duplicate-suppression history.
8.5.3.52. Original global source page 1436
The system cannot rely upon a guarantee no longer established.
16.54.18 — Receiver Registry Rollback
A previously processed operation appears new after destination-state
restoration.
Strong guarantees require appropriately protected receiver
persistence or other sufficient effect uniqueness controls.
16.54.19 — Registry/Effect Nonatomicity
The receiver records an identifier separately from the mutation.
The protected implementation requires an appropriate correspondence
or states weaker guarantees.
16.54.20 — Expired Idempotency Key
An attacker retries after deduplication retention ends.
The protected retry controller demands current verified safety.
Das Expires 29 April 2027 [Page 262]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
16.54.21 — Status Query False Negative
A receiver reports no record despite a possible earlier effect.
The system evaluates whether that response conclusively supports non-
effectuation.
16.54.22 — Forged Success Receipt
An attacker supplies false receiver completion evidence.
The outcome verifier requires authenticated qualified observation.
16.54.23 — Forged Failure Receipt
An attacker falsely claims the original effect did not occur.
The protected controller checks negative-effect evidence.
16.54.24 — Lost Acknowledgement
A successful external operation has no sender-visible response.
The state remains indeterminate until adequately reconciled.
16.54.25 — Timeout-As-Retry Authority
An agent treats timeout as permission to create a new effect.
8.5.3.53. Original global source page 1437
The indeterminate-outcome fence rejects the inference.
16.54.26 — Backoff Misuse
A requester waits and then resubmits an unsafe operation.
Elapsed time does not substitute for outcome evidence.
16.54.27 — Resource Version Drift
A resource changes between authorization and actual effect.
The sink verifies current resource conditions.
16.54.28 — Tool Semantic Change
A retried command gains additional side effects.
Das Expires 29 April 2027 [Page 263]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Current operation-contract and effect binding reject unauthorized
changes.
16.54.29 — Cross-Sink Replay
One consumed authority is presented at another effectuation sink.
Protected designated-sink and coordination state reject invalid
reuse.
16.54.30 — Distributed Split Brain
Multiple controllers simultaneously claim authoritative consumption
control.
The implementation requires appropriate coordination or bounded
nonoverlapping authority.
16.54.31 — Network Partition
The destination's status cannot be queried.
The system preserves indeterminate state rather than inventing
completion or failure.
16.54.32 — Privacy Budget Recredit
An uncertain disclosure is incorrectly treated as never transmitted.
Protected exposure accounting retains appropriate charge or
uncertainty.
16.54.33 — Physical Command Replay
A device command is reissued after uncertain actuation.
Protected hardware and actual-state verification constrain retry.
8.5.3.54. Original global source page 1438
16.54.34 — Unauthorized Compensation
An agent attempts to reverse a possibly nonexistent effect.
The correction requires separate qualified recovery authority.
16.54.35 — Residual Effect Misclassification
Das Expires 29 April 2027 [Page 264]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A compensation is incorrectly described as deleting all earlier
consequences.
The system preserves qualified actual and residual effect state.
16.54.36 — Cryptographic Identifier Reuse
A nonce or transaction identifier is reused in an incompatible
protected context.
Identity, generation, and operation bindings prevent unauthorized
acceptance.
16.54.37 — Journal Verification Exhaustion
An attacker supplies excessively large or malformed journal data.
Protected verification work is bounded.
16.54.38 — Checkpoint Forgery
An attacker provides an invalid protected checkpoint.
Current authoritative authentication and generation checks reject it.
16.54.39 — Compromised Dispatcher
A dispatcher attempts an effect outside the committed intent.
The actual resource sink enforces current operation-specific
authority.
16.54.40 — Compromised Finality Sink
The protected consequential interface is compromised.
A stronger guarantee requires an appropriately protected remaining
enforcement boundary.
16.54.41 — Cross-Provider State Confusion
Remote systems associate one operation identifier with differing
authority assumptions.
The receiver verifies the relevant authenticated operation and scope.
16.54.42 — Offline Authority Duplication
Das Expires 29 April 2027 [Page 265]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.5.3.55. Original global source page 1439
Two disconnected nodes exercise the same unpartitioned authority.
The selected coordination must prevent such duplication or withhold
affected effects.
16.54.43 — Hardware Counter Reset
An untrusted device resets a local counter.
Authoritative protected generation state must be maintained under the
specified hardware trust model.
16.54.44 — Emergency Retry Abuse
An agent claims urgency to bypass indeterminate-outcome fencing.
Emergency authority must be independently authenticated and bounded.
16.54.45 — Causal Receipt Misuse
A sender dispatch record is presented as evidence of remote effect
completion.
The protected successor verifier requires the correct qualified
actual-effect evidence.
16.55 — CRASH-INJECTION MATRIX
A non-limiting crash-injection test may examine these boundaries:
Crash Point A — Before operation preparation. No current committed
Candidate Act is presumed.
Crash Point B — During journal preparation. Incomplete entries are
not treated as durable finality state.
Crash Point C — After durable preparation but before consumption.
Current authoritative state determines eligibility for the next valid
transition.
Crash Point D — During authority consumption. Transaction-state
reconciliation determines whether consumption committed.
Das Expires 29 April 2027 [Page 266]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Crash Point E — After consumption but before dispatch intent. A
correct implementation must not allow the external effect to occur
through an unrecorded authority transition; the chosen protocol must
preserve or reconcile any incomplete coupling state.
Crash Point F — After atomic consumption and dispatch-intent
commitment. The committed logical operation remains identifiable;
retransmission requires the selected safety predicates.
Crash Point G — During transmission. External effectuation may be
uncertain.
8.5.3.56. Original global source page 1440
Crash Point H — After receiver acceptance but before resource
mutation. The receiver's stated guarantee determines whether the
effect can be recovered safely.
Crash Point I — During receiver mutation. Protected destination
transaction semantics determine the supported outcome.
Crash Point J — After receiver commit but before acknowledgement. A
retry must not create an additional mutation where strong receiver
deduplication is claimed.
Crash Point K — After sender receives acknowledgement but before
outcome journaling. Durable receiver evidence may support qualified
reconciliation.
Crash Point L — After outcome commit but before requester
notification. The requester may receive the previously committed
result without repeating the effect.
Crash Point M — During journal checkpoint. The authoritative prior
consumption and unresolved-effect state remain recoverable.
Crash Point N — During workload migration. Old ownership and
dispatch generations are appropriately fenced.
Crash Point O — During distributed controller failover. New
leadership does not permit stale workers to issue unmediated
commands.
Each point should be tested against actual resource effects, not only
software return codes.
16.56 — PRESENT-DAY PHOSITA REFERENCE IMPLEMENTATION
Das Expires 29 April 2027 [Page 267]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
16.56.1 — Minimum Prototype
A feasible reference implementation may comprise:
An autonomous-agent process;
A protected Finality Sink;
An authoritative transactional journal;
A durable dispatch-intent queue;
A receiving transactional service;
A receiver-side operation registry;
And an outcome reconciliation controller.
16.56.2 — Protected Candidate Act
8.5.3.57. Original global source page 1441
The agent proposes one bounded resource mutation.
16.56.3 — Finality Validation
The sink verifies current actual-operation scope and non-bearer
authority.
16.56.4 — Durable Journal
The controller commits the required operation, authority, and
dispatch state.
16.56.5 — Receiver-Side Registry
The receiver records logical operation identity and resource mutation
in one protected transaction where supported.
16.56.6 — Crash Injection
The prototype deliberately interrupts the sender at selected state
boundaries.
16.56.7 — Duplicate Submission
The agent submits the same logical operation several times.
Das Expires 29 April 2027 [Page 268]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
16.56.8 — Lost Acknowledgement
The receiver commits an effect but the sender's response is
suppressed.
16.56.9 — Receiver Reconciliation
The protected controller obtains qualified current result evidence.
16.56.10 — Stale Snapshot
The requester restores old local authority state.
16.56.11 — Old Worker
A previous dispatcher attempts execution after failover.
16.56.12 — External Resource Limit
The prototype distinguishes exactly-once local consumption from the
actual receiver guarantees.
16.56.13 — Hardware Extension
A protected device command controller may provide current operation
generation and durable acceptance state.
16.56.14 — Trust Model
8.5.3.58. Original global source page 1442
The implementation must specify the actual storage, receiver,
dispatcher, and Finality-Sink components required to remain
protected.
16.57 — NON-LIMITING PROPOSED FEASIBILITY EXPERIMENTS
The following experiments are proposed and are not represented as
completed results.
Experiment 1 — Valid Single-Use Finality: Commit one authorized
operation and corresponding consumption state.
Experiment 2 — Local Atomic Commit: Verify that a resource mutation
and authority consumption commit together.
Experiment 3 — Local Atomic Abort: Verify that neither claimed local
effect nor consumption commits after transaction abort.
Das Expires 29 April 2027 [Page 269]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Experiment 4 — Crash Before Preparation: Confirm the absence of
assumed committed authority.
Experiment 5 — Crash During Journal Write: Test incomplete journal
entry handling.
Experiment 6 — Crash After Durable Preparation: Recover current
protected operation state.
Experiment 7 — Crash During Consumption: Reconcile whether the atomic
transition committed.
Experiment 8 — Crash After Consumption: Reject attempted revival of
consumed authority.
Experiment 9 — Atomic Dispatch Intent: Verify protected coupling
between consumption and dispatch intent.
Experiment 10 — Crash After Intent: Recover the exact committed
external operation.
Experiment 11 — Crash During Transmission: Preserve an indeterminate
outcome.
Experiment 12 — Receiver Success, Response Lost: Reconcile committed
external effect without reapplying it.
Experiment 13 — Receiver Rejection: Verify qualified non-effecting
rejection state.
Experiment 14 — Partial Receiver Effect: Preserve component-specific
completed and unresolved state.
Experiment 15 — Duplicate Client Request: Test protected logical
operation identity.
8.5.3.59. Original global source page 1443
Experiment 16 — Duplicate Queue Delivery: Verify receiver handling of
repeated delivery.
Experiment 17 — Receiver Atomic Deduplication: Commit operation
registry and resource effect together.
Experiment 18 — Receiver Nonatomic Registry: Expose the failure modes
of separate registry and mutation writes.
Das Expires 29 April 2027 [Page 270]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Experiment 19 — Idempotency Parameter Mismatch: Reuse one identifier
with changed operation parameters.
Experiment 20 — Idempotency Retention Expiry: Test retry refusal
after duplicate-suppression evidence becomes insufficient.
Experiment 21 — Forged Receiver Receipt: Reject untrusted completion
evidence.
Experiment 22 — Forged Failure Record: Reject unsupported assertions
of non-effectuation.
Experiment 23 — Qualified Status Query: Confirm a completed external
effect.
Experiment 24 — Status Query False Negative: Ensure incomplete
negative evidence does not authorize retry.
Experiment 25 — Indeterminate Fence: Verify suppression of unsafe
effecting requests.
Experiment 26 — Observation-Only Reconciliation: Permit safe status
checking while effects remain fenced.
Experiment 27 — Verified Non-Effectuation: Permit consideration of a
bounded new attempt under current authority.
Experiment 28 — Verified Receiver Idempotency: Test safe same-
logical-operation retransmission.
Experiment 29 — Expired Receiver State: Withhold retransmission when
the guarantee is no longer supported.
Experiment 30 — Concurrent Authority Consumption: Attempt two
simultaneous uses of one single-use enablement.
Experiment 31 — Journal Snapshot Rollback: Restore stale consumption
state and verify rejection.
Experiment 32 — Journal Truncation: Detect invalid removal of
protected recent transitions.
Experiment 33 — Journal Reordering: Reject inconsistent protected
sequence state.
Das Expires 29 April 2027 [Page 271]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.5.3.60. Original global source page 1444
Experiment 34 — Forged Checkpoint: Reject an unauthenticated
compressed journal state.
Experiment 35 — Checkpoint Recovery: Restore valid authority and
unresolved-effect state.
Experiment 36 — Dual Recovery Workers: Prevent unauthorized duplicate
recovery attempts.
Experiment 37 — Stale Leader: Reject an old dispatch generation at
the actual sink.
Experiment 38 — Distributed Consumption State: Verify protected
coordination of several sinks.
Experiment 39 — Network Partition: Preserve the required safety
properties while remote outcome evidence is unavailable.
Experiment 40 — Bounded Offline Partitioning: Verify nonoverlapping
preallocated authority under specified assumptions.
Experiment 41 — Payment Transaction: Demonstrate current amount,
recipient, and logical-effect binding.
Experiment 42 — Database Mutation: Demonstrate atomic local resource
and authority commit.
Experiment 43 — File Commit: Verify version-bound mutation and
consumption state.
Experiment 44 — Message Publication: Distinguish durable outbox
commit from receiver processing.
Experiment 45 — Data Disclosure: Preserve the possibility of actual
disclosure after lost acknowledgement.
Experiment 46 — Device Command: Distinguish command acceptance,
dispatch, and physical completion.
Experiment 47 — Partial Physical Actuation: Obtain qualified actual
device-state evidence before recovery.
Experiment 48 — Credential Activation: Prevent reactivation of
already consumed protected authority.
Das Expires 29 April 2027 [Page 272]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Experiment 49 — Cross-Domain Finality: Verify journaled authority and
receiver effects across independent administrative domains.
Experiment 50 — Causal Receipt Integration: Require accepted actual-
effect evidence for a dependent successor Candidate Act.
Experiment 51 — Protected Recovery Integration: Treat compensation as
a distinct current consequential operation.
8.5.3.61. Original global source page 1445
Experiment 52 — Version-Bound Reservation: Verify actual resource
state after interruption.
Experiment 53 — Quorum-Authorized Operation: Preserve collective
approval without confusing it with actual remote completion.
Experiment 54 — Coverage Change: Invalidate stale finality or
dispatch authority after a material enforcement-path change.
Experiment 55 — Model Replacement: Ensure a restarted or changed
model does not recreate consumed authority.
Experiment 56 — Tool Semantics Change: Reject a retry whose real
downstream effect differs from the committed operation.
Experiment 57 — Hardware Ownership Migration: Fence former-owner
commands after controlled reassignment.
Experiment 58 — Privacy Budget Accounting: Prevent uncertain
information releases from incorrectly restoring consumed privacy
allowance.
Experiment 59 — Verification Work Exhaustion: Bound processing of
malformed or excessive journal evidence.
Experiment 60 — Full Crash Matrix: Execute the principal protected
workflow with interruptions at every defined state boundary.
Experiment 61 — No Receiver Deduplication: Demonstrate the limitation
of exactly-once local authority without strong destination
guarantees.
Experiment 62 — Receiver Deduplication Present: Demonstrate the
stronger result available under qualified destination-side
transaction semantics.
Das Expires 29 April 2027 [Page 273]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Experiment 63 — No Public Blockchain: Maintain protected journal,
authority consumption, and recovery state through ordinary suitable
protected transactional infrastructure.
Experiment 64 — Hardware Journal: Implement selected monotonic state
in protected device or security hardware.
Experiment 65 — Independent Outcome Witness: Require qualified
external observation of a consequential effect.
Experiment 66 — Cross-Sink Replay: Present one logical operation and
authority at unintended resource interfaces.
Experiment 67 — Retired Journal Entry: Verify that safe compaction
does not recreate authority or erase unresolved effects.
8.5.3.62. Original global source page 1446
Experiment 68 — Controlled Exactly-Once Authorization: Measure that
only one permitted protected consumption transition commits under the
stated coordination model.
Experiment 69 — Remote Outcome Qualification: Demonstrate that the
same local-consumption result can correspond to confirmed remote
success, confirmed rejection, or indeterminate remote outcome.
Experiment 70 — End-to-End Evidence-to-Outcome: Verify the complete
protected relationship among actual operation reconstruction,
evidence-qualified finality, durable consumption, dispatch intent,
receiver result, and current reconciliation state.
Each experiment should identify the precise claimed guarantee and the
technical evidence that establishes it.
16.58 — PERFORMANCE, AVAILABILITY, AND INDUSTRIAL ENGINEERING
16.58.1 — Durable Write Cost
Protected persistence barriers may add latency to consequential
operations.
16.58.2 — Group Commit
Suitable implementations may batch journal persistence where the
claimed ordering and authority guarantees remain preserved.
16.58.3 — Journal Compaction
Das Expires 29 April 2027 [Page 274]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Authenticated checkpoints may reduce long-term storage requirements.
16.58.4 — Receiver Lookup
Operation identifiers may support efficient destination-side
duplicate checks.
16.58.5 — Protected State Caching
Read-only operation history may be cached within current
authoritative validity rules.
16.58.6 — Monotonic Counters
Appropriate counters or version generations may provide compact
consumption-state checks.
16.58.7 — Distributed Coordination
Global uniqueness across multiple sinks may impose consensus or
coordination overhead.
16.58.8 — Partition Availability
8.5.3.63. Original global source page 1447
The implementation may deliberately withhold effects when current
authority or outcome safety cannot be established.
16.58.9 — Retry Work Budget
A protected controller may limit status queries, retransmissions, and
reconciliation work.
16.58.10 — Receiver Retention Cost
Longer deduplication retention may require additional destination
storage.
16.58.11 — Hardware Persistence
Embedded systems may use suitable nonvolatile memory or protected
device state.
16.58.12 — Real-Time Requirements
Das Expires 29 April 2027 [Page 275]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A latency-sensitive device may require an implementation-specific
protected journal and command controller with bounded timing
behavior.
16.58.13 — Safety Qualification
Reduced latency must not depend upon silently removing mandatory
authority or current-effect verification.
16.58.14 — Assurance Statement
The implementation must state which of local authority uniqueness,
local transaction atomicity, dispatch uniqueness, receiver effect
uniqueness, and external completion are actually guaranteed.
16.59 — OPTIONAL ADVANCED FUTURE-ORIENTED CONCEPTS
16.59.1 — Long-Running Autonomous Agent Journals
Agents may preserve protected effect state across many sessions
without reviving consumed authority.
16.59.2 — Multi-Provider Transaction Continuity
Independently administered providers may exchange authenticated
logical effect and qualified outcome references.
16.59.3 — Cross-Cloud Protected Dispatch
Remote operations may retain durable operation identity and authority
across cloud-service changes.
8.5.3.64. Original global source page 1448
16.59.4 — Confidential-Computing Journal Services
Protected computing environments may maintain authenticated authority
and dispatch state.
16.59.5 — Hardware Security Modules
Protected hardware may enforce selected monotonic finality state.
16.59.6 — Accelerator Command Journaling
Command submissions and effectful accelerator operations may be
associated with protected durable operation state.
Das Expires 29 April 2027 [Page 276]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
16.59.7 — Robotic Command Continuity
Autonomous robots may distinguish actual motion, command acceptance,
and uncertain command outcome following controller restarts.
16.59.8 — Industrial Device Recovery
Protected equipment may retain durable consequential command identity
through power interruptions.
16.59.9 — Network Configuration Transactions
Programmable network devices may journal qualified accepted changes
and prevent unsafe replay.
16.59.10 — Satellite and Intermittent Connectivity
Remote infrastructure may maintain bounded protected effect state
during communication outages.
16.59.11 — Privacy-Preserving Receiver Evidence
A receiving domain may provide qualified outcome evidence without
unnecessarily disclosing protected resource contents.
16.59.12 — Cryptographic Key Migration
Journal authentication primitives may change while protected
authority and consumption continuity remain intact.
16.59.13 — Future Shared Execution Fabric
Distributed compute and hardware systems may use common logical
operation and monotonic consumption protocols.
16.59.14 — Autonomous Financial Infrastructure
8.5.3.65. Original global source page 1449
Consequential transactions may be protected from duplicate execution
following orchestration or network faults.
16.59.15 — Causal Multi-Effect Systems
Dependent effects may require accepted earlier outcome evidence in
addition to durable current authorization.
16.59.16 — Dynamic Workload Migration
Das Expires 29 April 2027 [Page 277]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Protected dispatch generations may prevent former execution
environments from reusing consequential authority.
16.59.17 — Hardware-Level Receiver Deduplication
A device may record command identities and effect state under
suitable protected transaction or controller semantics.
16.59.18 — Distributed Authority Partitioning
Nonoverlapping bounded authority may support some disconnected
operations without duplicate use.
16.59.19 — Autonomous Recovery Governance
Recovery Candidate Acts may be journaled and consumed under the same
protected finality principles.
16.59.20 — Unified Finality Outcome Service
A protected service may provide authenticated operation journals,
consumption state, receiver evidence, and outcome reconciliation
across heterogeneous execution systems.
These implementations are proposed technical variations.
16.60 — OPTIONAL ADVANCED TECHNICAL COMBINATIONS
16.60.1 — Actual Operation Reconstruction Plus Durable Journal
The journal commits the actual operation verified by the Finality
Sink rather than an untrusted earlier description.
16.60.2 — Non-Bearer Finality Plus Monotonic Consumption
A copied authority reference cannot produce another valid consumption
after the permitted use is committed.
16.60.3 — Consumption Plus Dispatch Intent
8.5.3.66. Original global source page 1450
The exact external operation is durably associated with consumed
finality authority.
16.60.4 — Receiver Deduplication Plus Actual Mutation
Das Expires 29 April 2027 [Page 278]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A receiver binds logical operation identity to its actual committed
resource effect under a suitable transactional guarantee.
16.60.5 — Indeterminate Outcome Plus Retry Fence
A missing acknowledgement cannot independently activate a new effect.
16.60.6 — Qualified Non-Effectuation Plus New Authority
A new attempt may be considered only after sufficient evidence and
current operation-specific permission.
16.60.7 — Current Leader Generation Plus Sink Enforcement
A former dispatcher cannot effect commands after a protected
generation transfer.
16.60.8 — Snapshot Rollback Plus Protected Journal
A restored workload cannot restore consumed authority or erase
unresolved external effects.
16.60.9 — Multi-Sink Coordination Plus Partitioned Authority
Distributed effectuation may require shared authoritative consumption
or bounded nonoverlapping allocations.
16.60.10 — Causal Receipt Plus Qualified Outcome
A dependent successor operation may require accepted earlier actual-
effect evidence rather than a mere dispatch log.
16.60.11 — Privacy Accounting Plus Dispatch Uncertainty
Potentially completed disclosures remain appropriately represented in
protected cumulative exposure state.
16.60.12 — Hardware Command Plus Actual Physical Observation
Command journal state may be combined with independently qualified
physical-effect evidence.
16.60.13 — Recovery Authorization Plus Journaled Earlier Outcome
Corrective operations remain distinct from the original consumed
finality authority.
16.60.14 — Current Coverage Plus Journal Continuity
Das Expires 29 April 2027 [Page 279]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.5.3.67. Original global source page 1451
Topology changes may invalidate stale dispatch or finality paths
without erasing historical actual-effect state.
16.61 — PROPOSED INVENTIVE-STEP ANALYSIS
16.61.1 — Established Prior Art
Write-ahead logging, transactional outbox systems, idempotent
receivers, duplicate suppression, transactional commit, distributed
consensus, receiver operation registries, replay-resistant
identifiers, checkpoint recovery, and transaction reconciliation are
established technical areas.
The embodiment does not claim these individually.
16.61.2 — Candidate Objective Technical Problem
A candidate objective technical problem is:
How to maintain non-replayable operation-specific execution-finality
authority and safely reconcile actual consequential outcomes across
crashes, retries, and distributed failures when the protected
authorization-consumption event may not be atomic with the external
physical or remote effect.
16.61.3 — Candidate Technical Solution
A candidate combination comprises:
Actual Finality-Sink operation reconstruction;
Authenticated evidence-qualified operation authority;
Durable operation-specific finality journal state;
A monotonic protected consumption generation;
Atomic coupling of consumed authority and dispatch intent;
Receiver-side operation identity and qualified duplicate suppression
where supported;
Indeterminate-outcome fencing;
And independently verified outcome-based continuation or recovery.
Das Expires 29 April 2027 [Page 280]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
16.61.4 — Technical Interaction
The actual Finality Sink determines the real operation rather than
trusting an earlier computational intention.
8.5.3.68. Original global source page 1452
The evidence verifier establishes current authority.
The durable journal preserves the accepted operation and its finality
state.
The consumption controller prevents restoration or unauthorized
repeated exercise.
The dispatch-intent controller binds external transmission to the
protected logical operation.
The receiver registry may prevent repeated application of the same
logical effect.
The outcome verifier distinguishes actual completion from
uncertainty.
The retry fence prevents an unresolved operation from becoming an
independent new consequential authorization.
The recovery controller may later authorize a separate corrective
operation under appropriate qualified evidence.
16.61.5 — Not Merely a Write-Ahead Log
A journal may preserve state but does not independently determine
whether the original operation was authorized or whether an external
effect occurred.
The proposed arrangement binds durable state to actual Finality-Sink
operation verification and protected non-bearer authority.
16.61.6 — Not Merely an Outbox
A transactional outbox may reliably retain messages for delivery.
The proposed arrangement additionally restricts dispatch to the
precise effect whose finality authority has been independently
validated and durably consumed.
16.61.7 — Not Merely Idempotency
Das Expires 29 April 2027 [Page 281]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Idempotency may constrain repeated operations under receiver-specific
assumptions.
The proposed architecture additionally governs source authority,
actual operation binding, journal continuity, and protected outcome
classification.
16.61.8 — Not Merely a Single-Use Token
A single-use authorization may prevent repeated local consumption.
The proposed stronger relationship explicitly governs crashes between
consumption and actual external effectuation.
16.61.9 — Not Merely Transaction Recovery
Conventional recovery may restore an internal computational workflow.
8.5.3.69. Original global source page 1453
The proposed principal arrangement prevents the recovery process from
reconstructing fresh consequential authority merely because earlier
external completion was unobserved.
16.61.10 — Candidate Narrow Inventive Kernel
A protected autonomous consequential execution system in which an
independently enforcing Finality Sink reconstructs an actual pending
operation, verifies operation-specific non-bearer authority, durably
binds a monotonic authority-consumption transition to an
authenticated dispatch-intent record for that operation, and
maintains protected indeterminate-outcome state that prevents
unsupported repeat effectuation until qualified destination evidence,
a verified idempotent retry condition, or separately authorized
recovery permits a defined successor transition.
16.61.11 — Additional Local Transaction Kernel
A narrower candidate may require one atomic transaction associating
an actual protected resource mutation with operation-specific
finality consumption.
16.61.12 — Additional Receiver Kernel
Another candidate may require authenticated logical effect identity
and receiver-side atomic binding of duplicate state to the actual
committed resource mutation.
Das Expires 29 April 2027 [Page 282]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
16.61.13 — Additional Anti-Rollback Kernel
Another candidate may require protected monotonic finality
generations and journal checkpoint continuity preventing workload or
state restoration from reviving consumed authority.
16.61.14 — Additional Hardware Kernel
Another candidate may require durable device-command acceptance
state, current hardware authority, and qualified physical-effect
observation before repeat actuation.
16.61.15 — Hindsight Considerations
A proper inventive-step analysis should consider established
transactional messaging systems, secure payment gateways, capability-
based transaction controls, idempotent APIs, replicated transaction
logs, and existing fault-tolerant resource controllers.
A claim to journaling a permission and checking an idempotency key
may be obvious.
A stronger claim should identify the particular non-bypassable
binding among actual-effect reconstruction, protected finality
consumption, durable dispatch intent, and outcome-dependent authority
transitions.
16.61.16 — Patentability Qualification
Terminology such as exactly-once authorization, protected journal, or
outcome fence does not independently establish novelty.
8.5.3.70. Original global source page 1454
The attainable guarantees depend upon actual storage, network,
receiver, and resource-effect semantics.
A system must not claim universal exactly-once physical or remote
effectuation without a technically sufficient implementation and
supporting evidence.
16.62 — INDUSTRIAL APPLICABILITY
16.62.1 — Enterprise Autonomous Agents
Autonomous enterprise workflows may retain safe consequential
operation state across restarts and lost tool responses.
Das Expires 29 April 2027 [Page 283]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
16.62.2 — Cloud Infrastructure
Cloud services may durably bind protected authority to external
resource changes.
16.62.3 — Distributed Microservices
Services may reconcile partial effectuation and duplicate message
delivery under protected operation identity.
16.62.4 — Financial Transactions
Payment controllers may prevent unsupported duplicate payments
following timeout or acknowledgement loss.
16.62.5 — Electronic Commerce
Ordering, inventory, payment, and delivery operations may preserve
accurate partial-effect state.
16.62.6 — Banking Infrastructure
Account mutations may be transactionally bound to current
authorization and logical operation records.
16.62.7 — Database Systems
Protected resource transactions may atomically associate mutation and
authority consumption.
16.62.8 — Storage Systems
File and object mutations may be governed by version-bound finality
and durable commit records.
16.62.9 — Message Brokers
8.5.3.71. Original global source page 1455
Protected messaging may distinguish durable publish intent from
receiving-system processing.
16.62.10 — Credential Management
Credential activation may be journaled and constrained against
unauthorized repeated exercise.
16.62.11 — Information Disclosure
Das Expires 29 April 2027 [Page 284]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Protected data-release controllers may preserve exposure-state
accounting despite uncertain delivery.
16.62.12 — Network Infrastructure
Autonomous configuration commands may retain protected operation
identity and current device-state evidence.
16.62.13 — Telecommunications
Distributed control-plane operations may be reconciled after service
or connectivity failures.
16.62.14 — Industrial Automation
Controller restarts may preserve command and qualified device-effect
state.
16.62.15 — Robotics
Physical commands may be protected against unsafe replay after
uncertain actuation.
16.62.16 — Autonomous Transportation
Selected consequential device instructions may require durable
operation identity and supported physical-state verification.
16.62.17 — Hardware Accelerators
Accelerator-originated effectful commands may be journaled and fenced
across workload recovery.
16.62.18 — Confidential Computing
Protected computation may produce valid authority evidence while
independent sinks maintain durable consequential state.
16.62.19 — Edge Computing
Disconnected devices may operate under bounded protected authority
and preserve unresolved effect state.
8.5.3.72. Original global source page 1456
16.62.20 — Satellite and Remote Systems
Das Expires 29 April 2027 [Page 285]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Long communication delays may be handled without automatically
treating missing acknowledgements as failed commands.
16.62.21 — Long-Running Multi-Agent Workflows
Agents may resume tasks or be replaced without recreating previously
consumed authority.
16.62.22 — Distributed Recovery Services
Recovery planners may use authenticated earlier-outcome state without
receiving unrestricted corrective permission.
16.62.23 — Heterogeneous Computing
Device, storage, network, and application sinks may share protected
logical effect and journal semantics.
16.62.24 — Future Autonomous Critical Systems
Persistent execution-finality records may provide the basis for
bounded consequential authority across evolving computational and
physical infrastructures.
The industrial utility concerns preventing duplicate, stale, or
unsupported consequential operations while preserving technically
accurate evidence concerning actual effects.
16.63 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
16.63.1 — Candidate Independent System Claim
A candidate system may comprise:
A protected Finality Sink configured to reconstruct the actual
pending consequential operation;
An evidence and authority verifier configured to validate current
operation-specific non-bearer enablement;
A protected durable journal configured to store authenticated
operation and consumption transitions;
A monotonic finality-consumption controller configured to prevent
unauthorized repeated consumption;
A protected dispatch-intent controller configured to associate
consumed authority with a specified external operation;
Das Expires 29 April 2027 [Page 286]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.5.3.73. Original global source page 1457
An outcome-state controller configured to distinguish qualified
completion, non-effectuation, partial effect, and uncertainty;
And a reconciliation controller configured to withhold further
effectuation unless the applicable retry or recovery conditions are
independently established.
16.63.2 — Candidate Independent Method Claim
A corresponding method may comprise:
Constructing a consequential Candidate Act;
Maintaining the effect non-effective;
Verifying the actual pending operation at its Finality Sink;
Validating current non-bearer authority;
Durably committing an authenticated operation-specific journal state;
Consuming finality authority through a monotonic protected
transition;
Binding the resulting consumption to a specified dispatch intent;
Attempting the governed external effect;
Evaluating qualified outcome evidence;
And preventing unsupported additional effectuation where the earlier
result remains indeterminate.
16.63.3 — Candidate Independent Local Atomicity Claim
Another candidate may require atomic commitment of protected resource
mutation, actual operation identity, and finality consumption within
one resource transaction domain.
16.63.4 — Candidate Independent Remote-Effect Claim
Another candidate may require durable consumption–dispatch-intent
coupling, receiver-side operation identity, qualified outcome
reconciliation, and mandatory retry fencing.
16.63.5 — Candidate Independent Hardware Claim
Das Expires 29 April 2027 [Page 287]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A protected device apparatus may maintain durable command identity,
current hardware authority, monotonic command-consumption state, and
qualified completion or uncertainty classification.
16.63.6 — Candidate Independent Anti-Rollback Claim
8.5.3.74. Original global source page 1458
Another candidate may require protected journal generations and sink-
enforced fencing that prevent stale computational or dispatcher
states from reactivating consumed consequential authority.
These candidate structures may overlap and should be examined for
unity, prior-art distinctions, and support.
16.64 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
Dependent aspect 1: The system constructs an authenticated Candidate
Act.
Dependent aspect 2: The actual pending operation is reconstructed by
a protected Finality Sink.
Dependent aspect 3: Current source authority is verified immediately
before protected finality consumption.
Dependent aspect 4: Cross-committed validation evidence is associated
with the operation.
Dependent aspect 5: A stable logical effect identifier is
established.
Dependent aspect 6: Separate attempt identifiers represent permitted
dispatch attempts.
Dependent aspect 7: The operation identifier is bound to actual
parameters and resource identity.
Dependent aspect 8: A protected journal records the authorized
operation descriptor.
Dependent aspect 9: The journal records the finality enablement
reference.
Dependent aspect 10: The journal records the authority-consumption
generation.
Dependent aspect 11: The journal records dispatch-intent state.
Das Expires 29 April 2027 [Page 288]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Dependent aspect 12: The journal distinguishes dispatch intent from
actual dispatch.
Dependent aspect 13: The journal distinguishes dispatch from receiver
acceptance.
Dependent aspect 14: The journal distinguishes receiver acceptance
from qualified effect completion.
Dependent aspect 15: The journal records unresolved effectuation
outcomes.
Dependent aspect 16: Journal entries use protected authentication or
integrity commitments.
Dependent aspect 17: Journal ordering is verified.
Dependent aspect 18: Incomplete journal writes are detected or safely
rejected.
8.5.3.75. Original global source page 1459
Dependent aspect 19: The system employs an actual durability barrier
before the specified external effectuation transition.
Dependent aspect 20: Protected journal state includes a monotonic
generation.
Dependent aspect 21: Snapshot rollback cannot revive consumed
authority.
Dependent aspect 22: A local resource mutation and authority
consumption commit atomically where supported.
Dependent aspect 23: A local transaction abort prevents the
corresponding protected mutation and consumption from being treated
as committed.
Dependent aspect 24: A remote dispatch intent is durably associated
with consumed authority.
Dependent aspect 25: The dispatcher may transmit only the committed
actual operation.
Dependent aspect 26: The dispatcher verifies the designated
destination.
Das Expires 29 April 2027 [Page 289]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Dependent aspect 27: The dispatcher verifies its current authorized
generation.
Dependent aspect 28: A stale dispatcher is rejected at the actual
effectuation sink.
Dependent aspect 29: A receiver maintains an authenticated logical
operation registry.
Dependent aspect 30: A receiver associates the logical identifier
with an actual operation digest.
Dependent aspect 31: An incompatible retry using the same identifier
is rejected.
Dependent aspect 32: A receiver atomically commits operation
deduplication state with the actual resource mutation.
Dependent aspect 33: A duplicate request may return the previously
committed result without reapplying the mutation.
Dependent aspect 34: The system verifies the receiver's actual
duplicate-suppression retention conditions.
Dependent aspect 35: A retry is withheld when receiver retention has
expired and earlier outcome remains unknown.
Dependent aspect 36: An unresolved external result establishes a
protected retry fence.
Dependent aspect 37: A timeout does not constitute proof of non-
effectuation.
Dependent aspect 38: A missing acknowledgement does not restore
consumed authority.
Dependent aspect 39: The system obtains qualified receiver-status
evidence.
8.5.3.76. Original global source page 1460
Dependent aspect 40: The system authenticates a receiver's
observation role.
Dependent aspect 41: Receiver evidence identifies the actual logical
operation.
Das Expires 29 April 2027 [Page 290]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Dependent aspect 42: The system distinguishes qualified completed
effect from qualified non-effectuation.
Dependent aspect 43: The system represents partial effects
separately.
Dependent aspect 44: The system conservatively handles incomplete
negative-effect evidence.
Dependent aspect 45: A new attempt after confirmed non-effectuation
requires current bounded authority.
Dependent aspect 46: A receiver-idempotent retransmission uses the
same logical operation identity and parameters.
Dependent aspect 47: A different consequential retry is represented
as a new Candidate Act.
Dependent aspect 48: A corrective effect requires separately valid
recovery authority.
Dependent aspect 49: A causal successor effect requires an accepted
earlier actual-effect receipt where the selected CW-2 protocol so
specifies.
Dependent aspect 50: A protected journal may be checkpointed.
Dependent aspect 51: Journal compaction preserves required consumed-
authority and unresolved-effect state.
Dependent aspect 52: A protected checkpoint is verified against
rollback.
Dependent aspect 53: An old journal copy cannot restore a prior
consumption generation.
Dependent aspect 54: Multiple effectuation sinks share authoritative
consumption state where required.
Dependent aspect 55: Distributed disconnected domains may receive
nonoverlapping bounded authority.
Dependent aspect 56: Workload migration advances the relevant
dispatcher or resource-ownership generation.
Dependent aspect 57: An old device owner cannot exercise stale
command authority.
Das Expires 29 April 2027 [Page 291]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Dependent aspect 58: A physical device maintains protected command
identity and acceptance state.
Dependent aspect 59: Physical actuation completion may require
qualified sensor or device-controller evidence.
8.5.3.77. Original global source page 1461
Dependent aspect 60: Information-release uncertainty remains
represented in cumulative privacy accounting.
Dependent aspect 61: A payment sink verifies current account, amount,
recipient, and logical transaction identity.
Dependent aspect 62: A storage sink verifies current object version.
Dependent aspect 63: A model or tool update may require current
validation before resumed consequential execution.
Dependent aspect 64: A material effectuation-path change invalidates
dependent dispatch authority.
Dependent aspect 65: The system bounds reconciliation and retry
resource consumption.
Dependent aspect 66: A protected integrated controller may perform
finality, journaling, and resource mutation.
Dependent aspect 67: Separate authenticated domains may provide
finality, dispatch, receiving effect, and outcome observation.
Dependent aspect 68: Protected journal continuity may be maintained
without a public blockchain.
Dependent aspect 69: The implementation distinguishes exactly-once
protected consumption from receiver-side effect uniqueness.
Dependent aspect 70: An unresolved external effect cannot be
described as successfully reversed or safely unperformed without the
relevant qualified evidence.
These aspects are illustrative claim-support features and do not
individually establish patentability.
16.65 — UNIVERSAL NON-LIMITING COMBINATION AND PHOSITA IMPLEMENTATION
CLAUSE
Das Expires 29 April 2027 [Page 292]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The mechanisms disclosed in Embodiment 16 may be implemented
individually or in technically compatible combinations.
One implementation may govern atomic local database mutations.
Another may govern remote transactional services.
Another may govern durable message dispatch.
Another may govern financial transfers.
8.5.3.78. Original global source page 1462
Another may govern file and storage operations.
Another may govern protected information disclosure.
Another may govern direct device commands.
Another may govern heterogeneous autonomous agents acting across
independent computing domains.
A particular implementation may employ a transactional journal
without a separately named outbox.
Another may use a protected outbox.
Another may employ receiver-side deduplication.
Another may rely upon qualified confirmed non-effectuation before
permitting retries.
Another may require an independently authorized recovery operation
where earlier actual effects remain unresolved.
The terms exactly-once authorization, exactly-once local consumption,
exactly-once receiver mutation, and exactly-once external consequence
identify different technical guarantees and must not be treated as
interchangeable.
Where the selected claim requires one atomic resource and authority
transition, the implementation must actually provide that property.
Where the selected claim requires receiver-side duplicate-effect
prevention, the destination must implement a mechanism sufficient for
the claimed guarantee.
Das Expires 29 April 2027 [Page 293]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Where the selected claim requires monotonic rollback resistance,
protected authoritative state must remain valid despite untrusted
workload rollback.
The pseudocode, data structures, equations, worked examples, state
machines, technical variations, and proposed experiments are
illustrative and non-limiting.
They are intended to assist a person having ordinary skill in the art
in understanding and implementing the disclosed technical mechanisms.
No particular storage engine, transaction protocol, cryptographic
primitive, processor, communication system, vendor, operating system,
or hardware substrate is universally required unless recited by a
selected claim.
Compatible mechanisms from other embodiments may be combined where
supported by the disclosure and technically appropriate.
A cross-reference does not make every feature of another embodiment
mandatory.
A durable journal entry does not automatically prove external effect
completion.
8.5.3.79. Original global source page 1463
A protected finality receipt does not automatically permit repeated
execution.
A retry-safe transport operation does not automatically establish a
retry-safe physical consequence.
A compensated effect does not automatically erase the original
historical consequence.
A protected operation cannot be considered successfully completed
merely because the requesting agent received a local software success
result.
No proposed experiment is represented as completed merely by stating
its expected result.
Future-oriented implementation variations are proposed technical
alternatives and not statements of existing commercial deployment.
16.66 — FINAL TECHNICAL SUMMARY AND INVENTIVE-STEP CHARACTERIZATION
Das Expires 29 April 2027 [Page 294]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The present Embodiment 16 discloses a protected crash-consistent
autonomous execution-finality architecture that preserves operation-
specific consequential authority and actual-effect state across
failures, retries, restarts, and distributed processing uncertainty.
An autonomous computational entity may prepare a Candidate Act
describing a permitted consequential effect.
The actual operation remains non-effective until independently
enforced authorization conditions pass.
A protected Finality Sink reconstructs the actual pending operation
and verifies current non-bearer finality authority.
The system establishes an authenticated durable journal binding the
operation, evidence, authority, resource, and protected consumption
generation.
Where the affected resource and authority state are within one
appropriate transaction domain, the operation and its authority
consumption may commit atomically.
Where the effect occurs at a separate external destination, the
protected controller may durably associate consumption with an exact
dispatch-intent commitment.
The dispatcher is authorized only to attempt the corresponding
committed operation under current protected state.
A suitable receiving resource may maintain its own authoritative
logical effect registry.
Where receiver-side operation identity and actual mutation are
atomically coupled, repeated delivery may be processed without
duplicating the protected resource mutation.
8.5.3.80. Original global source page 1464
However, this stronger guarantee depends upon the real receiving
system's implementation, persistence, and retention properties.
A protected outcome controller distinguishes confirmed completion,
confirmed non-effectuation, partial effectuation, and indeterminate
results.
If a sender crashes, loses an acknowledgement, or cannot establish
the receiver's outcome, the system does not automatically restore
consumed authority.
Das Expires 29 April 2027 [Page 295]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Instead, it establishes or maintains an indeterminate-outcome fence.
Further consequential execution requires sufficiently qualified
receiver or actual-effect evidence, a verified retry-safe operation
under the relevant destination guarantees, or a separately authorized
recovery Candidate Act.
Protected journal generations and actual sink-enforced dispatcher
fencing prevent stale snapshots, restored workers, and former
coordinators from reviving earlier consequential authority.
The architecture may be implemented in databases, distributed
services, financial systems, message infrastructure, protected
storage, hardware controllers, robotics, communications systems,
confidential computing, edge devices, and future autonomous critical
infrastructure.
The embodiment does not claim to invent write-ahead logging,
transactional outbox systems, idempotency keys, distributed
consensus, receiver deduplication, or conventional transaction
recovery individually.
Its proposed candidate technical contribution is the enforced
coupling of actual Finality-Sink operation reconstruction, evidence-
qualified non-bearer authority, durable monotonic consumption,
protected dispatch-intent continuity, qualified outcome
reconciliation, and restrictions preventing uncertain earlier effects
from generating unauthorized new consequential authority.
The principal candidate inventive technical concept of Embodiment 16
is a crash-consistent protected execution-finality system in which an
independently enforcing Finality Sink reconstructs an actual pending
consequential operation, verifies current operation-specific non-
bearer authority, durably binds a monotonic authority-consumption
transition to the corresponding actual-effect dispatch-intent state,
and maintains a protected indeterminate-outcome fence preventing
unsupported additional effectuation until a qualified actual-effect
result, verified receiver-idempotent retransmission condition, or
separately authorized recovery transition has been established.
The resulting safety property is not an unqualified claim that every
real-world effect occurs exactly once.
Rather, the system can enforce precisely specified authority-
consumption and replay-prevention properties while maintaining
technically accurate distinctions among dispatch, receiver
acceptance, external completion, and unresolved outcomes.
Das Expires 29 April 2027 [Page 296]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.5.3.81. Original global source page 1465
Novelty, inventive step, unity of invention, and permissible claim
breadth remain subject to the closest relevant prior-art analysis and
the enabling technical disclosure actually filed.
END OF EMBODIMENT 16 — COMPLETE TECHNICAL DISCLOSURE.
8.6. Miscellaneous Embodiment M-2: Existing Authorization Standards as
Qualified Inputs, Not Finality
Original source global pages 1898-1952. Preserved for technical
discoverability and traceability; consult the cited full Zenodo
document for complete source context. This part primarily
concentrates on evidence binding, scope, non-bearer authority and
protected journal consumption; other documents provide specialized
enforcement, device handoff and actual effect receipt details.
8.6.1. Architecture and Protected Trust Boundaries
[OAuth/DPoP / OS app permission / key proof]
[RATS / COSE / IPC / network / hardware]
|
[Protected evidence adapters]
|
[Authorized effect translation]
|
[Revocation/coverage check]
|
[Non-bearer authority + Finality Sink]
Figure 22: Miscellaneous Embodiment M-2: Existing Authorization
Standards as Qualified Inputs, Not Finality — Protected
Architecture
8.6.2. Operational Decisions and Fail-Closed State Transitions
Das Expires 29 April 2027 [Page 297]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
[Existing security result received]
|
<Proves required exact property?>--NO-->[Do not elevate]
|YES
[Translate to bounded actual effect]
|
<Current authority/coverage qualified?>--NO-->[Withhold]
|YES
[Sink reconstructs actual operation]
|
<Evidence, authority, local state match?>--NO-->[Refuse]
|YES
[Consume/effect]
Figure 23: Miscellaneous Embodiment M-2: Existing Authorization
Standards as Qualified Inputs, Not Finality — Decision Flowchart
8.6.3. Page-Indexed Original Technical Disclosure
8.6.3.1. Original global source page 1898
MISCELLANEOUS EMBODIMENT M-2
STANDARDS-INTEROPERABLE, PLATFORM-INDEPENDENT EXECUTION-FINALITY
CONSTITUTION USING EXISTING AUTHORIZATION, CRYPTOGRAPHIC, OPERATING-
SYSTEM, NETWORK, IPC, SANDBOX, NOTIFICATION, AND HARDWARE SECURITY
MECHANISMS
M-2.0 — COMPLETE TECHNICAL TITLE
Systems, Methods, and Apparatus for Constituting Protected Operation-
Specific Execution-Finality Authority from Heterogeneous
Authorization and Security Mechanisms Using Independently Verified
Authorization Dependencies, Protected Authorization-to-Effect
Translation, Current Revocation and Enforcement-Topology Commitments,
Scoped Non-Bearer Finality Enablement, and Mandatory Sink-Local
Actual-Operation Verification and Consumption
M-2.0.1 — Technical Purpose
The present Miscellaneous Embodiment M-2 discloses systems, methods,
apparatus, software components, protected services, hardware-assisted
enforcement structures, communication protocols, machine-verifiable
records, and non-limiting implementation variations for integrating
existing authorization and security mechanisms into a protected
autonomous execution-finality architecture.
Das Expires 29 April 2027 [Page 298]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The embodiment addresses the technical problem that different
authorization and security systems may independently establish
permission, identity, possession of a cryptographic key, process
isolation, permitted network access, resource visibility, message
delivery, configuration state, or security-event observation, without
necessarily establishing current authority to perform the particular
consequential operation actually presented at a resource effectuation
boundary.
An autonomous computational entity may be authorized to invoke an
application interface while lacking permission to perform the
particular resource mutation that an invocation would produce.
A token may be active while the proposed operation exceeds its
authorized effect scope.
A sender may demonstrate possession of a bound cryptographic key
while the actual request body, recipient, resource version, or
subsequent operation differs from the previously authorized effect.
A security monitor may observe an operation without having the
ability to prevent its consequence.
A sandbox may constrain one execution environment while a privileged
broker or independently reachable resource interface retains a
different effectuation path.
A revocation notification may be delivered to one component without
having been applied at the protected resource.
A cryptographic signature may authenticate a previous approval
without establishing that the actual operation remains current, has
not been revoked, or has not already consumed its permitted
authority.
The disclosed invention does not require replacing each of these
established mechanisms.
8.6.3.2. Original global source page 1899
Instead, in selected implementations, existing authorization and
security mechanisms provide qualified inputs or enforcement functions
within a distinct protected execution-finality relationship.
Das Expires 29 April 2027 [Page 299]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The protected architecture identifies the authorization scope
established by each input mechanism, determines the actual technical
conditions under which the mechanism can enforce a particular
consequential operation, and prevents an evidentiary or upstream
permission result from automatically becoming executable finality
authority.
A protected finality controller establishes operation-specific
enablement only upon satisfaction of the applicable authority and
evidence predicates.
At the actual effectuation boundary, a designated Finality Sink
independently obtains or reconstructs the actual pending operation,
verifies the required current authority and enforcement conditions,
and performs the corresponding protected consumption transition
before permitting the consequence.
The principal implementation may additionally couple current
authority to revocation generations, effectuation-path coverage
state, resource identity, protected hardware or software execution
configuration, and bounded temporal validity.
M-2.0.2 — Fundamental Technical Principle
A component that proves identity, permission, key possession, sandbox
membership, request delivery, or enforcement attachment does not
necessarily prove that the actual pending consequence is currently
authorized.
In the present embodiment, a heterogeneous authorization result may
be used as evidence or as a bounded technical enforcement
contribution, without automatically being treated as sufficient
authority to make an external or persistent effect effective.
A valid authorization result is distinguished from:
A fully resolved operation descriptor;
An independently verified current authority state;
A qualified mandatory effectuation path;
A protected finality enablement;
And a sink-local protected exercise of that enablement.
M-2.0.3 — Principal Technical Combination
Das Expires 29 April 2027 [Page 300]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
In a principal implementation, the disclosed combination comprises:
(a) a consequential Candidate Act constructed from an autonomous
application's proposed operation;
(b) an authorization-source adapter capable of obtaining qualified
evidence from one or more existing permission systems;
(c) a protected operation-translation mechanism binding that evidence
to a canonical effect descriptor;
8.6.3.3. Original global source page 1900
(d) a protected evidence collector and independent current validation
function;
(e) a current authority-dependency and revocation-generation
verifier;
(f) a mechanism establishing that the corresponding actual
effectuation path is subject to suitable mandatory enforcement;
(g) a protected authority controller constituting scoped non-bearer
finality enablement;
(h) a designated Finality Sink capable of independently determining
the actual pending consequential operation;
(i) a protected sink-local authority and consumption state; and
(j) a fail-closed release condition rejecting an operation when
required source, actual-effect, revocation, enforcement, or
consumption predicates cannot be established.
The selected technical relationship is intended to operate even when
the underlying permission system, cryptographic protocol, process
isolation mechanism, enforcement hook, or network-control
implementation is replaced by a functionally compatible alternative.
M-2.0.4 — Separation Between Primitives and the Claimed Relationship
The embodiment does not characterize conventional token issuance,
token revocation, token introspection, proof-of-possession
authentication, mutual authentication, operating-system sandboxing,
interprocess communication, protected cryptographic key storage,
network filtering, event notifications, transactional databases, or
resource access control as individually invented.
Das Expires 29 April 2027 [Page 301]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
These functions may be employed as known technical substrates.
The proposed technical combination concerns the mandatory state and
evidence dependencies by which selected substrate outputs become
necessary but insufficient inputs to operation-specific consequential
authority, with separate protected finality constitution and actual
effectuation verification.
M-2.0.5 — Non-Limiting Implementation Models
The present invention may be implemented through one or more of the
following broad models:
A software authorization-and-resource-gateway implementation;
A mobile or desktop operating-system implementation;
A protected application-action implementation;
A privileged interprocess service implementation;
A network egress implementation;
A cloud or enterprise API implementation;
A distributed cross-domain implementation;
A protected credential-broker implementation;
8.6.3.4. Original global source page 1901
A hardware-backed authority implementation;
A device-command implementation;
A bounded offline implementation;
Or a hybrid implementation combining selected mechanisms.
No particular commercial operating system, cloud environment,
identity provider, AI model, or cryptographic hardware product is
universally necessary.
M-2.1 — TECHNICAL FIELD
This embodiment relates to autonomous computing security, execution-
finality enforcement, authorization protocol interoperability,
machine-verifiable operation scope, proof-of-possession
Das Expires 29 April 2027 [Page 302]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
authentication, protected revocation, cryptographic authority
binding, operating-system security, application tool invocation,
privileged service mediation, network egress control, hardware-backed
keys, resource-specific transactional control, and protected
consequential execution.
More particularly, the embodiment concerns transforming qualified
outputs of heterogeneous existing security mechanisms into precisely
bounded operation-specific authority and enforcing that authority at
the actual resource boundary rather than relying upon upstream
application permission alone.
M-2.2 — SPECIFIC TECHNICAL PROBLEMS
M-2.2.1 — Authorization-to-Effect Semantic Gap
An existing authorization mechanism may identify a permitted service,
API, scope, or general action without independently determining the
complete consequential operation that is about to occur.
M-2.2.2 — Active-Credential Gap
A credential may remain active while the proposed effect is outside
the original permitted task or exceeds current resource scope.
M-2.2.3 — Proof-of-Possession Gap
A requester may prove possession of a cryptographic key without
proving that every security-relevant field of the actual operation
matches independently established authorization.
M-2.2.4 — Structured-Intent Gap
An application may provide a structured proposed action, but the
action's actual resource-side behavior may differ because of
parameter resolution, redirects, aliases, tool implementation
changes, or additional side effects.
M-2.2.5 — Isolation-to-Effect Gap
8.6.3.5. Original global source page 1902
A sandbox may restrict selected process privileges while an available
privileged helper or remote service can still cause consequential
effects.
M-2.2.6 — Observation-to-Blocking Gap
Das Expires 29 April 2027 [Page 303]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
An operating-system monitor may report an event without possessing
authority to prevent the corresponding effect.
M-2.2.7 — Network-Flow-to-Content Gap
A network filter may identify endpoints and connections while lacking
authenticated access to the plaintext content or application
semantics required by the authorization policy.
M-2.2.8 — Cryptographic-Signature-to-Finality Gap
A protected signature may authenticate a record without establishing
current revocation status, actual operation correspondence, or
remaining consumable authority.
M-2.2.9 — Revocation-Propagation Gap
A valid revocation may have been committed upstream without yet being
applied by the actual resource sink.
M-2.2.10 — Notification-to-Enforcement Gap
An asynchronous notification may be delayed, dropped, reordered, or
delivered without causing the required protected invalidation.
M-2.2.11 — Cross-Mechanism State Inconsistency
Different mechanisms may evaluate permissions using different
resource identities, policy epochs, operation representations, or
authorization freshness conditions.
M-2.2.12 — Security-Primitive Substitution
A system may replace one authorization or enforcement implementation
with another that has weaker semantic coverage while retaining an
apparently valid high-level permission.
M-2.2.13 — Authority Replay
An earlier valid token, signed receipt, operation descriptor, or
capability reference may be reused for another effect.
M-2.2.14 — Current Operation Divergence
The actual outgoing operation may differ from the approved operation
after a service, model, resource, or transport transformation.
M-2.2.15 — Protection-Boundary Ambiguity
Das Expires 29 April 2027 [Page 304]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A deployment may be unable to establish whether a particular control
is mandatory, advisory, monitoring-only, or bypassable.
8.6.3.6. Original global source page 1903
M-2.2.16 — Technical Objective
A candidate objective technical problem is:
How to use heterogeneous established authorization, cryptographic,
process-isolation, communication, network, and hardware security
mechanisms to control autonomous consequential operations without
treating any one primitive's successful result as sufficient
executable authority, by translating each relevant security result
into protected operation-specific evidence and independently
enforcing current actual-effect correspondence, revocation, coverage,
and non-replayable finality consumption at the real resource
boundary.
M-2.3 — COMMON PROTECTED INTEGRATION ARCHITECTURE
A representative implementation may comprise:
1. An Autonomous Computational Requester.
2. A Protected Candidate Act Adapter.
3. A Heterogeneous Authorization Evidence Adapter.
4. A Protected Effect-Semantics Translation Controller.
5. A Collection-Time Evidence Instance.
6. An Independent Execution-Time Validation Instance.
7. A Current Authority and Revocation Dependency Controller.
8. An Enforcement-Coverage Qualification Controller.
9. A Protected Finality Enablement Controller.
10. A Privileged or Resource-Specific Effectuation Broker.
11. A Designated Finality Sink.
12. A Sink-Local Protected State and Consumption Controller.
13. An Optional External Effect Observer.
Das Expires 29 April 2027 [Page 305]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
14. An Optional Crash-Consistent Operation Journal.
A selected implementation may integrate several functions in one
protected component where the applicable claims do not require
structural separation.
Where independent validation, protected state separation, or external
sink authority is expressly required, the implementation must
preserve those properties.
The requesting computational entity does not automatically control
the protected finality authority or the actual resource-side
consumption state.
8.6.3.7. Original global source page 1904
M-2.4 — CENTRAL PROTECTED DATA STRUCTURES
M-2.4.1 — Authorization Source Evidence
AUTHORIZATION_SOURCE_EVIDENCE = { source_mechanism_class,
issuer_or_controller_identity, requester_identity,
credential_or_grant_reference, authorized_resource_scope,
authorized_operation_scope, protected_principal_reference,
proof_of_possession_reference, applicable_policy_version,
authorization_generation, current_revocation_reference,
evidence_freshness, authentication_result, evidence_assurance_profile
} The evidence describes the specific property established by the
underlying authorization mechanism.
A successful identity check is not encoded as proof that the actual
operation is valid.
M-2.4.2 — Protected Canonical Effect Descriptor
PROTECTED_CANONICAL_EFFECT_DESCRIPTOR = { candidate_act_identifier,
actual_operation_class, originating_authority,
actual_resource_identity, effective_target_or_recipient,
operation_method_or_primitive, operation_parameters_commitment,
outgoing_content_commitment, expected_resource_generation,
resolved_effectuation_interface, authorized_effect_envelope,
applicable_policy_commitment, protected_descriptor_authentication }
The descriptor includes the security-relevant fields needed to
distinguish authorized and unauthorized effects for the selected
operation class.
Fields that are not relevant to a particular effect may be omitted.
Das Expires 29 April 2027 [Page 306]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The descriptor must not depend solely on caller-supplied unverified
labels for an operation whose actual resource-side semantics differ.
M-2.4.3 — Enforcement Qualification Record
8.6.3.8. Original global source page 1905
ENFORCEMENT_QUALIFICATION_RECORD = { actual_effectuation_class,
actual_resource_or_interface, selected_enforcement_component,
enforcement_mode, mandatory_attachment_evidence,
blocking_capability_evidence, operation_visibility_profile,
actual_resource_binding, protected_configuration_generation,
current_coverage_epoch, unresolved_bypass_paths,
qualified_verification_result } The record distinguishes monitoring,
advisory, and blocking enforcement.
M-2.4.4 — Revocation-Dependent Finality Enablement
REVOCATION_DEPENDENT_FINALITY_ENABLEMENT = {
candidate_act_commitment, authorization_evidence_commitment,
collection_time_evidence_commitment,
independent_validation_commitment,
canonical_effect_descriptor_commitment, original_source_authority,
required_delegation_dependencies, current_revocation_generation,
required_freshness_state, current_enforcement_coverage_epoch,
designated_finality_sink, authorized_resource, permitted_use_count,
sink_local_consumption_reference, protected_finality_authentication }
The enablement may be maintained entirely within a protected
controller and represented to the requester by an inert reference.
M-2.4.5 — Sink-Local Finality State
SINK_LOCAL_FINALITY_STATE = { designated_sink_identity,
resource_identity, accepted_authority_generation,
accepted_revocation_generation, accepted_coverage_generation,
authorized_operation_commitment, finality_enablement_identifier,
consumption_generation, remaining_permitted_uses,
current_resource_state, active_enforcement_mode,
8.6.3.9. Original global source page 1906
pending_dispatch_state, protected_state_authentication } The
protected sink verifies the current state before consequential
release.
M-2.5 — PROTECTED AUTHORIZATION-TO-EFFECT TRANSLATION
Das Expires 29 April 2027 [Page 307]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
In one principal variation, the architecture includes a protected
translation mechanism converting authorization information from a
heterogeneous permission system into an effect-specific validation
requirement.
The translation is not limited to extracting an access-token scope.
It may reconcile:
The identity of the authorized principal;
The applicable source grant;
A permission's intended operation;
A structured application action;
The actual resource method;
The effective recipient;
The outgoing content;
The protected resource version;
The required proof-of-possession relation;
And the current resource-side enforcement boundary.
M-2.5.1 — Translation Input
The controller receives qualified permission evidence and a Candidate
Act descriptor.
M-2.5.2 — Independent Semantic Resolution
The controller determines the actual technical meaning of the
operation under its applicable contract.
M-2.5.3 — Protected Effect Envelope
The permissible operation scope is expressed as bounded effect
parameters.
M-2.5.4 — Source Authority Preservation
A narrow permission is not silently expanded into broader executable
authority.
Das Expires 29 April 2027 [Page 308]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
M-2.5.5 — Unresolved Semantics
8.6.3.10. Original global source page 1907
If the operation's relevant effects cannot be sufficiently
determined, the selected protected consequence remains withheld.
M-2.5.6 — Effect-Specific Finality
Different resource classes may employ different actual-operation
descriptors and sink checks.
M-2.5.7 — Technical Significance
The proposed relationship requires an established permission result
to remain subordinate to a protected actual-effect binding rather
than allowing an upstream token or tool label to become sufficient
effectuation authority.
M-2.6 — VARIATION A: OAUTH AND EQUIVALENT AUTHORIZATION-SERVER
INTEGRATION
An implementation may use an established authorization-server
architecture to identify principals, clients, resources, permissions,
and delegated access.
OAuth-style access tokens and grants may constitute one source of
authorization evidence.
The protected execution-finality controller does not assume that
token validity is sufficient to release every covered consequential
operation.
M-2.6.1 — Source Grant
The authorization server provides a resource-access grant under an
authenticated principal or delegation relationship.
M-2.6.2 — Candidate Act
The autonomous requester proposes a specific consequential API or
resource operation.
M-2.6.3 — Authority Translation
The protected adapter maps the authorized resource and scope into
required effect-specific predicates.
Das Expires 29 April 2027 [Page 309]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
M-2.6.4 — Independent Validation
A protected validator evaluates the current operation against the
actual permission envelope.
M-2.6.5 — Finality Enablement
A separate protected controller establishes scoped non-bearer
enablement for the specified operation.
M-2.6.6 — Sink Reconstruction
The resource sink resolves the actual pending request, target,
parameters, and authorized scope.
M-2.6.7 — Consequential Release
8.6.3.11. Original global source page 1908
The sink releases the operation only after current authority,
revocation, actual-effect, and protected consumption checks pass.
M-2.6.8 — Alternative Permission Systems
The same mechanism may use non-OAuth enterprise identity systems,
operating-system permissions, device-control grants, access-control
lists, capability registries, or authenticated custom authorization
services.
Technical contribution of this variation: Operation-specific actual-
effect finality remains independent of the particular authorization-
server protocol while maintaining a verifiable binding to the
original permission.
M-2.7 — VARIATION B: STRUCTURED OR RICH AUTHORIZATION DETAILS
An authorization system may provide detailed descriptions of
permitted actions, recipients, amounts, resources, or transaction
attributes.
The protected controller may treat these as candidate authorization
constraints.
It does not automatically assume the structured description
corresponds to the actual downstream operation.
M-2.7.1 — Structured Grant
Das Expires 29 April 2027 [Page 310]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A permission may identify a resource, operation type, amount,
recipient, method, or other attributes.
M-2.7.2 — Protected Normalization
The fields are converted into a typed canonical effect envelope.
M-2.7.3 — Current Resource Resolution
The actual resource and recipient are resolved at the relevant
effectuation boundary.
M-2.7.4 — Operation Correspondence
The protected sink compares the actual operation against the
authorized constraints.
M-2.7.5 — Downstream Transformation
Any material change in effect semantics may require revalidation.
M-2.7.6 — Failure State
A mismatch prevents the effect.
M-2.7.7 — Non-Limiting Standard
One optional implementation may use authorization-detail structures
compatible with Rich Authorization Requests.
8.6.3.12. Original global source page 1909
Technical contribution of this variation: A structured permission is
converted into an independently enforced actual-effect predicate
rather than being treated as self-enforcing authorization.
M-2.8 — VARIATION C: TOKEN REVOCATION AND AUTHORITY DEPENDENCY
INVALIDATION
An authorization system may invalidate a credential or grant.
The protected finality architecture may associate that grant with its
dependent Candidate Acts, protected evidence, reservations, and
finality enablements.
M-2.8.1 — Revocation Input
Das Expires 29 April 2027 [Page 311]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The protected controller obtains an authenticated revocation
commitment or current inactive-status evidence.
M-2.8.2 — Dependency Resolution
The system identifies operation-specific enablements dependent upon
the revoked grant.
M-2.8.3 — Protected Generation
The authoritative revocation generation advances.
M-2.8.4 — Pending Effect Invalidation
Affected finality enablements become ineligible.
M-2.8.5 — Sink-Local Fence
The actual resource controller applies or verifies current revoked
authority.
M-2.8.6 — Actual Operation Check
The sink determines whether the pending effect depends upon the
invalidated grant.
M-2.8.7 — Controlled Refusal
Revoked authority prevents new covered effects under the actual
sink's current enforcement state.
M-2.8.8 — Non-Limiting Standard
An optional authorization-server interface may use an OAuth token-
revocation protocol.
Technical contribution of this variation: Revocation becomes an
invalidation dependency of actual operation-specific finality, not
merely a change in token status.
M-2.9 — VARIATION D: TOKEN INTROSPECTION, CACHE FRESHNESS, AND SINK-
SIDE AUTHORITY
8.6.3.13. Original global source page 1910
An implementation may use a current authorization-status query.
The result may indicate whether a credential is active.
Das Expires 29 April 2027 [Page 312]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The protected controller additionally determines whether the response
is sufficiently current for the actual operation.
M-2.9.1 — Status Query
A protected resource or authority adapter requests current credential
status.
M-2.9.2 — Response Authentication
The result is authenticated under the appropriate issuer and resource
policy.
M-2.9.3 — Freshness Classification
The response is associated with a qualified age, generation, or
validity bound.
M-2.9.4 — Current Operation Risk
The required freshness may depend upon the relevant effect class.
M-2.9.5 — Generation Binding
The current source-authority and revocation generations are checked
where applicable.
M-2.9.6 — Cache Invalidation
A relevant authority change invalidates affected cached permission
evidence.
M-2.9.7 — Missing Freshness
The sink withholds the governed effect if mandatory current validity
cannot be established.
M-2.9.8 — Non-Limiting Standard
An optional implementation may use an OAuth token-introspection
response.
Technical contribution of this variation: The current authority
requirement is bound to the real consequential operation and its
protected sink, not merely to a cached general token status.
M-2.10 — VARIATION E: SENDER-CONSTRAINED TOKEN AND PROOF-OF-
POSSESSION INPUT
Das Expires 29 April 2027 [Page 313]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
An existing authorization system may bind a credential to a
cryptographic key and require the requester to demonstrate possession
of that key.
The proof may be useful to establish that the presenter is an
authorized holder under the credential protocol.
8.6.3.14. Original global source page 1911
Such proof is not automatically treated as evidence that every
consequential operation parameter is authorized.
M-2.10.1 — Bound Credential
The credential identifies an authorized key or cryptographic
principal.
M-2.10.2 — Possession Proof
The requester provides a qualified cryptographic proof.
M-2.10.3 — Proof Verification
The protected adapter verifies the binding and applicable request-
specific fields.
M-2.10.4 — Semantic Scope
The controller separately determines which actual operation
attributes are covered by the proof.
M-2.10.5 — Effect Descriptor
The full relevant consequential operation is represented by a
protected descriptor.
M-2.10.6 — Finality Authority
A separate operation-specific non-bearer finality enablement is
established.
M-2.10.7 — Sink Verification
The actual resource verifies the operation and current protected
consumption state.
M-2.10.8 — Non-Limiting Standard
Das Expires 29 April 2027 [Page 314]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
An optional implementation may use an application-layer
demonstration-of-proof-of-possession token mechanism.
Technical contribution of this variation: Key possession becomes one
authenticated input but does not independently constitute the
separate authority to perform the actual consequential operation.
M-2.11 — VARIATION F: MUTUAL AUTHENTICATION AND CERTIFICATE-BOUND
PERMISSION
A protected service may use mutual transport authentication and
certificate-bound access credentials.
M-2.11.1 — Authenticated Client
The requesting service proves possession of an applicable client
certificate key.
M-2.11.2 — Protected Channel
8.6.3.15. Original global source page 1912
The transport provides the selected authenticated communication
guarantees.
M-2.11.3 — Credential Binding
The resource verifies that the relevant token or grant is associated
with the authenticated client identity.
M-2.11.4 — Operation Scope
The protected controller separately validates the consequential
operation parameters.
M-2.11.5 — Current Revocation
The sink checks the current applicable authorization state.
M-2.11.6 — Non-Bearer Finality
The actual resource operation remains dependent upon its distinct
protected finality state.
M-2.11.7 — Substitution
Das Expires 29 April 2027 [Page 315]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Mutual authentication may be replaced by another technically suitable
authenticated channel without changing the operation-specific
finality relationship.
M-2.11.8 — Non-Limiting Standard
An optional implementation may use certificate-bound OAuth
credentials and mutual TLS.
Technical contribution of this variation: A correctly authenticated
service is still unable to exceed its current independently enforced
operation-specific authority.
M-2.12 — VARIATION G: HARDWARE-PROTECTED KEYS AND CRYPTOGRAPHIC
EVIDENCE
An implementation may use protected cryptographic hardware or a
suitably isolated key manager.
The hardware may protect private keys and authenticate selected
evidence or authority records.
M-2.12.1 — Protected Key Generation
The key may be generated in a protected security component.
M-2.12.2 — Non-Exportable Key
The requesting agent may lack access to the private key material.
M-2.12.3 — Evidence Authentication
The protected component may sign or authenticate selected collection,
validation, or generation commitments.
M-2.12.4 — Operation Binding
8.6.3.16. Original global source page 1913
The signed structure may identify the Candidate Act and applicable
authority context.
M-2.12.5 — Current State
A separate protected controller maintains relevant revocation and
consumption conditions.
M-2.12.6 — Actual Resource Enforcement
Das Expires 29 April 2027 [Page 316]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The Finality Sink verifies the real operation and current authority
rather than accepting the signature alone.
M-2.12.7 — Hardware Independence
A software-protected alternative may be used where it supplies the
selected trust properties.
M-2.12.8 — Scope Qualification
Protected key storage does not automatically establish a rollback-
resistant monotonic counter, resource-side execution gate, or
complete policy engine.
Technical contribution of this variation: Hardware-authenticated
evidence is separated from current actual-effect authority and
becomes part of an enforced multi-state finality decision.
M-2.13 — VARIATION H: APPLICATION SANDBOX AND ENTITLEMENT INPUT
An autonomous application may operate under operating-system sandbox
restrictions and assigned resource entitlements.
M-2.13.1 — Restricted Workload
The computational requester is confined to an identified protection
boundary.
M-2.13.2 — Entitlement Evidence
The protected controller obtains qualified information concerning
relevant permitted interfaces.
M-2.13.3 — Effectuation Path
The system determines how the actual consequential resource can be
reached.
M-2.13.4 — Privileged Intermediary
Any helper or service possessing broader effect authority is
identified as part of the relevant path.
M-2.13.5 — Mandatory Gate
The protected system establishes that the actual operation cannot
bypass the required finality controller within the declared coverage
domain.
Das Expires 29 April 2027 [Page 317]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
M-2.13.6 — Finality Validation
The operation remains subject to current source authorization and
actual-effect matching.
8.6.3.17. Original global source page 1914
M-2.13.7 — Configuration Change
A material entitlement or sandbox change may invalidate dependent
coverage authority.
M-2.13.8 — Non-Limiting Substrate
The sandbox may be implemented by operating-system access controls,
virtual machines, containers, process namespaces, or appropriate
hardware isolation.
Technical contribution of this variation: Process confinement and
operation-specific authority are coupled through a verified mandatory
consequential path rather than assuming that sandbox membership
proves authorization.
M-2.14 — VARIATION I: STRUCTURED APPLICATION ACTIONS AND AUTONOMOUS
TOOL INVOCATION
An application may expose structured actions to a voice assistant, AI
agent, automation service, or orchestration system.
M-2.14.1 — Proposed Action
The agent selects a structured tool or application action.
M-2.14.2 — Candidate Act Construction
The action is represented as a proposed consequence.
M-2.14.3 — Parameter Resolution
The controller determines the relevant resource, arguments,
recipient, and other effect-defining fields.
M-2.14.4 — Non-Effective Hold
The actual effect-capable primitive remains withheld.
M-2.14.5 — Current Validation
Das Expires 29 April 2027 [Page 318]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A protected verifier checks current source authority and applicable
operation scope.
M-2.14.6 — Action Implementation
The actual resource-side implementation may transform or resolve the
requested parameters.
M-2.14.7 — Sink Reconstruction
The protected sink obtains the effective operation and verifies
correspondence with the authorized Candidate Act.
M-2.14.8 — Dynamic Tool Change
Material changes to the action contract or its effectuation path
trigger revalidation.
8.6.3.18. Original global source page 1915
Technical contribution of this variation: A machine-readable action
declaration is prevented from becoming unrestricted execution
permission solely because the agent successfully invoked the
structured interface.
M-2.15 — VARIATION J: PRIVILEGED INTERPROCESS BROKER
A low-trust autonomous agent may communicate with a more privileged
local process through an authenticated interprocess channel.
The privileged service may be capable of accessing protected files,
resources, credentials, or devices that the agent cannot reach
directly.
M-2.15.1 — Separate Requester
The untrusted agent constructs a Candidate Act.
M-2.15.2 — Authenticated IPC
A protected channel conveys the candidate operation to a privileged
service.
M-2.15.3 — Principal Attribution
The service identifies the original requesting authority.
M-2.15.4 — Protected Operation Reconstruction
Das Expires 29 April 2027 [Page 319]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The service resolves the actual consequential primitive it would
perform.
M-2.15.5 — Current Validation
The service verifies required authority, revocation, and resource
predicates.
M-2.15.6 — Protected Consumption
The privileged service or downstream resource performs the applicable
sink-local finality transition.
M-2.15.7 — Credential Isolation
Reusable privileged credentials need not be exposed to the agent.
M-2.15.8 — Anti-Bypass
The requesting agent lacks another permitted uncontrolled route to
the governed effect under the declared coverage model.
Technical contribution of this variation: Privileged interprocess
communication becomes a mandatory, operation-specific effectuation
bridge rather than a general delegation of the helper's authority.
M-2.16 — VARIATION K: OPERATING-SYSTEM PRE-EFFECTUATION AUTHORIZATION
HOOK
8.6.3.19. Original global source page 1916
An operating system may provide mechanisms through which a protected
component can authorize or deny selected pending events.
M-2.16.1 — Relevant Event
The protected monitor identifies a supported event corresponding to a
consequential resource operation.
M-2.16.2 — Blocking Qualification
The controller determines whether the mechanism can actually prevent
the event.
M-2.16.3 — Operation Descriptor
The event is mapped to the actual resource and effect class.
Das Expires 29 April 2027 [Page 320]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
M-2.16.4 — Source Binding
The actual requesting process or principal is identified.
M-2.16.5 — Current Permission
The protected controller checks operation-specific authority and
revocation.
M-2.16.6 — Decision
The applicable authorization event is permitted or denied.
M-2.16.7 — Monitoring-Only Events
Observation events that cannot block are not misclassified as
mandatory pre-effectuation gates.
M-2.16.8 — Coverage Qualification
If an event type or relevant actual effect is not covered by the
operating-system mechanism, an alternate protected sink or resource
control must enforce the requirement.
Technical contribution of this variation: A qualified OS blocking
primitive may implement part of the finality boundary while current
operation-specific authority and enforcement coverage remain
separately verified.
M-2.17 — VARIATION L: NETWORK EXTENSION, PROXY, AND EGRESS
ENFORCEMENT
A protected system may control external network effects through
network filters, proxies, relays, controlled sockets, or resource
gateways.
M-2.17.1 — Effect Class
The protected controller identifies a relevant network transmission
or remote API operation.
M-2.17.2 — Network Interface
8.6.3.20. Original global source page 1917
The current egress route is identified.
M-2.17.3 — Destination Resolution
Das Expires 29 April 2027 [Page 321]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The effective network endpoint is determined according to the
relevant policy.
M-2.17.4 — Application Semantics
Where authorization depends upon message body, recipient, method,
path, or application operation, those properties are verified at a
suitable trusted semantic boundary.
M-2.17.5 — Encrypted Content
A content-blind flow filter is not presumed to know the relevant
protected plaintext.
M-2.17.6 — Protected Content Commitment
A trusted pre-encryption controller may establish a commitment
binding approved plaintext, intended recipient, and outgoing
transmission.
M-2.17.7 — Actual Egress Gate
The required effectuation path enforces current protected authority.
M-2.17.8 — Dynamic Routes
Changes to proxy, network namespace, route, or device state may
require coverage revalidation.
Technical contribution of this variation: Network-level and
application-level enforcement are linked through an operation-
specific protected effect descriptor and cannot independently be
substituted for one another where their visibility differs.
M-2.18 — VARIATION M: NOTIFICATION-ASSISTED REVOCATION
An implementation may use asynchronous notifications to signal that
protected permission state has changed.
A notification need not carry complete authoritative revocation
state.
M-2.18.1 — Revocation Commitment
The source authority commits the withdrawal of permission.
M-2.18.2 — Notification
Das Expires 29 April 2027 [Page 322]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A messaging service signals a relevant state change.
M-2.18.3 — Protected Refresh
A receiving enforcement controller obtains the current authoritative
state.
M-2.18.4 — Generation Verification
8.6.3.21. Original global source page 1918
The receiving sink establishes current revocation generation.
M-2.18.5 — Missing Notification
The sink's current authority requirement does not depend solely upon
guaranteed delivery of the notification.
M-2.18.6 — Deferred Delivery
Delayed notification does not constitute new authorization.
M-2.18.7 — Sink-Local Fence
The actual effectuation resource must enforce the applied
invalidation.
M-2.18.8 — Alternative Transport
The notification mechanism may be push messaging, event streaming,
polling, periodic state synchronization, or an authenticated
distribution channel.
Technical contribution of this variation: Asynchronous notification
is used as a latency optimization, while current effect authorization
remains dependent upon protected authoritative state or expressly
bounded offline validity.
M-2.19 — VARIATION N: TRANSACTIONAL AUTHORITY AND CONSUMPTION STORE
An implementation may use a transactional database or suitably
protected persistent state mechanism to maintain:
Candidate Acts;
Current source-authority generations;
Evidence commitments;
Das Expires 29 April 2027 [Page 323]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Protected reservations;
Pending finality enablements;
Current revocation generations;
Actual-operation commitments;
And consumption state.
M-2.19.1 — Protected Preparation
The controller prepares one bounded finality transition.
M-2.19.2 — Current Validation
The operation's mandatory predicates are checked.
8.6.3.22. Original global source page 1919
M-2.19.3 — Atomic State Transition
A protected transaction consumes the applicable authority.
M-2.19.4 — Replay
A subsequent attempt observes the consumed state.
M-2.19.5 — Crash Recovery
The authoritative store determines whether the transition committed.
M-2.19.6 — External Effects
Where the resource effect lies outside the transaction domain, the
system separately governs dispatch and outcome uncertainty.
M-2.19.7 — Hardware Alternative
Suitable protected hardware state may replace the transactional
database where it supplies the required property.
M-2.19.8 — Technical Effect
The security of an operation-specific permission is not reduced to
the secrecy of an authorization token; a protected state transition
is required at the actual effectuation boundary.
Das Expires 29 April 2027 [Page 324]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
M-2.20 — VARIATION O: RECEIVER-SIDE API AND REMOTE SERVICE FINALITY
A remote resource service may implement the Finality Sink.
The upstream autonomous agent may possess a valid authorization
token, key-bound proof, and structured request permission.
Nevertheless, the receiving service independently verifies:
The actual operation parameters;
The effective resource identity;
The relevant permission scope;
Current revocation state;
Operation-specific enablement;
Resource version;
And protected consumption state.
M-2.20.1 — Actual Request
The receiving service reconstructs the operation it is about to
perform.
8.6.3.23. Original global source page 1920
M-2.20.2 — No Unrestricted Token Authority
A general API-access credential is insufficient for the selected
protected consequence.
M-2.20.3 — Finality Commit
The receiving service enforces the protected resource mutation or
external release.
M-2.20.4 — Idempotency
A receiver-side operation registry may prevent duplicate effects
under suitable transactional guarantees.
M-2.20.5 — Cross-Domain Evidence
Das Expires 29 April 2027 [Page 325]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Protected validation records may be authenticated across
administrative domains.
M-2.20.6 — Current Enforcement
The remote service must actually implement the required resource-side
gate to claim destination finality.
M-2.21 — VARIATION P: HARDWARE COMMAND AND DEVICE-SIDE FINALITY
A protected device controller may receive operation-specific
authority originating from a software agent, remote service, or
authorized application.
M-2.21.1 — Candidate Command
An agent prepares a bounded device operation.
M-2.21.2 — Source Authority
The protected controller establishes the original permitted command
scope.
M-2.21.3 — Device Identity
The actual device and current ownership are verified.
M-2.21.4 — Command Descriptor
The relevant actual parameters and effect class are identified.
M-2.21.5 — Protected Generation
Current hardware resource or revocation generations are checked.
M-2.21.6 — Hardware Gate
The device command interface refuses unauthorized effects.
M-2.21.7 — Consumption
8.6.3.24. Original global source page 1921
A protected operation-specific generation or usage state is consumed.
M-2.21.8 — Actual Outcome
Das Expires 29 April 2027 [Page 326]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Physical completion remains distinguished from command acceptance or
dispatch.
Technical contribution of this variation: A software authorization
mechanism does not become a complete hardware execution authorization
until verified and enforced by the actual effect-capable device
boundary.
M-2.22 — VARIATION Q: MIXED HARDWARE AND SOFTWARE ENFORCEMENT
A protected implementation may combine a software policy controller
with a hardware resource gate.
The software component may perform complex policy or semantic
validation.
The hardware component may enforce a smaller mandatory release
condition.
The protected relationship may require:
An authenticated operation digest;
A current protected authority generation;
A hardware-recognized resource identifier;
A bounded command enablement;
And protected consumption.
The implementation may separate computation-intensive evidence
evaluation from a relatively compact protected effectuation check.
A hardware gate need not parse every high-level application policy if
its accepted release condition is securely bound to the validated
actual operation.
The system must establish that the hardware gate cannot be tricked
into applying an enablement to an unrelated command.
M-2.23 — VARIATION R: MULTI-PROTOCOL AUTHORIZATION COMPOSITION
A particular consequential operation may require evidence from
several independently functioning security mechanisms.
For example:
Das Expires 29 April 2027 [Page 327]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A principal authorization system may establish the user's delegated
permission.
A proof-of-possession mechanism may establish requester key
possession.
A protected sandbox may restrict ordinary application interfaces.
8.6.3.25. Original global source page 1922
A current revocation service may establish source-authority status.
A network filter may restrict the egress route.
A protected resource sink may verify the actual effect.
The system may combine the corresponding evidence according to an
explicit operation-specific policy.
M-2.23.1 — Conjunctive Requirements
Several distinct properties may all be mandatory.
M-2.23.2 — Alternative Mechanisms
Two technologies may supply equivalent evidence for one specified
security predicate.
M-2.23.3 — Non-Equivalent Evidence
A proof of identity cannot substitute for current authorization.
M-2.23.4 — Mandatory Effect Control
A monitoring-only component cannot replace a required blocking gate.
M-2.23.5 — Evidence Qualification
Each source's actual technical guarantee is represented.
M-2.23.6 — Finality Relationship
The sink determines whether all required predicates are satisfied for
the actual operation.
M-2.24 — VARIATION S: REPLACEMENT OF SECURITY SUBSTRATES WITHOUT
REAUTHORISATION EXPANSION
Das Expires 29 April 2027 [Page 328]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
One authorized implementation may be replaced by another.
The protected controller may identify:
The original authorization mechanism;
Its supported evidence properties;
Its resource binding;
Its current configuration generation;
Its blocking capability;
And the corresponding replacement properties.
8.6.3.26. Original global source page 1923
If a new component provides an equivalent qualified property, the
system may revalidate affected operations under current authority.
If the new component lacks a required property, existing dependent
finality enablements become ineligible.
The system does not presume security equivalence merely because both
components are described as authentication, sandbox, proxy, or policy
services.
M-2.24.1 — Equivalent Substitute
A functionally compatible mechanism may replace a nonessential
substrate.
M-2.24.2 — Weaker Substitute
A monitoring-only substitute cannot silently replace mandatory
blocking enforcement.
M-2.24.3 — Changed Authorization Semantics
A different permission format requires new semantic correspondence
validation.
M-2.24.4 — Current Generation
The substitution advances or revalidates applicable protected
configuration state.
Das Expires 29 April 2027 [Page 329]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
M-2.24.5 — Actual Sink
Finality remains dependent upon current effectuation coverage and
operation-specific authority.
Technical contribution of this variation: Security-substrate
replacement is treated as an authority-affecting technical transition
rather than a transparent implementation detail.
M-2.25 — VARIATION T: BOUNDED OFFLINE AUTHORIZATION
A protected resource sink may be unable to contact the originating
authorization server.
Under a strict-online mode, the corresponding operation remains
withheld.
Under a selected bounded-offline mode, the sink may exercise
previously allocated authority only within its protected limits.
Such limits may include:
A maximum number of effects;
A protected validity duration;
A specific resource or operation class;
A protected generation;
A non-replenishable local finality allowance;
8.6.3.27. Original global source page 1924
And a requirement for revalidation before further authority is
issued.
A remote notification service is not treated as guaranteed immediate
delivery.
The system must not claim immediate global revocation if a
disconnected sink is independently allowed to continue using stale
authority.
M-2.26 — VARIATION U: DATA-RELEASE AND ENCRYPTION BOUNDARY
An autonomous application may prepare sensitive content for external
release.
Das Expires 29 April 2027 [Page 330]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The protected disclosure policy may require inspection of the actual
information.
If encryption occurs before a content-blind network controller, that
controller may be unable to verify the necessary plaintext property.
The system may therefore establish:
A protected pre-encryption evidence commitment;
An authorized recipient and release-purpose binding;
Current disclosure authority;
A protected encryption-operation reference;
A ciphertext transmission commitment where appropriate;
And independent enforcement at the actual release boundary.
The network filter may control the destination or connection.
The content-aware protected component may establish the data-release
predicate.
Neither is incorrectly represented as providing the other's security
guarantee without actual technical support.
M-2.27 — VARIATION V: MULTI-AGENT DELEGATION AND REVOCATION
A task may be delegated through several autonomous agents.
The original authorization may originate from a user, enterprise
policy, or protected resource controller.
The system may preserve:
Original source-authority identity;
Delegated operation scope;
Applicable resource and recipient constraints;
Relevant proof-of-possession or process-identity evidence;
Das Expires 29 April 2027 [Page 331]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.6.3.28. Original global source page 1925
Current revocation dependencies;
And finality consumption state.
A downstream agent's separate authentication does not automatically
supersede the original source-authority restrictions.
Revocation of a mandatory ancestor grant invalidates dependent
operation-specific enablement under the selected protected dependency
model.
M-2.28 — VARIATION W: ACTIONS WITH MULTIPLE CONSEQUENCES
A structured application action may appear to be one logical
operation while producing several effects.
Examples may include:
Updating a database;
Sending a notification;
Activating a payment instruction;
Changing a file;
And transmitting a remote message.
The system may identify each distinct consequential release boundary.
A principal implementation may create separate bounded Candidate Acts
or effect-specific child operations.
Each covered effect may require a distinct protected finality
predicate.
One high-level successful application-action result does not
automatically establish that all resulting consequences were
authorized or completed.
Where a successor effect requires an earlier verified real
consequence, the applicable accepted actual-effect receipt remains a
constitutive dependency.
M-2.29 — VARIATION X: UNIVERSAL PRIMITIVE-SUBSTITUTION INTERFACE
Das Expires 29 April 2027 [Page 332]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A protected implementation may expose a typed interface through which
different authorization, cryptographic, operating-system, network,
and hardware components provide qualified evidence.
A representative interface may comprise:
SECURITY_PRIMITIVE_ADAPTER = { primitive_class, evidence_type,
authorized_source_identity, supported_security_property,
8.6.3.29. Original global source page 1926
applicable_operation_fields, current_resource_scope,
enforcement_visibility, blocking_capability, freshness_rule,
revocation_dependency, protected_configuration_generation,
evidence_authentication, qualification_result } The interface must
distinguish:
Proof of principal identity;
Proof of key possession;
Proof of current resource permission;
Proof of an attached blocking mechanism;
Proof of actual operation semantics;
Proof of revocation status;
And proof of finality consumption.
A system must not collapse these properties into one generic Boolean
called authorized.
Where a selected actual effect requires several properties, the
Finality Sink verifies the corresponding distinct predicates.
M-2.30 — PROTECTED TECHNICAL INVARIANTS
The principal implementation may enforce the following technical
invariants.
Invariant A — Computation/Authority Separation
Generation of an operation by an autonomous model does not
independently authorize its consequence.
Invariant B — Evidence/Authority Separation
Das Expires 29 April 2027 [Page 333]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Authenticated permission evidence does not independently become
reusable complete finality authority.
Invariant C — Proof/Effect Separation
Successful identity or key-possession proof does not automatically
validate the full actual effect.
Invariant D — Semantic Correspondence
The actual resource operation must satisfy the protected authorized-
effect descriptor.
8.6.3.30. Original global source page 1927
Invariant E — Current Authority
A previously valid authorization cannot override a mandatory current
revocation or resource-state condition.
Invariant F — Enforcement Qualification
A required blocking predicate cannot be satisfied solely through
observation-only security instrumentation.
Invariant G — Non-Bearer Enablement
Possession of an opaque or signed authority artifact is insufficient
without the required protected sink state.
Invariant H — Monotonic Consumption
An operation-specific use cannot be duplicated by copying or
restoring earlier requester state.
Invariant I — Topology Continuity
A material enforcement-path change invalidates or revalidates
affected finality dependencies.
Invariant J — Outcome Integrity
The system distinguishes authority consumption, dispatch, resource
commit, and external actual-effect completion.
These invariants may be implemented through distinct mechanisms
according to the selected operation class.
Das Expires 29 April 2027 [Page 334]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
M-2.31 — PRINCIPAL FULLY INTEGRATED WORKFLOW
A representative integrated implementation performs the following
sequence.
Step 1 — Receive Operation Proposal. An autonomous entity proposes a
consequential action.
Step 2 — Construct Candidate Act. The operation is identified as a
protected proposed consequence.
Step 3 — Hold Non-Effective. The actual resource effect is withheld.
Step 4 — Resolve Authorization Sources. The system identifies
applicable grants, credentials, permissions, and delegated authority.
Step 5 — Collect Qualified Evidence. A protected collector obtains
the relevant authenticated evidence.
Step 6 — Translate Effect Scope. The authorization evidence is
mapped into a protected actual-effect envelope.
Step 7 — Verify Key and Requester Relations. Applicable
cryptographic holder or client-authentication properties are
evaluated.
8.6.3.31. Original global source page 1928
Step 8 — Resolve Current Revocation Dependencies. The protected
authority controller identifies the relevant source and delegated
grants.
Step 9 — Verify Current Revocation State. A qualified current
generation or status is established.
Step 10 — Qualify Enforcement Coverage. The system determines
whether the actual consequence is subject to mandatory blocking
enforcement.
Step 11 — Resolve Current Resource State. The resource, identity,
version, ownership, and policy generation are established.
Step 12 — Independently Validate. A protected execution-time
instance verifies the necessary current conditions.
Step 13 — Cross-Commit Evidence. The accepted collection and
validation records are bound to the same Candidate Act.
Das Expires 29 April 2027 [Page 335]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Step 14 — Prepare Non-Bearer Enablement. A protected controller
establishes scoped effectuation authority.
Step 15 — Bind the Designated Sink. The corresponding actual
effectuation boundary is identified.
Step 16 — Monitor Material Changes. Revocation, tool, policy,
topology, and resource changes invalidate affected enablement.
Step 17 — Present Actual Operation. The requester submits the
consequential operation.
Step 18 — Reconstruct Actual Effect. The Finality Sink obtains the
actual current operation descriptor.
Step 19 — Compare Authority and Effect. The sink verifies
correspondence with the authorized effect envelope.
Step 20 — Verify Current Revocation. The sink checks the applicable
protected authority generation and freshness.
Step 21 — Verify Enforcement Coverage. The required mandatory
effectuation path remains qualified.
Step 22 — Verify Current Enablement. The protected non-bearer
authority remains valid for that sink and resource.
Step 23 — Verify Monotonic State. The sink determines whether
permitted use remains.
Step 24 — Consume Authority. The applicable protected state
transition is committed.
Step 25 — Release the Consequence. The sink permits only the
verified actual operation.
Step 26 — Preserve Attempt State. A protected journal records the
effect attempt where applicable.
Step 27 — Reconcile Actual Outcome. Confirmed, rejected, partial,
and uncertain effects are distinguished.
8.6.3.32. Original global source page 1929
Step 28 — Require New Authority for Material Change. A different
effect requires new or suitably revalidated authorization.
M-2.32 — REFERENCE PSEUDOCODE: SECURITY-PRIMITIVE QUALIFICATION
Das Expires 29 April 2027 [Page 336]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
FUNCTION QUALIFY_SECURITY_PRIMITIVE( primitive_input, candidate_act,
protected_qualifier ):
REQUIRE VERIFY_PRIMITIVE_SOURCE( primitive_input )
REQUIRE VERIFY_PRIMITIVE_EVIDENCE( primitive_input )
property = protected_qualifier .DETERMINE_ACTUAL_SECURITY_PROPERTY(
primitive_input )
scope = protected_qualifier .RESOLVE_SUPPORTED_OPERATION_SCOPE(
primitive_input )
coverage = protected_qualifier .RESOLVE_ENFORCEMENT_CAPABILITY(
primitive_input )
IF property == UNKNOWN: RETURN UNQUALIFIED
RETURN protected_qualifier .AUTHENTICATE_QUALIFICATION({ property:
property,
operation_scope: scope,
enforcement_coverage: coverage,
candidate: HASH(candidate_act),
8.6.3.33. Original global source page 1930
configuration_generation: CURRENT_CONFIGURATION_GENERATION() }) The
function does not assume that a valid primitive supplies all security
properties required by the Candidate Act.
M-2.33 — REFERENCE PSEUDOCODE: AUTHORIZATION-TO-EFFECT TRANSLATION
FUNCTION CONSTITUTE_EFFECT_ENVELOPE( candidate_act,
qualified_authorization_evidence, protected_translation_controller ):
proposed = RESOLVE_CANDIDATE_OPERATION( candidate_act )
granted = protected_translation_controller
.EXTRACT_VERIFIED_PERMISSION_SCOPE( qualified_authorization_evidence
)
actual_contract = protected_translation_controller
.RESOLVE_EFFECT_CONTRACT( proposed )
IF NOT SUFFICIENT_EFFECT_SEMANTICS( actual_contract ): RETURN HOLD
Das Expires 29 April 2027 [Page 337]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
envelope = INTERSECT_AUTHORIZED_EFFECT_CONSTRAINTS( proposed,
granted, actual_contract )
IF envelope IS EMPTY: RETURN DENY
RETURN protected_translation_controller
.AUTHENTICATE_EFFECT_ENVELOPE({ candidate: HASH(candidate_act),
source_authority: HASH(qualified_authorization_evidence),
8.6.3.34. Original global source page 1931
authorized_effect: HASH_CANONICAL(envelope),
current_contract: HASH(actual_contract),
current_policy: CURRENT_POLICY_EPOCH() }) The intersection
establishes a bounded effect envelope; it must not expand the
original permission.
M-2.34 — REFERENCE PSEUDOCODE: REVOCATION-BOUND FINALITY CONSTITUTION
FUNCTION PREPARE_INTEROPERABLE_FINALITY( candidate_act,
collection_evidence, validation_evidence, effect_envelope,
protected_finality_controller ):
REQUIRE VERIFY_COLLECTION_EVIDENCE( collection_evidence )
REQUIRE VERIFY_INDEPENDENT_VALIDATION( validation_evidence )
REQUIRE VERIFY_COMMON_CANDIDATE_BINDING( candidate_act,
collection_evidence, validation_evidence )
REQUIRE VERIFY_AUTHORIZED_EFFECT_ENVELOPE( effect_envelope )
REQUIRE VERIFY_CURRENT_SOURCE_AUTHORITY()
REQUIRE VERIFY_CURRENT_REVOCATION_DEPENDENCIES()
REQUIRE VERIFY_CURRENT_MANDATORY_EFFECT_COVERAGE()
enablement = protected_finality_controller
.ATOMIC_PREPARE_OPERATION_AUTHORITY({ candidate: HASH(candidate_act),
8.6.3.35. Original global source page 1932
evidence: HASH(collection_evidence, validation_evidence),
Das Expires 29 April 2027 [Page 338]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
effect_envelope: HASH(effect_envelope),
revocation_generation: CURRENT_REVOCATION_GENERATION(),
coverage_generation: CURRENT_ENFORCEMENT_GENERATION(),
designated_sink: CURRENT_FINALITY_SINK(),
permitted_use_count: AUTHORIZED_USE_LIMIT() })
RETURN INERT_REFERENCE(enablement) The requesting agent does not
automatically receive a reusable complete resource authority.
M-2.35 — REFERENCE PSEUDOCODE: ACTUAL SINK VERIFICATION
FUNCTION EFFECTUATE_USING_EXISTING_SECURITY_SUBSTRATES(
candidate_act, enablement_reference, protected_finality_sink ):
actual_operation = protected_finality_sink
.RECONSTRUCT_ACTUAL_PENDING_OPERATION()
actual_resource = protected_finality_sink .RESOLVE_ACTUAL_RESOURCE()
REQUIRE actual_operation IS VALID
REQUIRE VERIFY_ACTUAL_OPERATION_CORRESPONDENCE( actual_operation,
candidate_act )
REQUIRE VERIFY_CURRENT_SOURCE_AUTHORITY( actual_operation )
REQUIRE VERIFY_CURRENT_REVOCATION_STATE(
8.6.3.36. Original global source page 1933
actual_operation )
REQUIRE VERIFY_CURRENT_OPERATION_PARAMETERS( actual_operation )
REQUIRE VERIFY_CURRENT_MANDATORY_ENFORCEMENT_COVERAGE(
actual_operation )
REQUIRE VERIFY_VALID_NON_BEARER_ENABLEMENT( enablement_reference,
actual_operation, actual_resource )
REQUIRE VERIFY_CURRENT_RESOURCE_STATE()
REQUIRE VERIFY_SINK_LOCAL_CONSUMPTION_STATE()
Das Expires 29 April 2027 [Page 339]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
consumption = protected_finality_sink .ATOMIC_CONSUME_ENABLEMENT(
enablement_reference, actual_operation )
IF consumption != COMMITTED: RETURN DENY
RETURN protected_finality_sink .EFFECTUATE_ACTUAL_OPERATION(
actual_operation ) The actual resource must be controlled by the
selected Finality Sink or a technically sufficient downstream
enforcement interface.
M-2.36 — REFERENCE PSEUDOCODE: REVOCATION PROPAGATION AND LOCAL FENCE
FUNCTION APPLY_AUTHORITY_REVOCATION( revocation_commitment,
protected_sink_controller ):
REQUIRE VERIFY_AUTHENTIC_REVOCATION( revocation_commitment )
REQUIRE VERIFY_REVOKER_SCOPE()
8.6.3.37. Original global source page 1934
current = protected_sink_controller .LOAD_CURRENT_AUTHORITY_STATE()
REQUIRE VERIFY_GENERATION_CONTINUITY( current, revocation_commitment
)
affected = RESOLVE_DEPENDENT_FINALITY_ENABLEMENTS(
revocation_commitment )
applied = protected_sink_controller
.ATOMIC_ADVANCE_REVOCATION_AND_FENCE({ affected_authority: affected,
new_generation: revocation_commitment.generation,
current_state: current })
IF applied != COMMITTED: RETURN ENFORCEMENT_NOT_CONFIRMED
RETURN PROTECTED_SINK_ENFORCEMENT_RECEIPT( applied ) A message-
delivery acknowledgement alone does not replace the protected sink-
application result.
M-2.37 — CONCRETE PHOSITA EXAMPLE: AUTONOMOUS API ACTION
A user permits an autonomous application to perform one bounded
cloud-service operation.
An existing authorization server issues resource permission.
Das Expires 29 April 2027 [Page 340]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A sender-constrained credential proves the requesting application's
possession of a corresponding key.
A structured action interface identifies the intended operation.
A protected adapter obtains the original permission and constructs a
Candidate Act.
The first protected instance commits the relevant collection-time
evidence.
A second independently protected instance validates current
authority, effect semantics, resource scope, and revocation state.
The resulting evidence is cross-committed to the operation.
8.6.3.38. Original global source page 1935
A protected controller prepares non-bearer finality enablement.
At the actual remote service, the Finality Sink reconstructs the
pending operation.
If the requested amount, target, resource, or operation method
differs materially from the authorized effect, the sink refuses the
consequence.
If the source grant has been revoked, the sink refuses the
consequence.
If the permission remains valid but the finality enablement was
already consumed, the sink refuses the duplicate effect.
The system does not depend upon the particular token format for these
finality conditions.
Expected demonstrable result: Valid identity, valid token, and valid
proof-of-possession may coexist with a correctly denied unauthorized
actual operation.
M-2.38 — CONCRETE PHOSITA EXAMPLE: AUTONOMOUS DESKTOP TOOL
A desktop autonomous assistant invokes a structured application
action.
The assistant operates under restricted process privileges.
The requested effect requires a privileged local service.
Das Expires 29 April 2027 [Page 341]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The assistant provides a Candidate Act to the protected service
through an authenticated interprocess interface.
The privileged service determines the actual file, resource, or
device operation.
The service verifies current source authority and protected
validation evidence.
An operating-system authorization mechanism or protected resource
controller enforces the applicable blocking condition.
A logging-only event monitor may supply evidence but cannot replace
the required blocking gate.
The privileged service consumes operation-specific non-bearer
authority before the actual effect.
Expected demonstrable result: A compromised assistant cannot
automatically exercise every effect available to the privileged
helper merely by possessing a valid IPC channel or structured tool
identifier.
M-2.39 — CONCRETE PHOSITA EXAMPLE: REVOCATION NOTIFICATION DELAY
An authorization server revokes an agent's protected grant.
A notification service signals the change to the local application.
The notification may be delayed.
8.6.3.39. Original global source page 1936
The actual resource sink does not treat the absence of a notification
as proof that the grant remains valid indefinitely.
It applies the selected current-state or bounded-freshness rule.
A previously valid operation presented after the required revocation
state becomes applicable is refused.
Expected demonstrable result: Correctness of current finality
authorization does not depend solely upon successful asynchronous
push delivery.
M-2.40 — CONCRETE PHOSITA EXAMPLE: ENCRYPTED NETWORK EGRESS
Das Expires 29 April 2027 [Page 342]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
An autonomous assistant prepares protected information for
transmission.
A network filter sees the destination and encrypted transport flow.
A protected application-level release controller examines the actual
plaintext before encryption.
A cross-commitment binds the authorized plaintext information,
recipient, and outgoing operation.
The actual release sink verifies current authority and consumes the
specified finality enablement.
The network controller enforces the covered transmission route.
The architecture does not pretend that the network filter can infer
unobserved plaintext semantics.
Expected demonstrable result: Content-dependent authorization remains
enforceable through an appropriate protected plaintext boundary even
where the network-flow control itself lacks plaintext visibility.
M-2.41 — CONCRETE PHOSITA EXAMPLE: SUBSTRATE REPLACEMENT
A protected system originally uses an application gateway that blocks
selected resource effects.
The gateway is replaced by a component that produces only event
notifications.
The new component is correctly authenticated.
It may provide valid monitoring information.
However, it lacks mandatory blocking capability for the relevant
effect.
The protected enforcement qualification changes.
Previously prepared finality enablements depending upon the old
blocking mechanism become ineligible.
A new qualified gate must be established before affected consequences
resume.
Das Expires 29 April 2027 [Page 343]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Expected demonstrable result: A valid security-service replacement
does not silently preserve execution authority when the replacement
supplies a weaker required enforcement property.
8.6.3.40. Original global source page 1937
M-2.42 — NON-LIMITING ADVERSARIAL TEST PROTOCOL
The following tests are proposed rather than reported completed
results.
Test 1 — Active Token, Unauthorized Effect: Present an active
credential for an actual operation beyond the original permitted
scope.
Test 2 — Valid Key Proof, Changed Operation: Prove possession of the
correct bound key but change the protected resource or effect
parameters.
Test 3 — Detailed Authorization, Different Recipient: Present a valid
structured permission while redirecting the actual operation to
another recipient.
Test 4 — Revoked Token, Historical Approval: Attempt a pending effect
using an authentic earlier approval after revocation.
Test 5 — Stale Introspection Response: Reuse an earlier active-status
response outside its qualified freshness state.
Test 6 — Notification Dropped: Suppress delivery of the asynchronous
revocation notification and verify the actual sink's defined
freshness or bounded-offline rule.
Test 7 — Notification Delivered, Fence Missing: Verify that receipt
of a notification is not incorrectly classified as completed sink
enforcement.
Test 8 — Signed Evidence Without Authority: Present a valid
cryptographic evidence record without a current non-bearer finality
enablement.
Test 9 — Copied Enablement Reference: Attempt a duplicate effect with
the same opaque reference.
Test 10 — Sandboxed Agent, Privileged Helper: Verify that the helper
independently checks the actual operation rather than relying on the
agent's sandbox membership.
Das Expires 29 April 2027 [Page 344]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Test 11 — Monitoring-Only Security Hook: Demonstrate that an audit
event cannot satisfy a mandatory blocking predicate.
Test 12 — Blocking Security Hook: Verify actual refusal of an
unauthorized supported operating-system operation.
Test 13 — Alternate Resource Path: Attempt the effect through another
API, socket, storage interface, or privileged worker.
Test 14 — Encrypted Egress: Demonstrate whether the protected
architecture verifies required plaintext semantics at a suitable
boundary.
Test 15 — Tool Contract Change: Replace a structured action
implementation with one producing additional side effects.
Test 16 — Resource Alias: Redirect a permitted logical resource name
to another actual object.
Test 17 — Different Authentication Primitive: Replace proof-of-
possession with mutual authentication while preserving the
independently enforced finality properties.
8.6.3.41. Original global source page 1938
Test 18 — Hardware Key Versus Software Key: Compare supported key-
protection properties without attributing unrelated resource-
enforcement guarantees.
Test 19 — Privileged Service Replacement: Change the broker
implementation and verify current enforcement qualification.
Test 20 — Network Path Mutation: Introduce an alternative connection
route and require coverage reassessment.
Test 21 — Local Atomic Consumption: Ensure that only the authorized
number of protected finality transitions commit.
Test 22 — Crash After Consumption: Restore a requester snapshot and
verify the consumed authority remains unusable.
Test 23 — Cross-Domain Revocation: Propagate a protected authority
change to a remote sink and verify actual fence application.
Test 24 — Missing Remote Receipt: Distinguish propagation attempted
from enforcement confirmed.
Das Expires 29 April 2027 [Page 345]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Test 25 — Bounded Offline Authority: Enforce the selected local
effect count or lease bound during disconnection.
Test 26 — Device Ownership Change: Reject a command under a stale
hardware authority generation.
Test 27 — Current Resource Version: Change the protected resource
after upstream validation.
Test 28 — Multi-Agent Delegation: Revoke a parent grant and identify
dependent downstream finality enablements.
Test 29 — Partial Multi-Effect Action: Verify separate finality
treatment of distinct real consequences produced by one structured
action.
Test 30 — Alternate Authorization Server: Replace one permission
system with a functionally compatible source while retaining current
actual-effect enforcement.
Test 31 — Token Mechanism Removed: Use an authenticated non-token
permission source and verify that the finality architecture remains
implementable.
Test 32 — Notification Mechanism Removed: Use online current-state
verification without asynchronous push notifications.
Test 33 — Hardware Key Mechanism Removed: Use a suitable software-
protected authentication mechanism within a stated weaker trust
model.
Test 34 — Effectuation Gate Removed: Demonstrate that losing the
mandatory blocking boundary defeats the claimed effect prevention,
establishing the technical necessity of the gate.
Test 35 — Sink Reconstruction Removed: Demonstrate that a previously
valid approval can be misapplied to a changed actual operation when
current correspondence is not checked.
8.6.3.42. Original global source page 1939
Test 36 — Revocation Generation Removed: Demonstrate that old
authority may remain apparently usable after protected revocation
when current generation binding is absent.
Test 37 — Monotonic Consumption Removed: Demonstrate how repeated
requests may exercise the same logical authority where no
authoritative consumption condition exists.
Das Expires 29 April 2027 [Page 346]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Test 38 — Full Combination: Demonstrate the complete operation-
specific protected authority chain across several compatible existing
security substrates.
Each test should use a controlled resource and observable effect
boundary.
The reported outcome should distinguish actual completed tests from
expected demonstrable behavior.
M-2.43 — TECHNICAL CAUSALITY AND CONTRIBUTION OF THE COMBINATION
The technical character of a combination should not rest solely upon
the fact that multiple known security mechanisms are present.
The disclosed principal architecture creates an enforceable
dependency among components that would otherwise provide separate and
potentially insufficient guarantees.
M-2.43.1 — First Technical Dependency
The output of an authorization system is converted into a bounded
actual-effect envelope rather than being accepted as complete
finality authority.
M-2.43.2 — Second Technical Dependency
A proof of client identity or key possession is independently
classified as evidence of that property without being
mischaracterized as proof of the entire consequential operation.
M-2.43.3 — Third Technical Dependency
The protected system establishes current authority and revocation
state for the original grant and its required descendants.
M-2.43.4 — Fourth Technical Dependency
The actual effectuation interface is qualified for mandatory blocking
enforcement.
M-2.43.5 — Fifth Technical Dependency
The Finality Sink reconstructs the operation actually presented to
the resource.
M-2.43.6 — Sixth Technical Dependency
Das Expires 29 April 2027 [Page 347]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The actual operation must match the protected authorized-effect
envelope and current source authority.
M-2.43.7 — Seventh Technical Dependency
8.6.3.43. Original global source page 1940
Separate protected non-bearer finality enablement is consumed under
authoritative sink-local state.
M-2.43.8 — Resulting Technical Property
Where the selected trust and enforcement assumptions are satisfied, a
valid upstream permission, token, cryptographic proof, sandbox
entitlement, monitoring record, or notification does not
independently authorize an unauthorized or replayed consequential
effect.
This property arises from the enforced relationships among the
stages, rather than from the mere simultaneous presence of their
underlying primitives.
M-2.44 — TECHNICAL ABLATION AND COUNTERFACTUAL ANALYSIS
The following comparative investigations may be performed to identify
the contribution of the selected combination.
M-2.44.1 — Permission Verification Without Actual-Effect
Reconstruction
An implementation verifies authorization but does not reconstruct the
real operation at the resource boundary.
A controlled substitution test examines whether a changed target or
parameter may escape the earlier approval.
M-2.44.2 — Actual-Effect Reconstruction Without Current Revocation
An implementation verifies the operation but relies upon stale source
authority.
A controlled revocation test examines whether a previously approved
effect may still occur.
M-2.44.3 — Cryptographic Binding Without Consumption
An implementation authenticates the operation but does not enforce an
authoritative operation-specific use count.
Das Expires 29 April 2027 [Page 348]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A controlled replay test examines duplicate effectuation.
M-2.44.4 — Sandbox Without Privileged-Broker Finality
An application is restricted while a privileged helper accepts broad
commands.
A controlled operation tests whether the assistant can indirectly
cause an unauthorized effect.
M-2.44.5 — Monitoring Without Blocking
An event monitor observes unauthorized effects but does not prevent
them.
A controlled resource test establishes the distinction between
detection and pre-effectuation denial.
M-2.44.6 — Notification Without Authority Freshness
A system uses asynchronous revocation notification as its only
invalidation mechanism.
8.6.3.44. Original global source page 1941
A dropped-message test examines whether the resource can continue
accepting stale permission.
M-2.44.7 — Complete Protected Combination
The corresponding system enforces current source authority, actual
operation binding, qualified blocking, and protected consumption at
the resource.
The controlled tests compare actual consequences under the same
operation, resource, and attacker assumptions.
M-2.44.8 — Interpretation
A difference in observed behavior may support a specific technical-
effect argument.
The tests do not, by themselves, prove that the mechanism is legally
novel or non-obvious.
M-2.45 — PROPOSED INVENTIVE-STEP CHARACTERIZATION
M-2.45.1 — Avoiding a Mere Aggregation of Known Primitives
Das Expires 29 April 2027 [Page 349]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
The invention should not be characterized simply as:
“An AI security system comprising OAuth, sandboxing, cryptography,
notifications, and a network filter.”
Such a formulation presents independent known mechanisms without
establishing a necessary technical interaction.
The present disclosure instead identifies a protected ordered
authority transition in which each selected mechanism contributes a
specifically qualified property to a common effectuation decision.
M-2.45.2 — Candidate Objective Technical Problem
How to prevent a heterogeneous authorization or security subsystem
from being treated as sufficient permission for an actual autonomous
consequential effect when the subsystem proves only a partial
security property, especially after operation transformation,
resource change, revocation, execution-path modification, or
authority replay.
M-2.45.3 — Candidate Technical Solution
A protected translation and validation arrangement converts qualified
outputs of heterogeneous existing security mechanisms into operation-
specific evidence and effect constraints.
Current source-authority and revocation dependencies are verified.
Mandatory blocking enforcement is established at the corresponding
resource boundary.
Separate non-bearer finality enablement is constituted.
The actual Finality Sink reconstructs the operation presented for
effectuation and verifies the current constraints before protected
consumption and release.
M-2.45.4 — Why Mere Juxtaposition Is Insufficient
8.6.3.45. Original global source page 1942
An authorization token may establish permission but not the precise
current actual effect.
A cryptographic proof may establish key possession but not full
operation legitimacy.
Das Expires 29 April 2027 [Page 350]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A sandbox may restrict a process but not necessarily control every
privileged intermediary.
A network monitor may observe traffic without the information
necessary for semantic authorization.
A notification may signal revocation without establishing its
enforcement.
A cryptographic signature may authenticate an approval but not
establish remaining consumable authority.
The proposed stronger system does not merely place these mechanisms
side by side.
It assigns distinct evidentiary and enforcement roles and makes their
qualified outputs necessary, but individually insufficient, inputs to
one current protected actual-effect transition.
M-2.45.5 — Technical Interdependence
The authorization adapter produces qualified original authority
evidence.
The effect translator determines the permitted consequential
envelope.
The protected validator checks current operation and authority
correspondence.
The revocation controller invalidates affected pending finality
dependencies.
The enforcement qualifier establishes that the actual resource path
is controllable.
The finality controller prepares operation-specific non-bearer
authority.
The actual sink reconstructs the pending real operation.
The consumption controller prevents unsupported duplicate release.
A selected failure of a required dependency prevents the
corresponding protected effect.
M-2.45.6 — Prior-Art Combination Analysis
Das Expires 29 April 2027 [Page 351]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A proper comparison should ask whether an earlier system discloses
not merely individual permission and security controls, but the
specific protected relationships recited by the selected claim.
Where an earlier system already discloses the same dependencies and
actual sink behavior, the claim must be correspondingly narrowed or
differentiated through genuinely supported technical limitations.
M-2.45.7 — Hindsight Reconstruction Concern
A technical analysis should avoid treating knowledge of the proposed
architecture as the reason that a skilled person would have selected
and arranged the underlying primitives.
8.6.3.46. Original global source page 1943
Instead, an inventive-step evaluation may examine:
The objective technical problem recognized by the relevant prior
system;
Which actual effectuation or revocation failures the earlier system
addressed;
Which component possessed the necessary resource-side information;
Whether the earlier system required independent actual-operation
reconstruction;
Whether a separate finality enablement and protected consumption
transition were provided;
And whether the cited references disclose an express or technically
supported reason to make those particular dependencies mandatory.
The absence of an identical statement in one reference is not, by
itself, sufficient to establish inventive step.
M-2.45.8 — Interoperability Difficulty
The underlying primitives may use different operation identifiers,
permission semantics, freshness models, effectuation boundaries, and
protected-state assumptions.
The claimed technical integration addresses these incompatibilities
by requiring a typed and protected effect descriptor, qualified
evidence properties, current authority generations, and sink-local
finality state.
Das Expires 29 April 2027 [Page 352]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
M-2.45.9 — Non-Equivalent Substitution
Replacing one security primitive with another that provides weaker
actual-operation visibility or blocking capability may invalidate
current consequential authority.
A generic interchangeable-security-component architecture does not
necessarily provide this protected coverage invalidation behavior.
M-2.45.10 — Specificity of Technical Effect
Any inventive-step argument should identify demonstrable technical
behavior, including refusal of unauthorized transformed effects,
rejection of stale revoked authority, prevention of duplicate
finality consumption, or failure-closed handling of missing
enforcement.
Such behavior should be tied to corresponding claim limitations.
M-2.46 — CANDIDATE DISTINCTIVE TECHNICAL KERNELS
M-2.46.1 — Kernel A: Heterogeneous Authorization-to-Actual-Effect
Binding
A protected adapter converts one or more authorization-system results
into a bounded operation-specific effect envelope, and the actual
Finality Sink reconstructs and verifies the pending consequential
operation against that envelope.
M-2.46.2 — Kernel B: Revocation-Dependent Non-Bearer Authority
8.6.3.47. Original global source page 1944
Current revocation state of a source grant and its required delegated
dependencies is a mandatory condition of a separate protected
finality enablement verified and consumed at the actual sink.
M-2.46.3 — Kernel C: Proof-of-Possession Without Automatic Finality
A successful cryptographic proof identifies an authorized credential
presenter while actual consequential authority remains dependent upon
independent effect validation and protected consumption.
M-2.46.4 — Kernel D: Mandatory Enforcement Qualification
Das Expires 29 April 2027 [Page 353]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A protected controller classifies existing application, OS, network,
and hardware security mechanisms according to their actual blocking
capability and refuses effectuation when a required enforcement path
is not qualified.
M-2.46.5 — Kernel E: Notification-Independent Revocation Safety
A protected resource uses qualified current authority generations or
bounded offline validity rather than relying solely on asynchronous
revocation notification.
M-2.46.6 — Kernel F: Privileged Service Finality
An untrusted autonomous agent cannot convert an authenticated IPC
request into unrestricted exercise of a privileged service's
underlying credentials or device authority.
M-2.46.7 — Kernel G: Security-Substrate Replacement Invalidation
A material change to the semantic or blocking guarantee supplied by
an authorization or security component invalidates dependent
operation-specific finality authority until revalidation.
M-2.46.8 — Kernel H: Cross-Domain Effect Evidence and Resource
Consumption
Authenticated authorization evidence from one domain is independently
verified and transformed into finality eligibility consumed at a
different protected resource domain.
M-2.46.9 — Kernel I: Plaintext-Aware Release with Network Enforcement
A protected pre-encryption content commitment and recipient binding
are verified in conjunction with a controlled egress route, without
requiring the network-flow mechanism itself to understand plaintext.
M-2.46.10 — Kernel J: Crash-Consistent Finality Continuity
Actual-effect authority consumption and dispatch intent remain
protected across failures, independently of whether an external
receiver provides an immediate completion acknowledgement.
These kernels may support different claim families or dependent
limitations.
Their combination should preserve a single identifiable technical
relationship where required by the selected claim.
Das Expires 29 April 2027 [Page 354]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
8.6.3.48. Original global source page 1945
M-2.47 — POTENTIAL INDEPENDENT CLAIM ARCHITECTURES
M-2.47.1 — Candidate Independent Claim A: Interoperable Execution-
Finality System
A system comprising:
A protected adapter configured to obtain authenticated evidence from
at least one authorization or security mechanism;
A protected effect-translation controller configured to derive an
operation-specific permitted effect envelope from the evidence;
A protected validation controller configured to verify current
authority and applicable operation conditions;
A finality-authority controller configured to establish separate
scoped non-bearer effectuation enablement;
And an independently enforcing Finality Sink configured to
reconstruct the actual pending operation, verify correspondence with
the permitted effect envelope and current authority state, and
consume the enablement before permitting the consequential effect.
M-2.47.2 — Candidate Independent Claim B: Revocation-Coupled Method
A method comprising:
Receiving a Candidate Act;
Resolving its original authorization and downstream dependencies;
Authenticating a current revocation or authority-generation state;
Invalidating operation-specific enablement affected by the current
revocation state;
And refusing the actual resource effect at a mandatory Finality Sink
when a required source authority has been withdrawn.
M-2.47.3 — Candidate Independent Claim C: Protected Enforcement-
Qualification Apparatus
An apparatus comprising:
Das Expires 29 April 2027 [Page 355]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
An interface for obtaining qualified security-mechanism capability
evidence;
A controller configured to distinguish observation-only and blocking
enforcement;
A current effectuation-path dependency state;
And an actual effectuation gate configured to invalidate or refuse
operation-specific finality when a required blocking condition
becomes unavailable.
M-2.47.4 — Candidate Independent Claim D: Privileged Agent-Broker
Finality
8.6.3.49. Original global source page 1946
A protected service configured to receive a proposed operation from a
lower-trust autonomous requester, independently resolve the actual
resource-side operation, verify current source-derived authority and
protected non-bearer finality state, and exercise the privileged
resource only upon satisfaction of the corresponding sink-local
consumption condition.
M-2.47.5 — Candidate Independent Claim E: Hardware-Assisted Finality
A protected apparatus comprising a hardware-supported authority-
verification function, current resource or revocation state, and an
effect-capable command gate configured to refuse actual commands
without a matching operation-specific finality enablement.
M-2.47.6 — Candidate Independent Claim F: Cross-Domain Implementation
A system comprising an originating authorization domain, a protected
evidence and operation-translation component, a separately controlled
destination Finality Sink, and authenticated current authority and
actual-effect binding enforced by the destination before
consequential execution.
M-2.47.7 — Claim Drafting Consideration
The broadest candidate should capture a demonstrable common technical
interaction rather than require every optional standards adapter.
Dependent claims may introduce specific cryptographic, OS, network,
IPC, notification, and hardware implementations.
Das Expires 29 April 2027 [Page 356]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Where a narrower variation independently supports a distinct
technical effect, a separate claim family may be considered.
M-2.48 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
1. The authorization evidence is obtained from an OAuth-compatible
authorization server.
2. The authorization evidence comprises structured operation-
specific permission details.
3. A protected effect translator maps structured permission details
to an actual resource effect envelope.
4. The actual resource verifies correspondence between the requested
operation and the permission envelope.
5. A token-revocation result invalidates affected pending finality
enablement.
6. A current token-status or introspection result is associated with
an authenticated authority generation.
7. Authorization-status caching is subject to protected freshness
requirements.
8. A stale active-status result cannot override a current revoked
source grant.
9. A sender-constrained credential provides qualified proof-of-
possession evidence.
10. Proof-of-possession is evaluated separately from actual
operation authorization.
8.6.3.50. Original global source page 1947
11. A certificate-bound credential provides authenticated requester
binding.
12. A mutually authenticated communication channel transports
qualified authority evidence.
13. A protected cryptographic key manager authenticates operation-
related evidence.
14. Protected key material is unavailable to the untrusted requester
where selected.
Das Expires 29 April 2027 [Page 357]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
15. Key-possession evidence does not independently confer
unrestricted finality authority.
16. An operating-system sandbox constrains the requesting workload.
17. Entitlement or permission evidence is included in effectuation-
path qualification.
18. An alternate privileged intermediary is classified as a separate
effect-capable path.
19. A structured application action is represented as a Candidate
Act.
20. Tool or application-action parameters are resolved into a
protected actual-effect descriptor.
21. A material action-contract change invalidates dependent
authority.
22. An authenticated interprocess service receives a Candidate Act
from a lower-trust process.
23. The privileged service verifies original source-derived
operation authority.
24. The privileged service prevents release of reusable complete
resource credentials to the requester.
25. An operating-system event authorization hook serves as a
mandatory enforcement component for supported operations.
26. Observation-only hooks cannot satisfy a required blocking
predicate.
27. A protected network filter constrains the corresponding
effectuation route.
28. An application-level gateway verifies content semantics
unavailable to a lower-level network-flow monitor.
29. A protected pre-encryption commitment binds authorized plaintext
to a specified recipient or transmission.
30. A network routing or proxy change triggers finality-path
revalidation.
31. An asynchronous notification signals a revocation-state change.
Das Expires 29 April 2027 [Page 358]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
32. The system does not rely upon guaranteed delivery of the
notification to establish current finality safety.
33. A protected sink queries authoritative current revocation state
before a specified consequential effect.
34. A protected offline lease bounds the permissible use of stale
authorization evidence.
35. Revocation-dependent authority is associated with a monotonic
protected generation.
8.6.3.51. Original global source page 1948
36. A revocation of a mandatory parent grant invalidates dependent
delegated finality authority.
37. An unaffected independent authorization remains eligible where
the applicable policy permits it.
38. A protected finality controller cross-commits collection-time
and independently validated execution-time evidence.
39. The finality enablement is bound to one authorized Candidate
Act.
40. The enablement is bound to a designated Finality Sink.
41. The actual Finality Sink reconstructs the pending operation
independently of the requester's prior self-description.
42. The sink verifies current resource identity.
43. The sink verifies current revocation or authorization state.
44. The sink verifies current mandatory effectuation-path coverage.
45. The sink verifies a protected current policy or configuration
generation.
46. The sink verifies current resource version or ownership where
required.
47. A copied opaque enablement reference remains insufficient for
effectuation.
48. A protected consumption state prevents unauthorized repeated
exercise.
Das Expires 29 April 2027 [Page 359]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
49. A transactional resource controller atomically commits local
effect and corresponding finality consumption where supported.
50. A remote operation preserves durable consumption and dispatch-
intent state.
51. An uncertain external outcome does not automatically restore
consumed authority.
52. A hardware command gate verifies current device-bound finality.
53. A direct accelerator-originated effect is treated as a separate
controlled effectuation path where required.
54. Material hardware resource reassignment invalidates dependent
authority generations.
55. A security-substrate replacement triggers requalification of its
supplied enforcement property.
56. A weaker monitoring-only replacement does not inherit earlier
blocking coverage.
57. A notification-delivery acknowledgement is distinguished from
proof of sink-side revocation application.
58. A protected enforcement receipt identifies the actual sink and
committed invalidation state.
59. The system uses a typed interface identifying the technical
security property supplied by each underlying mechanism.
8.6.3.52. Original global source page 1949
60. A successful identity proof cannot substitute for a required
effect-semantics proof.
61. A successful token-validity check cannot substitute for
protected finality consumption.
62. A valid earlier approval cannot override a later mandatory
revocation.
63. A multi-effect structured action is decomposed into separately
governed actual consequences where selected.
64. A dependent successor operation requires an accepted earlier
real-effect receipt where the applicable causal protocol requires it.
Das Expires 29 April 2027 [Page 360]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
65. The disclosed finality relation is implemented without
dependence upon any particular authorization protocol or device
manufacturer.
M-2.49 — UNIVERSAL COMBINATION, SUBCOMBINATION, AND SUBSTITUTE-
IMPLEMENTATION CLAUSE
The individual implementation mechanisms described in this
Miscellaneous Embodiment M-2 may be used alone where they constitute
a technically complete selected invention, or in any technically
compatible subcombination or combined architecture.
An implementation may combine structured authorization details with
protected current revocation and actual-operation finality.
Another may combine proof-of-possession authentication with a
protected broker and sink-local finality consumption.
Another may combine a hardware-protected cryptographic key with
operation-specific finality and protected resource-state
verification.
Another may combine sandbox confinement, entitlement checks, and
mandatory operating-system resource authorization.
Another may combine structured application actions, privileged
interprocess communication, and actual-effect reconstruction.
Another may combine network egress control with protected plaintext-
aware data-release authorization.
Another may combine asynchronous revocation notification with current
authority-generation checking.
Another may combine protected transactional state, current revocation
dependencies, and finality consumption.
Another may combine hardware command enforcement with current device
ownership and protected authority generations.
Another may combine all of the foregoing, provided that each included
mechanism supplies an actually supported security property and the
claimed protected authority relationship remains enforceable.
8.6.3.53. Original global source page 1950
An authorization server may be replaced by another functionally
compatible authority provider.
Das Expires 29 April 2027 [Page 361]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A proof-of-possession protocol may be replaced by another
authenticated cryptographic holder-binding mechanism.
A protected key manager may be implemented in software or hardware
under the applicable selected protection model.
A sandbox may be implemented using suitable operating-system,
hypervisor, container, or hardware resource restrictions.
A structured application-action framework may be replaced by another
machine-readable tool or invocation interface.
A privileged IPC service may be replaced by another suitably
protected effectuation broker.
An operating-system authorization hook may be replaced by a resource-
specific blocking controller.
A network extension or proxy may be replaced by another controlled
network effectuation path.
An asynchronous notification transport may be replaced by polling,
authenticated event delivery, or current-state queries.
A transactional authority store may be replaced by an equivalent
protected monotonic state mechanism.
A Finality Sink may be an application service, network gateway,
database transaction controller, operating-system resource gate,
credential broker, storage controller, hardware command interface, or
another mandatory consequential boundary.
The functional equivalence of any substitute is determined by the
actual property required by the selected implementation, not merely
by the substitute's label or commercial classification.
The invention is not limited to the simultaneous use of every
optional security mechanism.
Where an operation requires one selected combination of authority,
evidence, current revocation, coverage, and finality predicates, the
corresponding required combination remains mandatory for that
operation.
The disclosed embodiments are not restricted to a single ordering of
nondependent administrative or preparatory operations.
Das Expires 29 April 2027 [Page 362]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
However, the protected causal relationships necessary to prevent
unauthorized consequential release must be preserved.
Compatible embodiments may share the same protected evidence
collector, validator, authority controller, revocation registry,
coverage verifier, resource controller, or Finality Sink.
Such sharing does not remove any expressly required independence or
protected-state separation.
The mathematical descriptions, pseudocode, security-protocol
examples, tests, data structures, and reference architectures are
non-limiting explanatory aids for a person having ordinary skill in
the art.
8.6.3.54. Original global source page 1951
The examples do not restrict the invention to a particular commercial
protocol or hardware implementation.
M-2.50 — FINAL TECHNICAL CHARACTERIZATION
The present Miscellaneous Embodiment M-2 discloses a protected
integration architecture that permits existing authorization,
cryptographic, operating-system, sandbox, communication, network,
credential, notification, transactional, and hardware security
mechanisms to contribute to autonomous execution-finality control
without treating their individual successful results as sufficient
authorization for a real consequential operation.
A requesting computational entity may possess valid credentials,
successful cryptographic authentication, permitted application-tool
access, and resource-interface connectivity while still lacking
current authority to produce a specific consequential effect.
A protected adapter obtains evidence concerning the properties
actually established by the selected security mechanisms.
A protected translation controller converts the relevant permission
and operation information into a bounded actual-effect envelope.
A protected validator determines whether the required source
authority, revocation state, resource conditions, and operation
semantics remain valid.
Where the selected implementation requires collection-time and
independent execution-time evidence, the corresponding records are
cross-committed to the same Candidate Act.
Das Expires 29 April 2027 [Page 363]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
A separate protected controller establishes scoped non-bearer
finality enablement.
The enablement remains dependent upon the selected current authority
and enforcement conditions.
Material changes to source authorization, revocation state, operation
semantics, security-substrate capability, or actual effectuation-path
coverage may invalidate affected authority.
At the actual resource boundary, an independent Finality Sink
reconstructs the pending consequential operation and checks the
relevant current predicates.
A valid upstream token, signed receipt, key-possession proof, sandbox
entitlement, structured action declaration, security event
notification, or cached active-status result does not independently
bypass that verification.
The resource-side controller requires valid protected enablement and
performs the applicable sink-local consumption transition before the
consequential effect is permitted.
The architecture may use known technical primitives while requiring
an additional operation-specific protected authority constitution and
finality relationship.
The principal candidate inventive technical concept of Miscellaneous
Embodiment M-2 is a standards-interoperable and platform-independent
protected execution-finality architecture in which heterogeneous
established authorization and security mechanisms supply individually
qualified evidence or enforcement properties, a protected controller
binds those properties to a specific consequential Candidate Act and
its current original authority, revocation and actual-effect scope,
separately constitutes non-bearer finality enablement, and
8.6.3.55. Original global source page 1952
requires an independently enforcing Finality Sink to reconstruct the
actual pending effect and verify current authority, enforcement
coverage, and sink-local protected consumption before releasing the
consequence.
END OF MISCELLANEOUS EMBODIMENT M-2 — COMPLETE TECHNICAL DISCLOSURE.
Das Expires 29 April 2027 [Page 364]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
9. Formalized Threat Models, Protected Assets, Attacker Capabilities
and Residual Risks
The following six categories are editorial security analyses inspired
by the source-described failure modes. They define threat
preconditions and proposed tests, but do not assert a formal proof or
successful mitigation outside an implementation-specific coverage and
trust model.
9.1. Prompt Injection and Unauthorized Agent Tool Effects
9.1.1. Attacker precondition and exploit path
Attacker controls retrieved documents, external web text or tool
responses and influences an AI agent to change a payment recipient or
export sensitive data.
9.1.2. Protected assets and security predicates
Protected original source grant, actual output content, recipient and
controlled Finality Sink.
9.1.3. Proposed defense and observables
Treat model output as untrusted Candidate Act; maintain source-
validated effect envelope independent of the injected instruction;
reconstruct actual request at sink.
9.1.4. Residual limitations
Uncontrolled alternate egress or a genuinely authorized later scope
increase requires separate treatment.
9.1.5. Validation link
See proposed security test cases T1, T7 and T13.
9.2. Replay, Credential Possession and Cloned Authority
9.2.1. Attacker precondition and exploit path
Attacker replays a once-valid enablement, clones an agent container
or restores a database snapshot after a valid earlier effect.
9.2.2. Protected assets and security predicates
Operation-scoped non-bearer authority and monotonic sink-local
consumption state.
Das Expires 29 April 2027 [Page 365]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
9.2.3. Proposed defense and observables
Use protected single-use state, independent actual operation binding,
epoch checks, durable journaling and replay-fencing conditions.
9.2.4. Residual limitations
A sink outside the mandatory coverage boundary or rolled-back
protected state can invalidate intended guarantees.
9.2.5. Validation link
See proposed security test cases T2, T8 and T14.
9.3. Forged, Replaced or Colluding Evidence
9.3.1. Attacker precondition and exploit path
Attacker forges a source approval, substitutes one operation evidence
record for another, compromises a validation service or makes two
validators share an uncontrolled signing key.
9.3.2. Protected assets and security predicates
Independent collection-time and execution-time evidence provenance,
commitments and validation result.
9.3.3. Proposed defense and observables
Authenticate protected observations and bind two evidence instances
to the same actual effect and source context; state independence
assumptions explicitly.
9.3.4. Residual limitations
Cryptographic protection cannot save measurements produced by fully
compromised trusted collectors.
9.3.5. Validation link
See proposed security test cases T3, T9 and T15.
9.4. Delegation, Scope Widening and Revocation Race
Das Expires 29 April 2027 [Page 366]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
9.4.1. Attacker precondition and exploit path
Authorized agent holds a broad API access credential but the original
user approved only a narrower resource operation; an upstream grant
changes before dispatch.
9.4.2. Protected assets and security predicates
Current originating grant, actual scope, revocation generation,
delegated authority and beneficiary.
9.4.3. Proposed defense and observables
Require current authority revalidation, no silent permission
expansion and sink-local matching of actual resource, method,
recipient and parameters.
9.4.4. Residual limitations
Remote authority services may be partitioned; fail-closed policy can
deny benign operations.
9.4.5. Validation link
See proposed security test cases T4, T10 and T16.
9.5. Crash, Duplicate Dispatch and Unknown Outcome
9.5.1. Attacker precondition and exploit path
Host crashes after protected consumption or after remote dispatch;
retry attempts repeat a payment, email or hardware act.
9.5.2. Protected assets and security predicates
Protected journal, logical operation identity, external effect
outcome and new recovery authority.
9.5.3. Proposed defense and observables
Preserve durable consumption, distinguish dispatch from completion,
use receiver-supported idempotency where available, mark unknown
outcomes indeterminate.
9.5.4. Residual limitations
Local exactly-once authorization does not guarantee exactly-once
remote effects absent receiver cooperation.
Das Expires 29 April 2027 [Page 367]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
9.5.5. Validation link
See proposed security test cases T5, T11 and T17.
9.6. Bypass, Alternate Credential Path and Protected-Component
Compromise
9.6.1. Attacker precondition and exploit path
Attacker avoids a policy middleware through direct sockets,
privileged connector, stale signing path, disabled sandbox or
compromised gateway.
9.6.2. Protected assets and security predicates
Effectuation boundary coverage, credential custody, hardware/OS
enforcement and protected sink execution integrity.
9.6.3. Proposed defense and observables
Inventory all covered effect paths, deny when coverage lost, hold
real credentials outside agent, require sink observation and fail
closed on required attestation failure.
9.6.4. Residual limitations
Some iOS/Android native resources cannot be subjected to third-party
systemwide mandatory enforcement; guarantees are limited by actual
available controls.
9.6.5. Validation link
See proposed security test cases T6, T12 and T18.
10. Reproducible Proposed Test Plan: 20 Independent Positive and
Negative Cases
Tests T01–T20 are design proposals, not assertions that software has
been written or that any assertion has already passed. An
independent implementer should publish repository commit, hardware/
software versions, input vectors, signed evidence objects, operation
traces, journal snapshots, observed receiving-resource result, and
false-accept/false-reject counts for each. Each test must verify
actual outcome where feasible, not merely a local authorization
return code.
Das Expires 29 April 2027 [Page 368]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
10.1. T01: Authorized iOS-originated API update
Preconditions, fixture, and attack stimulus: Valid user source grant;
two qualified evidence instances; actual authorized resource and
method.
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: One successful state consumption and
exactly the permitted resource change.
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
10.2. T02: Android intent-induced prompt injection
Preconditions, fixture, and attack stimulus: Authorized read intent;
injected tool output requests external export.
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: Reject actual export outside originally
permitted effect envelope.
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
10.3. T03: Alter request body after validation
Preconditions, fixture, and attack stimulus: Valid approved
descriptor; replace payload, recipient or amount before sink.
Das Expires 29 April 2027 [Page 369]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: Reject mismatch and leave resource
unchanged.
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
10.4. T04: Replay consumed finality enablement
Preconditions, fixture, and attack stimulus: Effect once with same
operation reference; present identical reference again.
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: First may complete; second denied based
on protected sink-local consumption.
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
10.5. T05: Stale originating source grant
Preconditions, fixture, and attack stimulus: Create approval then
commit principal revocation before actual dispatch.
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: Withhold effect despite valid previous
evidence/credential.
Das Expires 29 April 2027 [Page 370]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
10.6. T06: Compromised collection evidence
Preconditions, fixture, and attack stimulus: Alter evidence MAC/
signature, source binding or timestamp.
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: Reject altered or unauthenticated
collection-time evidence.
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
10.7. T07: Cross-commitment substitution
Preconditions, fixture, and attack stimulus: Combine collection
evidence of operation A with execution evidence of B.
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: Reject mixed or cross-operation evidence.
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
Das Expires 29 April 2027 [Page 371]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
10.8. T08: Execution validator independence failure
Preconditions, fixture, and attack stimulus: Run both validators
under single compromised caller-controlled authority.
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: Treat independence predicate as
unsatisfied for profile requiring separation.
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
10.9. T09: Unbound sink redirection
Preconditions, fixture, and attack stimulus: Present scoped authority
to another sink or substitute destination.
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: Refuse sink and actual destination
mismatch.
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
10.10. T10: Source credential scope exceeds user grant
Preconditions, fixture, and attack stimulus: API token allows broad
writes; user approved only one object.
Das Expires 29 April 2027 [Page 372]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: Reject unauthorized object despite
credential validity.
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
10.11. T11: Two concurrent workers use same authority
Preconditions, fixture, and attack stimulus: Race on same single-use
reference and candidate.
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: At most one protected consumption
succeeds at controlled sink.
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
10.12. T12: Crash between local consume and external dispatch
Preconditions, fixture, and attack stimulus: Persist consumption and
kill gateway before network send.
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: No unguarded reissue; record unconfirmed/
indeterminate as appropriate.
Das Expires 29 April 2027 [Page 373]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
10.13. T13: Dispatch completes but acknowledgment lost
Preconditions, fixture, and attack stimulus: Receiving service
applies effect; response dropped.
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: Do not assume failure; reconcile using
receiver-qualified effect evidence.
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
10.14. T14: Receiver lacks duplicate suppression
Preconditions, fixture, and attack stimulus: Indeterminate remote
effect; attempt blind retry.
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: Withhold automatic duplicate; require
distinct authorized recovery path.
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
Das Expires 29 April 2027 [Page 374]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
10.15. T15: Resource alias and HTTP redirect mutation
Preconditions, fixture, and attack stimulus: Authorize one endpoint;
redirect to another actual recipient.
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: Requalify target and refuse unauthorized
rebind.
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
10.16. T16: Revocation registry unreachable
Preconditions, fixture, and attack stimulus: Finality requires online
current state and authority service unavailable.
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: Withhold effect absent separately
authorized bounded freshness rule.
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
10.17. T17: Snapshot restores consumed journal
Preconditions, fixture, and attack stimulus: Restore older storage
image after effect.
Das Expires 29 April 2027 [Page 375]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: Protected monotonic generation detects
rollback or implementation guarantee fails.
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
10.18. T18: Alternate direct egress bypass
Preconditions, fixture, and attack stimulus: Agent opens direct
socket or privileged connector around gateway.
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: Demonstrate effect remains blocked or
document uncovered interface as limitation.
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
10.19. T19: High-volume malicious evidence workload
Preconditions, fixture, and attack stimulus: Submit malformed nested
objects, invalid signatures and stale nonces at scale.
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: Bound validation cost, reject malformed
input; no fail-open under load.
Das Expires 29 April 2027 [Page 376]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
10.20. T20: Cross-platform end-to-end audit reproducibility
Preconditions, fixture, and attack stimulus: iOS-originated candidate
validated by protected service; Android/cloud receiving sink.
Procedure: prepare the documented source grant and Candidate Act;
capture protected collection and execution evidence; present or
mutate the described operation at the effect-capable sink; obtain
journal and receiving-resource records. Run one baseline and one
adversarial variant where meaningful.
Expected observable result: Verify exact effect, independent
evidence, single-use journal and source trace reproducibly.
Evidence requirements: record source-grant version, test fixture,
candidate/effect descriptor commitment, validator identity, evidence
cross-commitment, sink-local state transition, actual resource state
and outcome classification. Proposed only; no measured result
claimed.
11. Detailed Industry and Product Alignment: Security Problems,
Integration Paths and Deployment Boundaries
Commercial names identify deployment environments or publicly
documented security mechanisms for technical comparison, not evidence
that any vendor has copied, adopted or implemented the proposed
system. A platform-specific implementation must be independently
assessed against its documented public interfaces and trust limits.
The portable source concept is the enforcement relationship between
effect authorization, qualified evidence and actual sink-side
control, not ownership of any vendor API. Apple, Siri, iOS, iPadOS,
macOS, Android, Gemini, Bixby, Copilot, Alexa, and other names used
in this document are trademarks of their respective owners.
11.1. Apple iOS, iPadOS, macOS, Apple Intelligence, Siri and App
Intents
Relevant security and interoperability problem: Third-party AI
commands can originate in app actions and flow through extensions,
remote services or companion applications. Mobile app permissions,
account login, and Keychain possession do not by themselves bind all
material fields of the actual eventual cloud or physical consequence.
Das Expires 29 April 2027 [Page 377]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Technically plausible relationship and deployment boundary: Integrate
app-controlled request preparation, authenticated consent/source-
grant evidence and independent gateway-side verification; actual
enforcement depends on receiving resource or permitted privileged
interface. Do not claim ordinary third-party iOS apps can impose a
systemwide mandatory gate.
11.2. Google Android, Gemini, Intents, Binder IPC and Android Keystore
Relevant security and interoperability problem: Exported components,
app-to-app requests, OAuth sessions, privileged services and model-
generated tool calls may differ in origin identity, user-approved
scope and actual resource semantics.
Technically plausible relationship and deployment boundary: Bind
caller/source evidence with Android permission and Keystore security
evidence where appropriate, then enforce exact effect at server or
authorized receiving component; Binder success/permission grant alone
does not imply finality.
11.3. Microsoft Windows, Azure and Agent Execution Containers
Relevant security and interoperability problem: AI and enterprise
automation may act using strong OS or workload isolation yet still be
able to invoke an effect beyond the current user or administrator
task grant.
Technically plausible relationship and deployment boundary: Use
sandbox isolation as one supporting boundary; validate bounded source
grant and qualified operation-specific evidence at independent
resource gateways or OS-enforced sinks.
11.4. OpenAI Responses API, Agents SDK, Codex and Computer-Use
Workloads
Relevant security and interoperability problem: Agent models can
issue API calls and GUI actions from untrusted content, potentially
performing credentialed external effects after apparently successful
tool authorization.
Technically plausible relationship and deployment boundary: Treat
outputs as candidate operations; create independently validated
effect records and controlled tool/resource finality, without
asserting product-specific conformance.
Das Expires 29 April 2027 [Page 378]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
11.5. Anthropic Claude, Claude Code and Managed Agents
Relevant security and interoperability problem: Tool sandboxing, user
approval and external connectors may have different scopes and
execution rights. Prompt injection or stale approvals can influence
consequential requests.
Technically plausible relationship and deployment boundary: Deploy
protected source-to-effect authorization at actual request boundaries
and distinguish protected credential possession from operation-
specific permission.
11.6. Google Cloud and Enterprise Agent Services
Relevant security and interoperability problem: Delegated cloud
identities and platform IAM roles may technically permit a resource
change exceeding the original bounded task or current resource
version.
Technically plausible relationship and deployment boundary: Combine
workload identity and IAM evidence with independent actual-request
semantics, current grant/revocation state and sink-local idempotent
authorization consumption.
11.7. Meta Agent Runtimes, Muse/Sentinel and Brokered Credentials
Relevant security and interoperability problem: Network egress
restrictions, credential surrogates and permission mediators address
important controls, while the exact operation/sink evidence model is
a distinct technical comparison.
Technically plausible relationship and deployment boundary: Compare
independently protected source evidence, operation-specific
enablement and separately verified receiving-resource effect; do not
claim specific published products already implement all these
mechanisms.
11.8. NVIDIA OpenShell/Sentry, GPUs, DPUs and Hardware Gateways
Relevant security and interoperability problem: Agent isolation and
protected hardware enforcement can be relevant when GPU, network or
device commands cause externally meaningful effects.
Technically plausible relationship and deployment boundary: Hardware
gates may enforce exact effect descriptors under protected state if
they control the true effectuation interface; device-level monitoring
alone does not establish original user authority.
Das Expires 29 April 2027 [Page 379]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
11.9. Qualcomm Snapdragon, Mobile SoCs and Trusted Security Hardware
Relevant security and interoperability problem: Mobile trusted
execution and hardware-backed key use can protect cryptographic
evidence but cannot independently authorize every possible data
release or privileged resource act.
Technically plausible relationship and deployment boundary: Use
protected hardware for key custody, attestation or journal state
where available; require separate operation-specific source/effect
validation.
11.10. Huawei Mobile, Cloud and Telecommunications Devices
Relevant security and interoperability problem: Heterogeneous mobile
security substrates and equipment controllers expose different
protected APIs and permission models across domains.
Technically plausible relationship and deployment boundary: Use
vendor-neutral effect descriptors, qualified security evidence
adapters and receiving sink enforcement without depending on a
proprietary interface.
11.11. Arm Security Architecture and Trusted Execution Environments
Relevant security and interoperability problem: Isolated secure
worlds or trusted subsystems can host protected evidence, key custody
and monotonic state under explicit threat assumptions.
Technically plausible relationship and deployment boundary:
Qualification must identify actual trust boundaries and enforcement
reach; attestation of a component does not establish the current
correctness of a particular external action.
11.12. Financial Systems, Payments, API Banking and Digital Signatures
Relevant security and interoperability problem: Payment credential
validity, authenticated payment instructions and actual settlement
outcomes are separate facts. Replay or recipient substitution can
cause irreversible transfers.
Technically plausible relationship and deployment boundary: Bind
resource/recipient/amount/approval to protected evidence and
receiving-side finality; distinguish authorization from confirmed
payment effect and recovery after ambiguous outcomes.
Das Expires 29 April 2027 [Page 380]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
11.13. Cloud APIs, Enterprise SaaS, Kubernetes and Service Mesh
Relevant security and interoperability problem: Service accounts, API
gateways, controllers and long-running distributed transactions
create stale permissions, aliases, policy evolution and multi-service
effects.
Technically plausible relationship and deployment boundary: Deploy
operation-scoped source-authority checks, guarded gateways,
transactional protected journals and independent receiving-resource
verification.
11.14. Telecommunications, 5G/6G, IoT and Edge Devices
Relevant security and interoperability problem: Network policy
updates, key activation, subscriber changes and remotely triggered
hardware commands may cross administrative domains with intermittent
links.
Technically plausible relationship and deployment boundary: Adapt
protected evidence and constrained authorization to actual managed-
resource sinks; reject where current mandatory authority cannot be
established.
11.15. Robotics, Industrial Controllers and Critical Infrastructure
Relevant security and interoperability problem: Remote agent actions
may create physical effects that cannot be reversed by rolling back a
database or authorization log.
Technically plausible relationship and deployment boundary: Require
qualified safety interlocks, effect-capable actuator sinks, strict
temporal freshness and separate authorization for corrective actions.
11.16. Patent Examiners and Prior-Art Technical Researchers
Relevant security and interoperability problem: Short conceptual
descriptions can obscure exact chronological source support, variant
disclosures, and distinctions between known authentication techniques
and actual effect finality.
Technically plausible relationship and deployment boundary: Provide
original global page index, verbatim technical disclosures, stable
document identifiers, exact Zenodo DOI, original PCT identifiers and
clearly labeled new examples; do not conflate publication date with
patent priority.
Das Expires 29 April 2027 [Page 381]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
11.17. Voice and System Assistants: Samsung Bixby, Microsoft Copilot,
Amazon Alexa, and Assistant-Initiated Actions
Relevant security and interoperability problem: system and voice
assistants, including Apple Siri, Google Gemini, Samsung Bixby,
Microsoft Copilot, and Amazon Alexa, convert a spoken or typed
request into actions in third-party apps and services using the
user's existing sessions and credentials. The assistant's request
typically arrives with valid authentication, so the receiving service
sees a credential, not evidence that the user authorized this
recipient, amount, file, or command; injected content read by the
assistant can steer the action while the credential stays valid.
Technically plausible relationship and deployment boundary: bind the
originating user request, the invoking assistant, the target app, and
the material parameters into protected collection-time evidence;
validate independently at execution time; and require the receiving
app or backend, acting as Finality Sink, to consume operation-scoped,
non-bearer enablement once. Third-party implementers can enforce
only at interfaces they control, such as their own action handlers
and server APIs; private assistant or operating-system internals are
not assumed to be available.
12. Detailed Relevance to IETF Working Groups, RFCs and Security-
Protocol Interoperability
This section is an explicit engineer-oriented standards crosswalk,
not a representation of working-group sponsorship or charter
adoption. Existing RFCs can supply individual authorization, sender
authentication, structured request, workload identity, attestation,
cryptographic evidence or resource-version properties; the specific
operation-to-evidence-to-actual-consequence relationship described in
this disclosure remains a separate implementation claim that requires
its own security analysis.
12.1. OAuth WG: Fine-Grained Authorization and Sender-Constrained
Credentials
Primary references: [OAUTH-WG], [RFC6749], [RAR], [DPOP].
Established work and precise contribution: RFC 9396 Rich
Authorization Requests supplies structured authorization_details.
RFC 9449 DPoP sender-constrains OAuth tokens; RFC 6749, RFC 8693 and
revocation/transaction profiles may provide related identity and
delegation mechanics.
Das Expires 29 April 2027 [Page 382]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Potential interoperability mapping, additional check, and boundaries:
Map authenticated grant scope to protected Candidate Act effect
scope. DPoP proof-of-possession does not alone bind every materially
authorized resource field or establish a sink-consumed single-use
effect. Verify token audience, method, target, revocation and
independent sink control.
Working group or activity reference:
https://datatracker.ietf.org/wg/oauth/about/.
12.2. WIMSE WG: Workload Identity Across Multi-System Trust Boundaries
Primary references: [WIMSE].
Established work and precise contribution: The WIMSE charter concerns
runtime workload identities, tokens, cross-boundary identities and
securing service-to-service HTTP/REST chains including transaction/
context associations.
Potential interoperability mapping, additional check, and boundaries:
Supply workload identity and caller-chain evidence as input to source
authority and validation. A caller-bound or transaction-related
workload token does not automatically demonstrate the exact final
effect or replace protected local resource-side consumption.
Working group or activity reference:
https://datatracker.ietf.org/wg/wimse/about/.
12.3. RATS WG: Trusted Attestation and Evidence Appraisal
Primary references: [RATS].
Established work and precise contribution: RFC 9334 describes
attesters, verifiers, relying parties, Evidence and Attestation
Results for platform properties and trustworthiness under a defined
appraisal model.
Potential interoperability mapping, additional check, and boundaries:
Attestation can qualify a collection component, secure hardware or
sink code integrity. Separate the predicate "this code ran on an
attested device" from "this specific payment, file transfer or
network action remains authorized at effectuation."
Working group or activity reference:
https://datatracker.ietf.org/wg/rats/about/.
Das Expires 29 April 2027 [Page 383]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
12.4. COSE, CBOR, Cryptographic Message Evidence
Primary references: [COSE], [CBOR].
Established work and precise contribution: RFC 9052 specifies
protected COSE message structures and RFC 8949 CBOR data
representation. Authenticated evidence can use protected objects
with exact encoding and algorithm profiles.
Potential interoperability mapping, additional check, and boundaries:
Use signed/MACed collection-time and execution-time records and
explicit cross-commitment schemas. Avoid signature-only conclusions:
verifier trust, semantic canonicalization, freshness, actual
operation equality and consume-on-use state remain independent
checks.
Working group or activity reference:
https://datatracker.ietf.org/wg/cose/about/.
12.5. ACE WG: Constrained Authorization for Embedded and Mobile Effects
Primary references: [ACE].
Established work and precise contribution: RFC 9200 and constrained
authorization profiles permit access-token protection for constrained
endpoints and resource servers, with endpoint-specific constraints.
Potential interoperability mapping, additional check, and boundaries:
Map constrained access permission to scoped effect authority; ensure
a constrained receiving actuator or data resource actually enforces
current operation fields and state. Offline revocation assumptions
require bounded explicit authority.
Working group or activity reference:
https://datatracker.ietf.org/wg/ace/about/.
12.6. SCITT WG: Signed Statements and Transparency
Primary references: [SCITT].
Established work and precise contribution: SCITT work addresses
transparency and accountability of signed statements in software
supply-chain and related contexts.
Das Expires 29 April 2027 [Page 384]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Potential interoperability mapping, additional check, and boundaries:
Signed evidence provenance or software-state records may be
supporting attestable facts. A transparency registration receipt is
not identical to a verified physical/remote effect receipt, current
originating permission or non-bearer finality consumption.
Working group or activity reference:
https://datatracker.ietf.org/wg/scitt/about/.
12.7. HTTPBIS and HTTP Semantics: Conditional Effects and Redirects
Primary references: [HTTP].
Established work and precise contribution: RFC 9110 defines resource
semantics, methods, conditional requests, validators and redirection.
HTTP 412/ETag and request-target details may help guard concurrent
versions.
Potential interoperability mapping, additional check, and boundaries:
Treat actual final effective target, method, body commitment and
version predicates as effect descriptors. Conditional request or
valid HTTP response alone does not necessarily establish original
task permission or exactly-once external consequence.
Working group or activity reference:
https://datatracker.ietf.org/wg/httpbis/about/.
12.8. SEC-DISPATCH, Security Area and Cross-WG Review
Established work and precise contribution: Security-area coordination
may be appropriate for a technical contribution spanning OAuth
permission, workload identity, protected evidence, remote attestation
and resource-side consequence enforcement.
Potential interoperability mapping, additional check, and boundaries:
Submit concrete problem statements, message schemas and non-goals for
review without asserting an assigned WG or that a charter presently
covers all proposed effect-finality semantics. BCP 79 IPR
obligations must be satisfied separately.
Working group or activity reference:
https://datatracker.ietf.org/wg/secdispatch/about/.
Das Expires 29 April 2027 [Page 385]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
13. 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.
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
Das Expires 29 April 2027 [Page 386]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
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.
14. Security, Privacy, Availability, Operational and IANA
Considerations
14.1. Independence and Collusion
Threat model must identify who controls the collection PED, execution
validator, authorization key service, and resource sink. Separate
names do not prove security if all protected secrets and state are
writable by the compromised agent.
14.2. Proof of Authority vs Proof of Effect
Authentication or cryptographic approval is not proof of actual
effect. An effect receipt or local journal status must not be
misrepresented as settlement or external resource confirmation
without receiver-qualified evidence.
14.3. Nonce, Epoch, Replay and Storage Rollback
Protect uniqueness, sink-local state, current revocation and journal
monotonicity against replay, crash, cloned workloads and snapshot
rollback. Specify durable failure assumptions.
14.4. Canonicalization and Type Confusion
Define versioned exact operation descriptors, Unicode/resource
identity normalization, valid method/recipient bindings, array
ordering and parser limits. Ambiguous comparisons must not silently
broaden authority.
14.5. Sensitive Evidence and Privacy
Evidence logs may expose user identities, targets, content digests,
recipients and internal infrastructure. Implement least-privilege
observation, redaction, encryption, retention limits and independent
audit access.
Das Expires 29 April 2027 [Page 387]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
14.6. Availability and Verification Exhaustion
Verification can fail under outage, DoS, clock uncertainty or missing
attestation. Fail-closed for mandatory consequential checks, and
document approved bounded degraded modes separately rather than
bypassing required validation.
14.7. Remote Outcome and Crash Semantics
A local durable state transition cannot make a remote payment or
physical operation atomic. Idempotency/receiver cooperation and
qualified outcome reconciliation are needed for stronger duplicate-
effect claims.
14.8. Publication and IANA Status
This individually proposed informational document currently requests
no IANA registries, media types or protocol code points. Any later
normative wire profile must specify registration/format and full
interoperability tests separately.
15. Patent Examiner and Industry Discovery Cross-Index: Original Page
and Figure Locations
Original Invention: Cross-Platform Authorization and Effect
Semantics: original source global pages 1–14; Part 3 technical
section scope-original; page-indexed text in scope-original-source-
detail; architecture figure fig-scope-original-architecture;
operational flowchart fig-scope-original-flowchart.
CW-1: Common Protected Execution-Finality Workflow — Evidence and
Authority Foundations: original source global pages 15–62; Part 3
technical section cw1-evidence; page-indexed text in cw1-evidence-
source-detail; architecture figure fig-cw1-evidence-architecture;
operational flowchart fig-cw1-evidence-flowchart.
CW-2: Validator-Qualified Effect Receipt — Evidence Dependency
Context: original source global pages 63–79; Part 3 technical section
cw2-evidence; page-indexed text in cw2-evidence-source-detail;
architecture figure fig-cw2-evidence-architecture; operational
flowchart fig-cw2-evidence-flowchart.
Embodiment 15: Cross-Domain Evidence Commitment, Independent
Validation and Non-Bearer Finality: original source global pages
1309–1384; Part 3 technical section emb15-evidence; page-indexed text
in emb15-evidence-source-detail; architecture figure fig-emb15-
evidence-architecture; operational flowchart fig-emb15-evidence-
flowchart.
Das Expires 29 April 2027 [Page 388]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Embodiment 16: Crash-Consistent Finality Journaling and Indeterminate
Outcome Reconciliation: original source global pages 1385–1465; Part
3 technical section emb16-journal; page-indexed text in emb16-
journal-source-detail; architecture figure fig-emb16-journal-
architecture; operational flowchart fig-emb16-journal-flowchart.
Miscellaneous Embodiment M-2: Existing Authorization Standards as
Qualified Inputs, Not Finality: original source global pages
1898–1952; Part 3 technical section misc-m2-evidence; page-indexed
text in misc-m2-evidence-source-detail; architecture figure fig-misc-
m2-evidence-architecture; operational flowchart fig-misc-m2-evidence-
flowchart.
For patent examination, compare exact technical elements with their
original publication date and original filing record. This digest
and newly illustrated implementation material cannot retroactively
change the content or earliest supported priority of any different
PCT/Indian filing. The full source is Zenodo record 23657985, DOI
10.5281/zenodo.23657985.
16. Cross-References to the Foundation and Companion Internet-Drafts
The following explicit in-text xrefs will resolve to planned
bibliography anchors. As of document preparation, future companion
Datatracker URLs are indicative and must not be represented as active
merely because the name is written into an Internet-Draft source
file.
Part 1 companion: [DAS-FOUNDATION]
Part 2 companion: [DAS-INTEROP]
Part 4 companion: [DAS-SINK]
Part 5 companion: [DAS-MULTIAGENT]
Part 6 companion: [DAS-RECEIPTS]
Part 7 companion: [DAS-TOOLS]
Part 8 companion: [DAS-RECOVERY]
Part 9 companion: [DAS-PRIVACY]
Part 10 companion: [DAS-MIGRATION]
Part 11 companion: [DAS-HARDWARE]
Das Expires 29 April 2027 [Page 389]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Part 12 companion: [DAS-INFRA]
17. Public Sources and Planned Companion References
[DAS-FOUNDATION]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 1: Foundational
Consequential Authority and Common Workflows", Work in
Progress, Internet-Draft, draft-das-interoperable-
consequence-authority-00,
<https://datatracker.ietf.org/doc/draft-das-interoperable-
consequence-authority/>.
[DAS-INTEROP]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 2: Secure iOS and
Android AI Tool Interoperability", Work in Progress,
Internet-Draft, draft-das-cross-platform-ai-
interoperability-00, <https://datatracker.ietf.org/doc/
draft-das-cross-platform-ai-interoperability/>.
[DAS-SINK] Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series — Part 4 of 12: Actual-
Operation Reconstruction, Sink-Local State and Non-
Bypassable Effectuation", Work in Progress, Internet-
Draft, draft-das-finality-sink-enforcement-00,
<https://datatracker.ietf.org/doc/draft-das-finality-sink-
enforcement/>.
[DAS-MULTIAGENT]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series — Part 5 of 12: Multi-Agent
Delegation, Conflict Arbitration and Authority Lineage",
Work in Progress, Internet-Draft, draft-das-multi-agent-
authority-control-00, <https://datatracker.ietf.org/doc/
draft-das-multi-agent-authority-control/>.
[DAS-RECEIPTS]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series — Part 6 of 12: Qualified
Actual-Effect Receipts and Causal Phase Continuation",
Work in Progress, Internet-Draft, draft-das-causal-effect-
receipts-00, <https://datatracker.ietf.org/doc/draft-das-
causal-effect-receipts/>.
Das Expires 29 April 2027 [Page 390]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
[DAS-TOOLS]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series — Part 7 of 12: Tool
Semantics, Resource Identity, Model Provenance and Runtime
Integrity", Work in Progress, Internet-Draft, draft-das-
agent-tool-integrity-00,
<https://datatracker.ietf.org/doc/draft-das-agent-tool-
integrity/>.
[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
Outcome Verification, Crash Recovery and Multi-Resource
Effects", Work in Progress, Internet-Draft, draft-das-
distributed-effect-recovery-00,
<https://datatracker.ietf.org/doc/draft-das-distributed-
effect-recovery/>.
[DAS-PRIVACY]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series — Part 9 of 12: Credential
Brokerage, Non-Exportable Secret Exercise and Privacy
Releases", Work in Progress, Internet-Draft, draft-das-
agent-credential-privacy-00,
<https://datatracker.ietf.org/doc/draft-das-agent-
credential-privacy/>.
[DAS-MIGRATION]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series — Part 10 of 12: Device
Migration, Revocation, Fences, Ownership Generations and
Offline Effects", Work in Progress, Internet-Draft, draft-
das-cross-device-authority-revocation-00,
<https://datatracker.ietf.org/doc/draft-das-cross-device-
authority-revocation/>.
Das Expires 29 April 2027 [Page 391]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
[DAS-HARDWARE]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series — Part 11 of 12: Kernel,
Sandbox, DPU, Accelerator and Hardware-Bound Effect
Control", Work in Progress, Internet-Draft, draft-das-
hardware-execution-finality-00,
<https://datatracker.ietf.org/doc/draft-das-hardware-
execution-finality/>.
[DAS-INFRA]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series — Part 12 of 12:
Enterprise, Cloud, Telecom and Critical-Infrastructure
Consequence Governance", Work in Progress, Internet-Draft,
draft-das-autonomous-infrastructure-finality-00,
<https://datatracker.ietf.org/doc/draft-das-autonomous-
infrastructure-finality/>.
[ZENODO] Das, S., "iOS and Android Interoperability for Secure
Third Party AI Tools - Cross-Platform Execution Finality,
Hardware Security, and Interoperability (3,567-Page
Specification)", DOI 10.5281/zenodo.23657985, October
2026, <https://zenodo.org/records/23657985>.
[PCT-DAS] Das, S., "Published international application WO
2026/150382 (PCT/IB2026/055615)", 2026,
<https://patentscope.wipo.int/search/en/WO2026150382>.
[BCP79] Bradner, S. and J. Contreras, "Intellectual Property
Rights in IETF Technology", RFC 8179, BCP 79,
DOI 10.17487/RFC8179, May 2017,
<https://www.rfc-editor.org/info/rfc8179>.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RAR] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/info/rfc9396>.
[DPOP] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/info/rfc9449>.
Das Expires 29 April 2027 [Page 392]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
[RATS] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
[COSE] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", RFC 9052, DOI 10.17487/RFC9052,
August 2022, <https://www.rfc-editor.org/info/rfc9052>.
[CBOR] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 8949, STD 94,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[ACE] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/info/rfc9200>.
[HTTP] Fielding, R., Nottingham, M., and J. Reschke, "HTTP
Semantics", RFC 9110, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[WIMSE] Internet Engineering Task Force, "Workload Identity in
Multi System Environments (wimse) Working Group",
<https://datatracker.ietf.org/wg/wimse/about/>.
[SCITT] Internet Engineering Task Force, "Supply Chain Integrity,
Transparency, and Trust (scitt) Working Group",
<https://datatracker.ietf.org/wg/scitt/about/>.
[OAUTH-WG] Internet Engineering Task Force, "Web Authorization
Protocol (oauth) Working Group",
<https://datatracker.ietf.org/wg/oauth/about/>.
[EU-AI-ACT]
European Parliament and Council of the European Union,
"Regulation (EU) 2024/1689 of the European Parliament and
of the Council laying down harmonised rules on artificial
intelligence (Artificial Intelligence Act)", 13 June 2024,
<https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.
Author's Address
Das Expires 29 April 2027 [Page 393]
Internet-Draft Execution-Finality Part 3: Evidence October 2026
Sangam Kumar Das
Independent Researcher
Balasore
Odisha
India
Email: info@sangamdas.com
Das Expires 29 April 2027 [Page 394]