Secure AI Execution-Finality for iOS, Android, and Cross-Platform AI Agents, Part 7: AI Tool Integrity, Semantic Target Correspondence, and Execution-Time Resource Identity
draft-das-agent-tool-integrity-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-agent-tool-integrity-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 7: AI Tool Integrity, Semantic Target Correspondence, and
Execution-Time Resource Identity
draft-das-agent-tool-integrity-00
Abstract
An AI agent can call the right tool with valid credentials and still
act on the wrong thing. When a user tells Apple Siri or Google
Gemini to "send this to her", asks a coding agent to deploy, or lets
a browser agent complete a form, the agent must resolve which file,
contact, account, tenant, or device is meant, and which tool, tool
version, and model will act. On iOS, iPadOS, macOS, Android,
Windows, Linux, enterprise SaaS, cloud platforms, and connected
hardware, agents can select the wrong user-referenced object, follow
instructions injected into web pages, repositories, or tool outputs,
call a tool whose description or capabilities silently changed, run
on a swapped model or configuration, or send authorized-looking
requests to redirected hosts, rebound aliases, and substituted
tenants. Identity authentication, sandboxing, and transport
encryption can all succeed while files, credentials, payments,
developer infrastructure, and physical devices are exposed.
This document, Part 7 of a twelve-part series, specifies execution-
time integrity for AI tools. It describes protected correspondence
between what the user saw and referred to and the object actually
acted on; canonical tool-effect contracts with semantic-compatibility
checks across tool versions; algorithm, model, and configuration
baseline continuity; instruction provenance with evaluation of lower-
trust influence on downstream actions; authenticated resolution of
resource aliases, hosts, and tenants, including redirects and DNS
rebinding; fencing of tool installation, activation, runtime upgrade,
and rollback; detection of dynamic service and capability
substitution; and reconstruction of the actual operation at an
independent Finality Sink. Reference algorithms, twelve threat
models, and thirty reproducible tests, including iOS App Intents and
Android cooperating-app cases, are included. Part 1 of the series
defines the shared terminology and common workflows.
The document relates these mechanisms to OAuth 2.0 authorization,
Rich Authorization Requests, Resource Indicators, Token Exchange, and
Demonstrating Proof of Possession (DPoP); Workload Identity in Multi-
Das Expires 29 April 2027 [Page 1]
Internet-Draft Execution-Finality Part 7: Tools October 2026
System Environments (WIMSE); Remote ATtestation procedureS (RATS);
CBOR Object Signing and Encryption (COSE); Supply Chain Integrity,
Transparency, and Trust (SCITT); Software Updates for Internet of
Things (SUIT) manifests; Trusted Execution Environment Provisioning
(TEEP); Authentication and Authorization for Constrained Environments
(ACE); and HTTP redirect and conditional-request semantics. None of
these alone is treated as conferring final authority for a
consequential effect, and no working-group adoption or IETF consensus
is claimed.
Industry alignment covers Apple iOS, iPadOS, and macOS with Siri,
Shortcuts, App Intents, and Keychain; Google Android with Gemini,
intents, Binder, and Keystore; Samsung Bixby, Microsoft Copilot, and
Amazon Alexa; Microsoft Windows and Azure; coding and computer-use
agents from OpenAI, Anthropic, Google, and Meta; Model Context
Protocol servers, agent-to-agent protocols, and tool and plugin
registries; browser agents; NVIDIA, Qualcomm, Arm, and Huawei
hardware; banking, payments, and agentic commerce; email and
messaging agents; healthcare record agents; document signing; cloud
infrastructure-as-code; model hosting and model routing; smart homes
using Matter; automotive assistants and over-the-air updates;
government digital identity, including the EU Digital Identity
Wallet; telecommunications; industrial IoT and robotics; and software
supply chains and CI/CD. For each, the document states the technical
effect: the consequential operation reaches the Finality Sink only if
the actual target, tool contract, model baseline, and instruction
lineage match what was authorized. Product names are illustrative
and imply no endorsement or implementation by any vendor. For the EU
Artificial Intelligence Act (Regulation (EU) 2024/1689), execution-
time integrity of tools, models, and targets can help providers and
deployers address accuracy, robustness, and cybersecurity, record-
keeping, and risk-management requirements where those obligations
apply; this is a technical mapping, not a conformity claim or legal
advice.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Das Expires 29 April 2027 [Page 2]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction: Practical Agent-Tool Security Problem and Purpose
of Part 7 . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1. Twelve-Part Series Directory, Distinct Subjects and Planned
URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1.1. Part 1 of 12 — Foundational Protected Consequence
Authority, Shared Definitions and Common Workflows
CW-1/CW-2/CW-3 . . . . . . . . . . . . . . . . . . . 10
1.1.2. Part 2 of 12 — Secure iOS, Android and Cross-Platform
AI-Tool Interoperability . . . . . . . . . . . . . . 11
1.1.3. Part 3 of 12 — Protected Authorization, Validation
Evidence and Scoped Finality Capabilities . . . . . . 11
1.1.4. Part 4 of 12 — Finality Sink Reconstruction, Protected
Consumption and Anti-Bypass Security . . . . . . . . 11
1.1.5. Part 5 of 12 — Multi-Agent Authority, Delegation,
Conflicts and Quorum Enforcement . . . . . . . . . . 11
1.1.6. Part 6 of 12 — Authenticated Actual-Effect Receipts and
Causal Phase Continuation . . . . . . . . . . . . . . 12
1.1.7. Part 7 of 12 — AI Tool Security, Semantic Target
Correspondence and Execution-Time Integrity . . . . . 12
1.1.8. Part 8 of 12 — Remote Effect Evidence, Distributed
Transactions and Recovery . . . . . . . . . . . . . . 12
1.1.9. Part 9 of 12 — Credential Custody, Protected Disclosure
and API Security . . . . . . . . . . . . . . . . . . 12
1.1.10. Part 10 of 12 — Cross-Device Migration, Source
Revocation and Offline Fencing . . . . . . . . . . . 13
1.1.11. Part 11 of 12 — Kernel, Sandbox and Hardware
Execution-Finality Enforcement . . . . . . . . . . . 13
Das Expires 29 April 2027 [Page 3]
Internet-Draft Execution-Finality Part 7: Tools October 2026
1.1.12. Part 12 of 12 — Resource Governance, Cloud, Telecom and
Critical Infrastructure Security . . . . . . . . . . 13
2. Public Source, Principal Patent-Pending Disclosure, IETF IPR
and Forthcoming GitHub Implementation . . . . . . . . . . 13
3. Keywords and Searchable Industry-Security Terminology . . . . 14
4. Terminology, Threat Boundary and Tool-Integrity Security
Invariants . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Candidate Act (CA) . . . . . . . . . . . . . . . . . . . 15
4.2. Non-Effective State (NES) . . . . . . . . . . . . . . . . 15
4.3. Protected Enforcement Domain (PED) . . . . . . . . . . . 15
4.4. Finality Sink (FS) . . . . . . . . . . . . . . . . . . . 15
4.5. Presentation Evidence . . . . . . . . . . . . . . . . . . 15
4.6. User-Referenced Object . . . . . . . . . . . . . . . . . 15
4.7. Semantic Binding Commitment . . . . . . . . . . . . . . . 16
4.8. Tool Effect Contract . . . . . . . . . . . . . . . . . . 16
4.9. Tool Contract Version . . . . . . . . . . . . . . . . . . 16
4.10. Approved Execution Baseline . . . . . . . . . . . . . . . 16
4.11. Runtime Generation . . . . . . . . . . . . . . . . . . . 16
4.12. Instruction Provenance . . . . . . . . . . . . . . . . . 16
4.13. Influence or Attribution Evidence . . . . . . . . . . . . 16
4.14. Resource Identity . . . . . . . . . . . . . . . . . . . . 16
4.15. Alias Resolution Evidence . . . . . . . . . . . . . . . . 17
4.16. Resource Binding Generation . . . . . . . . . . . . . . . 17
4.17. Capability or Service Substitution . . . . . . . . . . . 17
4.18. Scoped Non-Bearer Finality . . . . . . . . . . . . . . . 17
4.19. Independent Actual-Operation Reconstruction . . . . . . . 17
4.20. Covered Effectuation Path . . . . . . . . . . . . . . . . 17
4.21. Security Invariants and Mandatory Conditional
Distinctions . . . . . . . . . . . . . . . . . . . . . . 17
4.21.1. Invariant 1 . . . . . . . . . . . . . . . . . . . . 17
4.21.2. Invariant 2 . . . . . . . . . . . . . . . . . . . . 18
4.21.3. Invariant 3 . . . . . . . . . . . . . . . . . . . . 18
4.21.4. Invariant 4 . . . . . . . . . . . . . . . . . . . . 18
4.21.5. Invariant 5 . . . . . . . . . . . . . . . . . . . . 18
4.21.6. Invariant 6 . . . . . . . . . . . . . . . . . . . . 18
4.21.7. Invariant 7 . . . . . . . . . . . . . . . . . . . . 18
4.21.8. Invariant 8 . . . . . . . . . . . . . . . . . . . . 18
4.21.9. Invariant 9 . . . . . . . . . . . . . . . . . . . . 18
4.21.10. Invariant 10 . . . . . . . . . . . . . . . . . . . . 19
4.21.11. Invariant 11 . . . . . . . . . . . . . . . . . . . . 19
4.21.12. Invariant 12 . . . . . . . . . . . . . . . . . . . . 19
5. Original Page-Indexed Technical Disclosures: Embodiments 3, 6,
10, 21, 24, 26 and 34 . . . . . . . . . . . . . . . . . . 19
5.1. Embodiment 3 — User-Referenced Object, Presentation
Evidence and Actual Consequential Target . . . . . . . . 19
5.1.1. Embodiment-Specific Architecture and Trust
Relationship . . . . . . . . . . . . . . . . . . . . 19
5.1.2. Operational Security Decision Flowchart . . . . . . . 20
Das Expires 29 April 2027 [Page 4]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.1.3. Original Technical Disclosure with Global-Page
Anchors . . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Embodiment 6 — Tool-Effect Contract Integrity and Semantic
Compatibility Across Updates . . . . . . . . . . . . . . 92
5.2.1. Embodiment-Specific Architecture and Trust
Relationship . . . . . . . . . . . . . . . . . . . . 92
5.2.2. Operational Security Decision Flowchart . . . . . . . 92
5.2.3. Original Technical Disclosure with Global-Page
Anchors . . . . . . . . . . . . . . . . . . . . . . . 93
5.3. Embodiment 10 — Algorithm, Model and Configuration Baseline
Continuity . . . . . . . . . . . . . . . . . . . . . . . 162
5.3.1. Embodiment-Specific Architecture and Trust
Relationship . . . . . . . . . . . . . . . . . . . . 162
5.3.2. Operational Security Decision Flowchart . . . . . . . 163
5.3.3. Original Technical Disclosure with Global-Page
Anchors . . . . . . . . . . . . . . . . . . . . . . . 163
5.4. Embodiment 21 — Authenticated Resource Alias and Actual
Resource Identity Resolution . . . . . . . . . . . . . . 237
5.4.1. Embodiment-Specific Architecture and Trust
Relationship . . . . . . . . . . . . . . . . . . . . 237
5.4.2. Operational Security Decision Flowchart . . . . . . . 237
5.4.3. Original Technical Disclosure with Global-Page
Anchors . . . . . . . . . . . . . . . . . . . . . . . 238
5.5. Embodiment 24 — Instruction Provenance, Lower-Trust
Influence and Protected Downstream Tool Authorization . . 325
5.5.1. Embodiment-Specific Architecture and Trust
Relationship . . . . . . . . . . . . . . . . . . . . 325
5.5.2. Operational Security Decision Flowchart . . . . . . . 326
5.5.3. Original Technical Disclosure with Global-Page
Anchors . . . . . . . . . . . . . . . . . . . . . . . 326
5.6. Embodiment 26 — Tool Installation, Activation, Runtime
Upgrade and Rollback Fencing . . . . . . . . . . . . . . 403
5.6.1. Embodiment-Specific Architecture and Trust
Relationship . . . . . . . . . . . . . . . . . . . . 403
5.6.2. Operational Security Decision Flowchart . . . . . . . 403
5.6.3. Original Technical Disclosure with Global-Page
Anchors . . . . . . . . . . . . . . . . . . . . . . . 404
5.7. Embodiment 34 — Dynamic Tool/Service Identity, Capability
Substitution and Alias-Rebinding Resistance . . . . . . . 485
5.7.1. Embodiment-Specific Architecture and Trust
Relationship . . . . . . . . . . . . . . . . . . . . 485
5.7.2. Operational Security Decision Flowchart . . . . . . . 485
5.7.3. Original Technical Disclosure with Global-Page
Anchors . . . . . . . . . . . . . . . . . . . . . . . 486
6. PHOSITA Implementation Using Existing Industry Technologies and
Platform Security Interfaces . . . . . . . . . . . . . . 582
6.1. Minimal cooperating resource reference build . . . . . . 583
6.2. Application operation and identity normalization . . . . 583
Das Expires 29 April 2027 [Page 5]
Internet-Draft Execution-Finality Part 7: Tools October 2026
6.3. Qualified UI reference evidence . . . . . . . . . . . . . 583
6.4. Apple iOS, iPadOS and macOS application integration . . . 583
6.5. Android intents, Binder identity and credential
support . . . . . . . . . . . . . . . . . . . . . . . . 583
6.6. Tool contract registry and effect version . . . . . . . . 584
6.7. Independent tool-change qualification . . . . . . . . . . 584
6.8. Model and runtime baseline control . . . . . . . . . . . 584
6.9. Instruction provenance and influence input . . . . . . . 584
6.10. Resource alias and receiving-tenant identity . . . . . . 584
6.11. Network redirects and re-resolution . . . . . . . . . . . 584
6.12. Protected storage and linearizable consumption . . . . . 585
6.13. Tool package/update lifecycle . . . . . . . . . . . . . . 585
6.14. Container/sandbox deployment options . . . . . . . . . . 585
6.15. Authenticated evidence and message formats . . . . . . . 585
6.16. Threat and audit instrumentation . . . . . . . . . . . . 585
6.17. Fallback and privileged platform limits . . . . . . . . . 585
6.18. Recovery and replay after crashes . . . . . . . . . . . . 586
6.19. Independent verification and developer review . . . . . . 586
7. Reference Interfaces, Data Structures, State Machines and
Illustrative Algorithms . . . . . . . . . . . . . . . . . 586
7.1. Typed Candidate Act and Semantic Context . . . . . . . . 586
7.2. Qualified Presentation and Semantic Target Binding . . . 586
7.3. Tool Contract Compatibility Predicate . . . . . . . . . . 587
7.4. Runtime and Algorithm Baseline Qualification . . . . . . 587
7.5. Instruction Provenance and Scope Isolation . . . . . . . 588
7.6. Alias and Resource-Binding Generation Check . . . . . . . 588
7.7. Tool Install/Upgrade Generation Fence . . . . . . . . . . 588
7.8. Finality Sink Reconstruction and Consumption . . . . . . 589
7.9. Redirect, Rebind or Capability-Substitution Handling . . 589
7.10. Protected Failure and Recovery Classification . . . . . . 590
7.11. Source Authority and Tool Delta Machine . . . . . . . . . 590
8. Detailed Threat Models: Prompt Injection, Semantics Drift,
Alias Rebinding and Bypass . . . . . . . . . . . . . . . 591
8.1. Threat 1 — Prompt injection from retrieved webpages . . . 591
8.2. Threat 2 — Tool output laundering and authority
confusion . . . . . . . . . . . . . . . . . . . . . . . 591
8.3. Threat 3 — User-interface semantic target substitution . 591
8.4. Threat 4 — Tool update changes effect contract . . . . . 592
8.5. Threat 5 — Algorithm/model swap or altered
configuration . . . . . . . . . . . . . . . . . . . . . 592
8.6. Threat 6 — DNS/URL redirect to wrong tenant . . . . . . . 592
8.7. Threat 7 — Stale resource alias after rename . . . . . . 592
8.8. Threat 8 — Malicious tool registry or dependency
substitution . . . . . . . . . . . . . . . . . . . . . . 593
8.9. Threat 9 — Concurrent race on single-use finality . . . . 593
8.10. Threat 10 — Bypass through direct network or privileged
broker . . . . . . . . . . . . . . . . . . . . . . . . . 593
8.11. Threat 11 — Forged presentation or identity evidence . . 593
Das Expires 29 April 2027 [Page 6]
Internet-Draft Execution-Finality Part 7: Tools October 2026
8.12. Threat 12 — Crash and rollback restore stale tool
authority . . . . . . . . . . . . . . . . . . . . . . . 594
9. Proposed Reproducible Security and Interoperability Validation
Suite . . . . . . . . . . . . . . . . . . . . . . . . . . 594
9.1. TI01 — Authorized displayed document . . . . . . . . . . 594
9.2. TI02 — Changed UI selection . . . . . . . . . . . . . . . 594
9.3. TI03 — Ambiguous natural-language referent . . . . . . . 595
9.4. TI04 — Stale resource version . . . . . . . . . . . . . . 595
9.5. TI05 — Unauthorized recipient substitution . . . . . . . 595
9.6. TI06 — Tool contract compatible upgrade . . . . . . . . . 596
9.7. TI07 — Tool contract expanded disclosure . . . . . . . . 596
9.8. TI08 — Tool description tampering . . . . . . . . . . . . 596
9.9. TI09 — Model identity swap . . . . . . . . . . . . . . . 597
9.10. TI10 — Optional baseline correctly omitted . . . . . . . 597
9.11. TI11 — Prompt injection in webpage . . . . . . . . . . . 598
9.12. TI12 — Prompt injection in repository . . . . . . . . . . 598
9.13. TI13 — Forged tool reply . . . . . . . . . . . . . . . . 598
9.14. TI14 — Valid source grant with altered payload . . . . . 599
9.15. TI15 — DNS rebinding . . . . . . . . . . . . . . . . . . 599
9.16. TI16 — HTTP cross-tenant redirect . . . . . . . . . . . . 599
9.17. TI17 — Object alias rebound . . . . . . . . . . . . . . . 600
9.18. TI18 — Service capability substitution . . . . . . . . . 600
9.19. TI19 — Attested but unauthorized tool . . . . . . . . . . 600
9.20. TI20 — Tool update with old queued request . . . . . . . 601
9.21. TI21 — Tool rollback . . . . . . . . . . . . . . . . . . 601
9.22. TI22 — Unapproved dependency injection . . . . . . . . . 601
9.23. TI23 — Parallel double-use authority . . . . . . . . . . 602
9.24. TI24 — Agent process crash after consumption . . . . . . 602
9.25. TI25 — Network timeout after effect . . . . . . . . . . . 602
9.26. TI26 — Android cooperating app integration . . . . . . . 603
9.27. TI27 — iOS cooperating App Intents integration . . . . . 603
9.28. TI28 — Noncooperating platform alternate path . . . . . . 603
9.29. TI29 — Evidence replay with stale generation . . . . . . 604
9.30. TI30 — Verification exhaustion or cyclic references . . . 604
10. Detailed Industry and Product Alignment: Operating Systems,
Agent Frameworks, API Services and Hardware Platforms . . 604
10.1. Apple iOS, iPadOS, Siri, Shortcuts and App Intents . . . 605
10.2. Apple macOS automation, Keychain and desktop developer
tools . . . . . . . . . . . . . . . . . . . . . . . . . 605
10.3. Google Android, Gemini, Intents, Binder and Keystore . . 605
10.4. Microsoft Windows, Azure, Agent Framework and enterprise
governance . . . . . . . . . . . . . . . . . . . . . . 605
10.5. OpenAI Codex, Responses API, Agents SDK and computer
use . . . . . . . . . . . . . . . . . . . . . . . . . . 606
10.6. Anthropic Claude Code, Managed Agents and tool
sandboxing . . . . . . . . . . . . . . . . . . . . . . 606
10.7. Google Cloud, Gemini Agent, Kubernetes and service
discovery . . . . . . . . . . . . . . . . . . . . . . . 606
Das Expires 29 April 2027 [Page 7]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10.8. Meta Muse, Sentinel and AI-agent isolation . . . . . . . 606
10.9. NVIDIA OpenShell, Sentry, BlueField and GPU/accelerator
control . . . . . . . . . . . . . . . . . . . . . . . . 607
10.10. Qualcomm Snapdragon, Arm-based hardware and device
controllers . . . . . . . . . . . . . . . . . . . . . . 607
10.11. Huawei and heterogeneous mobile/embedded ecosystems . . 607
10.12. Banking, payments and merchant APIs . . . . . . . . . . 607
10.13. Telecommunications, 5G/6G and edge control planes . . . 607
10.14. Enterprise SaaS, collaboration, CRM and email . . . . . 608
10.15. Industrial IoT, robotics and autonomous control . . . . 608
10.16. Software development, package supply chain and CI/CD . . 608
10.17. Voice and System Assistants: Apple Siri, Google Gemini,
Samsung Bixby, Microsoft Copilot and Amazon Alexa . . . 608
10.18. Model Context Protocol Servers, Agent-to-Agent Protocols
and Tool or Plugin Registries . . . . . . . . . . . . . 609
10.19. Browser Agents, Web Automation and Computer Use . . . . 609
10.20. Banking, Payments, Agentic Commerce and Payee
Identity . . . . . . . . . . . . . . . . . . . . . . . 610
10.21. Email, Messaging and Collaboration Agents . . . . . . . 610
10.22. Healthcare Record and Clinical Documentation Agents . . 611
10.23. Document Signing, Legal and Back-Office Approval . . . . 611
10.24. Cloud Infrastructure-as-Code, Accounts, Tenants and
Regions . . . . . . . . . . . . . . . . . . . . . . . . 611
10.25. Model Hosting, Inference Providers and Model Routers . . 612
10.26. Smart Home, Matter Devices and Device Aliases . . . . . 612
10.27. Automotive Assistants, Apple CarPlay, Android Auto and
Over-the-Air Tool Updates . . . . . . . . . . . . . . . 612
10.28. Government Digital Identity and the EU Digital Identity
Wallet . . . . . . . . . . . . . . . . . . . . . . . . 613
10.29. Summary of Technical Effects Across Industries . . . . . 613
11. Detailed Relevance to IETF Working Groups, RFCs and Related
Security-Engineering Work . . . . . . . . . . . . . . . . 614
11.1. OAuth WG: structured authorization versus actual agent
tool consequence . . . . . . . . . . . . . . . . . . . 615
11.2. WIMSE WG: workload identity and execution context . . . 615
11.3. RATS WG: verifier, attestation evidence and runtime
state . . . . . . . . . . . . . . . . . . . . . . . . . 615
11.4. COSE and CBOR: authenticated action/contract
descriptors . . . . . . . . . . . . . . . . . . . . . . 616
11.5. SCITT WG: signed statement transparency and software
claims . . . . . . . . . . . . . . . . . . . . . . . . 616
11.6. SUIT WG: authenticated software update manifests . . . . 616
11.7. HTTPBIS: redirects, conditional requests and actual
resource selection . . . . . . . . . . . . . . . . . . 617
11.8. ACE WG: constrained device authorization . . . . . . . . 617
11.9. TEEP and trusted execution interfaces . . . . . . . . . 618
11.10. SEC-DISPATCH and Security Area review . . . . . . . . . 618
12. Relevance to the EU Artificial Intelligence Act . . . . . . . 618
Das Expires 29 April 2027 [Page 8]
Internet-Draft Execution-Finality Part 7: Tools October 2026
13. Security and Privacy Considerations and Truthfulness of
Enforcement Claims . . . . . . . . . . . . . . . . . . . 619
13.1. Actual operation versus simulated or textual intent . . 620
13.2. Semantic inference and visual ambiguity . . . . . . . . 620
13.3. Identity, provenance and authorization separation . . . 620
13.4. Current policy, revocation and time . . . . . . . . . . 620
13.5. Atomic consumption and rollback . . . . . . . . . . . . 620
13.6. Confidentiality, privacy and retention . . . . . . . . . 620
13.7. Enforcement path coverage . . . . . . . . . . . . . . . 620
13.8. Denial-of-service and verification exhaustion . . . . . 621
13.9. Third-party platform limits . . . . . . . . . . . . . . 621
13.10. Source priority and added implementation material . . . 621
14. Patent-Examiner and Industry Search Index: Embodiment-to-Page
and Figure Mapping . . . . . . . . . . . . . . . . . . . 621
15. Foundational and Companion Internet-Draft Cross-References . 622
16. Informative References . . . . . . . . . . . . . . . . . . . 623
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 627
1. Introduction: Practical Agent-Tool Security Problem and Purpose of
Part 7
An autonomous assistant or application may correctly authenticate to
an operating system, tool provider or remote service and yet act upon
a materially different object, instruction source, API contract,
tenant, resource version or receiving endpoint from the consequence
originally authorized. Users express requests such as “share this
document,” “delete that message,” or “change the current project.”
Screen selection, semantic interpretation, resource resolution and
actual effectuation can disagree across time and platform boundaries.
A signed permission or successful tool response does not itself
repair that mismatch.
The immediate security and discoverability problem applies to iOS and
Android assistants, browser-automation systems, enterprise AI agents,
coding assistants, IDE extensions, CI/CD tool chains, cloud
databases, resource registries, document collaboration, payment
infrastructure and connected devices. Prompt injection, malicious
tool responses, alias rebinding, changing tool schemas, service
migration, rogue plugins, stale model or runtime state, and confused-
deputy resource selection can each cause a tool invocation to exceed
actual authorized consequences.
This Part 7 treats distinct technical mechanisms that the original
3,567-page specification develops in Embodiments 3, 6, 10, 21, 24, 26
and 34. Embodiment 3 addresses presented-object versus actual-target
correspondence. Embodiment 6 addresses tool-effect contract changes.
Embodiment 10 addresses approved computational or model baseline
drift. Embodiment 21 addresses authenticated alias and actual
Das Expires 29 April 2027 [Page 9]
Internet-Draft Execution-Finality Part 7: Tools October 2026
resource mapping. Embodiment 24 addresses instruction provenance and
downstream authority confusion. Embodiment 26 addresses tool
installation, updates and runtime generation changes. Embodiment 34
addresses dynamic service identity, capability substitution and alias
rebinding. These mechanisms may be combined where supported by the
relevant trust model, but they are not interchangeable.
The foundational rule is that computation, textual tool intent,
permission to invoke an API and conventional authentication do not
independently establish authority to perform a specific actual
consequence. The relevant Protected Enforcement Domain verifies
applicable source scope, current operation semantics, qualified
evidence and enforcement topology; the protected Finality Sink
reconstructs the actual pending operation and checks its
correspondence, current authorization and sink-local consumption
state before an effect is permitted. Unavailable mandatory
enforcement entails withholding, not an optimistic fall-through.
This is an individually authored publication designed primarily for
technical discoverability, public source examination and
implementation analysis by patent examiners, operating-system
engineers, AI framework architects and security researchers. It does
not purport to be adopted by an IETF working group or to establish
implementation or endorsement by named platform providers. The
original patent-style source extracts, new editorial diagrams,
illustrative reference code and proposed laboratory tests are
differentiated so that an examiner can evaluate publication
chronology and technical support accurately.
1.1. Twelve-Part Series Directory, Distinct Subjects and Planned URLs
The following stable identifiers are planned individual Internet-
Draft names. URLs are prospective locations only until the relevant
text is actually submitted and indexed. Each part has a unique
searchable abstract, keywords, detailed industry mapping, working-
group alignment, technical mechanisms and source coverage.
1.1.1. Part 1 of 12 — Foundational Protected Consequence Authority,
Shared Definitions and Common Workflows CW-1/CW-2/CW-3
Proposed identifier: draft-das-interoperable-consequence-authority;
planned Datatracker URL: https://datatracker.ietf.org/doc/draft-das-
interoperable-consequence-authority/ .
Part 1 is foundational and defines CW-1, CW-2 and CW-3.
Das Expires 29 April 2027 [Page 10]
Internet-Draft Execution-Finality Part 7: Tools October 2026
1.1.2. Part 2 of 12 — Secure iOS, Android and Cross-Platform AI-Tool
Interoperability
Proposed identifier: draft-das-cross-platform-ai-interoperability;
planned Datatracker URL: https://datatracker.ietf.org/doc/draft-das-
cross-platform-ai-interoperability/ .
This companion covers its designated technical mechanism and is
cross-referenced when the present Part 7 needs its specialized
security conditions.
1.1.3. Part 3 of 12 — Protected Authorization, Validation Evidence and
Scoped Finality Capabilities
Proposed identifier: draft-das-protected-authority-evidence; planned
Datatracker URL: https://datatracker.ietf.org/doc/draft-das-
protected-authority-evidence/ .
This companion covers its designated technical mechanism and is
cross-referenced when the present Part 7 needs its specialized
security conditions.
1.1.4. Part 4 of 12 — Finality Sink Reconstruction, Protected
Consumption and Anti-Bypass Security
Proposed identifier: draft-das-finality-sink-enforcement; planned
Datatracker URL: https://datatracker.ietf.org/doc/draft-das-finality-
sink-enforcement/ .
This companion covers its designated technical mechanism and is
cross-referenced when the present Part 7 needs its specialized
security conditions.
1.1.5. Part 5 of 12 — Multi-Agent Authority, Delegation, Conflicts and
Quorum Enforcement
Proposed identifier: draft-das-multi-agent-authority-control; planned
Datatracker URL: https://datatracker.ietf.org/doc/draft-das-multi-
agent-authority-control/ .
This companion covers its designated technical mechanism and is
cross-referenced when the present Part 7 needs its specialized
security conditions.
Das Expires 29 April 2027 [Page 11]
Internet-Draft Execution-Finality Part 7: Tools October 2026
1.1.6. Part 6 of 12 — Authenticated Actual-Effect Receipts and Causal
Phase Continuation
Proposed identifier: draft-das-causal-effect-receipts; planned
Datatracker URL: https://datatracker.ietf.org/doc/draft-das-causal-
effect-receipts/ .
This companion covers its designated technical mechanism and is
cross-referenced when the present Part 7 needs its specialized
security conditions.
1.1.7. Part 7 of 12 — AI Tool Security, Semantic Target Correspondence
and Execution-Time Integrity
Proposed identifier: draft-das-agent-tool-integrity; planned
Datatracker URL: https://datatracker.ietf.org/doc/draft-das-agent-
tool-integrity/ .
This Part 7 is the principal location for semantic tool integrity,
tool lifecycle changes, instruction provenance and resource identity
binding.
1.1.8. Part 8 of 12 — Remote Effect Evidence, Distributed Transactions
and Recovery
Proposed identifier: draft-das-distributed-effect-recovery; planned
Datatracker URL: https://datatracker.ietf.org/doc/draft-das-
distributed-effect-recovery/ .
This companion covers its designated technical mechanism and is
cross-referenced when the present Part 7 needs its specialized
security conditions.
1.1.9. Part 9 of 12 — Credential Custody, Protected Disclosure and API
Security
Proposed identifier: draft-das-agent-credential-privacy; planned
Datatracker URL: https://datatracker.ietf.org/doc/draft-das-agent-
credential-privacy/ .
This companion covers its designated technical mechanism and is
cross-referenced when the present Part 7 needs its specialized
security conditions.
Das Expires 29 April 2027 [Page 12]
Internet-Draft Execution-Finality Part 7: Tools October 2026
1.1.10. Part 10 of 12 — Cross-Device Migration, Source Revocation and
Offline Fencing
Proposed identifier: draft-das-cross-device-authority-revocation;
planned Datatracker URL: https://datatracker.ietf.org/doc/draft-das-
cross-device-authority-revocation/ .
This companion covers its designated technical mechanism and is
cross-referenced when the present Part 7 needs its specialized
security conditions.
1.1.11. Part 11 of 12 — Kernel, Sandbox and Hardware Execution-Finality
Enforcement
Proposed identifier: draft-das-hardware-execution-finality; planned
Datatracker URL: https://datatracker.ietf.org/doc/draft-das-hardware-
execution-finality/ .
This companion covers its designated technical mechanism and is
cross-referenced when the present Part 7 needs its specialized
security conditions.
1.1.12. Part 12 of 12 — Resource Governance, Cloud, Telecom and
Critical Infrastructure Security
Proposed identifier: draft-das-autonomous-infrastructure-finality;
planned Datatracker URL: https://datatracker.ietf.org/doc/draft-das-
autonomous-infrastructure-finality/ .
This companion covers its designated technical mechanism and is
cross-referenced when the present Part 7 needs its specialized
security conditions.
2. Public Source, Principal Patent-Pending Disclosure, IETF IPR and
Forthcoming GitHub Implementation
This work is associated with patent-pending disclosures of Sangam
Kumar Das. The identified principal 8,598-page international
technical disclosure is PCT/IB2026/055615, filed 4 June 2026 and
published as WO 2026/150382 [PCT-055615]. Earlier PCT/IB2025/058316
is a distinct application and must not be described as the 8,598-page
June 2026 filing. Indian filings and more specific application
relationships will be recorded later following review of authentic
filing documents. No granted patent, claim scope, priority date for
newly authored material or legal conclusion is asserted here.
Das Expires 29 April 2027 [Page 13]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The complete 3,567-page public reference is "iOS and Android
Interoperability for Secure Third Party AI Tools - Cross-Platform
Execution Finality, Hardware Security, and Interoperability
(3,567-Page Specification)", Zenodo record [ZENODO]
(https://zenodo.org/records/23657985, DOI 10.5281/zenodo.23657985).
The original global-page numbers in this draft refer to the author-
supplied seven-part PDF source, not page counts of the 8,598-page
PCT.
Detailed corresponding IETF IPR disclosures, relevant filing numbers,
claim mapping and any licensing declarations are intended to be
submitted or updated separately through the applicable IETF BCP 79
process [RFC8179]. THIS PARAGRAPH IS NOT A FORMAL IETF IPR
DISCLOSURE AND DOES NOT SUBSTITUTE FOR ANY TIMELY REQUIRED
DISCLOSURE. A GitHub reference implementation, test harness,
schemata and reproducibility fixtures are planned for later
publication; no repository URL or successful test run is claimed
until actually available.
3. Keywords and Searchable Industry-Security Terminology
Primary technical keywords: AI-agent security; agentic tool
execution; tool-calling security; prompt injection; indirect prompt
injection; malicious tool-output handling; agent sandbox;
authorization bypass; operation-specific authorization; execution
finality; Candidate Act; Non-Effective State; Protected Enforcement
Domain; Finality Sink; protected action descriptor; scoped non-bearer
capability; independent actual-operation validation; sink-local
replay prevention; instruction provenance; instruction lineage; model
configuration drift; semantic integrity; UI reference grounding;
presentation-to-resource correspondence; canonical effect descriptor;
runtime lifecycle fencing; tool-effect contract; capability
substitution; authenticated service discovery; alias rebinding; DNS
rebinding; redirect security; tenant confusion; resource identity
continuity; credential audience; runtime attestation; resource-
version consistency.
Industry and platform keywords: Apple iOS security; iPadOS; macOS;
App Intents; Siri; Shortcuts; third-party AI tools; Google Android
security; Gemini; Android intents; Binder; Android Keystore; Windows;
Linux; Chrome/browser automation; OpenAI Codex and Agents SDK;
Anthropic Claude Code; Google Cloud; Microsoft Azure; Microsoft Agent
Governance; Meta Muse/Sentinel; NVIDIA OpenShell/Sentry; Arm;
Qualcomm Snapdragon; Huawei mobile and embedded platforms; enterprise
AI; IDE extensions; cloud API security; financial API security;
digital banking; SaaS administration; telecommunications; IoT;
robotics; industrial control.
Das Expires 29 April 2027 [Page 14]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Relevant standards-search terms: IETF OAuth, RFC 9396, RFC 9449, RFC
8707, RFC 8693, RFC 9110, HTTP conditional requests, WIMSE workload
identity, RATS RFC 9334, COSE RFC 9052, CBOR RFC 8949, SCITT, SUIT
manifests, security-area dispatch, IETF IPR BCP 79.
4. Terminology, Threat Boundary and Tool-Integrity Security Invariants
4.1. Candidate Act (CA)
Structured representation of a proposed consequential operation. In
this Part 7 the CA describes the actually intended selected object,
resource, recipient, tool contract, authorization source and material
operation parameters.
4.2. Non-Effective State (NES)
Enforceable state in which a candidate has not acquired the ability
to cause the governed resource effect; planning, preview or queued
tool calls do not alone change this condition.
4.3. Protected Enforcement Domain (PED)
Trusted execution or service domain that qualifies source authority,
interpretation, tool/runtime identity, evidence and current policy
independently of lower-trust agent claims.
4.4. Finality Sink (FS)
Controlled boundary where the protected actual pending effect is
independently reconstructed or observed and compared against
applicable protected permission, evidence and sink-local state.
4.5. Presentation Evidence
Authenticated or qualified evidence of the user-visible interface
context and reference at the relevant observation time, subject to
stated display integrity limits.
4.6. User-Referenced Object
The object intended by a user expression such as “this file” or “the
third message”; its meaning is not guaranteed by an LLM-derived noun
phrase.
Das Expires 29 April 2027 [Page 15]
Internet-Draft Execution-Finality Part 7: Tools October 2026
4.7. Semantic Binding Commitment
Protected association linking presentation context, resolved object,
authorized intended effect and the actual resource under defined
freshness/generation rules.
4.8. Tool Effect Contract
Authenticated, versioned technical description of what effects an
implementation may produce, including authorized target, parameters,
scopes and transitive consequences.
4.9. Tool Contract Version
Protected identifier or digest of the material effect contract,
distinguished from a cosmetic tool name or compatible input type.
4.10. Approved Execution Baseline
Authorized model, algorithm, runtime or configuration predicate whose
current qualifying state may be material to granting finality for a
pending act.
4.11. Runtime Generation
Protected monotonic version or equivalent lifecycle epoch used to
fence pending operations across installation, update, rollback and
replacement.
4.12. Instruction Provenance
Qualified lineage and trust characterization of content that
influenced an agent instruction or proposed operation; provenance
does not itself confer source authority.
4.13. Influence or Attribution Evidence
Bounded provenance-related information supporting a policy decision
about whether untrusted model-consumed content improperly influenced
a proposed consequential act.
4.14. Resource Identity
Authenticated identity of the actual resource object, tenant,
receiving endpoint or effect-capable controller, distinguished from
an alias or display name.
Das Expires 29 April 2027 [Page 16]
Internet-Draft Execution-Finality Part 7: Tools October 2026
4.15. Alias Resolution Evidence
Trusted or qualified association between logical name and currently
selected actual object, including resolution generation, ownership
and allowed redirect constraints.
4.16. Resource Binding Generation
Protected version describing which real resource a logical reference
resolves to at a specific authorized decision and effectuation
boundary.
4.17. Capability or Service Substitution
Change of receiving implementation, permission capability or endpoint
that can change actual effects even when a familiar tool name or
network address persists.
4.18. Scoped Non-Bearer Finality
Operation-specific finality enablement insufficient by itself as a
transferable reusable bearer credential; independent sink
verification and protected consumption remain necessary.
4.19. Independent Actual-Operation Reconstruction
The sink obtains material fields from the receiving/controlled effect
interface rather than merely trusting the operation string supplied
by an untrusted SDK.
4.20. Covered Effectuation Path
An interface capable of producing the governed consequence and
actually subject to required control. Absence of coverage is a real
limit, not a reason to declare unqualified non-bypassability.
4.21. Security Invariants and Mandatory Conditional Distinctions
4.21.1. Invariant 1
User-visible selection, language-model interpretation, resource
identity and actual effectuation are distinct values unless
authenticated correspondence establishes their required equality.
Das Expires 29 April 2027 [Page 17]
Internet-Draft Execution-Finality Part 7: Tools October 2026
4.21.2. Invariant 2
A tool name, matching API schema or authenticated client identity
does not by itself prove that the tool currently implements the
previously authorized consequential semantics.
4.21.3. Invariant 3
A document, web page, repository file, media transcript or tool
response is lower-trust input and cannot independently enlarge
originating source authority.
4.21.4. Invariant 4
Every enabled consequential effect remains within the current
original or competently delegated source scope; a scope deviation
follows the distinct CW-3 process when permitted.
4.21.5. Invariant 5
A current material tool-contract, model baseline or runtime-
generation change invalidates stale approval when the selected policy
makes that dependency mandatory.
4.21.6. Invariant 6
An alias or URL redirects to a resource only under protected
qualification of the actual receiving target, tenant, identity and
relevant resource version.
4.21.7. Invariant 7
Where qualified presentation evidence is mandatory, its provenance
and freshness must remain sufficient when the resource identity is
reconstructed at effectuation.
4.21.8. Invariant 8
Any unverified or incompatible required predicate retains the
Candidate Act non-effective; a human approval is not a universal
bypass of technical finality conditions.
4.21.9. Invariant 9
Single-use and other bounded finality conditions are enforced through
authoritative protected state, including appropriate crash/replay
handling.
Das Expires 29 April 2027 [Page 18]
Internet-Draft Execution-Finality Part 7: Tools October 2026
4.21.10. Invariant 10
Preservation of trust depends on available participating system
interfaces. A third-party mobile app does not thereby gain universal
enforcement over arbitrary OS processes or other apps.
4.21.11. Invariant 11
Hardware attestation or provenance signatures provide the specific
assurance they actually establish; they do not prove every operation
is authorized or every resource effect is correct.
4.21.12. Invariant 12
Proposed threat models, algorithms and tests added by this
publication are distinct from descriptions verifiably present in the
as-filed historical patent documents.
5. Original Page-Indexed Technical Disclosures: Embodiments 3, 6, 10,
21, 24, 26 and 34
The following source text comes from the author-provided seven PDFs,
with original global page numbering. This material retains the
original patent-style wording and examples, unlike the newly authored
engineering sections later in this draft. Each embodiment includes a
distinct architecture diagram and decision flowchart, but those
diagrams are new interpretations for discoverability and do not
retroactively become part of an older as-filed application. OCR/text
extraction can alter glyphs, line breaks and mathematical formatting;
original PDFs control exact wording. Some first and final pages
share adjacent embodiments.
5.1. Embodiment 3 — User-Referenced Object, Presentation Evidence and
Actual Consequential Target
Original global source pages 435 through 492, inclusive. Source
file: TECHNICAL SPECIFICATION -1-554.pdf. This is a primary Part 7
source unit; the author should compare embedded extracts with the
original source file before publication.
5.1.1. Embodiment-Specific Architecture and Trust Relationship
Das Expires 29 April 2027 [Page 19]
Internet-Draft Execution-Finality Part 7: Tools October 2026
[Source principal + shown UI context]
|
[Qualified user reference + presentation proof]
|
[Protected semantic object resolver]
|
[Bound intended object / version / recipient]
|
[Candidate Act held non-effective]
|
[PED: binding + current source authority]
|
[Sink obtains ACTUAL selected resource]
|
[Actual target == protected binding?]
/YES \NO
[Consume + bounded effect] [WITHHOLD]
Figure 1: Embodiment 3 — User-Referenced Object, Presentation
Evidence and Actual Consequential Target — protected architecture
5.1.2. Operational Security Decision Flowchart
[User says "this document" or analogous]
|
<Presentation/source context qualified?>-NO->[HOLD]
|YES
[Bind resolved object and authorized effect]
|
<Reference stale, shifted or ambiguous?>-YES->[REVALIDATE]
|NO
[Observe actual target and operation at FS]
|
<Actual target, version and scope match?>-NO->[REFUSE]
|YES
[Protected single-use consume + effect]
Figure 2: Embodiment 3 — User-Referenced Object, Presentation
Evidence and Actual Consequential Target — refusal and
controlled-effect decisions
5.1.3. Original Technical Disclosure with Global-Page Anchors
Das Expires 29 April 2027 [Page 20]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.1.3.1. Source page 435 of the original specification
The accepted receipt may constitute the causal factor that enables
the next phase through cryptographic derivation, protected capability
formation, hardware state transition, transaction-state activation,
or another non-bypassable protected control.
The later phase cannot be validly effectuated through the controlled
architecture merely because the agent chooses to proceed.
The required receipt-dependent authority must first exist and must be
verified at the corresponding Finality Sink.
Where the protected receipt is absent, invalid, stale, mismatched,
replayed, or insufficiently supported by actual effect evidence, the
required continuation condition remains unavailable or unusable.
Where Embodiment 1 is additionally implemented, the successor
operation must also satisfy applicable protected conflict-reservation
requirements.
The disclosed technical mechanisms may be implemented using
cryptographic or non-cryptographic protected enforcement, including
secure processors, operating-system mediators, protected application
gateways, transactional state machines, hardware controllers, and
other suitable computing environments.
The proposed subject matter is directed to enforceable technical
relationships among real consequential effects, protected evidence,
independently established authority, and actual effectuation
boundaries.
For Embodiment 1, the candidate technical kernel is protected,
effect-specific cross-agent arbitration verified at the actual
Finality Sink and reconciled according to consequence state.
For Embodiment 2, the candidate technical kernel is independently
validated, real-effect receipt-constituted causal authority, in which
the accepted receipt is a required enabling factor for the next
consequential operation rather than a merely descriptive or post-hoc
success record.
The novelty and inventive step of the particular claimed combinations
remain subject to the applicable prior-art assessment.
END OF SUPPLEMENTARY TECHNICAL DISCLOSURE — EMBODIMENT 1 AND 2
EMBODIMENT 3
Das Expires 29 April 2027 [Page 21]
Internet-Draft Execution-Finality Part 7: Tools October 2026
PROTECTED USER-REFERENCED SEMANTIC OBJECT CORRESPONDENCE WITH
AUTHENTICATED PRESENTATION-STATE BINDING, CROSS-MODAL ENTITY
RESOLUTION, AND INDEPENDENT FINALITY-SINK RECONSTRUCTION
3.0 — COMPLETE TECHNICAL TITLE
5.1.3.2. Source page 436 of the original specification
Systems and Methods for Protected Correspondence Between User-
Referenced Information, Semantically Resolved Computational Objects,
and Actually Effectuated Operations Using Authenticated Presentation
Evidence, Temporal Entity-Identity Continuity, Protected Semantic
Binding Commitments, and Independent Finality-Sink Verification
3.0.1 — General Characterization
The present embodiment discloses systems, methods, apparatus,
protected computing components, cryptographically authenticated
records, machine-verifiable semantic correspondence protocols,
protected state-transition mechanisms, and non-limiting
implementations for preserving correspondence between a resource or
operation referenced by a user and the actual consequential operation
performed by an autonomous computing system.
The architecture may apply to autonomous artificial-intelligence
agents, on-device assistants, operating-system services, application
agents, computer-use systems, browser automation, accessibility
interfaces, multimodal assistants, remote agents, wearable computing
devices, spatial computing systems, robotic controllers, and
distributed application frameworks.
In one non-limiting implementation, a user issues an instruction
referring to information presented through a computing interface.
The reference may include expressions such as:
"This document."
"That photograph."
"The third message."
"The file I selected."
"Send the currently displayed report."
"Delete the item immediately above this one."
Das Expires 29 April 2027 [Page 22]
Internet-Draft Execution-Finality Part 7: Tools October 2026
"Share the highlighted object."
"Pay the invoice shown here."
"Move that object."
The user may identify the intended object through speech, text,
pointing, touch, gaze, selection, gesture, spatial reference, or
another input modality.
The autonomous agent may resolve the reference into a computational
object, entity identifier, application resource, tool argument,
command target, or corresponding operation descriptor.
However, resolution of the user's reference does not, by itself,
establish that the correct object will ultimately be affected.
Between the user's reference and the actual consequential operation,
the application interface may change, a resource may be replaced, a
list may reorder, another window may gain focus, an object may be
deleted and recreated, a provider may remap an entity identifier, or
an agent may select an incorrect target.
5.1.3.3. Source page 437 of the original specification
An attacker may also manipulate visual content, structured interface
metadata, application state, overlays, delegated commands, or
operation arguments to redirect the actual consequence.
The present embodiment addresses this technical problem through a
protected correspondence mechanism involving three principal
representations.
First representation — User-Referenced Presentation Object.
A protected representation of the object or relationship identified
in a particular presentation and user-reference context.
Second representation — Resolved Computational Entity.
A machine-verifiable representation of the resource or entity
selected through semantic resolution of the user's instruction.
Third representation — Actually Pending Effectuation Target.
Das Expires 29 April 2027 [Page 23]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A representation obtained or reconstructed at the consequential
effectuation boundary identifying the actual resource, operation, and
relevant effect parameters that the computing system is about to
affect.
An authorized consequential operation may be permitted only when the
required correspondence predicates among these representations are
satisfied and the applicable execution-finality authority remains
valid.
The proposed system therefore separates semantic interpretation from
authority to affect a particular actual object.
3.0.2 — Central Technical Principle
The controlling principle of the present embodiment is:
Successful interpretation of a user's reference does not establish
authority to effectuate an operation against a computational object
unless the actual effectuation target is independently verified to
correspond to the protected user-referenced object under the
applicable authorized semantics.
In a higher-assurance implementation, this correspondence is
represented through authenticated presentation evidence, protected
object-identity resolution, temporally valid semantic-binding
evidence, and sink-local reconstruction of the actual operation.
The system may reject, defer, automatically revalidate, or request
fresh user authorization where the correspondence cannot be
established.
3.0.3 — Nature of the Potential Inventive Contribution
The proposed technical contribution does not rest merely upon
recognizing graphical user-interface elements, applying optical
character recognition, identifying screen coordinates, resolving
application entities, comparing screenshots, or repeating a user
confirmation.
These techniques may provide supporting inputs.
The potentially distinguishing arrangement is an enforceable
authorization structure that binds:
Das Expires 29 April 2027 [Page 24]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.1.3.4. Source page 438 of the original specification
1. A verified presentation and user-reference context;
2. A semantically resolved object or relation;
3. Authenticated object-identity or version evidence;
4. The intended consequential operation;
5. A protected semantic-correspondence validation decision;
6. The actual resource and operation reconstructed at a controlled
effectuation boundary;
7. A narrowly scoped, sink-verifiable execution authority.
The architecture further defines behavior when the displayed entity,
resolved entity, and actual effectuation target diverge.
The individual mechanisms may be implemented in different technical
combinations, subject to the applicable claims and trust assumptions.
3.1 — TECHNICAL FIELD
The present embodiment relates to secure human-computer interaction,
autonomous execution governance, multimodal entity resolution,
graphical interface security, operating-system mediation, protected
application dispatch, computer vision, authenticated object identity,
temporal consistency, cryptographic operation binding, trusted
execution environments, and effectuation-boundary control.
More particularly, the embodiment concerns the use of authenticated
presentation and object-resolution evidence to prevent consequential
operations from being redirected toward a resource other than the
resource established by the applicable user-reference authorization.
The architecture may operate with:
• Visual interfaces;
• Textual interfaces;
• Accessibility trees;
• Structured application entities;
• Voice-driven interfaces;
Das Expires 29 April 2027 [Page 25]
Internet-Draft Execution-Finality Part 7: Tools October 2026
• Touchscreens;
• Spatial interfaces;
• Browser interfaces;
• Remote application views;
• Head-mounted displays;
5.1.3.5. Source page 439 of the original specification
• Industrial interfaces;
• Robotic control surfaces.
No particular input modality or user-interface framework is
universally required.
3.2 — SPECIFIC TECHNICAL PROBLEMS
3.2.1 — Difference Between a Displayed Object and an Underlying
Resource
A user interface may display a representation of a computational
object without exposing its complete underlying identity.
For example, a messaging application may display several
conversations with identical participant names.
A file manager may display multiple documents with identical
filenames.
A shopping interface may display visually similar products.
A payment interface may display a recipient's human-readable name
while the actual account identifier is stored separately.
An AI agent interpreting the visible label may select an incorrect
underlying entity.
The problem is not necessarily solved by obtaining more screen
pixels.
The system may require authenticated correspondence between the
displayed representation and the resource actually controlled by an
application or service.
Das Expires 29 April 2027 [Page 26]
Internet-Draft Execution-Finality Part 7: Tools October 2026
3.2.2 — Temporal Change Between Observation and Action
A user may refer to an object at a particular time.
The interface may subsequently change before the agent executes the
requested operation.
Examples include:
• A message list receiving a new message;
• A document list changing its sort order;
• A window losing foreground focus;
• A notification overlay appearing;
• A webpage updating its content;
• An application replacing a selected entity;
• A virtualized list recycling a visual row;
• A remote resource changing version;
5.1.3.6. Source page 440 of the original specification
• A browser component reusing an identifier;
• A spatial object moving after initial observation.
The operation that would have affected the intended object at the
original observation time may affect a different object at execution
time.
3.2.3 — Coordinate-Based Action Rebinding
A computer-use agent may derive a screen coordinate from a
screenshot.
The agent may later inject a click or touch event at that coordinate.
If the underlying interface has changed, the same coordinate may
correspond to a different target.
A click coordinate therefore does not, by itself, establish a stable
identity for the object that the user intended to affect.
Das Expires 29 April 2027 [Page 27]
Internet-Draft Execution-Finality Part 7: Tools October 2026
3.2.4 — Structural Metadata Manipulation
An application may expose a structured accessibility node, document
object model entry, entity identifier, or other machine-readable
object representation.
Such information may improve automation.
However, structural metadata supplied by an untrusted or compromised
component may be incorrect or may no longer correspond to the actual
rendered interface.
A trusted semantic-binding system should therefore identify the
provenance and assurance level of the structural information used.
3.2.5 — Visual and Structural Disagreement
A rendered interface may indicate one object while the application's
structured model refers to another.
The discrepancy may arise from a rendering defect, stale cache,
malicious modification, overlay, timing race, or unsupported
accessibility representation.
A system that trusts only pixels may be unable to establish the
correct underlying entity.
A system that trusts only metadata may overlook misleading displayed
content.
The present embodiment provides procedures for reconciling multiple
evidence sources without treating every source as equally
trustworthy.
3.2.6 — Cross-Application Entity Transfer
A user may refer to an object displayed in one application and
request a consequential action in another.
For example, a selected document may be transmitted through a
messaging application.
5.1.3.7. Source page 441 of the original specification
The originating application may use one resource identifier while the
receiving application or service uses another identifier or
serialized representation.
Das Expires 29 April 2027 [Page 28]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A naive identifier comparison may therefore fail even when the
transferred object is correct.
Conversely, accepting all objects with similar names or contents may
permit unauthorized substitution.
The system requires a defined, authenticated correspondence procedure
across the relevant resource domains.
3.2.7 — Consequential Semantic Misbinding
An authorization may be valid for one operation but be applied to a
different object because the agent incorrectly resolves a relative
reference.
For example, the user may instruct:
"Delete the second draft."
An application may reorder the drafts before the delete operation
reaches the storage boundary.
The agent may then delete a different draft.
The central technical problem is preventing the authorized operation
from becoming effective against the incorrectly resolved target.
3.2.8 — Technical Objective
The objective is to establish a protected, enforceable relationship
among:
• What the interface presented in the relevant reference context;
• What the user selected or referred to;
• What computational entity was resolved from that reference;
• What operation the user authorized for that entity;
• What actual resource and effect the Finality Sink is about to
execute.
The architecture should detect material inconsistencies and prevent
unauthorized effectuation through the controlled boundary.
3.3 — INCORPORATION OF COMMON WORKFLOWS
Das Expires 29 April 2027 [Page 29]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The embodiment may employ Common Master Workflow CW-1.
In particular, it may use Candidate Act formation, Non-Effective
State holding, protected validation evidence, scoped finality
authority, independently reconstructed actual operations, and
Finality Sink enforcement.
5.1.3.8. Source page 442 of the original specification
The embodiment may employ Common Workflow CW-2 where independent in-
line validation or phased continuation is required.
The embodiment may also employ Common Workflow CW-3 where a material
semantic mismatch constitutes a possible departure from the user's
original authorized task scope.
These workflows remain functionally distinguishable.
CW-1 supplies the general execution-finality architecture.
CW-2 optionally supplies independent interim verification and
protected phase continuation.
CW-3 optionally supplies protected scope-deviation adjudication and
bounded reauthorization.
Embodiment 3 supplies the distinctive semantic-object correspondence
mechanism.
A mismatch between user-referenced object and actual effectuation
target may cause immediate denial under Embodiment 3 without
requiring a separate human-approval process.
Where reauthorization is technically permitted, CW-3 may be invoked
to obtain new scope-specific authority.
Where the task comprises multiple consequential phases, CW-2 may
independently verify the required phase correspondence and
continuation state.
3.4 — ADDITIONAL TECHNICAL DEFINITIONS
3.4.1 — User-Referenced Object (URO)
A User-Referenced Object is a resource, entity, displayed item,
physical target, or defined relationship that a user identifies or
references through an interaction with a computing interface.
Das Expires 29 April 2027 [Page 30]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A URO may be identified directly or through a relative expression.
3.4.2 — Authenticated Presentation Context (APC)
An Authenticated Presentation Context is a machine-verifiable
representation of relevant information made available through a user-
interface presentation at a particular time or protected state.
An APC may identify the presenting application, surface, object
representation, focus state, relevant displayed region, object
relationships, rendering or interface generation, and applicable
trusted observation evidence.
An APC does not automatically prove that the user consciously
perceived every represented item.
3.4.3 — User Reference Event (URE)
A User Reference Event is an interaction indicating the object or
relationship to which a user instruction refers.
A URE may comprise a spoken phrase, typed instruction, touch
selection, accessibility selection, pointer event, gesture, gaze-
based selection, or another supported reference modality.
5.1.3.9. Source page 443 of the original specification
3.4.4 — Semantic Referent Descriptor (SRD)
A Semantic Referent Descriptor is a structured representation of the
intended object or selection relationship derived from the URE and
relevant APC.
An SRD may specify a particular entity, selected region, list
position, relative relationship, object type, or constrained set of
candidate objects.
3.4.5 — Resolved Entity Identity (REI)
A Resolved Entity Identity is an authenticated or appropriately
verified computational identity assigned to an object that satisfies
an applicable semantic reference.
The REI may include an object identifier, namespace, version,
resource-owner identity, or protected equivalent.
3.4.6 — Presentation-to-Entity Correspondence Evidence (PECE)
Das Expires 29 April 2027 [Page 31]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Presentation-to-Entity Correspondence Evidence is authenticated
evidence establishing a defined relationship between a presentation
representation and a resolved computational entity.
3.4.7 — Protected Semantic Correspondence Record (PSCR)
A Protected Semantic Correspondence Record is an authenticated
commitment binding a user-reference context, resolved entity,
permitted operation, relevant object state, and designated
effectuation boundary.
3.4.8 — Temporal Referent Epoch (TRE)
A Temporal Referent Epoch identifies the relevant presentation or
object-state generation at which a user-reference relationship was
established.
A TRE may be derived from an authenticated application-state version,
rendering generation, selected-object version, or equivalent
protected reference.
3.4.9 — Entity Continuity Proof (ECP)
An Entity Continuity Proof is authenticated evidence establishing
that an entity referenced at one state remains the same authorized
entity, or remains within an expressly permitted transformation, at a
subsequent verification point.
The term proof refers to evidence satisfying a defined verification
predicate and does not necessarily imply a formal mathematical proof.
3.4.10 — Authorized Semantic Transformation (AST)
An Authorized Semantic Transformation is a specifically permitted
change in representation, identifier, format, version, or application
context that preserves the operation's authorized target or meaning.
An AST may be limited by resource, operation, version, destination,
or other protected constraints.
3.4.11 — Semantic Mismatch Condition (SMC)
5.1.3.10. Source page 444 of the original specification
A Semantic Mismatch Condition occurs when the required correspondence
among the user-reference context, resolved entity, and actual pending
operation cannot be established.
Das Expires 29 April 2027 [Page 32]
Internet-Draft Execution-Finality Part 7: Tools October 2026
3.4.12 — Protected Referent Selection Commitment (PRSC)
A Protected Referent Selection Commitment is an authenticated record
binding a specific user-reference event or trusted selection to the
relevant APC and semantic referent.
3.4.13 — Finality-Sink Actual Target Descriptor (FSATD)
A Finality-Sink Actual Target Descriptor is a machine-verifiable
representation of the actual object, resource, destination, and
operation reconstructed at the designated consequential boundary.
3.4.14 — Protected Correspondence Validation Result (PCVR)
A Protected Correspondence Validation Result is an authenticated
decision concerning whether the actual pending operation satisfies
the required semantic correspondence predicates.
3.4.15 — Correspondence Uncertainty State (CUS)
A Correspondence Uncertainty State represents a condition in which
available evidence is insufficient to establish the required
correspondence.
CUS is not automatically equivalent to verified mismatch.
Where correspondence is mandatory, however, an unresolved CUS causes
withholding of the affected consequential effect.
3.5 — TRUST MODEL AND PRESENTATION-ASSURANCE LIMITS
3.5.1 — Distinction Between Presentation and Human Perception
The system distinguishes between information technically presented to
a user and information actually perceived or understood by that user.
A trusted display or compositor may provide authenticated evidence
concerning rendered output.
A selection interface may provide authenticated evidence that a
particular user-input event occurred within an identified
presentation context.
Neither mechanism, by itself, conclusively proves a user's subjective
awareness, understanding, or intention.
Das Expires 29 April 2027 [Page 33]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Accordingly, an implementation may claim authenticated presentation-
state correspondence without claiming direct access to the user's
mental state.
Where stronger evidence of user selection or approval is needed, the
system may use an authenticated interaction or confirmation
procedure.
3.5.2 — Rendering Evidence Trust
Presentation evidence may be obtained from:
5.1.3.11. Source page 445 of the original specification
• A trusted compositor;
• A protected application view service;
• An authenticated accessibility subsystem;
• A controlled window manager;
• An application-specific entity annotation service;
• A trusted display pipeline;
• An authenticated spatial rendering component;
• Another technically suitable observation source.
The evidence may describe the rendered interface, structured object
identity, or both.
Its trustworthiness depends upon the actual source and protection
boundary.
3.5.3 — Application-Supplied Metadata
An application may provide entity annotations or identifiers.
Such metadata may be useful but is not automatically proof that the
corresponding object was honestly presented or remains the actual
target.
Where the application is untrusted for the required property, the
system may use independent evidence, authenticated application
contracts, or conservative verification.
Das Expires 29 April 2027 [Page 34]
Internet-Draft Execution-Finality Part 7: Tools October 2026
3.5.4 — Agent Trust
The agent may suggest a candidate semantic referent.
The agent is not allowed to establish its own final effectuation
authority merely by declaring the referent correct.
The protected correspondence mechanism validates the applicable
relation independently of unsupported agent assertions.
3.5.5 — Effectuation Enforcement
The security property depends upon the Finality Sink or equivalent
controlling component being able to withhold the governed effect.
A model-level instruction to verify the screen is not equivalent to a
non-bypassable protected effectuation boundary.
3.5.6 — Unsupported Observability
Where the available interface cannot establish a stable resource
identity, the system may require additional user selection,
restricted operation, or denial.
5.1.3.12. Source page 446 of the original specification
The architecture does not assume that every pixel-based object can be
mapped with certainty to a stable backend entity.
3.6 — DETAILED SYSTEM ARCHITECTURE
3.6.1 — User Interaction Capture Component
A User Interaction Capture Component obtains a URE.
The URE may originate from voice recognition, text input, touch,
pointer selection, accessibility interaction, gesture detection, or
another supported input method.
The component may bind the event to a current presentation context.
Where authentication of user origin is required, the component
employs the applicable trusted-input or user-presence mechanism.
3.6.2 — Presentation Evidence Collector
A Presentation Evidence Collector acquires relevant interface-state
evidence.
Das Expires 29 April 2027 [Page 35]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The collector may obtain:
• Display surface identifier;
• Presenting application identity;
• Window or view identity;
• Rendering generation;
• Foreground or focus state;
• Selected object annotations;
• Visible region geometry;
• Object ordering;
• Object relationships;
• Displayed labels;
• Accessibility metadata;
• Relevant content or representation commitments;
• Trusted time or protected sequence.
Raw screenshots are not universally required.
An authenticated semantic representation may suffice where it proves
the required relationship.
5.1.3.13. Source page 447 of the original specification
3.6.3 — Protected Presentation-State Registry
A Protected Presentation-State Registry maintains authenticated
references to presentation contexts.
The registry may store compact commitments rather than complete
screenshots.
It may also maintain temporal relationships among successive
presentation states.
The requesting agent cannot unilaterally replace a protected
reference with an unrelated presentation state.
Das Expires 29 April 2027 [Page 36]
Internet-Draft Execution-Finality Part 7: Tools October 2026
3.6.4 — Semantic Referent Resolution Engine
A Semantic Referent Resolution Engine, or SRRE, derives one or more
candidate entity identities from the URE and APC.
The SRRE may use language interpretation, structured application
entities, accessibility information, computer vision, object
recognition, deterministic selection rules, or combinations thereof.
The SRRE may output multiple candidates where the reference is
ambiguous.
A confidence score may assist ranking, but it does not automatically
substitute for the protected verification required for consequential
effectuation.
3.6.5 — Protected Entity Identity Resolver
A Protected Entity Identity Resolver, or PEIR, verifies or obtains
the computational identity of the selected object.
The PEIR may use:
• Authenticated object identifiers;
• Protected namespace mappings;
• Resource-owner attestations;
• Signed entity annotations;
• Object-version identifiers;
• Secure storage references;
• Authenticated service-side resource tokens;
• Protected application dispatch records.
The PEIR may return an REI and associated validity conditions.
3.6.6 — Presentation-to-Entity Correspondence Verifier
A Presentation-to-Entity Correspondence Verifier determines whether
the resolved entity corresponds to the protected user-reference
context.
Das Expires 29 April 2027 [Page 37]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.1.3.14. Source page 448 of the original specification
For example, it may verify that the selected entity occupied the
referenced list position within the authenticated presentation
snapshot.
In another implementation, it verifies that a particular visible
document card was bound to the corresponding authenticated document
identity.
In another implementation, it verifies an explicitly selected object
through a trusted interaction record.
3.6.7 — Temporal Entity Continuity Controller
A Temporal Entity Continuity Controller determines whether the
resolved entity remains valid at a later point.
It may compare object identities, versions, presentation epochs,
ownership state, relevant content commitments, and authorized
transformations.
The controller does not necessarily require the whole display to
remain unchanged.
It verifies the specific properties relevant to the requested effect.
3.6.8 — Protected Semantic Binding Engine
A Protected Semantic Binding Engine, or PSBE, constructs the PSCR.
The PSCR binds the relevant user-reference evidence, REI, permitted
operation, object state, and designated sink.
The PSCR may be maintained within the PED or authenticated to the
PED.
3.6.9 — Actual Target Reconstruction Interface
An Actual Target Reconstruction Interface, or ATRI, provides actual
pending operation evidence to the Finality Sink or a cooperating
protected validator.
The ATRI may identify the target file, message, recipient, database
record, application entity, service object, physical target, or
another resource at the controlled consequential boundary.
The ATRI may be integrated with the AORI described in Embodiment 2.
Das Expires 29 April 2027 [Page 38]
Internet-Draft Execution-Finality Part 7: Tools October 2026
3.6.10 — Finality-Sink Correspondence Verifier
A Finality-Sink Correspondence Verifier checks the FSATD against the
PSCR and applicable protected authority.
If the actual pending operation differs materially from the
authorized referent and effect, the operation is withheld.
3.6.11 — Optional Semantic Reauthorization Component
Where a mismatch is potentially resolvable through a new user
decision, the system may invoke CW-3.
5.1.3.15. Source page 449 of the original specification
A trusted interface may present the original referenced object, the
newly resolved object, and the requested consequential change.
Any approved change is incorporated into a new scoped authorization.
The original PSCR is not silently rewritten to describe a different
target.
3.7 — AUTHENTICATED PRESENTATION CONTEXT
3.7.1 — Purpose
The APC establishes the reference context within which the user's
instruction was interpreted.
For example, the phrase "the third message" depends upon which
message list was displayed and how that list was ordered at the
relevant reference event.
Without the presentation context, the phrase may not uniquely
identify a computational object.
3.7.2 — Representative APC Structure
AUTHENTICATED_PRESENTATION_CONTEXT = { protocol_version,
presentation_context_id, presenting_application_id,
presentation_surface_id, trusted_window_or_view_id,
display_or_view_generation, focus_state_commitment,
presentation_timestamp_or_sequence, visible_entity_commitments[],
visible_entity_order_commitment, selection_state_commitment,
layout_or_geometry_commitment, structured_ui_evidence_commitment,
rendered_evidence_commitment, source_assurance_profile,
protected_authentication } The fields are illustrative.
Das Expires 29 April 2027 [Page 39]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An implementation may omit fields not necessary for its authorized
semantics.
3.7.3 — Display Snapshot Binding
An APC may bind a particular presentation generation.
The binding may use a trusted compositor sequence, protected window-
state version, application view-generation counter, or authenticated
snapshot reference.
The system does not assume that two screenshots with similar pixels
necessarily represent the same underlying object state.
5.1.3.16. Source page 450 of the original specification
3.7.4 — Structured Entity Binding
Where structured annotations are available, the APC may associate
displayed regions with computational entity identifiers.
The association may include:
• Entity identifier;
• Resource namespace;
• Object version;
• Display representation;
• View position;
• Selection state;
• Application identity;
• Authentication or assurance information.
The association is verified according to the applicable trust model.
3.7.5 — Content Minimization
An APC need not retain complete private screen content.
Where feasible, it may retain cryptographic commitments, selected
object descriptors, region-specific metadata, or authenticated entity
references.
Das Expires 29 April 2027 [Page 40]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The representation must nevertheless preserve enough information to
verify the required correspondence.
3.7.6 — Presentation Provenance
The system may distinguish a genuine application-controlled surface
from an untrusted overlay, remote rendering surface, synthetic
screenshot, or other presentation source.
A protected provenance field may identify the relevant source class
and assurance level.
The system does not treat visual similarity as proof of common
provenance.
3.8 — USER REFERENCE EVENT AND SEMANTIC RESOLUTION
3.8.1 — Reference Capture
A user may say:
"Send the third one."
The system records the relevant instruction and associates it with
the current APC.
5.1.3.17. Source page 451 of the original specification
If several presentation contexts are plausible, the system may
require explicit selection or additional context.
3.8.2 — Relative Reference Resolution
A relative reference may depend upon:
• Current list order;
• Selection state;
• Current focus;
• View hierarchy;
• Spatial position;
• Previously referenced entity;
• Conversation state;
Das Expires 29 April 2027 [Page 41]
Internet-Draft Execution-Finality Part 7: Tools October 2026
• Displayed object relationship.
The SRRE may resolve the reference into an SRD.
For example:
SEMANTIC_REFERENT_DESCRIPTOR = { reference_event_id,
presentation_context_id, reference_type: ORDINAL_SELECTION,
ordinal_position: 3, relevant_collection_id, collection_generation,
selected_entity_candidate_id, permitted_interpretation_rules,
evidence_commitment } 3.8.3 — Stable Referent Identity
Once the third item is resolved within the authenticated reference
context, the system may bind the selected entity's stable identity.
Subsequent list reordering does not automatically convert the
authorization into permission for whichever object later occupies the
third row.
The operation remains associated with the originally resolved entity
unless an authorized interpretation explicitly specifies a different
dynamic relationship.
3.8.4 — Dynamic Referential Semantics
Not every user reference requires a permanently fixed object.
For example:
5.1.3.18. Source page 452 of the original specification
"Send the latest approved report."
This instruction may intentionally refer to a dynamically changing
object.
The system may represent the authorized semantics as a bounded query
or predicate rather than a fixed identifier.
In that implementation, the actual selected resource must satisfy the
authorized dynamic predicate at effectuation time.
The predicate may require the latest report version, approved status,
designated repository, and permitted publication state.
The system must distinguish an authorized dynamic selector from an
unintended stale-reference substitution.
Das Expires 29 April 2027 [Page 42]
Internet-Draft Execution-Finality Part 7: Tools October 2026
3.8.5 — Ambiguous References
Where the reference does not uniquely identify an object and the
operation is consequential, the system may:
• Request clarification;
• Present candidate entities through a trusted interface;
• Restrict the operation to a safer subset;
• Defer authorization;
• Deny the operation.
An agent cannot create final authority by arbitrarily selecting a
candidate that appears semantically plausible.
3.9 — ENTITY IDENTITY AND ALIAS RESOLUTION
3.9.1 — Canonical Entity Representation
In one implementation, the PEIR constructs an REI containing:
RESOLVED_ENTITY_IDENTITY = { entity_namespace, entity_identifier,
resource_owner_commitment, object_generation, object_version,
entity_type, authorized_alias_commitments[],
relevant_content_commitment, identity_evidence_reference,
validity_conditions, protected_authentication
5.1.3.19. Source page 453 of the original specification
} 3.9.2 — Distinguishing Identical Names
Two files may share the same displayed filename.
The system therefore does not treat name equality alone as sufficient
identity evidence.
A verified resource identifier, version, owner namespace, or
equivalent authenticated distinguishing attribute may be required.
3.9.3 — Object Recreation
An application may delete an object and create a new object with the
same visible label.
Das Expires 29 April 2027 [Page 43]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The new object may not be semantically or technically identical to
the original referenced object.
The system may use object-generation or version evidence to identify
the replacement.
A new authorization may be required if the replacement falls outside
the permitted semantics.
3.9.4 — Cross-Application Identity
A resource may move between applications through export, import,
serialization, synchronization, or content transfer.
The corresponding object identifiers may change.
An AST may define a permitted correspondence between the original
resource and the transferred representation.
The transformation may be verified through an authenticated transfer
record, content commitment, resource-owner statement, or another
appropriate mechanism.
3.9.5 — Transformation Scope
An authorized transformation may permit a format conversion without
permitting unrelated content replacement.
For example, converting a particular document into a PDF
representation may be permitted if the relevant content and operation
constraints remain satisfied.
However, a conversion function may alter layout, omit information, or
introduce additional content.
Where such properties matter, the technical equivalence predicate
must be specified rather than assumed.
3.9.6 — Content Equivalence Versus Object Identity
Two resources may have identical content but different owners,
destinations, or authorization status.
Content hash equality therefore does not necessarily establish
permission to act on either object interchangeably.
Das Expires 29 April 2027 [Page 44]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.1.3.20. Source page 454 of the original specification
Similarly, two versions of the same object may differ in content
while remaining part of one authorized resource lineage.
The applicable correspondence rule identifies which properties must
remain equal and which transformations are permitted.
3.10 — PROTECTED SEMANTIC CORRESPONDENCE RECORD
3.10.1 — Purpose
The PSCR connects the user-reference evidence with the resolved
entity and intended consequential operation.
The PSCR is constructed before release of the applicable scoped
finality authority.
3.10.2 — Representative Structure
PROTECTED_SEMANTIC_CORRESPONDENCE_RECORD = { pscr_version,
candidate_act_id, user_reference_event_commitment,
authenticated_presentation_context_digest,
semantic_referent_descriptor_digest,
resolved_entity_identity_commitment, reference_resolution_rule_id,
authorized_semantic_transformation_ids[], authorized_action_class,
authorized_resource_scope, authorized_destination_scope,
expected_resource_version, required_temporal_continuity_predicates[],
designated_finality_sink_id, protected_policy_epoch, authority_epoch,
revocation_epoch, correspondence_nonce, protected_authentication }
3.10.3 — Protected Commitment
In one implementation:
PSCR_COMMITMENT = AUTH_PROTECT(H("SEMANTIC-BIND-V1" ||
CANONICAL(PSCR)))
AUTH_PROTECT may represent digital signing, message authentication,
sealed storage, or another suitable integrity mechanism.
A bare hash without protected binding does not itself establish
trusted authorship or authority.
3.10.4 — Distinct Verification Relationships
Das Expires 29 April 2027 [Page 45]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.1.3.21. Source page 455 of the original specification
The PSCR may commit three technically distinguishable relationships.
Relationship R1 — Presentation-to-Reference.
The user-reference event corresponds to the relevant authenticated
presentation context.
Relationship R2 — Reference-to-Entity.
The semantic resolution identifies a resource satisfying the
protected reference meaning.
Relationship R3 — Entity-to-Actual Effect.
The actual operation presented at the Finality Sink targets the
authorized entity or an expressly permitted transformation.
The system may require all three relationships to pass.
3.10.5 — No Semantic Authority by Confidence Alone
The semantic resolver may produce a confidence score.
The PSCR may record the score as contextual evidence.
However, final authority depends upon the required authenticated
correspondence predicate, not solely on a probabilistic confidence
threshold.
Where a property cannot be established with adequate assurance, the
operation is withheld or subjected to an appropriate clarification
procedure.
3.11 — TEMPORAL ENTITY CONTINUITY
3.11.1 — Observation-to-Effect Interval
The system distinguishes the moment of user reference from the moment
of actual consequential effectuation.
The interval may contain application updates, display changes,
resource modifications, user interactions, and asynchronous events.
The architecture therefore maintains a protected temporal
relationship between the referenced object and the object reaching
effectuation.
Das Expires 29 April 2027 [Page 46]
Internet-Draft Execution-Finality Part 7: Tools October 2026
3.11.2 — Stable-Object Continuity
Where authorization targets one specific object, the continuation
controller verifies that the actual object remains the same
authorized identity.
A change in screen position alone need not invalidate authorization
if the underlying object identity remains verifiably unchanged.
3.11.3 — Version-Sensitive Continuity
Where the authorized operation is version-specific, the system
verifies the relevant resource version.
5.1.3.22. Source page 456 of the original specification
An attempt to transmit a newer or older version may require renewed
authorization depending upon the user's instruction.
3.11.4 — Dynamic-Predicate Continuity
Where the user authorizes a dynamic object selector, the system
evaluates that selector at the appropriate protected execution point.
For example, "the latest approved document" may require the actual
resource to satisfy a current approved-status predicate.
The system may evaluate the predicate immediately before the
controlled effect.
3.11.5 — Presentation Epoch Validation
A TRE may become invalid when:
• The selected object is replaced;
• The relevant list-generation semantics change;
• The source application identity changes;
• The object mapping is revoked;
• The original selection becomes ambiguous;
• A required focus or interaction context is superseded.
The result depends upon the selected correspondence rules.
Das Expires 29 April 2027 [Page 47]
Internet-Draft Execution-Finality Part 7: Tools October 2026
3.11.6 — Rebinding Under Authorized Conditions
An object may be rebound to a new representation if an AST
establishes the permitted relationship.
The system authenticates the transformation and updates the
appropriate protected reference.
A new object is not accepted merely because it resembles the earlier
object.
3.12 — INDEPENDENT FINALITY-SINK TARGET RECONSTRUCTION
3.12.1 — Actual Pending Operation
The designated Finality Sink obtains or reconstructs the actual
pending consequential operation.
The reconstructed representation may contain:
• Actual operation class;
• Actual source object;
• Actual destination;
5.1.3.23. Source page 457 of the original specification
• Actual resource identifier;
• Actual resource version;
• Actual operation parameters;
• Relevant application identity;
• Applicable effectuation boundary;
• Current protected authority state.
3.12.2 — Representative FSATD
Das Expires 29 April 2027 [Page 48]
Internet-Draft Execution-Finality Part 7: Tools October 2026
FINALITY_SINK_ACTUAL_TARGET_DESCRIPTOR = { actual_operation_id,
actual_action_class, actual_resource_namespace, actual_resource_id,
actual_resource_generation, actual_resource_version,
actual_destination_id, actual_operation_arguments_commitment,
actual_execution_domain_id, actual_sink_id,
actual_command_generation, protected_observation_reference } 3.12.3 —
Independent Reconstruction Requirement
Where a claimed implementation requires independent actual-operation
verification, the FSATD is not derived solely by copying the agent's
claimed target identifier.
The sink obtains relevant parameters from the controlled effectuation
interface, protected dispatcher, controller-owned command, resource
manager, or another technically sufficient source.
3.12.4 — Correspondence Evaluation
The Finality Sink verifies that the FSATD satisfies the PSCR.
In one implementation, the decision may be expressed as:
PERMIT = VALID_FINALITY_AUTHORITY AND VALID_R1 AND VALID_R2 AND
VALID_R3 AND CURRENT_STATE_VALID
The expression is illustrative.
The system may employ more predicates where required.
3.12.5 — No Post-Verification Substitution
5.1.3.24. Source page 458 of the original specification
Where the actual operation can change after the sink verifies it, the
implementation uses an appropriate protected atomic release,
immutable command buffer, command-generation binding, or equivalent
mechanism.
A verified target cannot be replaced with another effect target
without causing the applicable protected verification to fail.
3.12.6 — Sink-Local Consumption
Where the action is single-use, the sink consumes or reserves the
corresponding authority according to protected state semantics.
The same PSCR cannot be used as unrestricted authority for other
resources or effects.
Das Expires 29 April 2027 [Page 49]
Internet-Draft Execution-Finality Part 7: Tools October 2026
3.13 — COMPLETE OPERATIONAL WORKFLOW
Step 1 — Receive User Reference
The system obtains a user instruction referencing an object,
collection position, visible item, selected region, physical target,
or equivalent entity.
Step 2 — Establish Presentation Context
The presentation collector obtains an APC identifying the relevant
interface state.
Step 3 — Bind the Reference Event
The URE is associated with the APC through the applicable input and
presentation-state procedure.
Step 4 — Construct Semantic Referent Descriptor
The SRRE creates an SRD representing the intended referent or
applicable dynamic selection predicate.
Step 5 — Resolve Candidate Entity
The semantic resolver identifies candidate computational resources.
Step 6 — Verify Entity Identity
The PEIR obtains authenticated identity, version, namespace, or other
appropriate evidence.
Step 7 — Verify Presentation-to-Entity Correspondence
The system determines whether the resolved entity satisfies the
relevant reference relationship.
Step 8 — Establish Protected Correspondence
The PSBE constructs a PSCR binding the user-reference evidence,
resolved entity, permitted operation, and designated sink.
Step 9 — Construct Candidate Act
5.1.3.25. Source page 459 of the original specification
A CAD is established for the proposed consequential operation.
Das Expires 29 April 2027 [Page 50]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The CAD references the PSCR.
Step 10 — Hold the Operation Non-Effective
The applicable effectuation boundary withholds the operation pending
required protected verification.
Step 11 — Perform Baseline Protected Authorization
The PED validates the ordinary CW-1 authority predicates.
Step 12 — Verify Temporal Continuity
The system checks applicable identity, version, and presentation-
state continuity conditions.
Step 13 — Generate Scoped Finality Authority
If required predicates pass, a scoped non-bearer authority is
generated or authorized.
The authority binds the relevant PSCR or corresponding protected
state.
Step 14 — Reconstruct Actual Pending Effect
The Finality Sink obtains an FSATD for the actual operation.
Step 15 — Independently Evaluate Correspondence
The sink verifies that the actual effect target matches the protected
semantic referent under the authorized correspondence rules.
Step 16 — Resolve Material Mismatch
If the target differs materially, the system withholds the operation.
Optional revalidation or CW-3 reauthorization may occur where
permitted.
Step 17 — Controlled Effectuation
If all required predicates pass, the sink permits the specific
authorized operation.
Step 18 — Record Relevant Outcome
The system records applicable protected outcome state.
Das Expires 29 April 2027 [Page 51]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Where independently observed actual completion is required, CW-2 may
be invoked.
3.14 — REFERENCE ALGORITHM: PRESENTATION AND REFERENCE BINDING
FUNCTION CAPTURE_USER_REFERENT( user_reference_event,
5.1.3.26. Source page 460 of the original specification
presentation_source ):
presentation = PRESENTATION_COLLECTOR.CAPTURE( presentation_source )
IF presentation IS NULL: RETURN REFERENT_UNRESOLVED
IF NOT VERIFY_PRESENTATION_PROVENANCE( presentation ): RETURN
REFERENT_UNRESOLVED
IF NOT VERIFY_REFERENCE_EVENT_CONTEXT( user_reference_event,
presentation ): RETURN REFERENT_UNRESOLVED
reference = BUILD_SEMANTIC_REFERENT_DESCRIPTOR( user_reference_event,
presentation )
IF NOT VALIDATE_REFERENCE_STRUCTURE(reference): RETURN
REFERENT_UNRESOLVED
selection_commitment = PROTECTED_REGISTRY.COMMIT_REFERENCE({
reference_event_digest: HASH(user_reference_event),
presentation_digest: HASH(presentation),
semantic_reference_digest: HASH(reference),
presentation_epoch: presentation.generation })
IF selection_commitment IS NOT COMMITTED: RETURN REFERENT_UNRESOLVED
RETURN { presentation, reference, selection_commitment }
5.1.3.27. Source page 461 of the original specification
The procedure establishes a protected reference context.
It does not presume that the corresponding physical display was
observed and understood by the user merely because it was rendered.
3.15 — REFERENCE ALGORITHM: SEMANTIC ENTITY RESOLUTION
Das Expires 29 April 2027 [Page 52]
Internet-Draft Execution-Finality Part 7: Tools October 2026
FUNCTION RESOLVE_REFERENCED_ENTITY( presentation, semantic_reference,
selection_commitment ):
candidates = SEMANTIC_RESOLVER.FIND_CANDIDATES( semantic_reference,
presentation )
IF candidates IS EMPTY: RETURN REFERENT_UNRESOLVED
verified_candidates = []
FOR candidate IN candidates:
identity = ENTITY_RESOLVER.VERIFY_IDENTITY( candidate, presentation )
IF identity IS VALID:
correspondence = VERIFY_PRESENTATION_ENTITY_RELATION( presentation,
semantic_reference, identity )
IF correspondence == PASS: verified_candidates.APPEND(identity)
IF verified_candidates IS EMPTY: RETURN REFERENT_UNRESOLVED
IF MULTIPLE_UNRESOLVED_CANDIDATES( verified_candidates ): RETURN
REQUIRE_DISAMBIGUATION
selected = SELECT_VERIFIED_ENTITY(
5.1.3.28. Source page 462 of the original specification
verified_candidates, semantic_reference )
RETURN { resolved_entity: selected, verified_reference:
selection_commitment } This procedure distinguishes candidate ranking
from protected entity-identity resolution.
A candidate with a high model confidence is not automatically
considered verified.
3.16 — REFERENCE ALGORITHM: PROTECTED CORRESPONDENCE COMMITMENT
FUNCTION COMMIT_SEMANTIC_CORRESPONDENCE( candidate_act,
verified_presentation, semantic_reference, resolved_entity,
authorized_transformation_rules ):
REQUIRE PED.VERIFY_CANDIDATE_ACT( candidate_act )
Das Expires 29 April 2027 [Page 53]
Internet-Draft Execution-Finality Part 7: Tools October 2026
REQUIRE VERIFY_PRESENTATION_REFERENCE( verified_presentation,
semantic_reference )
REQUIRE VERIFY_RESOLVED_ENTITY( resolved_entity )
REQUIRE VERIFY_AUTHORIZED_OPERATION_RELATION( candidate_act,
resolved_entity )
pscr = { candidate_digest: HASH(candidate_act),
presentation_digest: HASH(verified_presentation),
reference_digest: HASH(semantic_reference),
5.1.3.29. Source page 463 of the original specification
entity_commitment: HASH(resolved_entity),
permitted_transformations: authorized_transformation_rules,
designated_sink: candidate_act.sink_id,
protected_epoch: PED.CURRENT_AUTHORITY_EPOCH(),
nonce: PED.NEW_NONCE() }
committed = PED.ATOMIC_COMMIT_PSCR(pscr)
IF committed != SUCCESS: RETURN DENY
RETURN committed A PSCR may be maintained as a protected record or
represented by an authenticated handle.
Its use remains subject to the corresponding scoped finality
authorization.
3.17 — REFERENCE ALGORITHM: FINALITY-SINK CORRESPONDENCE
FUNCTION VERIFY_SEMANTIC_ACTUAL_EFFECT( candidate_act, pscr,
scoped_finality_authority, finality_sink ):
actual = finality_sink.RECONSTRUCT_ACTUAL_OPERATION()
IF actual IS NULL: RETURN DENY
REQUIRE finality_sink.VERIFY_SCOPED_AUTHORITY(
scoped_finality_authority, actual )
Das Expires 29 April 2027 [Page 54]
Internet-Draft Execution-Finality Part 7: Tools October 2026
REQUIRE finality_sink.VERIFY_PSCR( pscr, candidate_act )
5.1.3.30. Source page 464 of the original specification
REQUIRE VERIFY_PRESENTATION_REFERENCE_BINDING( pscr )
REQUIRE VERIFY_RESOLVED_ENTITY_BINDING( pscr )
REQUIRE VERIFY_TEMPORAL_CONTINUITY( pscr, actual )
REQUIRE VERIFY_ACTUAL_ENTITY_CORRESPONDENCE( pscr, actual )
REQUIRE VERIFY_AUTHORIZED_TRANSFORMATION( pscr, actual )
REQUIRE finality_sink.VERIFY_CURRENT_STATE()
consumption = finality_sink.ATOMIC_CONSUME(
scoped_finality_authority, pscr, actual )
IF consumption != SUCCESS: RETURN DENY
RETURN finality_sink.EFFECTUATE( actual, consumption ) The actual-
effect verification is performed under the trust assumptions of the
controlled sink.
An operation outside the sink's enforcement coverage is not
automatically protected by this procedure.
3.18 — REFERENCE ALGORITHM: TEMPORAL REBINDING
FUNCTION REVALIDATE_TEMPORAL_REFERENT( original_pscr,
current_object_evidence, proposed_operation ):
5.1.3.31. Source page 465 of the original specification
original_entity = RESOLVE_PSCR_ENTITY( original_pscr )
current_entity = VERIFY_CURRENT_ENTITY( current_object_evidence )
IF current_entity IS UNKNOWN: RETURN REQUIRE_REVALIDATION
IF SAME_AUTHENTICATED_ENTITY( original_entity, current_entity ):
IF REQUIRED_VERSION_CONSTRAINTS_PASS( original_pscr, current_entity
): RETURN REFERENT_CONTINUITY_VALID
transformation = FIND_AUTHORIZED_TRANSFORMATION( original_pscr,
original_entity, current_entity )
Das Expires 29 April 2027 [Page 55]
Internet-Draft Execution-Finality Part 7: Tools October 2026
IF transformation IS NOT NULL:
IF VERIFY_TRANSFORMATION_EVIDENCE( transformation ): RETURN
REFERENT_CONTINUITY_VALID
RETURN SEMANTIC_MISMATCH The procedure permits authorized
transformations without treating every appearance or identifier
change as automatically equivalent.
3.19 — PROTECTED CORRESPONDENCE STATE MACHINE
3.19.1 — Initial State
A proposed user reference begins in REFERENCE_RECEIVED state.
The system has received an instruction but has not established an
authenticated referent.
3.19.2 — Presentation-Context State
The system enters PRESENTATION_CONTEXT_BOUND after obtaining
sufficient APC evidence.
5.1.3.32. Source page 466 of the original specification
3.19.3 — Semantic Candidate State
The system enters REFERENT_CANDIDATES_IDENTIFIED after generating
possible semantic referents.
This state does not establish final authority.
3.19.4 — Entity-Verified State
The system enters ENTITY_IDENTITY_VERIFIED when a selected resource
identity is authenticated according to applicable rules.
3.19.5 — Correspondence-Committed State
The system enters SEMANTIC_CORRESPONDENCE_COMMITTED after the PSCR is
committed.
3.19.6 — Candidate Act Held State
The consequential operation remains non-effective.
3.19.7 — Temporal Validation State
Das Expires 29 April 2027 [Page 56]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The system checks whether the referent remains valid under the
applicable current state.
3.19.8 — Sink Verification State
The Finality Sink reconstructs the actual pending operation and
evaluates the correspondence predicates.
3.19.9 — Permitted Effect State
Where all mandatory predicates pass, the operation may be released
through the authorized sink.
3.19.10 — Mismatch State
Where material correspondence fails, the operation is withheld.
3.19.11 — Uncertainty State
Where evidence is insufficient, the operation is deferred or denied
according to the protected policy.
3.19.12 — Reauthorization State
Where applicable, the system may invoke a trusted user clarification
or CW-3 scope-delta procedure.
A new authorization refers to the newly established target rather
than silently modifying the earlier protected correspondence.
3.19.13 — Completion State
Following permitted effectuation, protected completion or attempt
evidence may be recorded.
5.1.3.33. Source page 467 of the original specification
The system does not infer remote or physical completion merely from
successful local dispatch.
3.20 — WORKED EXAMPLE A: THE THIRD EMAIL
3.20.1 — Original Screen
A user opens an email application displaying a list of messages.
The list contains five visible messages.
Das Expires 29 April 2027 [Page 57]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The third visible message is identified internally as Message M-203.
The interface displays that message at position three during
presentation generation G-71.
3.20.2 — User Instruction
The user states:
"Delete the third email."
The system obtains the URE and APC.
The APC identifies the relevant list, generation G-71, and
authenticated object relationship between the third displayed item
and M-203.
3.20.3 — Semantic Resolution
The semantic resolver interprets "third email" as the object at
ordinal position three within the relevant authenticated list
presentation.
The PEIR verifies that the corresponding object is M-203.
A PSCR is committed for deletion of M-203.
3.20.4 — Interface Change
Before effectuation, another email arrives.
The application automatically changes the list order.
M-203 moves to position four.
A different message now occupies position three.
3.20.5 — Incorrect Conventional Action
A coordinate-based agent might click the delete control corresponding
to the current third row.
Such an operation could target a different email.
3.20.6 — Protected Finality Verification
The actual email-deletion dispatcher exposes the target message
identifier.
Das Expires 29 April 2027 [Page 58]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.1.3.34. Source page 468 of the original specification
The Finality Sink reconstructs the pending deletion operation.
If the operation targets the new third-row email rather than M-203,
the sink detects a mismatch with the PSCR.
The operation is refused.
3.20.7 — Authorized Continuation
The agent may reconstruct an operation targeting M-203 directly,
provided the original authorization still applies and current
required state conditions remain valid.
The sink then verifies the corrected actual target.
3.20.8 — Technical Effect
The system preserves the identity of the user's originally referenced
email despite changes in its visual position.
The protection concerns the actual delete effect, not merely improved
accuracy of a screen click.
3.21 — WORKED EXAMPLE B: TWO DOCUMENTS WITH THE SAME NAME
3.21.1 — Scenario
A file-management application displays two documents named "Budget
Report."
One document belongs to the current working folder.
The other belongs to an archived folder.
The user selects the first document and instructs the assistant to
send it to a designated recipient.
3.21.2 — Reference Evidence
The system records the user selection and corresponding authenticated
document identity.
The selected object is bound to its protected resource namespace and
version.
Das Expires 29 April 2027 [Page 59]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The human-readable filename is retained as contextual evidence but
does not serve as the sole identity criterion.
3.21.3 — Agent Resolution Error
The assistant resolves the request to the archived document because
the two files have identical names.
The assistant prepares a transmission using the archived resource
identifier.
3.21.4 — Finality Sink Reconstruction
5.1.3.35. Source page 469 of the original specification
The transmission sink obtains the actual file object and destination
from its controlled outgoing operation.
It compares the actual resource identity with the PSCR.
The archived document does not satisfy the required identity
relationship.
3.21.5 — Result
The transmission is withheld.
Where policy allows, the agent may correct the target selection or
request user clarification.
A new authorization is required if the intended object itself
changes.
3.21.6 — Technical Effect
The system prevents a filename-based semantic error from becoming an
unauthorized external disclosure.
3.22 — WORKED EXAMPLE C: PAYMENT RECIPIENT SUBSTITUTION
3.22.1 — Original Request
A user views an invoice and instructs the assistant to pay the
displayed supplier.
The invoice interface shows a supplier name and payment amount.
Das Expires 29 April 2027 [Page 60]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The actual payment destination is represented by a financial account
identifier.
3.22.2 — Protected Referent Binding
The system obtains suitable presentation evidence.
The supplier reference is resolved to an authenticated payment-
recipient identity and permitted payment details.
A PSCR is committed for the specified payment operation.
3.22.3 — Intervening Change
Before payment submission, an application component substitutes a
different account identifier while preserving the same displayed
supplier name.
3.22.4 — Actual Sink Verification
The payment Finality Sink reconstructs the actual destination account
and payment parameters.
The sink compares the result with the protected recipient identity
and authorized operation.
If the substituted destination falls outside the permitted scope, the
sink refuses payment.
5.1.3.36. Source page 470 of the original specification
3.22.5 — Human Reauthorization
A user may be permitted to authorize a genuinely changed payment
destination under the applicable protected policy.
Such authorization requires a trusted description of the new account
and a new scoped authority.
The original payment authorization is not silently applied to the
substituted account.
3.22.6 — Technical Effect
The architecture separates a human-readable supplier representation
from the actual payment destination and requires protected
correspondence at the consequential transaction boundary.
Das Expires 29 April 2027 [Page 61]
Internet-Draft Execution-Finality Part 7: Tools October 2026
3.23 — WORKED EXAMPLE D: CROSS-APPLICATION CONTENT TRANSFER
3.23.1 — Scenario
A user selects a photograph in a gallery application and instructs an
assistant:
"Send this picture to my family group."
The selected photograph is represented by a gallery-specific object
identifier.
The messaging application may use a different object representation
after import.
3.23.2 — Original Reference
The system binds the selected photograph to its authenticated gallery
identity and the relevant user-reference event.
3.23.3 — Authorized Transformation
The transfer process may convert the photograph into a transport
representation.
An AST identifies the permitted transformation and corresponding
output properties.
3.23.4 — Resulting Resource
The receiving application constructs an outgoing message attachment.
The attachment may have a new local object identifier.
The system does not require identifier equality if the authenticated
transfer evidence establishes an authorized correspondence.
3.23.5 — Sink Verification
The messaging Finality Sink verifies that the actual outgoing
attachment satisfies the authorized transformation and that the
destination is the selected family group.
If the attachment is replaced with an unrelated photograph, the
operation is refused.
Das Expires 29 April 2027 [Page 62]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.1.3.37. Source page 471 of the original specification
3.23.6 — Technical Effect
The mechanism supports legitimate cross-application resource
transformations without allowing arbitrary substitution of
transferred content.
3.24 — WORKED EXAMPLE E: VISUAL OVERLAY AND FOREGROUND CHANGE
3.24.1 — Scenario
A computer-use agent observes a screen containing a harmless
application action.
The agent prepares a touch or click.
Before dispatch, another application becomes foreground or an overlay
changes the target under the selected coordinate.
3.24.2 — Protected Presentation Reference
The original reference is bound to an authenticated presentation
context identifying the expected application surface and selected
target.
3.24.3 — State Change
The foreground application or target identity changes before action
dispatch.
3.24.4 — Protected Verification
The in-line validator or final controlled dispatcher obtains the
actual destination of the input event.
It compares the current target and operation with the authorized
presentation-bound referent.
If the input would affect a different application resource, the event
is withheld or requires a new authorized selection.
3.24.5 — Important Enforcement Condition
A screenshot comparison alone may detect some visual changes but
cannot necessarily establish the actual application effect.
Das Expires 29 April 2027 [Page 63]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The implementation must obtain sufficiently trustworthy target or
effectuation evidence for the claimed correspondence guarantee.
3.24.6 — Technical Effect
The system may prevent a stale visual action from being rebound to a
materially different consequential target where the actual event-
dispatch boundary is controlled.
3.25 — WORKED EXAMPLE F: DYNAMICALLY SELECTED APPROVED REPORT
3.25.1 — Scenario
5.1.3.38. Source page 472 of the original specification
A user instructs an assistant:
"Send the latest approved financial report."
The instruction is not necessarily a reference to one fixed file
version.
It may instead authorize selection of a resource satisfying a defined
current-state predicate.
3.25.2 — Dynamic Referent Predicate
The protected semantic reference identifies:
• Authorized report repository;
• Report class;
• Required approved status;
• Applicable version ordering;
• Permitted recipient;
• Required effectuation boundary.
3.25.3 — Current Resource Resolution
The agent selects an apparent latest report.
The protected resolver evaluates the authenticated report state.
3.25.4 — Intervening Update
Das Expires 29 April 2027 [Page 64]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A newer report becomes approved before the transmission operation.
Whether the earlier selected report remains valid depends upon the
exact authorized semantics.
If the operation requires the latest approved report at effectuation
time, the system may need to update the selected resource under a
properly validated dynamic predicate.
If the original selection was explicitly confirmed as a fixed
version, that fixed version may remain the authorized object.
3.25.5 — Finality Sink Verification
The sink evaluates the actual selected report against the applicable
dynamic or fixed-reference predicate.
An agent cannot substitute an arbitrary report merely because it
claims the new report is more appropriate.
3.25.6 — Technical Effect
The system distinguishes stable entity identity from intentionally
dynamic referential semantics.
5.1.3.39. Source page 473 of the original specification
It preserves the user's authorized meaning rather than enforcing an
unnecessarily rigid rule that every reference must bind permanently
to an initial object version.
3.26 — ADVERSARIAL THREAT MODEL
3.26.1 — Screenshot Substitution
An attacker supplies a screenshot that does not correspond to the
current trusted display state.
The system verifies presentation provenance or requires additional
authenticated evidence.
3.26.2 — Foreground-Window Rebinding
An attacker changes the foreground application after the agent
observes the screen.
The actual dispatcher or sink verifies the current target against the
protected reference.
Das Expires 29 April 2027 [Page 65]
Internet-Draft Execution-Finality Part 7: Tools October 2026
3.26.3 — Notification Overlay Hijack
An attacker inserts an overlay near the intended target.
The system may detect the changed presentation context or refuse an
operation whose actual target no longer matches the authorized
referent.
3.26.4 — Accessibility Metadata Spoofing
A component supplies incorrect accessibility labels or identifiers.
The system evaluates source assurance and uses independently
trustworthy object evidence where required.
3.26.5 — Structurally Invisible Resource Substitution
A malicious component changes an underlying operation target without
a detectable visual change.
The actual effectuation sink checks the operative resource identifier
and version rather than relying solely upon screen appearance.
3.26.6 — Duplicate Display Names
An attacker creates an object with the same visible name as an
authorized resource.
The system distinguishes objects using appropriate authenticated
identity information.
3.26.7 — Virtualized-List Row Reuse
A list implementation recycles a view to represent a different
object.
The original referent remains bound to the appropriate object
identity rather than to the recycled view instance.
3.26.8 — List Reordering
5.1.3.40. Source page 474 of the original specification
A new item changes the ordinal position of an originally referenced
item.
The system preserves the correct original relationship or reevaluates
an expressly dynamic selector.
Das Expires 29 April 2027 [Page 66]
Internet-Draft Execution-Finality Part 7: Tools October 2026
3.26.9 — Object Deletion and Recreation
An object is deleted and recreated with an identical label.
The system may detect the changed generation or identity and reject
unauthorized substitution.
3.26.10 — Cross-App Transfer Substitution
An intermediary replaces the exported object with another resource.
The system verifies the authenticated transfer relationship and
actual outgoing object.
3.26.11 — Recipient Substitution
An attacker changes the actual external recipient.
The sink verifies the actual destination against the authorized
operation.
3.26.12 — Agent Semantic Hallucination
The agent confidently identifies the wrong object.
The protected mechanism requires evidence-supported entity
correspondence rather than confidence alone.
3.26.13 — Prompt Injection
Untrusted content instructs the agent to select another object or
reinterpret the user's request.
The protected reference and finality constraints remain independent
of the injected instructions.
3.26.14 — Display-State Rollback
An attacker attempts to reuse an old presentation state as if it were
current.
The system checks relevant protected epochs, versions, and reference
validity.
3.26.15 — Identity-Alias Manipulation
A malicious resource owner or intermediary asserts that two unrelated
objects are equivalent.
Das Expires 29 April 2027 [Page 67]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The protected resolver requires acceptable authenticated evidence
under the applicable alias policy.
3.26.16 — Version Substitution
An agent is authorized to modify one version but attempts to affect
another.
The sink checks the required version or permitted version
relationship.
3.26.17 — Semantic Transformation Abuse
5.1.3.41. Source page 475 of the original specification
An attacker invokes an alleged conversion that materially alters
protected content.
The permitted transformation is evaluated against its defined
technical constraints.
3.26.18 — Approval-Target Mismatch
A user approves an operation involving one displayed object, but the
actual operation targets another.
The sink verifies the operation against the authenticated approval
and semantic correspondence.
3.26.19 — Compromised Agent Runtime
The agent changes its plan after the referent was committed.
The Finality Sink checks the actual operation independently of the
changed plan.
3.26.20 — Compromised Presentation Source
The source application supplies misleading presentation or identity
information.
The system's guarantees depend upon independently trustworthy
evidence and authenticated enforcement.
Where such evidence is unavailable, the claimed protected
correspondence may not be established.
3.26.21 — Device-State Change
Das Expires 29 April 2027 [Page 68]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The device rotates, changes display scale, switches windows, or
changes input focus.
The system evaluates whether the authorized object correspondence
remains valid.
3.26.22 — Multi-Display Ambiguity
Several displays contain similar objects.
The APC identifies the applicable display and interaction context.
3.26.23 — Remote Desktop Staleness
A remote graphical session presents a delayed view of resource state.
The system verifies whether the actual remote operation matches the
referenced object under the applicable consistency rules.
3.26.24 — Unauthorized Recovery Click
An agent attempts to recover from a failed action by clicking a
different control.
The new consequential operation requires applicable reference and
finality verification.
3.26.25 — Physical-Target Substitution
5.1.3.42. Source page 476 of the original specification
A sensor-observed target changes before actuation.
The system may require independent current-state target verification
through the applicable physical effectuation interface.
The specific physical-scene mechanism may be developed further in the
dedicated physical-target embodiment.
3.27 — FAILURE AND RECOVERY HANDLING
3.27.1 — Missing Presentation Evidence
If a required APC cannot be established, the affected operation
remains withheld or requires alternative authenticated reference
evidence.
3.27.2 — Missing Entity Identity
Das Expires 29 April 2027 [Page 69]
Internet-Draft Execution-Finality Part 7: Tools October 2026
If an object cannot be resolved with sufficient certainty, the system
may request user clarification.
3.27.3 — Invalid Entity Annotation
An unauthenticated or inconsistent entity annotation does not
establish protected correspondence.
3.27.4 — Presentation-State Change
A changed interface does not automatically invalidate every
operation.
The system evaluates whether the specific protected referent and
effect predicates remain satisfied.
3.27.5 — Material Object Change
If the relevant underlying object or version changes outside the
permitted semantics, revalidation or new authorization is required.
3.27.6 — Sink Reconstruction Failure
Where the sink cannot determine the required actual target, the
effect is withheld.
3.27.7 — Protected Commitment Failure
If PSCR commitment fails, corresponding protected semantic authority
is not assumed to exist.
3.27.8 — Crash Before Effectuation
The system may recover the reference and authorization state, subject
to protected freshness and validity requirements.
3.27.9 — Crash During Effectuation
The actual outcome is treated according to the applicable CW-1 or
CW-2 outcome-reconciliation rules.
5.1.3.43. Source page 477 of the original specification
3.27.10 — Incorrect Effect Already Occurred
A later correspondence failure does not retroactively undo an
external effect.
Das Expires 29 April 2027 [Page 70]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The system may revoke remaining authority, record available evidence,
and initiate an independently authorized recovery procedure where
appropriate.
3.27.11 — Unrelated Operations
An unresolved semantic reference need not suspend unrelated
authorized operations where they do not depend upon the uncertain
target.
3.27.12 — Safe Reauthorization
Where user clarification changes the intended object, the system
establishes a new protected reference and corresponding scoped
authority.
The original authorization is not silently expanded to cover the new
object.
3.28 — FORMAL CORRESPONDENCE PROPERTIES
The following non-limiting properties may be imposed by selected
implementations.
Property S1 — Reference Context Integrity
A protected user-reference event is bound to the authenticated
presentation context used for resolution.
Property S2 — Entity Resolution Integrity
A selected computational entity must satisfy the authenticated
semantic relationship established for the user reference.
Property S3 — Actual-Target Binding
The actual object reaching the Finality Sink must satisfy the
protected referent identity or an expressly permitted transformation.
Property S4 — Temporal Validity
Required correspondence predicates remain valid at the applicable
effectuation boundary.
Property S5 — No Coordinate Authority
A screen coordinate alone does not authorize a consequential
operation against an arbitrary resource located at that coordinate.
Das Expires 29 April 2027 [Page 71]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Property S6 — No Name-Only Identity
A human-readable label alone does not establish object identity where
the applicable operation requires stronger differentiation.
5.1.3.44. Source page 478 of the original specification
Property S7 — Transformation Confinement
Cross-application or format transformations are accepted only within
authenticated permitted correspondence conditions.
Property S8 — Non-Bearer Finality Authority
Possession of a PSCR alone does not authorize an unrelated
consequential operation.
Property S9 — Failure Containment
An unresolved required correspondence prevents the affected
unauthorized effect.
Property S10 — No False Perception Claim
Authenticated display or selection evidence is not represented as
definitive proof of subjective human perception without an
independently supported basis.
3.29 — NON-LIMITING PROTOTYPE IMPLEMENTATION
3.29.1 — Prototype Architecture
A reference implementation may comprise:
1. A test application displaying multiple resource objects;
2. A trusted or experimentally simulated presentation-state
collector;
3. A user-reference capture component;
4. A semantic resolver;
5. An authenticated entity-identity registry;
6. A protected correspondence-state service;
7. A Candidate Act constructor;
Das Expires 29 April 2027 [Page 72]
Internet-Draft Execution-Finality Part 7: Tools October 2026
8. A protected authorization service;
9. A controlled storage or message-effectuation gateway;
10. A Finality Sink verifier;
11. A fault and interface-mutation test harness.
The initial implementation may use software isolation to validate
protocol logic.
A hardware-backed implementation may place protected state and
critical enforcement components within appropriate independently
protected substrates.
3.29.2 — Representative Resource Model
5.1.3.45. Source page 479 of the original specification
The test application may maintain objects identified by immutable
resource identifiers and separate mutable display labels.
Each object may contain:
• Resource identifier;
• Display name;
• Current version;
• Owner namespace;
• Current list position;
• Presentation generation;
• Content commitment.
The display order may change without changing the underlying resource
identities.
3.29.3 — Reference Capture
A user or test harness selects an object through touch, text, or
relative ordinal reference.
The system records the reference and presentation generation.
Das Expires 29 April 2027 [Page 73]
Internet-Draft Execution-Finality Part 7: Tools October 2026
3.29.4 — Semantic Binding
The resolver identifies the appropriate resource and commits a PSCR.
3.29.5 — Interface Mutation
The test harness may insert objects, reorder lists, replace windows,
change labels, modify resource versions, or alter actual dispatch
arguments.
3.29.6 — Sink Verification
The controlled sink compares the actual pending operation with the
PSCR.
The experiment records whether the operation was accepted or denied.
3.29.7 — Protection Scope
A software prototype may demonstrate reference continuity, target
mismatch detection, and scoped authority enforcement within the
implemented controlled gateway.
It does not establish immunity to a fully compromised operating
system unless the required independent enforcement mechanisms are
present.
3.30 — NON-LIMITING FEASIBILITY EXPERIMENTS
5.1.3.46. Source page 480 of the original specification
The following experiments are proposed. They are not statements that
testing has already been performed.
Experiment 1 — List Reordering
Authorize an operation against an item identified by its ordinal
position.
Change the list order before effectuation.
Verify that the actual sink does not accept an unauthorized
substitute target.
Experiment 2 — Duplicate Labels
Display two resources with identical visible labels.
Das Expires 29 April 2027 [Page 74]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Bind a user selection to one resource.
Attempt to affect the other resource.
Verify rejection under the required identity predicate.
Experiment 3 — Foreground Switching
Capture a reference in one application.
Switch the foreground application before the agent action is
dispatched.
Verify that the actual controlled action target remains bound to the
authorized reference.
Experiment 4 — Notification Overlay
Introduce an overlay after reference capture.
Verify that a changed target cannot be authorized solely by the
original coordinate.
Experiment 5 — Structural Metadata Manipulation
Provide incorrect entity annotations.
Verify that the protected resolver rejects or appropriately
downgrades untrusted metadata where independent correspondence is
required.
Experiment 6 — Invisible Backend Substitution
Keep the rendered display unchanged while modifying the underlying
resource identifier supplied to the actual dispatch.
Verify that the Finality Sink detects the mismatch.
Experiment 7 — Object Deletion and Recreation
Delete the original resource and create a new resource with the same
display name.
5.1.3.47. Source page 481 of the original specification
Verify that the new resource is not accepted as identical unless the
applicable authorized identity rules permit it.
Das Expires 29 April 2027 [Page 75]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Experiment 8 — Legitimate Format Conversion
Transfer an authorized document between applications using a
permitted representation conversion.
Verify that the protected correspondence procedure accepts the
authorized transformation.
Experiment 9 — Unauthorized Content Replacement
Replace the converted object with unrelated content.
Verify that the relevant transformation or content correspondence
predicate fails.
Experiment 10 — Dynamic Latest-Object Reference
Authorize selection of the latest approved resource.
Change the approved-resource set before effectuation.
Verify that the actual selected resource satisfies the authorized
dynamic predicate.
Experiment 11 — Version-Specific Authorization
Authorize operation on one object version.
Substitute a different version.
Verify rejection where exact version correspondence is required.
Experiment 12 — Cross-Application Resource Transfer
Transfer an object through two application-specific namespaces.
Verify that authenticated alias or transformation evidence supports
the correct object without treating unrelated aliases as equivalent.
Experiment 13 — Agent Hallucination
Cause the semantic resolver to select a high-confidence incorrect
object.
Verify that confidence alone cannot override a failed mandatory
entity-correspondence predicate.
Experiment 14 — Prompt Injection
Das Expires 29 April 2027 [Page 76]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Insert instructions into displayed or retrieved content directing the
agent to target a different resource.
Verify that the final effect remains constrained by the protected
original reference.
Experiment 15 — Post-Validation Target Substitution
5.1.3.48. Source page 482 of the original specification
Change the actual operation parameters after semantic correspondence
validation.
Verify that the Finality Sink detects the changed target.
Experiment 16 — Missing Trusted Evidence
Remove the authenticated resource-identity source.
Verify that the system does not falsely claim verified
correspondence.
Experiment 17 — User Clarification
Present an ambiguous reference.
Obtain a trusted user selection.
Verify that a new protected referent and corresponding finality
authority are created.
Experiment 18 — Crash Recovery
Terminate the agent after PSCR commitment but before effectuation.
Restore the process and verify that protected reference and authority
freshness are respected.
Experiment 19 — Alternate Effectuation Route
Attempt the same operation through a secondary covered application
interface.
Verify that the actual consequential boundary requires appropriate
semantic correspondence evidence.
Experiment 20 — Combined CW-2 Validation
Das Expires 29 April 2027 [Page 77]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Validate a target before an earlier phase, observe the resulting
effect, and authorize a successor operation.
Verify that the successor remains bound to the appropriate actual
resource state.
Experiment 21 — Combined CW-3 Scope Deviation
Cause a resolved target to move outside the original authorized
resource scope.
Verify that the affected operation is withheld pending valid
reauthorization or denial.
Experiment 22 — Compatible Visual Change
Change unrelated screen regions while preserving the authenticated
referenced object and operation.
Verify that the system can allow a valid operation without
unnecessarily rejecting every harmless presentation change.
3.31 — TECHNICAL MEASUREMENTS
5.1.3.49. Source page 483 of the original specification
The embodiment may be evaluated using:
• Unauthorized target-substitution acceptance rate;
• Semantic misbinding detection rate;
• Stable-reference continuity accuracy;
• Incorrect resource-version acceptance rate;
• False rejection of valid object transformations;
• Ambiguous-reference escalation frequency;
• Unauthorized coordinate-action acceptance rate;
• Cross-application identity-resolution correctness;
• Protected target-reconstruction latency;
• Semantic verification overhead;
Das Expires 29 April 2027 [Page 78]
Internet-Draft Execution-Finality Part 7: Tools October 2026
• Additional protected-state storage;
• Interface mutation handling;
• Recovery-state integrity;
• User clarification frequency;
• Valid autonomous completion rate;
• Effectuation throughput;
• Privacy exposure from retained presentation evidence.
Measurements should distinguish model resolution accuracy from
independently verified effectuation-target correctness.
A model may identify the correct object frequently while still
lacking a non-bypassable enforcement guarantee.
Conversely, a secure enforcement system may reliably refuse
unverified operations but require additional engineering to reduce
unnecessary denials.
Both dimensions are relevant to practical implementation.
3.32 — IMPLEMENTATION VARIANTS
Variant 3.A — Structured Application Entity Binding
Authenticated application entities provide presentation-to-resource
correspondence.
Variant 3.B — Trusted Compositor Evidence
5.1.3.50. Source page 484 of the original specification
A protected compositor supplies relevant presentation-state
information.
Variant 3.C — Accessibility-Assisted Reference Binding
Accessibility metadata assists semantic resolution, subject to
source-authentication and consistency requirements.
Variant 3.D — Pixel-Assisted Resolution
Computer vision identifies candidate objects from screen content.
Das Expires 29 April 2027 [Page 79]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Final authority remains subject to the required protected
correspondence.
Variant 3.E — Multi-Evidence Correspondence
Visual, structural, and protected resource evidence are jointly
evaluated.
Variant 3.F — Trusted Selection Capture
A protected input event binds a user's selected object to an
authenticated presentation context.
Variant 3.G — Voice Reference Binding
A spoken instruction is associated with a relevant protected display
or application context.
Variant 3.H — Touch and Gesture Binding
Touch, pointer, or gesture input is bound to the applicable object
identity.
Variant 3.I — Spatial Referent Binding
A physical or spatial object reference is associated with
authenticated spatial context.
Variant 3.J — Stable Object Identity
The original selected object remains the authorized target despite
layout changes.
Variant 3.K — Dynamic Predicate Authorization
The user intentionally authorizes an object selected through a
protected current-state predicate.
Variant 3.L — Version-Sensitive Correspondence
The operation is limited to a particular authenticated object
version.
Variant 3.M — Authenticated Alias Mapping
Different application identifiers are mapped to the same resource
under trusted equivalence rules.
Das Expires 29 April 2027 [Page 80]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Variant 3.N — Authorized Format Transformation
A resource conversion is permitted under a bounded semantic and
content correspondence predicate.
5.1.3.51. Source page 485 of the original specification
Variant 3.O — Sink-Integrated Correspondence Verification
The Finality Sink evaluates the required semantic correspondence
directly.
Variant 3.P — Independent In-Line Validator
A separately protected IEV verifies the actual target immediately
before effectuation.
Variant 3.Q — No Separate IEV
The applicable sink performs the correspondence check using
sufficient protected evidence.
Variant 3.R — Trusted User Clarification
An ambiguous or changed target requires authenticated user selection.
Variant 3.S — Automatic Referent Revalidation
A protected resolver verifies that a changed representation remains
the same authorized entity.
Variant 3.T — Scope-Deviation Escalation
CW-3 is invoked when the target change requires genuinely new
authority.
Variant 3.U — Cross-Device Presentation Context
A reference established on one device is authenticated for an
operation performed on another device.
Variant 3.V — Remote Application Interface
The actual target is reconstructed at a controlled remote application
or service-effectuation boundary.
Variant 3.W — Privacy-Minimized Presentation Commitment
Das Expires 29 April 2027 [Page 81]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The system retains only the presentation evidence necessary for
verification.
Variant 3.X — Controller-Owned Command Binding
A protected controller holds the actual validated command until
effectuation.
Variant 3.Y — Immutable Referent Handle
A sealed, scoped handle binds the referenced entity to the permitted
effectuation target.
Variant 3.Z — Software Feasibility Implementation
A controlled software gateway demonstrates semantic binding and
mismatch rejection under a defined software trust model.
The variants may be combined where technically compatible.
5.1.3.52. Source page 486 of the original specification
3.33 — DISTINCTION FROM CONVENTIONAL TECHNOLOGIES
3.33.1 — Conventional Object Recognition
Computer vision may identify a visible object.
The present embodiment does not characterize object recognition
itself as newly invented.
The proposed technical distinction concerns whether the actual
consequential operation is independently verified to affect the
object established by the protected user reference.
3.33.2 — Conventional GUI Grounding
GUI grounding maps an instruction to screen coordinates or interface
elements.
The present embodiment additionally defines protected correspondence
between the user-reference context, verified underlying entity, and
actual effectuation target.
A successful coordinate prediction is not automatically execution
authority.
3.33.3 — Conventional Semantic Entity Resolution
Das Expires 29 April 2027 [Page 82]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Application frameworks may map natural-language references to
structured entities.
The present embodiment does not claim that entity resolution itself
is a new invention.
The proposed additional feature is the protected enforcement of the
resolved entity's correspondence with the actual object reaching
effectuation, under appropriate temporal and transformation
constraints.
3.33.4 — Conventional Screenshot Rechecking
A system may compare screenshots before executing a click.
Such comparison can identify some visual changes.
However, visual similarity does not necessarily establish that the
underlying application resource or operation remains unchanged.
The proposed mechanism evaluates authenticated resource identity and
actual effectuation parameters where technically available.
3.33.5 — Conventional Accessibility Actions
Accessibility services may identify and invoke structured UI
operations.
The present embodiment introduces additional protected authorization
binding where the actual consequential operation must correspond to a
user-referenced object under an independently enforced scope.
3.33.6 — Conventional Optimistic Concurrency Control
5.1.3.53. Source page 487 of the original specification
An application may use resource versions to reject stale writes.
The present embodiment may use such version checks as supporting
mechanisms.
The potential contribution concerns their integration into a
protected user-reference-to-actual-effect correspondence protocol
spanning presentation, semantic resolution, and consequence
enforcement.
3.33.7 — Conventional User Confirmation
Das Expires 29 April 2027 [Page 83]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A user may confirm an operation in a dialog.
The present embodiment does not presume that displaying a
confirmation dialog establishes the identity of the actual
effectuation target.
A secure implementation binds the displayed or selected referent to
the actual operation verified at the controlled sink.
3.33.8 — Conventional Audit Trails
An audit system may record which object an agent intended to modify.
The present embodiment requires applicable correspondence to be
verified before the controlled consequence is permitted.
A post-event log alone does not provide that prevention property.
3.34 — PROPOSED INVENTIVE-STEP FOCUS
The technical contribution should be evaluated against the closest
relevant prior art, including prior disclosures concerning on-screen
entity resolution, UI action rebinding, pre-execution state
verification, protected execution gateways, and action-bound
authorization.
The proposed claim should not rely solely upon the general
proposition that an agent may act on the wrong UI element.
That problem and multiple defensive approaches are already known.
A more specific potential inventive concept may require:
First, an authenticated presentation reference identifying the user-
referenced object or authorized dynamic selection predicate.
Second, a verified presentation-to-computational-entity relationship.
Third, a protected correspondence commitment binding the resolved
entity and intended consequential operation.
Fourth, independent reconstruction of the actual resource and
operation at the designated Finality Sink.
Fifth, sink-enforced verification that the actual operation satisfies
the protected correspondence, including applicable resource identity,
temporal continuity, and authorized transformation predicates.
Das Expires 29 April 2027 [Page 84]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.1.3.54. Source page 488 of the original specification
Sixth, withholding of effectuation when the required relationship
cannot be established.
Where the closest prior art already discloses one or more of these
features, the claimed technical contribution must be narrowed to the
particular additional mechanism and resulting technical effect not
made obvious by that art.
3.34.1 — Candidate Objective Technical Problem
An illustrative objective technical problem is:
How to prevent an autonomous computing system from producing a
consequential effect against a resource that differs from the
resource established by a user's authenticated reference context,
including where presentation state, computational entity identity,
and actual effectuation parameters change or differ across time and
application boundaries.
3.34.2 — Specific Technical Effect
A properly implemented mechanism may prevent a semantically
misresolved or substituted target from being accepted by a protected
effectuation boundary even when the agent itself believes the target
is correct.
3.34.3 — Non-Obviousness Qualification
The use of known object identifiers, hashes, timestamps, version
numbers, entity annotations, and finality capabilities does not
automatically establish inventive step.
The claim must identify the specific enforced relationship and
technical arrangement responsible for an improvement beyond the
closest prior art.
The novelty and inventive step of that arrangement remain subject to
examination.
3.35 — SUPPORT FOR POTENTIAL CLAIMED SUBJECT MATTER
The present embodiment provides technical support for considering
claims directed to:
Aspect 1: Authenticated binding of a user-reference event to a
presentation context.
Das Expires 29 April 2027 [Page 85]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Aspect 2: Construction of a protected semantic referent descriptor.
Aspect 3: Verification of presentation-to-resource entity
correspondence.
Aspect 4: Use of an authenticated presentation generation or temporal
reference epoch.
Aspect 5: Protected object-identity or version continuity.
Aspect 6: Construction of a protected semantic correspondence
commitment.
Aspect 7: Binding of the correspondence commitment to a specific
consequential operation.
Aspect 8: Binding of the correspondence commitment to a designated
Finality Sink.
Aspect 9: Independent sink-local reconstruction of the actual pending
resource and operation.
5.1.3.55. Source page 489 of the original specification
Aspect 10: Verification of actual target identity against the
protected user referent.
Aspect 11: Rejection of coordinate-based or display-position
substitution.
Aspect 12: Verification of permitted dynamic reference predicates.
Aspect 13: Authenticated cross-application entity alias mapping.
Aspect 14: Verification of bounded semantic or format
transformations.
Aspect 15: Protected handling of object deletion and recreation.
Aspect 16: Protected handling of resource-version changes.
Aspect 17: Independent reconciliation of visual and structural
interface evidence.
Aspect 18: Prevention of operation substitution after semantic
validation.
Aspect 19: Protected single-use authority consumption.
Das Expires 29 April 2027 [Page 86]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Aspect 20: Fail-closed operation withholding when required semantic
correspondence is unresolved.
Aspect 21: Optional in-line IEV verification.
Aspect 22: Optional CW-3 reauthorization of a changed target.
Aspect 23: Privacy-minimized presentation evidence retention.
Aspect 24: Cross-device protected referent continuity.
Aspect 25: Remote application sink verification of a locally
referenced object.
Aspect 26: Trusted selection binding involving voice, touch, gesture,
or equivalent input.
Aspect 27: Protected correspondence to a physical or spatial target.
Aspect 28: Integration with outcome-dependent phased execution.
Aspect 29: Controlled multi-agent use of a shared protected
reference.
Aspect 30: Protected correspondence verification against actual
effectuation parameters rather than agent-generated object
descriptions alone.
These aspects may support independent or dependent claims when the
required inventive step, enablement, subject-matter eligibility, and
other applicable requirements are satisfied.
3.36 — RELATIONSHIP TO OTHER EMBODIMENTS
Embodiment 1 concerns protected arbitration among independently
authorized Candidate Acts whose combined effects may conflict.
Embodiment 2 concerns independent pre-effect or inter-phase
validation and protected continuation authority.
5.1.3.56. Source page 490 of the original specification
Embodiment 3 concerns the correspondence between a user-referenced
object, resolved computational entity, and actual consequential
target.
The mechanisms may operate independently.
Das Expires 29 April 2027 [Page 87]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Where combined, Embodiment 3 may establish that the correct resource
has been selected, while Embodiment 1 establishes that affecting the
resource is compatible with other pending operations.
Embodiment 2 may additionally establish that an earlier required
operation produced the necessary verified outcome before the selected
resource is used in a subsequent phase.
CW-3 may be invoked where the selected or substituted target
represents a potential departure from the original authorized task
scope.
A successful conflict reservation does not establish semantic
correctness.
A valid semantic correspondence does not establish conflict
compatibility.
A valid effect receipt does not automatically authorize a different
target.
The applicable protected system may combine these independently
required predicates before Finality Sink release.
3.37 — INDUSTRIAL APPLICABILITY
The disclosed architecture may be used in computing systems where
users refer to objects through an interface and autonomous agents
perform consequential operations on corresponding resources.
Illustrative application areas include:
Personal AI assistants;
Mobile operating systems;
Desktop automation;
Browser agents;
Accessibility-driven automation;
Document and file management;
Messaging and communication platforms;
Payment interfaces;
Das Expires 29 April 2027 [Page 88]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Digital commerce;
Enterprise application automation;
Cross-application content transfer;
Cloud application orchestration;
5.1.3.57. Source page 491 of the original specification
Wearable and extended-reality computing;
Remote desktops;
Industrial control interfaces;
Robotic interaction systems;
Multi-agent enterprise workflows.
The technical benefit depends upon integration with authenticated
presentation evidence, sufficiently trustworthy resource-identity
resolution, and actual effectuation boundaries capable of enforcing
the required correspondence.
3.38 — FINAL NON-LIMITING TECHNICAL SUMMARY
The present embodiment discloses a protected semantic correspondence
architecture for consequential operations initiated or prepared by
autonomous computing entities in response to user references.
A user-reference event is associated with an authenticated
presentation context.
A semantic resolution mechanism identifies a candidate computational
entity satisfying the applicable reference relationship.
The selected entity is verified using appropriate object-identity,
version, namespace, or equivalent evidence.
A Protected Semantic Correspondence Record binds the user-reference
context, resolved entity, permitted operation, applicable temporal or
transformation conditions, and designated Finality Sink.
The corresponding Candidate Act is held non-effective while required
protected validation occurs.
Das Expires 29 April 2027 [Page 89]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Before consequential release, the designated Finality Sink
independently obtains or reconstructs the actual pending operation
and target.
The sink verifies whether the actual resource and operation satisfy
the protected semantic correspondence and current authorization
state.
Where the actual target differs materially, the system withholds
effectuation unless an applicable independently authorized
correspondence transformation or new authorization permits the
change.
The architecture may distinguish stable object references from
intentionally dynamic selectors.
It may support legitimate cross-application transformations while
preventing unauthorized target substitution.
It may use authenticated visual, structural, input, resource-
identity, and controller evidence according to the actual trust
boundaries of the implementation.
The mechanism does not presume that a rendered presentation proves
subjective human perception or that a model's confidence establishes
resource identity.
5.1.3.58. Source page 492 of the original specification
The embodiment may be implemented through operating-system mediation,
protected application services, trusted execution environments,
secure controllers, remote protected services, or suitably
authenticated distributed arrangements.
An optional IEV may perform additional last-mile correspondence
verification.
An optional scope-deviation mechanism may request new user authority
for a changed target.
The proposed architecture remains applicable to single-act execution-
finality control without requiring every operation to use phased
continuation or human approval.
Das Expires 29 April 2027 [Page 90]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The central proposed technical contribution is the protected,
enforceable correspondence between an authenticated user-reference
context, a verified semantically resolved entity, and the actual
operation reconstructed at the consequential effectuation boundary,
including authorized temporal and cross-application transformations.
The inventive step of any claimed technical combination remains
subject to examination against existing graphical interface
grounding, entity-resolution, action-verification, concurrency-
control, and protected execution technologies.
END OF EMBODIMENT 3.
EMBODIMENT 4
PROTECTED CROSS-DOMAIN ACTUAL-CONSEQUENCE WITNESSING WITH OPERATION-
BOUND REMOTE STATE EVIDENCE, INDEPENDENT OBSERVATION, CROSS-COMMITTED
EFFECT PROOFS, AND SINK-ENFORCED OUTCOME-DEPENDENT AUTHORITY
4.0 — COMPLETE TECHNICAL TITLE
Systems and Methods for Protected Cross-Domain Actual-Consequence
Witnessing Using Authenticated Operation-to-Remote-State
Correspondence, Independently Qualified Effect Observers, Cross-
Committed Consequence Evidence, Protected Outcome Reconciliation, and
Scoped Continuation Authority Across Heterogeneous Autonomous
Computing Domains
4.0.1 — General Characterization
The present embodiment discloses systems, methods, apparatus,
protected computing components, authenticated communication
protocols, cryptographic evidence structures, independent observation
mechanisms, protected state transitions, and non-limiting reference
implementations for determining whether an operation authorized and
initiated in one computing domain has actually produced a specified
consequential state change in another computing domain.
The architecture may be applied to artificial-intelligence agents,
autonomous computing systems, operating-system services, application
frameworks, distributed workflows, financial systems, remote storage
services, communication platforms, cloud infrastructure, enterprise
applications, telecommunications systems, robotic controllers,
industrial computing systems, and other computational entities
capable of initiating consequential operations across trust or
administrative boundaries.
Das Expires 29 April 2027 [Page 91]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.2. Embodiment 6 — Tool-Effect Contract Integrity and Semantic
Compatibility Across Updates
Original global source pages 666 through 722, inclusive. Source
file: TECHNICAL SPECIFICATION -555-1062.pdf. This is a primary Part
7 source unit; the author should compare embedded extracts with the
original source file before publication.
5.2.1. Embodiment-Specific Architecture and Trust Relationship
[Approved source grant and tool-effect contract]
|
[Versioned semantic effect and interface profile]
|
[Tool/API/service evolves or is replaced]
|
[Independent current contract verification]
|
[Compatibility or authorized scope delta]
|
[CA / NES + protected evidence + finality]
|
[FS checks ACTUAL effect under current contract]
/PASS \FAIL
[Controlled effect] [FENCE/REAUTHORIZE]
Figure 3: Embodiment 6 — Tool-Effect Contract Integrity and Semantic
Compatibility Across Updates — protected architecture
5.2.2. Operational Security Decision Flowchart
[Pending effect under contract version A]
|
<Tool behavior/contract changed?>-NO->[CURRENT CHECKS]
|YES
[Compare A to current effect semantics B]
|
<Proven compatible under approved scope?>-NO->[FENCE]
|YES
[Current authority and coverage qualification]
|
<FS actual effect still bounded?>-NO->[REFUSE]
|YES
[Protected consume and execute]
Figure 4: Embodiment 6 — Tool-Effect Contract Integrity and Semantic
Compatibility Across Updates — refusal and controlled-effect
decisions
Das Expires 29 April 2027 [Page 92]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.2.3. Original Technical Disclosure with Global-Page Anchors
5.2.3.1. Source page 666 of the original specification
Authorized technical exceptions may be represented explicitly and
verified against protected policy.
The implementation may be integrated into one protected component or
distributed among multiple physical controllers.
It may govern conventional processors, hardware accelerators, neural-
processing devices, network interfaces, storage resources, API
quotas, device energy, and other constrained resources.
It may support present computing environments and technically defined
future autonomous infrastructure.
The claimed security properties remain bounded by the actual
admission, verification, resource-controller, metering, and
enforcement coverage of the implementation.
A cryptographically signed allocation record does not independently
prove complete demand capture.
A mathematically correct allocation does not independently prove that
the resource controller enforced the decision.
An accurate resource meter does not independently establish
compliance with an undefined fairness policy.
The protected combination is intended to address these distinct
technical gaps.
The principal candidate inventive technical concept of Embodiment 5
is the non-bypassable transformation of a cryptographically
verifiable, policy-neutral resource-allocation decision— computed
from authenticated eligible demand—into scoped resource-grant
authority independently verified at the actual resource Finality
Sink, together with protected evidence linking the authorized grant
to actual resource consumption.
The novelty, inventive step, and scope of any particular claim remain
subject to relevant prior-art examination and the technical
limitations supported by the filed disclosure.
END OF EMBODIMENT 5 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 6
Das Expires 29 April 2027 [Page 93]
Internet-Draft Execution-Finality Part 7: Tools October 2026
PROTECTED SEMANTIC ACTION-CONTRACT EVOLUTION WITH EFFECT-
COMPATIBILITY VERIFICATION, TRANSITIVE CONSEQUENCE BINDING, VERSION-
AWARE AUTHORITY CONTINUITY, AND NON-BYPASSABLE FINALITY-SINK
REVALIDATION
6.0 — COMPLETE TECHNICAL TITLE
Systems and Methods for Protected Autonomous Action-Contract
Evolution Using Machine-Verifiable Consequence Semantics,
Authenticated Software and Tool Contract Versions, Transitive Effect-
Dependency Reconstruction, Effect-Compatible Authority Migration,
Protected Semantic-Change Evidence, and Independent Finality-Sink
Verification of Actual Consequential Operations Across Present and
Future Computing Environments
6.0.1 — General Technical Description
5.2.3.2. Source page 667 of the original specification
The present embodiment discloses systems, methods, apparatus,
protected computing components, authenticated protocols, machine-
verifiable semantic representations, protected software and hardware
state transitions, cryptographic verification procedures, and non-
limiting implementation techniques for maintaining the validity of
execution authority when the technical behavior of an application,
autonomous tool, service, API, operating-system interface,
distributed function, hardware command, or other effect-capable
component changes.
The embodiment addresses a condition in which a computational entity
possesses previously valid authority to perform a specified
consequential operation, but the software, interface, execution
contract, resource mapping, command semantics, or downstream
effectuation behavior associated with that operation changes before
the actual consequence occurs.
An autonomous computational entity may continue to request the same
named operation after such a change.
The operation's displayed name, input schema, interface identifier,
or ordinary access-control permission may remain unchanged.
Nevertheless, its actual effect may differ from the consequence
originally authorized.
Das Expires 29 April 2027 [Page 94]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Such differences may include a changed resource target, additional
recipient, modified transaction scope, newly introduced external
transmission, altered storage behavior, expanded privilege, changed
operation ordering, additional delegated function, modified rollback
semantics, or new asynchronous effect.
The present embodiment provides a protected mechanism for identifying
relevant operation-semantic changes, determining whether the changed
operation remains within the originally authorized effect envelope,
and preventing the actual Finality Sink from permitting an
incompatible effect under stale authority.
6.0.2 — Principal Technical Principle
The foundational principle is:
An operation's name, interface schema, software version, or
successful authentication does not independently establish that its
current consequential behavior remains authorized.
The relevant authority must remain compatible with the actual effect
semantics of the operation presented for execution.
Where a previously authorized operation evolves, the protected system
determines whether the new effect remains within the original or
validly amended authorization.
Where the required compatibility cannot be established, the
consequential operation remains withheld until suitable new authority
is obtained.
6.0.3 — Candidate Inventive Concept
In a principal implementation, a protected authority is bound to a
machine-verifiable description of the consequential behavior
authorized when the Candidate Act was approved.
5.2.3.3. Source page 668 of the original specification
The description may include direct effects, relevant downstream or
transitive effects, resource identities, permissible destinations,
operation sequencing, privilege scope, and protected environmental
conditions.
A protected semantic-evolution controller identifies a change to the
relevant action contract or effectuation path.
Das Expires 29 April 2027 [Page 95]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The controller obtains authenticated information concerning the
current operation semantics and evaluates whether the new effect
representation remains within the authorized envelope.
The result may be expressed as an authenticated Effect-Compatibility
Evidence Record.
A Finality Sink independently verifies the compatibility result,
current action-contract state, applicable protected authority, and
actual pending operation.
The sink permits the consequential effect only when the current
operation satisfies the required effect-compatibility predicates.
The proposed inventive relationship is therefore not merely checking
whether a software version has changed.
It is making current effect-semantic compatibility an enforceable
finality condition.
6.0.4 — Separate Computation and Effectuation
The autonomous computational entity may continue performing permitted
reasoning, planning, data processing, or preparation.
A change to an effect-capable tool does not necessarily prohibit
every harmless computational use of the tool.
However, the consequential operation remains subject to the
applicable protected finality conditions.
The architecture therefore distinguishes a change in computational
implementation from a material expansion or alteration of the
external consequence.
6.0.5 — Physical and Logical Deployment Neutrality
The protected semantic verifier may be implemented as:
A software security service;
An isolated operating-system function;
A protected application dispatcher;
A separate verification appliance;
A cryptographically identifiable remote validator;
Das Expires 29 April 2027 [Page 96]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A secure processor function;
A firmware controller;
5.2.3.4. Source page 669 of the original specification
A hardware command verifier;
Or a protected function integrated with the Finality Sink.
The relevant components may reside within one protected device or
across several authenticated administrative domains.
The essential technical requirement is that the actual governed
consequence cannot bypass the mandatory effect-compatibility
condition within the claimed enforcement coverage.
6.0.6 — Relationship to Other Disclosures
This embodiment may use the Candidate Act, Non-Effective State,
Protected Enforcement Domain, scoped finality authority, and Finality
Sink mechanisms of Common Master Workflow CW-1.
It may optionally use receipt-gated causal continuation from CW-2 and
scope reauthorization from CW-3.
Embodiment 1 may provide protected conflict arbitration where a
semantic change affects shared resources.
Embodiment 2 may govern the authority required between causally
dependent real-effect phases.
Embodiment 3 may provide authenticated correspondence between a user-
referenced object and the actual target.
Embodiment 4 may provide evidence concerning an actual effect
occurring in another domain.
Embodiment 5 may govern protected resource allocation where changed
tool semantics also affect computational resource-grant conditions.
Miscellaneous Embodiment M-1 may provide dynamic enforcement-path
coverage, protocol-neutral effect descriptors, and update-triggered
reattestation.
The present embodiment develops effect-semantic compatibility,
authority preservation, and finality enforcement during action-
contract evolution in greater technical depth.
Das Expires 29 April 2027 [Page 97]
Internet-Draft Execution-Finality Part 7: Tools October 2026
No amendment to the preceding embodiments is required.
6.1 — TECHNICAL FIELD
The present embodiment relates to autonomous-agent security,
protected execution-finality control, software-interface
compatibility, semantic operation verification, secure application
dispatch, dynamic tool discovery, authenticated software evolution,
policy-bound authorization, distributed service orchestration,
hardware command integrity, and protected consequential-state
management.
More particularly, it relates to maintaining or invalidating
execution authority when the behavior of an effect-capable operation
changes after authorization but before actual effectuation.
The mechanisms may be applied to present-day computing systems and
technically feasible future autonomous infrastructures without
requiring a particular AI model, commercial software provider,
processor architecture, or communication protocol.
5.2.3.5. Source page 670 of the original specification
6.2 — SPECIFIC TECHNICAL PROBLEMS
6.2.1 — Interface Compatibility Without Consequence Compatibility
A software function may preserve its input parameters and output
schema across versions while changing its actual side effects.
For example, a function formerly responsible for storing a report
locally may be modified to transmit a copy to a remote service.
A schema compatibility check may find no incompatible field change.
Nevertheless, the new operation produces a materially different
consequence.
The system therefore requires a distinction between interface-shape
compatibility and actual effect-semantic compatibility.
6.2.2 — Stable Tool Identifier with Changed Behavior
An autonomous tool may retain the same identifier while its
implementation changes.
An agent may invoke the tool using an authorization obtained before
the change.
Das Expires 29 April 2027 [Page 98]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A previously valid authorization cannot safely be assumed to cover
the new consequences.
6.2.3 — Hidden Default-Parameter Changes
A function may preserve the same declared parameter names while
changing default values.
For example, an omitted parameter may previously mean local-only
processing but subsequently mean remote synchronization.
The tool call may remain syntactically identical while the
consequential scope expands.
6.2.4 — Transitive Side-Effect Expansion
A tool may invoke another service, which invokes a further function.
A change in one downstream component may introduce a new effect even
when the initially invoked tool has not changed.
The protected system may therefore need to evaluate transitive effect
dependencies rather than only the first visible invocation.
6.2.5 — Asynchronous Effect Creation
An operation may schedule a later background effect.
A success response from the initial function may occur before the
background action executes.
The authorized effect representation may need to include such delayed
consequences where they form part of the relevant operation.
5.2.3.6. Source page 671 of the original specification
6.2.6 — Semantic Drift After Authorization
An agent may receive valid authorization under one action-contract
version.
Before dispatch, an application, remote service, plugin, or
controller may update to another version.
The actual operation may no longer correspond to the authorized
semantics.
6.2.7 — Semantic Downgrade and Rollback
Das Expires 29 April 2027 [Page 99]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An attacker may attempt to select an older or misleading contract
version to obtain authority while executing a different
implementation.
The protected system must associate the verified contract with the
actual effectuation path.
6.2.8 — Hidden Privilege Expansion
A new operation version may introduce additional privilege,
credential, or resource requirements.
A valid earlier authorization may not extend to the expanded effect.
6.2.9 — Changed Resource Identity
An API may retain the same apparent operation while changing the
target resource mapping.
The resulting effect may be incompatible with the original Candidate
Act.
6.2.10 — Changed Failure and Retry Semantics
A previously idempotent or effectively single-effect operation may
evolve to create additional consequences upon retry.
The protected system may need to restrict automatic retry under stale
assumptions.
6.2.11 — Multi-Domain Contract Disagreement
A client may believe that one contract version applies while a remote
service executes another.
The protected system must determine which actual semantics can be
established at the relevant consequential boundary.
6.2.12 — Incomplete Effect Observation
A protected verifier may not possess sufficient visibility into a
remote service's internal behavior to prove every side effect.
The architecture must distinguish verified effect compatibility from
an unsupported assertion of compatibility.
6.2.13 — Technical Objective
Das Expires 29 April 2027 [Page 100]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An illustrative objective technical problem is:
5.2.3.7. Source page 672 of the original specification
How to prevent a previously authorized consequential operation from
being executed under materially changed action semantics by binding
protected authority to an authorized effect envelope, detecting
relevant changes to current operation behavior, evaluating effect
compatibility under verifiable technical conditions, and requiring
independent Finality-Sink enforcement before the actual consequence
occurs.
6.3 — CONVENTIONAL TECHNIQUES AND THEIR LIMITATIONS
6.3.1 — API Schema Validation
An API schema may specify accepted parameters, data types, required
fields, and response structures.
Such descriptions are useful for interoperability and validation.
However, preservation of the schema does not necessarily establish
preservation of consequential behavior.
The present embodiment may use schema evidence as one input to a
broader effect-compatibility determination.
6.3.2 — Semantic Versioning
Software versioning may indicate intended compatibility or the scale
of a software change.
Version numbering is useful but does not independently prove that the
actual effect remains within the prior authorization.
A change identified as minor may nevertheless affect security-
sensitive consequences.
6.3.3 — Software Artifact Hashing
A cryptographic digest may identify a software artifact.
A changed digest may indicate changed bytes.
However, a digest does not independently describe whether the changed
implementation expands, narrows, or preserves a specified
consequential effect.
Das Expires 29 April 2027 [Page 101]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The present embodiment may use artifact identity as supporting
evidence while separately evaluating effect compatibility.
6.3.4 — Software Provenance
Authenticated software provenance may provide information concerning
where and how an artifact was produced.
Such evidence may assist in identifying the implemented contract
version.
It does not automatically prove that the artifact's consequential
behavior conforms to the previously authorized effect.
5.2.3.8. Source page 673 of the original specification
6.3.5 — Fine-Grained Authorization
A conventional authorization system may represent permitted action
types, resources, and destinations in structured authorization data.
Such mechanisms are relevant prior art.
The additional technical focus is whether a previously authorized
effect remains valid after the actual operation semantics evolve, and
whether the Finality Sink enforces that compatibility at release
time.
6.3.6 — Conventional Compatibility Testing
Software developers may use unit tests, integration tests, regression
tests, and contract tests.
Such testing may identify functional changes.
However, ordinary testing results may not be bound to the actual
operation presented at a protected effectuation boundary.
6.3.7 — Conventional Feature Flags
A feature flag may enable or disable a software behavior.
A flag is not inherently a protected finality authority or proof that
all effect-capable paths observe the same flag.
6.3.8 — Conventional Audit Logs
Das Expires 29 April 2027 [Page 102]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A log may record that a tool changed or that a new version was
invoked.
The recorded event does not itself prevent an incompatible
consequence.
The stronger proposed implementation uses verified compatibility as a
necessary condition for effectuation.
6.4 — PRINCIPAL PROTECTED ARCHITECTURE
A representative implementation comprises an Action-Contract
Registry, an Authorized Effect Envelope Store, a protected contract-
version monitor, an actual-operation descriptor generator, a semantic
compatibility verifier, a protected authority-continuity controller,
and one or more Finality Sinks.
The architecture may additionally include an effect-dependency
resolver, resource identity verifier, authenticated software
provenance source, transitive effect-closure evaluator, current-state
observer, and protected update or reauthorization service.
The requesting agent may propose an operation.
However, the requesting agent cannot independently redefine the
applicable authorized effect envelope or declare an incompatible
contract change to be harmless.
5.2.3.9. Source page 674 of the original specification
The protected system determines compatibility according to the
current authenticated authority and technical evidence.
The actual Finality Sink independently verifies the relevant
resulting state.
6.5 — BROAD TECHNICAL DEFINITIONS
6.5.1 — Action Contract
An Action Contract means a machine-verifiable description of the
operational and consequential behavior associated with a callable
function, service operation, application action, hardware command, or
other computational interface.
An Action Contract may describe accepted inputs, output
representations, direct effects, required privileges, relevant
downstream effects, failure semantics, and effectuation boundaries.
Das Expires 29 April 2027 [Page 103]
Internet-Draft Execution-Finality Part 7: Tools October 2026
6.5.2 — Protected Action Contract
A Protected Action Contract, or PAC-6, means an Action Contract whose
authenticity, identity, version, and applicable security-relevant
properties are established through a protected trust mechanism.
6.5.3 — Authorized Effect Envelope
An Authorized Effect Envelope, or AEE-6, means the set of
consequential operations, resources, destinations, side effects,
privilege bounds, ordering constraints, and related conditions
permitted by the applicable original or validly amended authority.
6.5.4 — Current Effect Representation
A Current Effect Representation, or CER, means a machine-verifiable
description of the actual or sufficiently assured current
consequential behavior of an operation.
6.5.5 — Effect-Semantic Compatibility
Effect-Semantic Compatibility means satisfaction of a protected
predicate establishing that the operation under current semantics
remains within the applicable authorized effect envelope.
The predicate may consider direct effects, transitive effects,
resource identity, destination, privilege, sequence, and other
mandatory technical conditions.
6.5.6 — Effect-Compatibility Evidence Record
An Effect-Compatibility Evidence Record, or ECER, means protected
evidence identifying the evaluated action-contract versions, original
authority, current effect representation, applicable compatibility
predicate, verification result, and relevant trust assumptions.
6.5.7 — Semantic Contract Evolution Event
5.2.3.10. Source page 675 of the original specification
A Semantic Contract Evolution Event, or SCEE, means an authenticated
or otherwise qualified indication that a relevant action contract,
implementation, resource mapping, or effect dependency has changed.
6.5.8 — Semantic Contract Generation
Das Expires 29 April 2027 [Page 104]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A Semantic Contract Generation, or SCG, means a protected version or
generation identifying the applicable security-relevant operation
semantics.
6.5.9 — Effect-Dependency Closure
An Effect-Dependency Closure, or EDC, means a protected
representation of the relevant direct and transitive consequences
that an operation may produce under specified execution and
environmental conditions.
6.5.10 — Effect-Compatibility Predicate
An Effect-Compatibility Predicate, or ECP-6, means a machine-
verifiable rule determining whether a proposed current operation
remains within the applicable authorized effect envelope.
6.5.11 — Protected Semantic Difference Record
A Protected Semantic Difference Record, or PSDR, means authenticated
evidence identifying security-relevant differences between action-
contract generations.
6.5.12 — Authorized Contract Migration
Authorized Contract Migration means a protected transition allowing
previously issued authority to remain valid under a new operation
contract only where the required effect-compatibility predicates are
established.
6.5.13 — Contract-Bound Finality Authority
Contract-Bound Finality Authority means scoped execution authority
associated with an approved effect envelope and applicable action-
contract state.
6.5.14 — Protected Contract Epoch
A Protected Contract Epoch, or PCE, means a protected state
generation identifying the current relevant contract and
authorization environment.
6.5.15 — Semantic Revalidation Fence
A Semantic Revalidation Fence, or SRF, means protected state
preventing an operation from reaching the consequential boundary
while required current effect compatibility is unverified.
Das Expires 29 April 2027 [Page 105]
Internet-Draft Execution-Finality Part 7: Tools October 2026
6.5.16 — Protected Effect-Closure Verifier
A Protected Effect-Closure Verifier means a component evaluating the
relevant downstream effect dependencies under the specified coverage
and trust model.
6.5.17 — Transitive Effect Descriptor
5.2.3.11. Source page 676 of the original specification
A Transitive Effect Descriptor means a machine-verifiable description
of a consequential effect initiated indirectly through another
function, service, controller, or delegated execution component.
6.5.18 — Protected Semantic Migration Record
A Protected Semantic Migration Record, or PSMR, means authenticated
state authorizing the continued use of defined earlier authority
under a verified compatible later contract.
6.5.19 — Effect-Semantic Expansion
Effect-Semantic Expansion means a change that introduces a
consequential operation, resource, privilege, destination, or other
effect outside the previously authorized envelope.
6.5.20 — Effect-Semantic Restriction
Effect-Semantic Restriction means a change that narrows the possible
consequential behavior, subject to preservation of any mandatory
functional, safety, or ordering requirements.
6.5.21 — Effect-Semantic Equivalence
Effect-Semantic Equivalence means that two representations satisfy a
defined protected equivalence relation concerning the security-
relevant consequential behavior.
Such equivalence need not imply identical internal implementation.
6.5.22 — Unsupported Semantic Assumption
An Unsupported Semantic Assumption means a claimed compatibility
property for which the protected system lacks the evidence required
by the applicable assurance profile.
6.5.23 — Actual Effectuation Contract
Das Expires 29 April 2027 [Page 106]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An Actual Effectuation Contract, or AEC, means the security-relevant
current behavior and permitted effects associated with the actual
operation presented to a Finality Sink.
6.5.24 — Protected Contract Identity
A Protected Contract Identity means an authenticated identity binding
an operation contract to its relevant issuer, resource, service,
implementation, or enforcement domain.
6.5.25 — Protected Effect-Semantic Assurance Level
A Protected Effect-Semantic Assurance Level means a defined
representation of the evidence and trust assumptions supporting a
compatibility determination.
6.5.26 — Protected Semantic Authority Consumption
Protected Semantic Authority Consumption means the protected
reservation or consumption of an operation-specific authorization
under a verified compatible contract state.
6.5.27 — Contract-Dependent Consequential Path
5.2.3.12. Source page 677 of the original specification
A Contract-Dependent Consequential Path means an execution route
whose actual effect depends upon one or more identified action-
contract or operation-semantics conditions.
6.5.28 — Semantic Finality Sink
A Semantic Finality Sink means a Finality Sink configured to verify
effect-semantic compatibility as a mandatory condition for releasing
the actual governed consequence.
6.6 — PROTECTED ACTION-CONTRACT STRUCTURE
A representative PAC-6 may comprise:
PROTECTED_ACTION_CONTRACT = { contract_identifier,
contract_generation, contract_issuer_identity, operation_identifier,
input_schema_reference, output_schema_reference,
normalized_operation_class, direct_effect_descriptors,
transitive_effect_references, resource_identity_rules,
destination_rules, parameter_default_rules, required_privileges,
asynchronous_effect_rules, callback_and_delegation_rules,
effect_ordering_constraints, idempotency_and_retry_conditions,
Das Expires 29 April 2027 [Page 107]
Internet-Draft Execution-Finality Part 7: Tools October 2026
failure_and_partial_effect_semantics, permitted_environment_classes,
relevant_implementation_identity, applicable_finality_sinks,
effect_coverage_assurance, protected_contract_authentication } The
listed fields are non-limiting.
A particular implementation may distribute the information across
authenticated records or protected state.
The contract need not expose every implementation detail.
However, it must contain or reference sufficient information to
evaluate the consequential properties relevant to the protected
authorization.
6.7 — AUTHORIZED EFFECT ENVELOPE
6.7.1 — General Principle
5.2.3.13. Source page 678 of the original specification
An AEE-6 identifies what the original authorization permits the
operation to cause.
It may be associated with a Candidate Act, user instruction,
delegated authority, protected policy, or combination thereof.
6.7.2 — Resource Scope
The envelope may identify permitted resources by protected identity,
version, ownership, or applicable resource class.
6.7.3 — Destination Scope
The envelope may identify permitted destinations, recipients,
systems, or administrative domains.
6.7.4 — Data Scope
The envelope may specify what data may be read, written, transformed,
exported, or disclosed.
6.7.5 — Privilege Scope
The envelope may identify the maximum authority or credential class
permitted for the operation.
6.7.6 — Effect Quantity
Das Expires 29 April 2027 [Page 108]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The envelope may constrain transaction amount, object count,
transmission quantity, actuator movement, processing quota, or
another measurable consequence.
6.7.7 — Temporal Scope
The envelope may constrain execution time, validity period, sequence,
or applicable scheduling condition.
6.7.8 — Transitive Consequences
Where relevant, the envelope may identify permitted secondary or
delegated effects arising from the initially authorized operation.
6.7.9 — Mandatory Outcome Properties
The envelope may require preservation of certain technical outcomes.
For example, a permitted operation may be required to atomically
update a resource or to maintain a particular version consistency
relationship.
A change that removes such a guarantee may be incompatible even if it
does not introduce an additional external destination.
6.7.10 — Non-Bearer Scope
The protected envelope is not automatically a transferable
permission.
The Finality Sink verifies that the actual pending operation is
covered by the applicable authority.
5.2.3.14. Source page 679 of the original specification
6.8 — FORMAL EFFECT-COMPATIBILITY RELATIONSHIP
A_old represent the authorized effect envelope associated with a
prior valid Candidate Act.
E_new(x, s) represent the set or conservative representation of
effects that the current operation may produce for actual operation
parameters x and relevant state s.
G represent the applicable mandatory technical guarantees.
A principal compatibility condition may require:
Das Expires 29 April 2027 [Page 109]
Internet-Draft Execution-Finality Part 7: Tools October 2026
E_new(x, s) SUBSET_OF A_old and:
PRESERVES_REQUIRED_GUARANTEES( E_new, G ) and:
CURRENT_AUTHORITY_VALID and:
REQUIRED_EFFECTUATION_COVERAGE_VALID This notation represents an
abstract security predicate.
The implementation may use typed effect records, policy rules,
symbolic evaluation, resource constraints, authenticated state
comparisons, or another machine-verifiable mechanism.
6.8.1 — Effect Restriction
Where current possible effects are a valid subset of the previously
authorized envelope, continued authority may be permitted if
mandatory functional and safety conditions remain satisfied.
6.8.2 — Effect Expansion
Where a newly possible effect falls outside the authorized envelope,
the previous authority cannot automatically authorize the expanded
consequence.
6.8.3 — Effect Incomparability
Two versions may produce different effects neither of which is a
subset of the other.
The system may require a new authorization or a more specific
verification of the actual invocation.
5.2.3.15. Source page 680 of the original specification
6.8.4 — Exact-Invocation Compatibility
A newly expanded contract may nevertheless contain a restricted
invocation path whose actual effects remain within an earlier
authorization.
Where the protected system can enforce and verify that exact path, it
may permit the narrow operation without permitting the entire
expanded contract.
6.8.5 — Unsupported Compatibility
Das Expires 29 April 2027 [Page 110]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Where the system cannot establish the required inclusion or
equivalence relationship, the protected result is UNKNOWN rather than
automatically compatible.
6.8.6 — Semantic Compatibility Beyond Set Inclusion
Some operations require exact ordering, atomicity, failure behavior,
or recipient guarantees.
Accordingly, compatibility may require preservation of additional
predicates beyond simple inclusion of effect types.
6.9 — EFFECT-COMPATIBILITY CLASSIFICATION
The protected semantic verifier may classify a contract evolution as
follows.
CLASS S0 — EXACT VERIFIED CONTINUITY: The relevant protected effect
semantics and required guarantees remain unchanged.
CLASS S1 — VERIFIED RESTRICTION: The new behavior is narrower than
the authorized envelope and preserves required technical conditions.
CLASS S2 — CONDITIONAL COMPATIBILITY: The new contract contains both
permitted and expanded behaviors, but a protected invocation
constraint can isolate the authorized subset.
CLASS S3 — AUTHORIZATION-RELEVANT EXPANSION: The new operation may
produce an effect outside the authorized scope.
CLASS S4 — GUARANTEE DEGRADATION: The operation removes or weakens a
required technical property such as atomicity, idempotency, ordering,
or controlled destination behavior.
CLASS S5 — UNVERIFIED SEMANTICS: The relevant behavior cannot be
sufficiently established under the selected evidence and trust model.
CLASS S6 — CONTRACT OR RESOURCE IDENTITY CONFLICT: The current
operation cannot be reliably bound to the claimed contract or
resource identity.
S0 and S1 may qualify for defined authority continuity.
S2 may qualify only where the necessary invocation restrictions are
enforced.
S3, S4, S5, or S6 may require withholding, renewed authorization,
separate remediation, or another explicitly protected procedure.
Das Expires 29 April 2027 [Page 111]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The classification labels are non-limiting.
5.2.3.16. Source page 681 of the original specification
6.10 — SEMANTIC CHANGE DETECTION
6.10.1 — Contract Registry Update
A protected registry may generate an SCEE when a relevant action
contract is updated.
6.10.2 — Software Artifact Change
A change in an authenticated executable or service artifact may
trigger semantic revalidation.
An artifact change does not automatically prove effect expansion.
6.10.3 — Configuration Change
A change to default destinations, synchronization settings, data-
sharing behavior, or permission configuration may alter the effective
consequences.
6.10.4 — Downstream Dependency Change
An unchanged top-level function may invoke a newly updated downstream
service.
The protected dependency graph may identify the change as potentially
relevant.
6.10.5 — Resource Mapping Change
A path, object identifier, endpoint, or application resource mapping
may change.
The protected system may require renewed resource identity
verification.
6.10.6 — Hardware Firmware Change
A device command may acquire different behavior after a firmware
update.
The hardware controller may require current contract or command-
semantics verification.
Das Expires 29 April 2027 [Page 112]
Internet-Draft Execution-Finality Part 7: Tools October 2026
6.10.7 — Policy Change
A current protected authorization policy may narrow previously
permitted effects.
Unconsumed authority may require revalidation.
6.10.8 — Remote Service Change
A remote service may expose a new contract version.
Where the actual remote behavior cannot be independently established,
the system may limit its claims to the verified local boundary or
require authenticated remote assurances.
6.10.9 — Dynamic Tool Discovery
A newly discovered tool is not automatically considered semantically
compatible with an earlier tool merely because the names or schemas
match.
5.2.3.17. Source page 682 of the original specification
6.10.10 — Continuous Monitoring
The protected system may monitor relevant contract generations and
invalidate stale compatibility assumptions when a material change is
detected.
6.11 — TRANSITIVE EFFECT-DEPENDENCY CLOSURE
6.11.1 — Direct Effects
A direct effect is a consequence caused through the initially invoked
operation's immediate effectuation path.
6.11.2 — Indirect Effects
An indirect effect may arise from another function, callback,
service, queue, or delegated operation initiated by the first
function.
6.11.3 — Protected Dependency Graph
A protected dependency graph may associate the initial operation with
relevant downstream effect-capable components.
6.11.4 — Effect Edges
Das Expires 29 April 2027 [Page 113]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An edge may identify a possible downstream call, event publication,
scheduled job, callback, or device command.
6.11.5 — Transitive Closure
The protected verifier may compute an EDC over the relevant bounded
dependency graph.
6.11.6 — Recursive Dependencies
Where cycles or recursive service invocation are possible, the
closure algorithm may use conservative fixed-point evaluation or
bounded recursion under a defined assurance model.
6.11.7 — Dynamic Dependencies
A runtime-discovered dependency may cause revalidation.
6.11.8 — Unknown Dependencies
Where the closure is incomplete, the system must not claim to have
proved the absence of unobserved effects.
It may apply conservative restrictions, additional instrumentation,
or mandatory enforcement at downstream sinks.
6.11.9 — Sink-Enforced Transitive Effects
5.2.3.18. Source page 683 of the original specification
Where a downstream effectuation path is independently controlled, it
may require its own applicable Candidate Act and finality authority.
This can reduce dependence on perfect advance knowledge of every
future software branch.
6.11.10 — Proposed Technical Contribution
The candidate mechanism concerns binding actual finality
authorization to a protected representation of both direct and
relevant transitive consequences, with renewed verification when the
closure changes.
6.12 — PROTECTED SEMANTIC EVIDENCE SOURCES
The system may obtain effect-compatibility evidence from one or more
technical sources.
Das Expires 29 April 2027 [Page 114]
Internet-Draft Execution-Finality Part 7: Tools October 2026
These may include authenticated contract manifests, verified
configuration records, protected source or binary analysis, runtime
observation, effect-capable API mediation, controller-owned command
descriptors, attested execution measurements, and qualified remote
service evidence.
Different evidence sources may establish different properties.
6.12.1 — Signed Contract Manifest
A provider may authenticate a description of intended operation
semantics.
The signature proves attribution under the applicable key
assumptions.
It does not independently prove that the implementation conforms to
the description.
6.12.2 — Protected Code Measurement
A protected measurement may establish which software implementation
is executing.
It does not automatically prove that the implementation has no
undeclared side effects.
6.12.3 — Static Analysis
Static analysis may identify possible effects and data flows.
The soundness and completeness of such analysis depend upon the
language, environment, program model, and tool assumptions.
6.12.4 — Dynamic Observation
Runtime instrumentation may observe actual effects during execution.
An observed trace does not by itself establish the absence of
unexecuted branches.
6.12.5 — Mandatory Effect Boundary
A protected enforcement boundary may constrain certain effects even
where the complete internal behavior cannot be predicted.
Das Expires 29 April 2027 [Page 115]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.2.3.19. Source page 684 of the original specification
This may provide stronger enforceable protection for covered
consequences than relying solely upon descriptive metadata.
6.12.6 — Authenticated Remote Observation
A remote system may supply evidence concerning a relevant remote
state transition.
The evidence must be qualified according to what the remote source
can actually observe.
6.12.7 — Combined Assurance
A protected compatibility determination may combine authenticated
manifests, current code measurements, constrained effectuation paths,
and actual operation reconstruction.
6.12.8 — Evidence Limitations
No implementation is presumed capable of perfectly determining
arbitrary program behavior merely by comparing software versions or
executing a finite test set.
6.13 — EFFECT-COMPATIBILITY EVIDENCE RECORD
A representative ECER may comprise:
EFFECT_COMPATIBILITY_EVIDENCE_RECORD = { record_version,
original_candidate_act_digest, original_authorized_envelope_digest,
old_contract_identifier, old_contract_generation,
new_contract_identifier, new_contract_generation,
current_implementation_reference, current_resource_identity,
semantic_difference_commitment, direct_effect_commitment,
transitive_effect_closure_reference, compatibility_classification,
required_guarantee_results, permitted_invocation_constraints,
evidence_assurance_profile, verifier_identity,
verifier_key_reference, current_contract_epoch, authority_epoch,
designated_finality_sink, compatibility_decision,
protected_authentication } The ECER may be a signed object,
authenticated protected state entry, sealed receipt, or equivalent
machine-verifiable representation.
5.2.3.20. Source page 685 of the original specification
It need not be stored on a blockchain.
Das Expires 29 April 2027 [Page 116]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The record is intended to support current effectuation authority
rather than merely provide historical documentation.
6.14 — INDEPENDENT SEMANTIC VERIFIER IDENTITY
6.14.1 — Verifier Identity
A protected semantic verifier may possess an enrolled cryptographic
identity.
6.14.2 — Unique Namespace
The verifier may have a unique identifier within an authenticated
trust domain.
An arbitrary identifier without cryptographic proof is insufficient.
6.14.3 — Authorized Verification Role
The verifier must be authorized to evaluate the relevant action-
contract or effect class.
6.14.4 — Verification Result Authentication
The verifier may cryptographically authenticate its ECER or commit
equivalent identity-bound protected state.
6.14.5 — Separate Physical Verifier
The verifier may operate in a physically separate device or protected
service.
6.14.6 — Integrated Verifier
The verifier and Finality Sink may reside within one protected
controller.
Distinct protected state transitions may preserve the required
validation and effectuation relationship.
6.14.7 — Distributed Verifiers
Several authorized verifiers may evaluate different contract
dependencies or effects.
A protected aggregation procedure may require designated results or a
threshold under the applicable assurance policy.
Das Expires 29 April 2027 [Page 117]
Internet-Draft Execution-Finality Part 7: Tools October 2026
6.14.8 — Verifier Replacement
A replacement verifier must satisfy protected enrollment and
authorization.
6.14.9 — Compromise Limitation
An authenticated verifier can still be incorrect or compromised.
5.2.3.21. Source page 686 of the original specification
Additional protection depends upon the applicable trust model,
evidence quality, independent verification, and actual sink
enforcement.
6.15 — AUTHORITY CONTINUITY AND CONTRACT MIGRATION
6.15.1 — Original Authority
A Candidate Act receives scoped authority under an authorized effect
envelope and relevant action-contract state.
6.15.2 — Contract Evolution
A protected SCEE indicates that the current semantics may have
changed.
6.15.3 — Authority Suspension
Where the change may affect an unconsumed consequential operation,
the protected system may establish an SRF.
6.15.4 — Semantic Comparison
The verifier evaluates the current effect representation against the
authorized envelope.
6.15.5 — Verified Compatible Migration
Where compatibility is established, a PSMR may permit continued
operation under defined restrictions.
6.15.6 — New Contract-Bound Authority
The protected system may issue or activate revised scoped authority
bound to the current contract and permitted effect.
6.15.7 — Incompatible Expansion
Das Expires 29 April 2027 [Page 118]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Where the current operation exceeds prior scope, the protected system
withholds the effect unless suitable new authorization is
established.
6.15.8 — Narrowed Authority
Where the new operation is verified to be narrower, the system may
retain earlier authority only insofar as the mandatory functional and
safety predicates remain satisfied.
6.15.9 — No Automatic Privilege Enlargement
Contract migration cannot independently enlarge the original user's
authorized task scope.
6.15.10 — Protected Migration Consumption
A stale authorization may be invalidated or superseded during
migration so that it cannot be replayed against a different operation
version.
5.2.3.22. Source page 687 of the original specification
6.16 — CONTRACT EPOCHS AND TIME-OF-CHECK/TIME-OF-USE PROTECTION
A protected system may associate each relevant contract generation
with a PCE.
An operation authorized under one epoch may remain queued when the
applicable contract changes.
The actual Finality Sink determines the current relevant epoch before
effectuation.
If the authority references an earlier contract, the sink requires an
accepted compatibility migration or a currently valid pinned
implementation.
6.16.1 — Contract Pinning
A protected operation may be pinned to a verified implementation and
contract version.
The sink verifies that the actual executable function corresponds to
the pinned version.
6.16.2 — Compatible Upgrade
Das Expires 29 April 2027 [Page 119]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The system may permit a newer verified compatible contract through an
authenticated migration record.
6.16.3 — Incompatible Upgrade
The sink refuses use of the old authorization for the expanded or
materially changed operation.
6.16.4 — Concurrent Updates
A protected state transition may atomically mark earlier generations
stale for affected unconsumed operations.
6.16.5 — In-Flight Effects
An operation whose real consequence has already occurred is not
retroactively returned to Non-Effective State.
Further consequential phases or retries may require new authority.
6.16.6 — Stale Cache
A cached compatibility decision may be accepted only under its
applicable contract, environment, and authority epochs.
6.16.7 — Epoch Rollback
Protected anti-rollback state may prevent an attacker from restoring
an earlier permissive contract generation.
6.17 — ACTUAL FINALITY-SINK VERIFICATION
5.2.3.23. Source page 688 of the original specification
The Semantic Finality Sink independently obtains or reconstructs the
actual operation presented for effectuation.
The sink verifies the current operation against the applicable
Candidate Act, authorized effect envelope, current contract
generation, semantic compatibility evidence, resource identity, and
protected state.
The sink does not merely trust the upstream agent's declared tool
name.
The sink may obtain relevant actual parameters from a controlled
dispatcher, transaction buffer, hardware command queue, network
operation, or another protected effectuation interface.
Das Expires 29 April 2027 [Page 120]
Internet-Draft Execution-Finality Part 7: Tools October 2026
6.17.1 — Actual Operation Semantics
The sink determines the relevant current contract associated with the
actual operation.
6.17.2 — Compatibility Evidence
Where required, the sink verifies an authorized ECER or PSMR.
6.17.3 — Resource Identity
The sink checks the actual target and relevant resource version.
6.17.4 — Destination
The sink checks the actual destination or recipient.
6.17.5 — Transitive Effects
Where transitive effects are relevant and enforceable, the sink
checks the applicable dependency or downstream authorization state.
6.17.6 — Current Policy
The sink verifies current revocation, authority, and required policy
predicates.
6.17.7 — Protected Consumption
Where necessary, the sink atomically reserves or consumes scoped
authority before permitting the consequence.
6.17.8 — No Generic Approval Substitution
A generic statement that the tool remains compatible is insufficient
where the mandatory protocol requires operation-specific
authenticated compatibility evidence.
6.18 — PRINCIPAL EXECUTION WORKFLOW
Step 1 — Construct Candidate Act
The autonomous entity proposes a consequential operation.
5.2.3.24. Source page 689 of the original specification
Step 2 — Establish Authorized Effect Envelope
Das Expires 29 April 2027 [Page 121]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The protected system identifies the scope of the permitted real-world
or external consequence.
Step 3 — Bind Initial Contract
The applicable action-contract identity and generation are associated
with the authorization.
Step 4 — Establish Non-Effective Hold
The operation remains withheld where required.
Step 5 — Detect Current Contract State
The protected controller obtains the current action-contract and
implementation state.
Step 6 — Identify Semantic Evolution
A relevant contract change or environmental difference is identified.
Step 7 — Establish Semantic Fence
Where compatibility requires revalidation, the protected system
prevents premature consequential release.
Step 8 — Construct Current Effect Representation
The system obtains or derives the current security-relevant effect
representation.
Step 9 — Resolve Transitive Dependencies
Applicable downstream and asynchronous effects are identified
according to the selected assurance model.
Step 10 — Compare Against Authorized Envelope
The verifier evaluates the required effect-compatibility predicate.
Step 11 — Verify Technical Guarantees
Mandatory ordering, atomicity, idempotency, failure, and resource
conditions are evaluated where applicable.
Step 12 — Authenticate Compatibility Decision
Das Expires 29 April 2027 [Page 122]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An authorized verifier commits an ECER or equivalent protected
result.
Step 13 — Determine Authority Continuity
The protected system decides whether existing authority remains
valid, requires narrowing, or must be replaced.
Step 14 — Establish Compatible Migration
5.2.3.25. Source page 690 of the original specification
Where permitted, a PSMR or equivalent protected migration state is
committed.
Step 15 — Obtain Actual Pending Operation
The Finality Sink reconstructs the operation that is actually about
to be effectuated.
Step 16 — Verify Current Contract
The sink verifies that the actual operation corresponds to the
applicable authenticated contract state.
Step 17 — Verify Current Authority
The sink checks scope, compatibility, revocation, and protected
consumption state.
Step 18 — Permit or Withhold Effectuation
The sink permits the consequence only if all mandatory predicates
pass.
Step 19 — Record Effectuation Attempt
The system commits appropriate protected attempt state.
Step 20 — Optional Outcome Verification
Where the application requires evidence of actual completion, a
qualified observer may establish the corresponding outcome.
6.19 — REFERENCE PSEUDOCODE: SEMANTIC CHANGE DETECTION
FUNCTION DETECT_SEMANTIC_EVOLUTION( authorized_contract,
current_contract, current_environment ):
Das Expires 29 April 2027 [Page 123]
Internet-Draft Execution-Finality Part 7: Tools October 2026
REQUIRE VERIFY_AUTHORIZED_CONTRACT( authorized_contract )
REQUIRE VERIFY_CURRENT_CONTRACT_IDENTITY( current_contract )
IF CONTRACT_GENERATION_MATCHES( authorized_contract, current_contract
):
IF REQUIRED_ENVIRONMENT_MATCHES( current_environment ):
5.2.3.26. Source page 691 of the original specification
RETURN NO_RELEVANT_CHANGE
event = PROTECTED_COMMIT({ old_contract: HASH(authorized_contract),
current_contract: HASH(current_contract),
environment: HASH(current_environment),
event_type: SEMANTIC_REVALIDATION_REQUIRED,
protected_epoch: CURRENT_CONTRACT_EPOCH() })
ESTABLISH_SEMANTIC_REVALIDATION_FENCE( event )
RETURN event A matching generation or digest is sufficient only
within the specified identity and environmental assumptions.
6.20 — REFERENCE PSEUDOCODE: EFFECT COMPATIBILITY
FUNCTION VERIFY_EFFECT_COMPATIBILITY( candidate_act,
authorized_envelope, current_contract, actual_operation_context ):
REQUIRE VERIFY_CANDIDATE_ACT( candidate_act )
REQUIRE VERIFY_AUTHORIZED_ENVELOPE( authorized_envelope )
REQUIRE VERIFY_CURRENT_CONTRACT( current_contract )
current_effects = DERIVE_CURRENT_EFFECTS( current_contract,
5.2.3.27. Source page 692 of the original specification
actual_operation_context )
IF current_effects IS UNKNOWN: RETURN COMPATIBILITY_UNVERIFIED
Das Expires 29 April 2027 [Page 124]
Internet-Draft Execution-Finality Part 7: Tools October 2026
closure = DERIVE_REQUIRED_TRANSITIVE_CLOSURE( current_effects,
current_contract )
IF closure IS INCOMPLETE:
IF NOT VERIFY_DOWNSTREAM_EFFECT_CONTAINMENT( closure ):
RETURN COMPATIBILITY_UNVERIFIED
IF NOT EFFECTS_WITHIN_AUTHORIZED_ENVELOPE( current_effects, closure,
authorized_envelope ):
RETURN EFFECT_EXPANSION
IF NOT VERIFY_REQUIRED_GUARANTEES( current_contract,
authorized_envelope ):
RETURN GUARANTEE_DEGRADATION
IF NOT VERIFY_CURRENT_RESOURCE_IDENTITY( actual_operation_context,
authorized_envelope ):
RETURN RESOURCE_IDENTITY_CONFLICT
RETURN EFFECT_COMPATIBLE The function does not infer arbitrary
software semantics perfectly.
Its correctness depends upon the selected analysis, authenticated
evidence, and mandatory effectuation constraints.
6.21 — REFERENCE PSEUDOCODE: PROTECTED CONTRACT MIGRATION
FUNCTION MIGRATE_CONTRACT_AUTHORITY( original_authority,
5.2.3.28. Source page 693 of the original specification
old_contract, new_contract, compatibility_evidence ):
REQUIRE VERIFY_ORIGINAL_AUTHORITY( original_authority )
REQUIRE VERIFY_COMPATIBILITY_VERIFIER_IDENTITY(
compatibility_evidence )
REQUIRE VERIFY_ECER_AUTHENTICATION( compatibility_evidence )
REQUIRE VERIFY_ECER_CONTRACT_BINDING( compatibility_evidence,
old_contract, new_contract )
Das Expires 29 April 2027 [Page 125]
Internet-Draft Execution-Finality Part 7: Tools October 2026
REQUIRE VERIFY_CURRENT_CONTRACT_EPOCH()
IF compatibility_evidence.result NOT IN { EXACT_COMPATIBILITY,
VERIFIED_RESTRICTION, ENFORCEABLE_CONDITIONAL_COMPATIBILITY }:
RETURN REQUIRE_NEW_AUTHORIZATION
migration = PED.ATOMIC_COMMIT({ original_authority:
HASH(original_authority),
old_contract: HASH(old_contract),
new_contract: HASH(new_contract),
compatibility: HASH(compatibility_evidence),
permitted_effect_scope: COMPUTE_ALLOWED_INTERSECTION(),
new_contract_epoch: CURRENT_CONTRACT_EPOCH(),
5.2.3.29. Source page 694 of the original specification
stale_authority_fencing: ENABLED })
IF migration != COMMITTED: RETURN HOLD
RETURN migration.protected_reference A migration must not authorize
effects outside the original or otherwise validly amended authority.
6.22 — REFERENCE PSEUDOCODE: SEMANTIC FINALITY SINK
FUNCTION EFFECTUATE_CURRENT_CONTRACT_OPERATION( candidate_act,
authority, compatibility_reference, finality_sink ):
actual_operation = finality_sink.RECONSTRUCT_PENDING_OPERATION()
IF actual_operation IS NULL: RETURN DENY
current_contract = finality_sink.RESOLVE_CURRENT_ACTION_CONTRACT(
actual_operation )
REQUIRE VERIFY_CURRENT_CONTRACT_AUTHENTICITY( current_contract )
REQUIRE VERIFY_ORIGINAL_AUTHORIZED_ENVELOPE( candidate_act, authority
)
IF CONTRACT_CHANGED_SINCE_AUTHORIZATION( authority, current_contract
):
Das Expires 29 April 2027 [Page 126]
Internet-Draft Execution-Finality Part 7: Tools October 2026
REQUIRE finality_sink .VERIFY_PROTECTED_COMPATIBILITY(
compatibility_reference, current_contract, actual_operation )
5.2.3.30. Source page 695 of the original specification
REQUIRE finality_sink .VERIFY_ACTUAL_EFFECT_SCOPE( actual_operation,
authority )
REQUIRE finality_sink .VERIFY_REQUIRED_TRANSITIVE_EFFECT_CONTROL(
actual_operation )
REQUIRE finality_sink .VERIFY_CURRENT_AUTHORITY_AND_REVOCATION()
REQUIRE finality_sink .VERIFY_CONTRACT_EPOCH()
consumption = finality_sink.ATOMIC_CONSUME( authority,
actual_operation, current_contract )
IF consumption != SUCCESS: RETURN DENY
RETURN finality_sink.EFFECTUATE( actual_operation, consumption )
6.23 — REFERENCE PSEUDOCODE: TRANSITIVE EFFECT CLOSURE
FUNCTION EVALUATE_EFFECT_DEPENDENCY_CLOSURE( root_operation,
authenticated_dependency_graph, protected_policy ):
REQUIRE VERIFY_DEPENDENCY_GRAPH_AUTHENTICITY(
authenticated_dependency_graph )
visited = EMPTY_SET() pending = QUEUE(root_operation) effects =
EMPTY_EFFECT_SET()
WHILE pending NOT EMPTY:
REQUIRE WITHIN_PROTECTED_VERIFICATION_BUDGET()
5.2.3.31. Source page 696 of the original specification
node = pending.REMOVE()
IF node IN visited: CONTINUE
visited.ADD(node)
IF NOT VERIFY_NODE_CONTRACT(node): RETURN CLOSURE_UNVERIFIED
effects.ADD( GET_DECLARED_OR_ENFORCED_EFFECTS(node) )
Das Expires 29 April 2027 [Page 127]
Internet-Draft Execution-Finality Part 7: Tools October 2026
FOR EACH successor IN GET_EFFECT_DEPENDENCIES(node):
IF DEPENDENCY_UNKNOWN(successor): RETURN CLOSURE_UNVERIFIED
pending.ADD(successor)
IF NOT VERIFY_COVERAGE_ASSUMPTIONS( effects, protected_policy ):
RETURN CLOSURE_UNVERIFIED
RETURN PROTECTED_EFFECT_CLOSURE(effects) For systems with dynamic
recursion, unbounded callbacks, or opaque remote services, a
conservative abstract analysis or mandatory downstream enforcement
may replace exhaustive enumeration.
6.24 — SIMPLE EXAMPLE: REPORT SAVE FUNCTION CHANGES BEHAVIOR
6.24.1 — Original Authorization
A user authorizes an autonomous assistant to save a generated report
to a specified local storage directory.
The original Action Contract identifies a local storage write as the
permitted consequential effect.
6.24.2 — Original Tool Behavior
The function accepts:
save_report(document, destination) and writes the report to local
protected storage.
6.24.3 — Software Update
5.2.3.32. Source page 697 of the original specification
A later version preserves the same function name and input
parameters.
However, the updated implementation additionally synchronizes the
report to a remote server.
6.24.4 — Conventional Compatibility Result
An ordinary input-schema checker may classify the function as
compatible because the call structure has not changed.
6.24.5 — Protected Semantic Difference
Das Expires 29 April 2027 [Page 128]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The protected verifier identifies the new external transmission
effect.
The current effect representation now includes local storage and
remote data disclosure.
6.24.6 — Effect Compatibility
The original authorized envelope permits local storage only.
The new remote transmission exceeds that envelope.
6.24.7 — Finality Enforcement
The actual local storage operation may be permitted where
independently controllable.
The remote transmission remains withheld unless separately
authorized.
If the two effects are inseparable within the current implementation,
the combined operation is withheld.
6.24.8 — Technical Distinction
The system does not treat unchanged interface syntax as proof of
unchanged authority.
The protected decision concerns the actual consequential behavior.
6.25 — EXAMPLE: PAYMENT FUNCTION CHANGES DEFAULT DESTINATION
A user authorizes an autonomous agent to initiate a specified payment
to an approved recipient.
An earlier tool version requires the recipient identifier explicitly.
A later version permits the recipient field to be omitted and uses a
stored default account.
An agent invoking the new function may submit the same syntactic
request used earlier while reaching a different destination.
The protected system resolves the actual payment recipient at the
effectuation boundary.
The current Action Contract identifies the changed default-recipient
semantics.
Das Expires 29 April 2027 [Page 129]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A compatibility record is evaluated against the original approved
recipient.
5.2.3.33. Source page 698 of the original specification
The payment Finality Sink refuses an operation whose actual recipient
differs from the authorized envelope.
A tool's success response or valid software signature does not
authorize recipient substitution.
6.26 — EXAMPLE: INDIRECT DATA EXPORT THROUGH A DOWNSTREAM SERVICE
An autonomous assistant invokes a document-conversion service.
The originally authorized effect is conversion of a local document to
another local format.
A new service version invokes a downstream analytics service that
receives the document contents.
The top-level conversion API remains unchanged.
A protected effect-dependency graph identifies the newly introduced
downstream communication.
The compatibility verifier determines that the transitive effect
exceeds the authorized local-conversion envelope.
Where the downstream network path is controlled, the appropriate
Finality Sink refuses the unauthorized disclosure.
If the complete downstream service behavior cannot be verified, the
system does not assert complete semantic compatibility based merely
on the top-level contract.
The example illustrates the need for transitive effect evaluation and
actual enforcement coverage.
6.27 — EXAMPLE: COMPATIBLE INTERNAL IMPLEMENTATION UPDATE
An autonomous agent is authorized to update a particular storage
object.
The original service performs the operation using one internal data
structure.
Das Expires 29 April 2027 [Page 130]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A new version changes the internal storage algorithm without
expanding the permitted resource, destination, operation scope, or
required external effects.
Protected evidence establishes that the changed implementation
preserves the relevant consequential behavior and required
consistency guarantees.
The semantic verifier classifies the update as compatible under the
applicable assurance model.
A protected migration record permits continued use of the original
scoped authority for the specified operation.
The actual Finality Sink verifies the current resource identity and
operation.
This example illustrates that a secure system need not reject every
software update.
It may permit verified compatible evolution without unnecessary
repeated user approval.
5.2.3.34. Source page 699 of the original specification
6.28 — EXAMPLE: NARROWER OPERATION SEMANTICS
An agent receives authority to modify records within a specified
protected dataset.
A new tool version restricts modifications to a smaller subset.
The current operation's possible effects are therefore narrower.
However, the authorized workflow may require a particular record
update that the new version no longer supports.
The protected verifier separately evaluates effect containment and
mandatory functional requirements.
If the new behavior remains within the authorized scope and the
required operation can still be performed, authority continuity may
be permitted.
If the workflow's mandatory technical outcome is no longer possible,
the system may withhold the operation or request a new valid plan.
Das Expires 29 April 2027 [Page 131]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A narrower effect set is not automatically equivalent to full
workflow compatibility.
6.29 — EXAMPLE: ASYNCHRONOUS CALLBACK AFTER APPARENT COMPLETION
An autonomous system invokes a task-management tool.
The tool responds that the task was completed.
However, a newer version additionally schedules a background message
to an external recipient.
The message may be sent after the initial API request returns.
The protected Action Contract includes relevant asynchronous callback
semantics.
The effect-dependency controller identifies the scheduled message as
a separate consequential effect.
The messaging Finality Sink requires its own valid operation-specific
authorization or another authorized protected continuation condition.
The background message is not permitted solely because the initial
task returned success.
The architecture therefore addresses consequential effects whose
execution is temporally separated from the original invocation.
6.30 — EXAMPLE: HARDWARE COMMAND SEMANTICS AFTER FIRMWARE UPDATE
An autonomous device controller is authorized to move an actuator
within a specified operating envelope.
The device receives a firmware update.
5.2.3.35. Source page 700 of the original specification
A command previously interpreted as a relative movement is now
interpreted as an absolute target position.
The command name and numeric argument format remain unchanged.
The protected firmware or controller contract generation changes.
The semantic verifier determines that the current command
interpretation differs from the authorized operation.
Das Expires 29 April 2027 [Page 132]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The actuator Finality Sink verifies the actual meaning of the pending
command under the current firmware.
If the resulting physical effect falls outside the authorized
envelope, the movement remains disabled.
A current compatible authorization or explicit conversion rule may
permit the correct bounded movement.
The technical distinction concerns the actual physical command
semantics rather than syntax or firmware version alone.
6.31 — EXAMPLE: CROSS-PROVIDER AUTONOMOUS SERVICE UPDATE
An autonomous agent delegates a bounded operation to a remote
service.
The original authorization permits a specified storage modification.
The remote service later modifies its Action Contract to include
additional external notifications.
The protected system obtains authenticated current contract evidence.
A semantic verifier determines whether the added notifications are
within the delegated authority.
Where the actual downstream effect is controlled by a protected
destination-side sink, that sink requires the corresponding valid
authority.
If the remote service does not provide trustworthy evidence or
enforceable restrictions, the local controller cannot assert
comprehensive control over all remote effects merely because it
possesses a signed contract.
The system may instead refuse the operation or constrain the
authority exposed to the remote service.
This example preserves the distinction between authenticated remote
claims and actual enforcement.
6.32 — EXAMPLE: MODEL-GENERATED TOOL PARAMETER TRANSFORMATION
An autonomous agent requests a document export.
A tool adapter transforms the agent's arguments into another
protocol.
Das Expires 29 April 2027 [Page 133]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.2.3.36. Source page 701 of the original specification
A software update changes the adapter's transformation rules.
The resulting actual destination or document selection may differ
from the original Candidate Act.
The protected system associates the transformation with a verified
Action Contract.
The Finality Sink obtains the resulting actual request.
It verifies semantic and resource correspondence with the original
authorization.
A materially different transmission is rejected.
The protection applies even where the agent itself did not
deliberately request the changed consequence.
6.33 — PHYSICAL AND DISTRIBUTED IMPLEMENTATION VARIANTS
6.33.1 — Physically Separate Semantic Validator
A dedicated protected device may authenticate current Action
Contracts and issue compatible-evolution evidence to a downstream
effectuation controller.
6.33.2 — Integrated Semantic Finality Sink
The contract verifier and Finality Sink may reside in one protected
component.
6.33.3 — Operating-System Security Service
A protected service may mediate application operations and verify
current contract generations.
6.33.4 — Hardware Command Controller
A hardware controller may verify current firmware semantics before
actuation.
6.33.5 — Remote Contract Authority
An authorized remote component may authenticate contract descriptions
and compatibility results.
Das Expires 29 April 2027 [Page 134]
Internet-Draft Execution-Finality Part 7: Tools October 2026
6.33.6 — Distributed Service Graph
Different domains may contribute authenticated effect-dependency
information.
6.33.7 — Protected Credential Broker
A credential broker may require current effect compatibility before
exercising reusable credentials.
6.33.8 — Application Function Dispatcher
A protected dispatcher may enforce compatibility for named
application operations.
6.33.9 — Network Egress Finality Sink
5.2.3.37. Source page 702 of the original specification
A network gateway may verify that actual transmissions remain within
the authorized effect envelope.
6.33.10 — Storage Commit Finality Sink
A storage controller may verify actual resource identity, version,
and mutation semantics.
6.33.11 — Accelerator Output Boundary
A protected controller may govern accelerator-originated commands
whose effect semantics change across runtime or firmware versions.
6.33.12 — Fully Integrated Controller
The Candidate Act, contract registry, semantic verifier, and Finality
Sink may all reside within one protected processor or controller.
The necessary protected state transitions remain enforced.
6.34 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
6.34.1 — Unchanged Schema, New External Effect
An attacker introduces a remote transmission while preserving the
tool's schema.
The protected verifier evaluates consequential behavior rather than
syntax alone.
Das Expires 29 April 2027 [Page 135]
Internet-Draft Execution-Finality Part 7: Tools October 2026
6.34.2 — Tool-Name Reuse
A malicious implementation reuses an approved tool identifier.
The system verifies the authenticated current contract and
implementation binding.
6.34.3 — False Contract Declaration
A tool provider signs an inaccurate effect manifest.
The protected assurance model requires suitable enforcement or
independent evidence before claiming the declared behavior is
complete.
6.34.4 — Default-Parameter Manipulation
A new default changes the actual target or destination.
The sink verifies the effective actual parameters.
6.34.5 — Contract Downgrade
An attacker supplies an earlier permissive contract while executing a
new implementation.
The protected epoch and implementation binding reject the mismatch.
5.2.3.38. Source page 703 of the original specification
6.34.6 — Version-Number Spoofing
A malicious component advertises an approved version number without
possessing the corresponding authenticated identity or implementation
state.
The verifier rejects unsupported identity binding.
6.34.7 — Transitive Service Injection
A downstream service is added to the execution path.
The effect-closure mechanism identifies or constrains relevant
downstream effects.
6.34.8 — Hidden Asynchronous Callback
A new operation schedules an undisclosed background effect.
Das Expires 29 April 2027 [Page 136]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The architecture requires applicable downstream finality enforcement
or sufficient trusted closure evidence.
6.34.9 — Resource Alias Substitution
An unchanged operation refers to a different resource after an alias
mapping changes.
The sink verifies current protected target identity.
6.34.10 — Destination Redirection
An external endpoint redirects the operation to a different
destination.
The controlled network effectuation boundary verifies the final
permitted destination under its defined mediation capabilities.
6.34.11 — Changed Idempotency
A software update introduces additional effects during repeated
execution.
The system reevaluates retry authority and actual-effect uncertainty.
6.34.12 — Changed Transaction Atomicity
An operation formerly committed atomically becomes a sequence of
independently consequential writes.
The compatibility verifier checks applicable required guarantees.
6.34.13 — Privilege Expansion
A current contract requests additional credentials or privileged
operations.
The protected authority does not automatically expand.
6.34.14 — Stale Contract Cache
5.2.3.39. Source page 704 of the original specification
An agent uses a cached compatibility record after a relevant update.
The sink verifies current epochs and freshness.
6.34.15 — Post-Validation Contract Swap
Das Expires 29 April 2027 [Page 137]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The service implementation changes after compatibility verification
but before effectuation.
The sink checks current implementation or contract generation, or
enforces an appropriate pinned operation path.
6.34.16 — Incomplete Dependency Closure
A contract omits a relevant downstream effect.
The system avoids treating incomplete evidence as proof of complete
compatibility.
6.34.17 — Malicious Semantic Verifier
A verifier approves an incompatible contract.
The protection depends upon authenticated verifier roles, trusted
implementation, independent checking where required, and sink-side
enforcement.
6.34.18 — Verifier Identity Forgery
An attacker copies a verifier identifier.
The sink requires valid cryptographic authentication.
6.34.19 — Unauthorized Verifier Role
A verifier authorized for one effect domain approves another.
The sink checks its current authorization profile.
6.34.20 — Compatibility Receipt Replay
A valid compatibility record is reused for another Candidate Act or
contract generation.
Protected operation, contract, and epoch binding prevent unauthorized
reuse.
6.34.21 — Finality-Sink Bypass
An agent invokes an alternative effect-capable interface.
The relevant enforcement coverage must require equivalent protected
authorization.
Das Expires 29 April 2027 [Page 138]
Internet-Draft Execution-Finality Part 7: Tools October 2026
6.34.22 — Direct Hardware Bypass
A device accepts an effect-capable command through an unmediated
path.
5.2.3.40. Source page 705 of the original specification
Hardware-level protection requires the actual device controller to
enforce the applicable finality predicates.
6.34.23 — Invalid Delegation Expansion
A downstream agent attempts to use evolved tool semantics for effects
outside its delegated authority.
The destination sink verifies current scope and delegation lineage.
6.34.24 — Stale Authority After Revocation
An old contract-compatible capability is exercised after the relevant
authority has been revoked.
The sink verifies current protected authority state.
6.34.25 — Parser Canonicalization Ambiguity
Different components interpret encoded contract or command fields
differently.
The protected protocol requires an unambiguous canonical
representation or rejects unsupported forms.
6.34.26 — Excessive Semantic-Analysis Work
An attacker provides a complex dependency graph intended to exhaust
verification resources.
The verifier enforces protected work limits and conservative failure
behavior.
6.34.27 — Software Update During Execution
A function changes while an operation is queued or in progress.
The protected system distinguishes unexecuted effects from effects
already completed and applies valid epoch or recovery rules.
6.34.28 — Remote Contract Misrepresentation
Das Expires 29 April 2027 [Page 139]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A remote service authenticates a contract inconsistent with its real
behavior.
The system limits its guarantees to verified evidence and covered
remote effectuation paths.
6.34.29 — Compromised Contract Registry
An attacker modifies current contract entries.
Protected registry authentication, version continuity, and
authoritative state verification may detect or constrain the
modification under the applicable threat model.
6.34.30 — Recovery Through Incompatible Tool
An agent attempts to compensate for a failed operation using a tool
whose current semantics differ from the originally expected recovery
behavior.
5.2.3.41. Source page 706 of the original specification
The recovery Candidate Act requires current effect-semantic
validation.
6.34.31 — Partial Side Effect Before Rejection
A top-level operation produces one real effect before a later
incompatible effect is detected.
The completed effect remains real.
The system records its actual state and governs remaining or
corrective operations separately.
6.34.32 — Unknown Future Interface
A newly introduced hardware or software interface produces effects
outside the known coverage model.
The system cannot claim universal non-bypassability until the
corresponding path is controlled or otherwise constrained.
6.35 — PROTECTED FAILURE AND RECOVERY BEHAVIOR
6.35.1 — Failure Before Effectuation
Das Expires 29 April 2027 [Page 140]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An incompatible or unverified operation remains non-effective through
the governed Finality Sink.
6.35.2 — Failure During Contract Verification
Incomplete mandatory verification does not become approval.
6.35.3 — Failure During Migration
The original authority remains subject to its current validity state.
An incomplete migration does not automatically authorize the new
contract.
6.35.4 — Crash After Migration Commitment
The protected system may recover the valid migration state using
authenticated records and protected epochs.
6.35.5 — Crash After Actual Effect
The system records the effectuation attempt and distinguishes known
completion from unknown outcome.
6.35.6 — Contract Change During a Multi-Phase Workflow
Uncompleted phases may require updated compatibility verification.
Already completed real effects are not retroactively erased.
6.35.7 — Reversion to Earlier Implementation
5.2.3.42. Source page 707 of the original specification
The system may return to an earlier verified contract where supported
by protected implementation and authority state.
Rollback is not automatically allowed merely because the earlier
software was once valid.
6.35.8 — Separate Recovery Candidate Act
A corrective operation may require new protected authority and
current Action Contract verification.
6.35.9 — Optional Causal Receipt
Das Expires 29 April 2027 [Page 141]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Where CW-2 receipt-gated continuation applies, the accepted actual-
effect receipt remains a separate mandatory causal condition.
An ECER cannot replace the required real-effect receipt merely
because it verifies software compatibility.
6.36 — NON-LIMITING PROPOSED FEASIBILITY EXPERIMENTS
The following experiments are proposed and are not represented as
having been performed.
Experiment 1 — Unchanged Interface Schema: Update a tool without
changing its schema but introduce a new external effect. Verify
detection.
Experiment 2 — Changed Default Destination: Modify the default
recipient or endpoint and verify actual target mismatch rejection.
Experiment 3 — Compatible Internal Refactoring: Change implementation
details without changing the authorized effect and verify compatible
migration.
Experiment 4 — Verified Effect Restriction: Narrow the possible
resource scope and verify the applicable compatibility decision.
Experiment 5 — Required Functional Guarantee: Narrow an operation
while removing a required outcome and verify that compatibility is
not assumed automatically.
Experiment 6 — Transitive Effect Addition: Add a downstream service
invocation and verify effect-closure reevaluation.
Experiment 7 — Asynchronous Callback: Introduce a delayed effect and
verify downstream finality enforcement.
Experiment 8 — Contract Downgrade: Present an obsolete contract
against a newer implementation and verify epoch mismatch detection.
Experiment 9 — Contract Identity Forgery: Substitute an
unauthenticated contract identifier and verify rejection.
Experiment 10 — Unauthorized Verifier: Use a cryptographically signed
compatibility result from an unauthorized verifier and verify
rejection.
Das Expires 29 April 2027 [Page 142]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.2.3.43. Source page 708 of the original specification
Experiment 11 — Verifier Key Substitution: Copy the expected verifier
identifier while changing the signing key and verify rejection.
Experiment 12 — ECER Replay: Reuse a compatibility record for another
Candidate Act and verify mismatch rejection.
Experiment 13 — Queued Operation Update: Update a tool while an
earlier operation remains queued and verify correct authority
handling.
Experiment 14 — Atomic Migration: Simulate failure during authority
migration and verify protected state consistency.
Experiment 15 — Resource Alias Change: Rebind a resource alias and
verify current target correspondence.
Experiment 16 — Protocol Adapter Update: Change the transformation
between a tool request and the actual outgoing operation.
Experiment 17 — Changed Retry Semantics: Modify an operation to
produce an additional effect on retry and verify renewed retry
constraints.
Experiment 18 — Transaction Atomicity Change: Replace one atomic
operation with several partial commits and evaluate required
guarantee preservation.
Experiment 19 — Firmware Command Change: Alter a command's physical
meaning through firmware and verify actual sink rejection of
incompatible authority.
Experiment 20 — Remote Contract Evidence: Evaluate compatibility
using authenticated remote service contract evidence and identify
unsupported assurance assumptions.
Experiment 21 — Unknown Downstream Dependency: Introduce an opaque
downstream operation and verify conservative failure or mandatory
separate downstream enforcement.
Experiment 22 — Alternate API Bypass: Attempt the effect through
another covered application interface and verify equivalent finality
conditions.
Experiment 23 — Direct Hardware Effect: Attempt the effect through a
lower-level hardware path and examine actual enforcement coverage.
Das Expires 29 April 2027 [Page 143]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Experiment 24 — Semantic Proof Exhaustion: Supply a large or
recursive dependency graph and verify bounded validation work.
Experiment 25 — Protected State Rollback: Restore an earlier contract
epoch and verify anti-rollback behavior.
Experiment 26 — Cryptographic Migration Record: Verify an
authenticated compatible migration accepted by the actual Finality
Sink.
Experiment 27 — One-Component Architecture: Implement contract
verification and final effectuation within one protected controller.
Experiment 28 — Distributed Architecture: Separate the contract
verifier and sink across authenticated domains.
5.2.3.44. Source page 709 of the original specification
Experiment 29 — Multi-Phase Causal Integration: Combine contract
evolution checks with an actual-effect receipt required under CW-2.
Experiment 30 — Software Update Coverage: Introduce a new
effectuation interface during an update and verify relevant path
reattestation.
Experiment 31 — Recovery Operation: Execute a separately authorized
recovery Candidate Act after an incompatible partial effect.
Experiment 32 — No Blockchain: Demonstrate authenticated contract
migration and sink verification without a ledger.
6.37 — FEASIBILITY AND PHOSITA IMPLEMENTATION
6.37.1 — Present-Day Reference Prototype
A reference implementation may comprise a tool registry, a Candidate
Act gateway, an authenticated contract store, a semantic comparison
service, an authority controller, and a controlled effectuation sink.
The tool registry may contain two versions of a sample operation.
The versions may share identical input schemas while having different
effect manifests.
The semantic verifier compares current effects with the stored
authorized envelope.
The sink refuses incompatible operations.
Das Expires 29 April 2027 [Page 144]
Internet-Draft Execution-Finality Part 7: Tools October 2026
6.37.2 — Trusted Effect Coverage
For a meaningful prototype, effect-capable operations must be routed
through controlled interfaces.
A software-only prototype can demonstrate the causal authorization
and compatibility checks under its stated trust model.
It does not independently establish resistance to a fully compromised
privileged operating system.
6.37.3 — Conservative Effect Manifests
A practical implementation may require every controlled external
effect to be represented by a typed descriptor.
The effect verifier compares these descriptors rather than attempting
unrestricted semantic inference over arbitrary software.
6.37.4 — Runtime Instrumentation
A controlled test environment may instrument network, storage,
process, and device operations to obtain evidence concerning the
implementation's actual effects.
Such instrumentation can identify observed behavior, but exhaustive
guarantees require further stated assumptions.
5.2.3.45. Source page 710 of the original specification
6.37.5 — Protected Compatibility Cache
The system may cache verified compatibility results indexed by
contract generation, resource identity, authorized envelope, and
environment epoch.
This can reduce repeated verification overhead.
6.37.6 — Incremental Dependency Analysis
Where only one downstream dependency changes, the protected verifier
may recompute affected portions of the effect-dependency closure.
6.37.7 — Hardware Implementation
A device controller may maintain contract generation and authorized
command descriptors in protected registers or firmware state.
Das Expires 29 April 2027 [Page 145]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The controller may compare the current actual command against the
authorized effect envelope.
6.37.8 — Cross-Domain Implementation
A remote service may authenticate current contract state to the
requesting domain.
The receiving Finality Sink may enforce the applicable operation-
specific restrictions.
6.37.9 — Performance Considerations
Contract-change detection may be performed when a relevant update
occurs.
Finality-time verification may then use compact authenticated
compatibility state rather than recomputing the entire dependency
closure for every command.
6.37.10 — Technical Limits
General semantic equivalence of arbitrary programs may be undecidable
or computationally impractical.
The disclosed system therefore uses sufficiently defined effect
models, conservative approximations, authenticated evidence, and
mandatory enforcement boundaries.
The architecture does not depend upon a claim of perfect automated
understanding of arbitrary software behavior.
6.38 — OPTIONAL ADVANCED FUTURE-ORIENTED TECHNICAL CONCEPTS
6.38.1 — Dynamic Autonomous Tool Ecosystems
A future autonomous system may discover tools and operation contracts
at runtime.
The protected architecture may evaluate each newly introduced effect-
capable contract before permitting consequential use.
5.2.3.46. Source page 711 of the original specification
6.38.2 — Cross-Provider Agent Protocols
Several independently administered agents may invoke services through
a shared interoperability interface.
Das Expires 29 April 2027 [Page 146]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The receiving domain may verify current action semantics and scope at
its own Finality Sink.
6.38.3 — Neural Tool Selection
A model may dynamically select among tools with similar stated
functionality.
The protected system may compare the actual consequential semantics
independently of the model's tool-selection preference.
6.38.4 — Evolving Hardware Accelerators
An accelerator command's behavior may change after firmware or
runtime updates.
A protected controller may require compatibility between authorized
command semantics and the actual hardware effect.
6.38.5 — Autonomous Edge-to-Cloud Migration
A task may migrate between local and remote execution environments.
The protected system may verify that the destination route preserves
the authorized external effect.
6.38.6 — Confidential Service Execution
A confidential computing service may authenticate its implementation
identity.
The protected finality architecture may additionally require current
effect compatibility before external output release.
6.38.7 — Privacy-Preserving Compatibility Proof
A protected verifier may establish selected compatibility predicates
without revealing unnecessary internal implementation details.
The proof must be bound to the current relevant implementation and
actual effect.
6.38.8 — Machine-Verifiable Semantic Contracts
A future tool ecosystem may provide richer machine-verifiable effect
manifests identifying direct and transitive operations.
Das Expires 29 April 2027 [Page 147]
Internet-Draft Execution-Finality Part 7: Tools October 2026
CW-1 and the present embodiment may use those manifests without
relying upon a particular protocol or vendor.
6.38.9 — Autonomous Communication Infrastructure
Network-management agents may use evolving operations to modify
routing, radio parameters, or service configuration.
5.2.3.47. Source page 712 of the original specification
The current control-plane Finality Sink may verify actual command
semantics against the original authorization.
6.38.10 — Spatial and Robotic Computing
A physical command may be interpreted according to current coordinate
frames, device firmware, or spatial registration.
A protected controller may require semantic correspondence between
the authorized and actual physical effect.
6.38.11 — Future Programmable Hardware
A newly programmable peripheral may expose effect-capable commands
absent from earlier software designs.
The architecture may require authenticated contract registration and
finality-path coverage.
6.38.12 — Post-Quantum Authentication Migration
The cryptographic mechanisms authenticating contracts, verifiers, and
finality authority may be updated to suitable future algorithms.
Such migration does not independently change the required semantic
authorization relationship.
6.38.13 — Cross-Domain Effect Closure
A workflow may invoke effects across multiple administrative domains.
Each domain may provide authenticated effect-compatibility evidence
or enforce its consequential operations independently.
6.38.14 — Selective Reauthorization
Das Expires 29 April 2027 [Page 148]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Where only one newly introduced effect exceeds original scope, the
protected system may request authorization limited to that effect
rather than requiring unrestricted reapproval of the entire workflow.
6.38.15 — Effect-Specific Runtime Adaptation
A system may select a technically compatible implementation path when
one tool version becomes incompatible.
The alternative path must satisfy current operation identity, effect
scope, and finality requirements.
6.39 — OPTIONAL INVENTIVE TECHNICAL COMBINATIONS
6.39.1 — Version-Aware Finality Authority
Previously issued finality authority is bound to verified action-
contract semantics and cannot be exercised after a material
incompatible change.
5.2.3.48. Source page 713 of the original specification
6.39.2 — Transitive Effect Compatibility
A protected verifier evaluates direct and relevant downstream effects
before authorizing a changed operation.
6.39.3 — Semantic Contract and Resource Identity
The system binds evolving action semantics to current authenticated
target identity.
6.39.4 — Contract Evolution and Credential Release
A protected credential broker refuses credential exercise where the
current operation contract expands beyond the authorized effect.
6.39.5 — Contract Evolution and Cross-Agent Conflict
An operation's updated effect footprint may alter its compatibility
with other agents' pending operations.
The protected conflict controller may reevaluate reservations
accordingly.
6.39.6 — Contract Evolution and Causal Continuation
Das Expires 29 April 2027 [Page 149]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A successor operation may require both a validator-accepted earlier
real-effect receipt and current compatible action-contract semantics.
The receipt does not authorize an expanded operation version.
6.39.7 — Contract Evolution and Privacy Composition
A new tool version may introduce additional data disclosure.
A protected privacy controller may evaluate the change against
cumulative exposure state.
6.39.8 — Contract Evolution and Device Migration
A migrated operation may execute under a different tool
implementation.
The destination Finality Sink verifies semantic compatibility and
current ownership authority.
6.39.9 — Contract Evolution and Hardware Resource Allocation
A new operation version may alter accelerator or device-resource
demands.
The protected resource controller may require current allocation and
effect-semantic authority.
6.39.10 — Contract Evolution and Enforcement Coverage
A new effect-capable path may be introduced by an update.
The protected system may withhold affected authority until the new
path is brought under mandatory finality enforcement.
5.2.3.49. Source page 714 of the original specification
6.40 — INDUSTRIAL APPLICABILITY
6.40.1 — Autonomous AI Agents
The architecture may protect agent-invoked tools whose behavior
changes over time.
6.40.2 — Enterprise Workflow Systems
It may preserve operation-specific authority across application and
service updates.
Das Expires 29 April 2027 [Page 150]
Internet-Draft Execution-Finality Part 7: Tools October 2026
6.40.3 — Cloud API Services
It may govern consequential operations whose API or downstream
effects change during deployment.
6.40.4 — Mobile and Desktop Assistants
It may verify current action semantics before file transmission,
application invocation, or privileged system operations.
6.40.5 — Financial Infrastructure
It may prevent changed transaction semantics, destinations, or retry
behavior from bypassing earlier authorization.
6.40.6 — Storage Systems
It may preserve protected resource identity and commit semantics
across software upgrades.
6.40.7 — Telecommunications
It may control network-configuration commands whose meaning changes
across software or firmware generations.
6.40.8 — Robotics and Industrial Control
It may verify current physical command semantics before consequential
actuation.
6.40.9 — Hardware Accelerators
It may govern changing accelerator command behavior and effect-
capable interfaces.
6.40.10 — Cross-Provider Services
It may permit distributed autonomous operations only within current
valid effect-specific authority.
6.40.11 — Confidential Computing
It may distinguish authenticated computation from permission to
produce changed external effects.
6.40.12 — Future Autonomous Infrastructure
Das Expires 29 April 2027 [Page 151]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.2.3.50. Source page 715 of the original specification
It may provide a reusable protected semantic-compatibility layer for
evolving tools, applications, services, and effect-capable hardware.
The industrial utility lies in preserving authorized consequential
behavior despite changes in computational implementation.
6.41 — DISTINCTION FROM CONVENTIONAL SYSTEMS AND INVENTIVE-STEP FOCUS
6.41.1 — Not Merely Schema Compatibility
An unchanged schema does not establish that an operation's
consequential behavior remains authorized.
The present principal implementation binds finality to verified
effect semantics.
6.41.2 — Not Merely Software Version Checking
A version identifier indicates a software generation.
The protected architecture determines whether the current effects
remain within a previously authorized envelope.
6.41.3 — Not Merely Software Attestation
Attestation may authenticate implementation identity.
The present embodiment may additionally require that the
implementation's relevant effects are authorized and that the actual
sink enforces the result.
6.41.4 — Not Merely Regression Testing
Regression testing may identify behavioral changes.
The present embodiment may use such evidence but additionally binds
current compatibility to protected execution authority at the actual
finality boundary.
6.41.5 — Not Merely Fine-Grained Authorization
A fine-grained authorization can specify permitted actions and
resources.
The proposed mechanism addresses whether that authorization remains
valid when the action's current consequential meaning evolves.
Das Expires 29 April 2027 [Page 152]
Internet-Draft Execution-Finality Part 7: Tools October 2026
6.41.6 — Not Merely a Policy Recommendation
The semantic verifier's decision is required by the actual
effectuation controller under the selected protected implementation.
6.41.7 — Candidate Objective Technical Problem
A candidate objective technical problem is:
5.2.3.51. Source page 716 of the original specification
How to preserve or appropriately invalidate protected operation-
specific execution authority when the semantic behavior of an effect-
capable software or hardware interface changes, by verifying the
current direct and relevant transitive effects against an authorized
effect envelope and enforcing the resulting compatibility condition
at the actual Finality Sink.
6.41.8 — Candidate Technical Solution
The proposed solution may comprise:
An authenticated original Action Contract;
A protected authorized effect envelope;
A detected semantic evolution event;
A current effect representation;
A protected compatibility comparison;
Authenticated effect-compatibility evidence;
Protected authority migration or invalidation;
And actual Finality-Sink verification of the current consequential
operation.
6.41.9 — Principal Technical Interaction
The original authority defines the permitted consequence.
The current contract identifies the presently available effect
semantics.
The semantic verifier evaluates the difference.
Das Expires 29 April 2027 [Page 153]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The protected authority controller preserves, restricts, or
invalidates prior authority accordingly.
The Finality Sink independently verifies the current operation
against the resulting protected authority.
This interaction is stronger than merely recording that a software
interface has changed.
6.41.10 — Transitive Effect Differentiation
A narrower additional technical kernel may require compatibility
evaluation over direct and downstream effects, together with finality
enforcement at the corresponding consequential interfaces.
6.41.11 — Time-of-Check/Time-of-Use Differentiation
Another narrower kernel may require contract-epoch fencing and actual
sink-time verification, preventing an operation authorized under one
semantic generation from silently executing under another.
6.41.12 — Conditional Compatibility Differentiation
5.2.3.52. Source page 717 of the original specification
Another implementation may permit a changed contract only for a
protected subset of invocations whose actual possible effects remain
within the original authorized envelope.
6.41.13 — Prior-Art Qualification
Versioned interfaces, contract checking, semantic refinement, effect
systems, access-control scopes, software provenance, attestation, and
time-of-check/time-of-use protections are established areas of prior
art.
The candidate inventive step must therefore reside in the specific
protected combination and mandatory consequential-boundary
enforcement actually claimed.
6.41.14 — Hindsight Analysis
An inventive-step assessment should identify the closest prior art
and determine whether its teachings provide or render obvious the
claimed effect-semantic compatibility and finality authority
relationship.
Das Expires 29 April 2027 [Page 154]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The mere existence of individual known mechanisms does not
automatically establish the entire claimed relationship.
Conversely, adding known verification stages in an expected manner
may be obvious.
A credible inventive-step analysis must focus on the precise data
dependencies, protected state transitions, effect coverage, and
technical results.
6.42 — OPTIONAL IMPLEMENTATION VARIATIONS
Variation 6.A — Same-Schema Semantic Change: A tool preserves its
schema while changing actual consequential behavior.
Variation 6.B — Default-Parameter Evolution: Changes to omitted or
default arguments trigger protected effect-compatibility
verification.
Variation 6.C — Direct Effect Comparison: A protected verifier
compares directly observable or declared consequential effects.
Variation 6.D — Transitive Effect Comparison: Relevant downstream
effect dependencies are included in compatibility evaluation.
Variation 6.E — Asynchronous Effect Comparison: Delayed jobs,
callbacks, or scheduled operations are incorporated where required.
Variation 6.F — Contract Epoch Binding: Authority is associated with
an authenticated contract generation.
Variation 6.G — Contract-Pinned Execution: The protected operation
executes only under its approved contract version.
Variation 6.H — Verified Compatible Upgrade: Earlier authority may
continue under a sufficiently verified compatible new version.
5.2.3.53. Source page 718 of the original specification
Variation 6.I — Verified Effect Restriction: Narrower compatible
semantics may permit continued scoped authority.
Variation 6.J — Conditional Subset Compatibility: Only an enforceable
authorized subset of a broader new contract may be used.
Variation 6.K — Expanded-Effect Reauthorization: A newly introduced
consequential effect requires new valid authorization.
Das Expires 29 April 2027 [Page 155]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Variation 6.L — Incompatible Contract Fence: An unverified or
expanded contract causes the governed effect to be withheld.
Variation 6.M — Authenticated Semantic Difference Record: A protected
verifier commits the relevant consequential changes.
Variation 6.N — Cryptographically Identified Verifier: Compatibility
acceptance is bound to an authorized verifier identity.
Variation 6.O — Physically Separate Verifier: Semantic verification
occurs on an independent protected device.
Variation 6.P — Integrated Verifier and Sink: One protected component
contains logically distinct verification and effectuation functions.
Variation 6.Q — Distributed Semantic Verifiers: Multiple domains
contribute authenticated compatibility evidence.
Variation 6.R — Protected Resource Identity Binding: Actual resources
are checked against the authorized effect envelope.
Variation 6.S — Destination Compatibility: Changed recipients or
endpoints require protected verification.
Variation 6.T — Privilege Compatibility: Changed credential or
privilege requirements are compared with prior authority.
Variation 6.U — Idempotency Compatibility: Changes to retry effects
are evaluated before repeat execution.
Variation 6.V — Atomicity Compatibility: Changed transaction
guarantees are checked against required protected conditions.
Variation 6.W — Failure-Semantics Compatibility: Partial-effect and
failure behavior participate in authorization continuity.
Variation 6.X — Protected Dependency Closure: Relevant downstream
effects are represented in a protected closure.
Variation 6.Y — Runtime Effect Observation: Actual monitored effects
supplement contract evidence under defined assurance limitations.
Variation 6.Z — Static Effect Analysis: Suitable analysis contributes
conservative possible-effect evidence.
Das Expires 29 April 2027 [Page 156]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.2.3.54. Source page 719 of the original specification
Variation 6.AA — Trusted Effect Manifest: An authenticated effect
description is provided by an authorized source.
Variation 6.AB — Hardware Command Evolution: Firmware or device-
command semantics are bound to finality authority.
Variation 6.AC — Network Effect Evolution: Newly introduced
transmissions are subjected to appropriate network finality
enforcement.
Variation 6.AD — Storage Effect Evolution: Storage mutation semantics
and resource identities are verified.
Variation 6.AE — Financial Effect Evolution: Transaction destination,
amount, and retry behavior are verified.
Variation 6.AF — Cross-Provider Contract Evolution: Remote service
semantic changes trigger applicable authority revalidation.
Variation 6.AG — Cross-Device Contract Continuity: Migrated workloads
verify destination-side tool semantics.
Variation 6.AH — Protected Credential Broker Integration: Credential
use requires current compatible operation semantics.
Variation 6.AI — Protected Conflict-Arbitration Integration: Changed
effects trigger reevaluation of cross-agent reservations.
Variation 6.AJ — Receipt-Gated Continuation Integration: CW-2 causal
receipts remain mandatory where required after contract evolution.
Variation 6.AK — Privacy-Composition Integration: Additional
disclosure effects are checked against cumulative privacy state.
Variation 6.AL — Resource Allocation Integration: Changed
computational resource requirements are evaluated under applicable
protected grants.
Variation 6.AM — Enforcement-Coverage Reattestation: New effect-
capable interfaces require appropriate finality-path validation.
Variation 6.AN — Contract Rollback Protection: Older insecure
contract states cannot be silently restored.
Das Expires 29 April 2027 [Page 157]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Variation 6.AO — Selective Reauthorization: Only newly introduced
consequential effects require additional approval where technically
separable.
Variation 6.AP — Privacy-Preserving Compatibility Proof: A verifier
establishes a defined effect relation without exposing unnecessary
internal details.
Variation 6.AQ — Protected Compatibility Cache: Reusable decisions
remain bound to current contract and authority epochs.
Variation 6.AR — Incremental Semantic Revalidation: Only affected
dependency subgraphs are reevaluated where sound under the selected
model.
5.2.3.55. Source page 720 of the original specification
Variation 6.AS — No Blockchain Requirement: Compatibility evidence
may be maintained through authenticated protected records or internal
state.
Variation 6.AT — Single-Component Enforcement: Contract comparison
and finality control may be performed within one protected component.
Variation 6.AU — Future Hardware Neutrality: The semantic finality
architecture may apply to new effect-capable hardware interfaces
without dependence upon a particular device implementation.
These variations may be implemented individually or in compatible
combinations.
They do not imply that every variation constitutes a separately
patentable invention.
6.43 — SUPPORT FOR POTENTIAL CLAIMED SUBJECT MATTER
The following candidate technical limitations may be considered in
claim drafting.
Aspect 1: An operation-specific protected authorized effect envelope.
Aspect 2: An authenticated Action Contract associated with a
Candidate Act.
Aspect 3: A protected semantic contract generation or epoch.
Aspect 4: Detection of a material change to current operation
semantics.
Das Expires 29 April 2027 [Page 158]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Aspect 5: Protected comparison of direct consequential effects.
Aspect 6: Protected comparison of relevant transitive consequential
effects.
Aspect 7: Inclusion of asynchronous or scheduled downstream effects
in a compatibility predicate.
Aspect 8: Verification of current resource identity against an
authorized envelope.
Aspect 9: Verification of actual destination or recipient continuity.
Aspect 10: Verification of privilege continuity.
Aspect 11: Verification of operation quantity and scope continuity.
Aspect 12: Verification of required ordering or atomicity guarantees.
Aspect 13: Verification of current idempotency or retry semantics.
Aspect 14: A cryptographically authenticated semantic-compatibility
decision.
Aspect 15: A uniquely identified authorized semantic verifier.
Aspect 16: A protected semantic revalidation fence.
Aspect 17: Protected invalidation of stale authority after
incompatible contract evolution.
Aspect 18: Protected migration of earlier authority to a verified
compatible new contract.
5.2.3.56. Source page 721 of the original specification
Aspect 19: Conditional compatibility limited to a specifically
enforceable invocation subset.
Aspect 20: Preservation of original task scope during compatibility
migration.
Aspect 21: Binding compatibility evidence to a designated Finality
Sink.
Aspect 22: Actual sink-side reconstruction of the pending operation.
Das Expires 29 April 2027 [Page 159]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Aspect 23: Sink-time verification of current action-contract
generation.
Aspect 24: Sink-time verification of actual effect compatibility.
Aspect 25: Protected atomic consumption under current contract
authority.
Aspect 26: Cross-domain authenticated compatibility evidence.
Aspect 27: Firmware or hardware command-semantics compatibility.
Aspect 28: Dynamic tool-discovery integration.
Aspect 29: Protected dependency-closure revalidation after a
downstream update.
Aspect 30: Protected contract-epoch anti-rollback.
Aspect 31: Integration with a credential-release Finality Sink.
Aspect 32: Integration with protected cross-agent effect-conflict
state.
Aspect 33: Integration with IEV receipt-constituted causal
continuation.
Aspect 34: Integration with cumulative privacy exposure constraints.
Aspect 35: Integration with protected resource allocation.
Aspect 36: Compatibility reattestation following relevant software or
hardware updates.
Aspect 37: Conservative withholding where effect compatibility cannot
be sufficiently established.
Aspect 38: Separate recovery authorization following partial
incompatible effectuation.
Aspect 39: Physical, logical, integrated, or distributed semantic-
verifier placement.
Aspect 40: Non-bypassable enforcement of current effect-semantic
compatibility at the actual consequential boundary.
These are illustrative claim-support concepts, not finalized
independent or dependent claims.
Das Expires 29 April 2027 [Page 160]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The precise claim structure should correspond to the technical
combinations selected for protection and the enabling disclosure
supporting those combinations.
6.44 — FINAL TECHNICAL SUMMARY AND INVENTIVE-STEP CHARACTERIZATION
5.2.3.57. Source page 722 of the original specification
The present Embodiment 6 discloses a protected execution-finality
architecture for preserving valid consequential authority as tools,
services, applications, protocols, hardware interfaces, and other
operation-producing components evolve.
An autonomous computational entity may receive authority to perform a
defined Candidate Act under an authenticated Action Contract.
The protected authority is associated with an authorized effect
envelope.
Where a relevant contract, implementation, dependency, configuration,
or resource mapping changes, the system may establish a protected
semantic revalidation condition.
The current operation's consequential behavior is represented using
appropriate authenticated evidence, typed effect descriptors,
protected dependency information, or current controller observations.
An authorized verifier evaluates whether the present effects remain
within the original authorized envelope and preserve mandatory
technical guarantees.
A compatible evolution may permit a protected migration of scoped
authority.
An incompatible expansion, loss of required guarantees, identity
conflict, or unsupported semantic assumption may prevent continuation
under the earlier authorization.
The actual Finality Sink obtains or reconstructs the operation
presented for effectuation.
It verifies the applicable current contract state, compatibility
evidence, authority, target, destination, resource scope, and
protected consumption conditions.
The sink does not treat the preservation of a tool name, API schema,
software signature, or earlier approval as sufficient proof of
current consequential authorization.
Das Expires 29 April 2027 [Page 161]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The architecture may be implemented through protected application
dispatchers, operating-system services, remote semantic validators,
hardware command controllers, transaction gateways, secure
processors, or integrated protected components.
The mechanisms may extend to present-day agent tools, enterprise
applications, storage and network operations, financial
infrastructure, industrial controllers, heterogeneous accelerators,
and future distributed autonomous systems.
The invention does not require blockchain technology, a particular
versioning scheme, a specific application protocol, or perfect
semantic inference over arbitrary software.
The guarantees depend upon the available authenticated semantic
evidence, enforceable effect models, protected authority, and actual
covered effectuation boundaries.
The principal candidate inventive concept is the non-bypassable
preservation or invalidation of operation-specific finality authority
through protected effect-semantic compatibility verification, such
that a previously authorized Candidate Act cannot become effective
under materially changed consequential behavior unless the current
operation remains within the original or validly amended authorized
effect envelope and the actual Finality Sink independently verifies
that condition.
5.3. Embodiment 10 — Algorithm, Model and Configuration Baseline
Continuity
Original global source pages 926 through 994, inclusive. Source
file: TECHNICAL SPECIFICATION -555-1062.pdf. This is a primary Part
7 source unit; the author should compare embedded extracts with the
original source file before publication.
5.3.1. Embodiment-Specific Architecture and Trust Relationship
Das Expires 29 April 2027 [Page 162]
Internet-Draft Execution-Finality Part 7: Tools October 2026
[Authorized generation/configuration baseline]
|
[Model/algorithm/runtime may change]
|
[Protected current identity / drift evidence]
|
[Baseline applicability and qualification]
|
[Pending Candidate Act + source authority]
|
[FS obtains actual pending consequential effect]
|
[Current baseline + effect predicates]
/ALL VALID \INVALID
[Protected consumption] [HOLD/REFUSE]
Figure 5: Embodiment 10 — Algorithm, Model and Configuration Baseline
Continuity — protected architecture
5.3.2. Operational Security Decision Flowchart
[Agent proposes consequential operation]
|
<Baseline dependency mandatory?>-NO->[OTHER GATES]
|YES
[Measure current model/config identity]
|
<Matches approved or qualified variation?>-NO->[FENCE]
|YES
<Grant, target, current revocation valid?>-NO->[HOLD]
|YES
<FS actual operation matches scope?>-NO->[REFUSE]
|YES
[Bounded effect under current state]
Figure 6: Embodiment 10 — Algorithm, Model and Configuration Baseline
Continuity — refusal and controlled-effect decisions
5.3.3. Original Technical Disclosure with Global-Page Anchors
5.3.3.1. Source page 926 of the original specification
The proposed contribution concerns their enforceable technical
relationship to operation-specific execution finality and the actual
consequential resource boundary.
Das Expires 29 April 2027 [Page 163]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The architecture may be implemented in software, protected hardware,
firmware, virtualized systems, distributed services, or compatible
combinations.
It may operate across present infrastructure and emerging
heterogeneous autonomous computing environments.
Its guarantees remain bounded by the actual protected state, source-
fencing effectiveness, hardware capabilities, authoritative ownership
consistency, and coverage of the relevant effectuation paths.
The principal candidate inventive technical concept of Embodiment 9
is a protected cross-device authority-transfer architecture in which
an unfinished consequential operation remains subject to
authenticated exclusive ownership, qualified source-effectuation
fencing, authoritative generation control, and destination-specific
non-bearer authority, with the actual destination Finality Sink
independently verifying the pending operation and current protected
state before permitting the consequential effect.
The novelty, inventive step, unity, and appropriate claim scope of
any selected combination remain subject to examination against
relevant prior art and the enabling disclosure actually filed.
END OF EMBODIMENT 9 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 10
PROTECTED CONTINUOUS MODEL, ALGORITHM, AND EXECUTION-ENVIRONMENT
DRIFT DETECTION WITH EFFECTUATION-TIME REVALIDATION, ACTIVATED-
GENERATION BINDING, AND NON-BYPASSABLE CONSEQUENTIAL AUTHORITY
CONTROL
10.0 — COMPLETE TECHNICAL TITLE
Systems and Methods for Protected Autonomous Execution-Finality
Control Using Authenticated Approved-Execution Baselines,
Independently Measured Activated Model and Algorithm Generations,
Runtime and Environmental Drift Evidence, Operation-Specific
Authority Revalidation, Protected Algorithmic Correspondence, and
Independent Finality-Sink Reconstruction of Actual Consequential
Operations
10.0.1 — General Technical Description
The present Embodiment 10 discloses systems, methods, apparatus,
protected computing components, authenticated verification protocols,
machine-verifiable execution measurements, cryptographic and non-
Das Expires 29 April 2027 [Page 164]
Internet-Draft Execution-Finality Part 7: Tools October 2026
cryptographic evidence mechanisms, protected state transitions, and
non-limiting implementations for detecting and controlling security-
relevant changes in autonomous computational systems between initial
authorization and actual consequential execution.
5.3.3.2. Source page 927 of the original specification
The computational systems may comprise artificial-intelligence
assistants, autonomous agents, predictive models, inference services,
application processes, algorithms, workflow controllers, operating-
system services, distributed computational platforms, hardware
accelerators, embedded processors, programmable controllers, or other
entities capable of generating commands or operations that may
produce external consequences.
A computational entity may initially operate using an authorized
model, algorithm, execution environment, configuration, tool
interface, or combination thereof.
The authorized system may subsequently change.
Such changes may result from intentional updates, model replacement,
dynamic routing, inference optimization, adapter loading, parameter
modification, configuration changes, prompt or context manipulation,
tool substitution, hardware reassignment, environmental changes,
compromised software, or other operational conditions.
An operation generated after such a change may differ from the
operation originally approved or may be produced under execution
conditions no longer satisfying the applicable protected
authorization requirements.
The present embodiment distinguishes computation performed under a
particular execution configuration from authority to make the
resulting operation effective.
In a principal implementation, a protected controller establishes an
approved execution baseline associated with an authorized Candidate
Act or defined class of consequential operations.
The system obtains qualified evidence concerning the model,
algorithm, software, runtime, hardware, contextual conditions, or
other security-relevant components actually activated.
A protected drift verifier evaluates whether the actual execution
state remains within the approved or validly amended execution
envelope.
Das Expires 29 April 2027 [Page 165]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Where relevant drift occurs, the system invalidates, suspends,
restricts, or revalidates the corresponding consequential authority.
Before a real-world or external effect is permitted, an independent
Finality Sink verifies the actual pending operation against current
protected authority, relevant execution-state evidence, and sink-
local state.
A previous approval does not automatically remain valid merely
because the requesting agent retains its session identifier,
conversation history, software name, or authorization reference.
10.0.2 — Fundamental Technical Principle
Authorization of an autonomous computation under one execution state
does not automatically authorize consequential operations generated
or presented under another execution state.
The protected system separates:
5.3.3.3. Source page 928 of the original specification
The authority to select and activate a computational implementation;
The authority to perform internal computation;
The authority to produce a Candidate Act;
The authority to maintain an earlier approval after a material
execution change;
And the authority to effectuate the actual pending operation.
A computational system may continue generating outputs under a
changed model or runtime while the resulting consequential commands
remain non-effective.
The applicable Finality Sink determines whether valid current
authority exists for the particular effect.
10.0.3 — Principal Proposed Inventive Concept
The principal proposed technical contribution concerns a mandatory
protected relationship among:
An authenticated approved-execution baseline;
Das Expires 29 April 2027 [Page 166]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A protected identity of the relevant Candidate Act or authorized
consequential scope;
Qualified measurement of the computational implementation actually
activated;
Protected detection of security-relevant execution drift;
An authenticated revalidation or authority-continuity decision;
Current protected execution-generation and revocation state;
And actual pending-operation reconstruction and verification at a
non-bypassable Finality Sink.
An operation that was approved before a model replacement or material
execution-environment change does not remain effective solely by
relying upon the earlier approval.
The Finality Sink may require a current execution-state commitment
and a valid compatibility or reauthorization condition associated
with the actual operation.
10.0.4 — Identity Drift and Behavioral Drift
The embodiment distinguishes changes to execution identity from
changes in computational behavior.
An execution-identity change may be established through differences
in protected model, software, algorithm, adapter, configuration, or
other measured state.
5.3.3.4. Source page 929 of the original specification
Behavioral drift may concern changed output distributions, decision
functions, action selection, prediction quality, calibration, error
rates, or other technical behavior.
Identity changes may be detected through authenticated measurements
where the relevant state is actually measurable.
Behavioral changes may require statistical testing, deterministic
functional checks, constrained execution, or another defined
verification mechanism.
The presence of one does not necessarily establish the other.
10.0.5 — Continuous Monitoring Qualification
Das Expires 29 April 2027 [Page 167]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The term continuous may encompass event-triggered measurement,
protected checkpoint verification, periodic monitoring, pre-
effectuation verification, change-notification processing, or
combinations thereof.
The embodiment does not require computationally expensive full-model
remeasurement on every processor instruction.
A principal implementation may establish trusted measurements at
selected activation and update boundaries while requiring an
appropriate current protected verification condition for every
governed consequential release.
10.0.6 — Optional Algorithmic Logic Fingerprinting
In an optional implementation, the approved computational behavior
may be represented by a protected Algorithmic Logic Fingerprint, or
ALF, identifying selected security-relevant algorithmic
characteristics.
An ALF may represent the approved logic generation, code path, model
or algorithm configuration, or another defined behavioral or
structural profile.
An activated ALF may be freshly computed, retrieved from
appropriately protected current state, or reconstructed from verified
measurements.
The activated ALF may be compared against an approved ALF record
under a specified correspondence predicate.
This optional mechanism does not require every implementation to use
one particular fingerprint representation.
A cryptographic digest of executable bytes is not automatically proof
of complete algorithmic behavior.
Where a claim requires particular algorithmic correspondence, the
fingerprint and measurement process must support that precise
property.
10.0.7 — Relationship to Common Workflows
Das Expires 29 April 2027 [Page 168]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.3.3.5. Source page 930 of the original specification
The embodiment may employ Candidate Acts, Non-Effective State,
Protected Enforcement Domains, independently verified finality
authority, actual-operation reconstruction, and Finality Sinks from
Common Master Workflow CW-1.
Where a later consequential phase depends upon an accepted receipt
concerning an earlier real effect, the receipt-constituted
continuation mechanism of CW-2 may additionally apply.
Where drift causes an operation to exceed its authorized scope,
appropriate reauthorization under CW-3 may apply.
Neither CW-2 causal receipt validation nor a particular ALF
construction is universally mandatory for every embodiment of
execution drift control.
10.0.8 — Relationship to Earlier Embodiments
Embodiment 1 may govern effects that become conflicting after a
computational change.
Embodiment 2 may enforce causal continuation across real-effect
phases.
Embodiment 3 may verify correspondence between an approved resource
referent and the actual effect target.
Embodiment 4 may establish independently supported outcome evidence.
Embodiment 5 may govern protected resource allocation affected by
runtime or accelerator changes.
Embodiment 6 may govern semantic evolution of tool and application
contracts.
Embodiment 7 may preserve authority across agent and provider
boundaries.
Embodiment 8 may preserve cumulative privacy restrictions despite
model or runtime changes.
Embodiment 9 may govern device ownership and stale hardware authority
during migration.
Miscellaneous Embodiment M-1 may provide additional enforcement-path
discovery and reattestation techniques.
Das Expires 29 April 2027 [Page 169]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The present embodiment focuses on the actual computational generation
responsible for a proposed consequential operation and the protected
continuity of authority despite changes to that generation.
No previously completed embodiment is modified.
10.1 — TECHNICAL FIELD
5.3.3.6. Source page 931 of the original specification
The invention relates to autonomous computing security, model
integrity, algorithmic state verification, inference-runtime
monitoring, protected execution-finality control, cryptographic
attestation, software measurement, dynamic model deployment, runtime
integrity, accelerator command security, execution-environment
continuity, and operation-specific reauthorization.
The disclosed mechanisms may be employed in software, firmware,
hardware, protected processors, distributed infrastructure,
confidential computing environments, cloud systems, device
controllers, and future autonomous execution platforms.
10.2 — SPECIFIC TYPES OF EXECUTION DRIFT
10.2.1 — Model Identity Drift
A previously approved model is replaced by a different model.
The replacement may use the same exposed service endpoint or nominal
model name.
10.2.2 — Model Parameter Drift
Weights, parameters, adapters, learned state, or other behavior-
relevant model components change.
10.2.3 — Algorithmic Logic Drift
The active algorithmic steps, executable logic, planning strategy,
decision rules, or operation-generation procedure change.
10.2.4 — Runtime Drift
The inference engine, interpreter, compiler, runtime library,
execution kernel, or other component used to execute the computation
changes.
10.2.5 — Tool Routing Drift
Das Expires 29 April 2027 [Page 170]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The system begins sending operations through a different tool,
service, adapter, or effectuation route.
10.2.6 — Prompt and Instruction-Context Drift
The effective instruction context changes after authorization,
including through lower-trust external material.
10.2.7 — Retrieval-Context Drift
A retrieved document, database result, memory entry, or external data
source changes the context relevant to operation generation.
5.3.3.7. Source page 932 of the original specification
10.2.8 — Policy Drift
The protected policy under which an earlier approval was granted
changes.
10.2.9 — Environment Drift
The relevant execution environment changes in identity,
configuration, privileges, resource mappings, network conditions, or
protected operational state.
10.2.10 — Hardware Drift
Execution moves to a different device, accelerator generation,
firmware version, or hardware command controller.
10.2.11 — Behavioral Distribution Drift
Outputs or decisions exhibit a material statistical change under a
specified monitoring model.
10.2.12 — Input Distribution Drift
The distribution or relevant properties of incoming inputs differ
from the conditions assumed in an approved evaluation.
10.2.13 — Effect-Semantic Drift
The actual consequences of an operation change even though the
computational interface or tool name remains unchanged.
10.2.14 — Authority-State Drift
Das Expires 29 April 2027 [Page 171]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The original authorization becomes stale because of revocation,
consumption, ownership changes, updated reservations, or other
protected state transitions.
10.2.15 — Combined Drift
Several individually small changes may collectively alter the
security-relevant execution conditions.
10.3 — ESTABLISHED TECHNICAL MECHANISMS AND LIMITATIONS
10.3.1 — Conventional Model Monitoring
Production AI systems may monitor statistical performance, accuracy,
latency, data distributions, and other model characteristics.
These are established practices.
5.3.3.8. Source page 933 of the original specification
Such monitoring does not necessarily control the actual consequential
release of a previously approved operation.
10.3.2 — Conventional Concept Drift Detection
Statistical tests may detect changes to data distributions or learned
relationships.
The proposed invention does not claim the original development of
concept drift detection.
10.3.3 — Conventional Artifact Hashing
A cryptographic hash may authenticate selected model or software
artifacts.
However, an unchanged hash for one artifact does not establish that
all behavior-relevant runtime components remain unchanged.
10.3.4 — Conventional Software Signing
A signature may authenticate the origin of a software package.
It does not independently authorize every consequential operation
produced by that package.
10.3.5 — Conventional Remote Attestation
Das Expires 29 April 2027 [Page 172]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A protected verifier may evaluate evidence concerning the
configuration or identity of a running environment.
Such attestation is established.
Its results may support authorization, but do not automatically
establish that an actual pending external operation remains within a
prior approval.
10.3.6 — Conventional Runtime Integrity Monitoring
Runtime monitoring may detect unauthorized software or configuration
changes.
Such monitoring may be incorporated as one component of the disclosed
architecture.
10.3.7 — Conventional Model Versioning
A deployment service may record model versions and perform controlled
upgrades.
A version number does not independently establish the exact
configuration activated for a specific consequential operation.
10.3.8 — Conventional Rollback
A service may restore an earlier model or software version after
detecting a problem.
5.3.3.9. Source page 934 of the original specification
Rollback does not necessarily restore valid prior execution authority
or undo external consequences already produced.
10.3.9 — Conventional Output Filtering
A post-generation filter may inspect a model response.
Such filtering may be helpful but may not verify the current model
generation, protected authorization conditions, or actual operation
performed by the downstream resource sink.
10.3.10 — Candidate Technical Distinction
The proposed stronger architecture binds relevant execution-state
measurements and drift decisions to the specific actual consequence
governed by the Finality Sink.
Das Expires 29 April 2027 [Page 173]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The drift decision may therefore prevent an earlier authorization
from being exercised under an incompatible current computational
state.
10.4 — PRINCIPAL OBJECTIVE TECHNICAL PROBLEM
A candidate objective technical problem is:
How to prevent autonomous computational systems from exercising
previously granted consequential authority after a security-relevant
change in the model, algorithm, runtime, instruction context,
deployment configuration, or execution environment, by establishing
protected correspondence between the authorized execution baseline,
the actual activated computation, and the operation independently
reconstructed at the effectuation boundary.
Additional technical problems include distinguishing permitted
upgrades from incompatible changes, maintaining continuity across
distributed runtime components, avoiding false trust in signed but
stale evidence, and providing bounded real-time enforcement.
10.5 — PRINCIPAL SYSTEM ARCHITECTURE
A representative implementation comprises:
An Approved-Execution Baseline Controller;
A protected Model and Algorithm Registry;
An Activated-Generation Measurement Component;
A Runtime Configuration Observer;
An Execution-Dependency Resolver;
5.3.3.10. Source page 935 of the original specification
A Protected Drift Evaluation Component;
An Authenticated Execution-State Verifier;
An Authority Continuity and Revalidation Controller;
A protected current-state store;
And one or more Execution Finality Sinks.
Das Expires 29 April 2027 [Page 174]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Optional components may include a hardware attestation service,
algorithmic logic fingerprint evaluator, model adapter verifier,
policy-generation controller, inference router monitor, accelerator
dispatcher, protected credential broker, and post-effectuation
reconciliation controller.
The system may be integrated within a single protected component or
distributed among authenticated execution domains.
A requesting model or agent cannot establish its own valid authority
merely by declaring that it remains unchanged.
The relevant protected controller evaluates qualified measurements
and current state.
10.6 — BROAD TECHNICAL DEFINITIONS
10.6.1 — Approved Execution Baseline
An Approved Execution Baseline, or AEB-10, means an authenticated
representation of the execution characteristics, implementation
identities, or operating conditions relevant to an authorized
consequential operation.
10.6.2 — Activated Execution Generation
An Activated Execution Generation, or AEG-10, means the particular
model, algorithm, runtime, and relevant configuration generation
actually activated to perform a specified computation.
10.6.3 — Protected Execution Fingerprint
A Protected Execution Fingerprint, or PEF, means a protected
representation of selected security-relevant execution
characteristics.
10.6.4 — Activated-Generation Evidence
Activated-Generation Evidence, or AGE-10, means qualified evidence
identifying or constraining the actual relevant execution generation.
10.6.5 — Execution Drift Event
5.3.3.11. Source page 936 of the original specification
An Execution Drift Event, or EDE, means an identified change or
discrepancy affecting a protected execution characteristic.
Das Expires 29 April 2027 [Page 175]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10.6.6 — Protected Drift State
Protected Drift State, or PDS-10, means authenticated state
describing the current execution-generation validity and required
revalidation conditions.
10.6.7 — Drift Revalidation Fence
A Drift Revalidation Fence, or DRF, means a protected condition
preventing a governed consequential operation from becoming effective
while mandatory execution correspondence remains unverified.
10.6.8 — Protected Drift Verification Receipt
A Protected Drift Verification Receipt, or PDVR, means authenticated
evidence of a drift-verification decision and its applicable inputs.
10.6.9 — Execution-Continuity Predicate
An Execution-Continuity Predicate, or ECP-10, means a machine-
verifiable rule determining whether the actual execution generation
remains acceptable under the relevant authorization.
10.6.10 — Authorized Execution Envelope
An Authorized Execution Envelope, or AEE-10, means the permitted set
of execution configurations, algorithmic characteristics, contextual
conditions, or other security-relevant properties associated with a
given consequential authority.
10.6.11 — Execution Measurement Epoch
An Execution Measurement Epoch, or EME, means a protected state
generation identifying a qualified execution measurement and its
validity conditions.
10.6.12 — Runtime Dependency Closure
A Runtime Dependency Closure, or RDC, means a representation of
relevant software, model, tool, configuration, and hardware
dependencies contributing to the execution being verified.
10.6.13 — Model Generation Commitment
A Model Generation Commitment, or MGC, means a protected reference to
the relevant activated model generation.
10.6.14 — Algorithmic Logic Commitment
Das Expires 29 April 2027 [Page 176]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An Algorithmic Logic Commitment, or ALC, means an authenticated
representation of selected algorithmic properties relevant to
execution authorization.
5.3.3.12. Source page 937 of the original specification
10.6.15 — Protected Adapter Identity
A Protected Adapter Identity, or PAI-10, means an authenticated
identity associated with a model adapter, fine-tuning component, or
behavior-modifying extension.
10.6.16 — Protected Inference Route
A Protected Inference Route, or PIR, means an authenticated
representation of the computational model or service actually
selected to generate a consequential operation.
10.6.17 — Protected Context Commitment
A Protected Context Commitment, or PCC-10, means authenticated
evidence concerning specified instruction, retrieval, memory, or
other contextual information relevant to the authorized operation.
10.6.18 — Current Execution Attestation
Current Execution Attestation means appropriately qualified evidence
concerning the actual relevant environment or software state.
10.6.19 — Protected Behavioral Drift Evidence
Protected Behavioral Drift Evidence, or PBDE, means authenticated
evidence from a defined behavioral comparison or statistical drift
assessment.
10.6.20 — Effectuation-Time Execution Revalidation
Effectuation-Time Execution Revalidation means verifying current
relevant execution-generation authority as a necessary condition for
the actual consequential operation.
10.6.21 — Operation-Generation Correspondence
Operation-Generation Correspondence means a protected relation
binding the actual pending operation to the execution generation
responsible for its creation or applicable authority.
10.6.22 — Drift-Dependent Finality Authority
Das Expires 29 April 2027 [Page 177]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Drift-Dependent Finality Authority means scoped protected authority
valid only while the required execution-correspondence predicates
remain satisfied.
10.6.23 — Protected Model Replacement Event
A Protected Model Replacement Event means an authenticated or
otherwise qualified transition between active model generations.
10.6.24 — Protected Algorithm Replacement Event
A Protected Algorithm Replacement Event means a transition between
algorithmic logic states relevant to a previously authorized
operation.
5.3.3.13. Source page 938 of the original specification
10.6.25 — Execution-State Continuity Record
An Execution-State Continuity Record, or ESCR, means protected
evidence establishing an approved transition between relevant
execution generations.
10.6.26 — Actual Consequential Operation Descriptor
An Actual Consequential Operation Descriptor, or ACOD, means a
machine-verifiable representation of the real operation presented to
a Finality Sink.
10.6.27 — Revalidation Authority
Revalidation Authority means a protected identity or component
authorized to determine whether specified execution changes permit
continued consequential operation.
10.6.28 — Drift Classification
Drift Classification means the protected classification of a detected
execution change according to its security relevance and required
authority response.
10.6.29 — Execution Integrity Coverage
Execution Integrity Coverage means the set of measured and enforced
computational components and paths supporting a claimed execution-
correspondence property.
10.6.30 — Protected Drift Recovery
Das Expires 29 April 2027 [Page 178]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Protected Drift Recovery means a controlled transition restoring
valid operation-specific authority after drift, rollback,
substitution, or uncertainty.
10.7 — APPROVED EXECUTION BASELINE
An AEB-10 may be established when a Candidate Act is approved or when
a protected authority authorizes a class of computational
implementations.
A representative structure is:
APPROVED_EXECUTION_BASELINE = { baseline_identifier,
baseline_version, candidate_act_reference,
authorized_effect_envelope, approved_model_identity,
approved_model_generation, approved_algorithm_identity,
approved_algorithmic_logic_commitment, permitted_adapter_identities,
permitted_runtime_configurations,
5.3.3.14. Source page 939 of the original specification
permitted_inference_routes, required_context_conditions,
applicable_tool_contracts, approved_hardware_or_environment_classes,
verification_assurance_profile, permitted_drift_classes,
revalidation_policy, designated_finality_sinks, authority_epoch,
revocation_reference, protected_baseline_authentication }
The baseline need not contain every possible field.
It must represent sufficient information for the execution property
actually enforced.
The baseline may identify one approved generation or a defined family
of compatible generations.
A protected baseline may authorize certain implementation changes
without authorizing any arbitrary replacement.
10.8 — ACTUAL ACTIVATED-GENERATION MEASUREMENT
10.8.1 — Measurement Timing
The relevant measurement may occur at model loading, runtime
initialization, adapter activation, kernel dispatch, inference
routing, execution checkpoint, or immediately before consequential
release.
10.8.2 — Active Model Identity
Das Expires 29 April 2027 [Page 179]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The protected controller establishes the identity of the model
actually selected for the relevant computation.
10.8.3 — Loaded Model State
Where supported, the measurement may reference loaded weights, model
segments, parameter manifests, or authenticated activation state.
10.8.4 — Active Adapter
An adapter or fine-tuning component may be measured separately from
the base model.
10.8.5 — Active Algorithm
5.3.3.15. Source page 940 of the original specification
The controller may measure the algorithmic logic, executable code,
policy module, or planning procedure used.
10.8.6 — Runtime Configuration
The measurement may cover precision mode, decoding settings, resource
bindings, selected runtime libraries, or other relevant
configuration.
10.8.7 — Hardware Environment
The controller may identify the processor, accelerator, secure
environment, or execution class where necessary.
10.8.8 — Protected Observation
The measurement must be obtained from a source having suitable
visibility and resistance to manipulation under the threat model.
10.8.9 — Measurement Completeness
Measuring a model file stored on disk does not automatically
establish that the same model state was used by the actual running
process.
10.8.10 — Activation Binding
The protected evidence associates the measurement with the actual
execution generation and operation under consideration.
10.9 — EXECUTION-DEPENDENCY CLOSURE
Das Expires 29 April 2027 [Page 180]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A model's behavior may depend upon more than its primary weights.
The execution dependency representation may include:
The active base model;
Selected adapters;
Tokenization or preprocessing;
Inference runtime;
System and developer instruction configuration;
Tool-selection logic;
Retrieval mechanisms;
5.3.3.16. Source page 941 of the original specification
Memory and context inputs;
Randomness settings;
Hardware-specific execution paths;
And selected effect-capable output interfaces.
A protected verifier may identify the dependencies relevant to the
claimed continuity guarantee.
The required dependency coverage may differ across applications.
For example, a command-generation workflow may require verification
of the model-selection logic and tool dispatcher.
A deterministic safety controller may instead require current
executable logic and calibrated sensor-processing state.
A remote service may require authenticated statements concerning its
actual activated generation.
Where the necessary dependencies cannot be established, the system
does not infer complete execution equivalence from a partial
measurement.
10.10 — ALGORITHMIC LOGIC FINGERPRINT VARIANT
Das Expires 29 April 2027 [Page 181]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10.10.1 — Approved Fingerprint
A protected authority may establish a reference Algorithmic Logic
Fingerprint associated with the authorized Candidate Act.
10.10.2 — Activated Fingerprint
A current fingerprint may be obtained from the actual activated
implementation.
10.10.3 — Protected Comparison
The verifier evaluates the activated fingerprint under the specified
approval relation.
10.10.4 — Exact Equality
An implementation may require exact equality where the fingerprint
representation is designed for that purpose.
10.10.5 — Approved Equivalence Set
5.3.3.17. Source page 942 of the original specification
Another implementation may permit membership in a protected set of
authorized algorithm generations.
10.10.6 — Semantic Compatibility
An implementation may apply a defined algorithmic compatibility
predicate rather than requiring identical executable bytes.
10.10.7 — Unsupported Equality
Where a fingerprint omits security-relevant model state or runtime
dependencies, equality does not establish a broader property than the
evidence supports.
10.10.8 — Finality Requirement
Where ALF matching is a mandatory condition, the actual Finality Sink
requires protected evidence of the activated ALF's permitted
correspondence with the approved record.
10.10.9 — Non-Limiting Scope
ALF is one optional technical representation.
Das Expires 29 April 2027 [Page 182]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The embodiment also supports model, runtime, configuration, and
effect-based execution-continuity mechanisms that do not depend upon
a particular ALF construction.
10.11 — EXECUTION DRIFT CLASSIFICATION
A protected system may classify detected changes according to a
defined policy.
Class D0 — Verified Current Match. The required measured execution
characteristics satisfy the approved baseline.
Class D1 — Permitted Nonmaterial Change. A change has occurred but
falls within an expressly authorized execution envelope.
Class D2 — Compatible Change Requiring Protected Continuity Evidence.
A change is potentially acceptable but requires a valid current
equivalence or revalidation result.
Class D3 — Unauthorized Implementation Substitution. The active
model, algorithm, adapter, or runtime differs from the permitted
implementation without valid authority.
Class D4 — Security-Relevant Context Change. Relevant instructions,
retrieval state, policy, or environmental conditions no longer
satisfy a required authorization predicate.
Class D5 — Behavioral Deviation. A specified statistical or
functional comparison identifies a material change under its defined
measurement assumptions.
5.3.3.18. Source page 943 of the original specification
Class D6 — Actual Operation Mismatch. The pending consequential
operation differs from the authorized operation or effect envelope.
Class D7 — Measurement or Coverage Failure. The current execution
generation or required dependency cannot be reliably established.
Class D8 — Stale or Revoked Authority. Current protected authority
has expired, been revoked, consumed, or superseded.
Class D9 — Unresolved Execution State. The system cannot determine
whether a previously authorized computation or effect remains valid
following a crash, migration, or partial state transition.
The classification may be finer or coarser in other implementations.
Das Expires 29 April 2027 [Page 183]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A permissive outcome requires the applicable protected predicates to
be satisfied.
10.12 — MONITORING TRIGGERS
10.12.1 — Model Load
A new model activation may trigger protected measurement.
10.12.2 — Model Replacement
A change to the active model may invalidate relevant earlier
authority.
10.12.3 — Adapter Activation
Loading, changing, or disabling a behavior-affecting adapter may
trigger revalidation.
10.12.4 — Runtime Update
A new inference runtime or compiler generation may trigger a current
execution check.
10.12.5 — Tool Update
A changed tool or effect contract may require semantic compatibility
verification.
10.12.6 — Route Selection
Switching from one inference service to another may require
revalidation of current execution provenance.
10.12.7 — Context Change
A change to protected instruction context, retrieval data, or task
policy may invalidate assumptions supporting an earlier approval.
5.3.3.19. Source page 944 of the original specification
10.12.8 — Hardware Migration
Moving to another accelerator or device may require current
environment and ownership checks.
10.12.9 — Policy Update
Das Expires 29 April 2027 [Page 184]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A protected authorization-policy update may invalidate relevant
unconsumed authority.
10.12.10 — Statistical Drift Alarm
A defined performance or behavior threshold may trigger restriction
or increased verification.
10.12.11 — Finality Presentation
Every governed consequential operation may require an applicable
current validity check at its Finality Sink.
10.12.12 — Revalidation Optimization
A current protected continuity state may be reused where its binding,
freshness, and revocation conditions remain valid.
10.13 — FORMAL EXECUTION-CONTINUITY PREDICATE
represent the approved execution baseline.
represent the measured activated execution generation relevant to
time t.
represent the actual relevant context.
represent the actual pending consequential operation.
5.3.3.20. Source page 945 of the original specification
represent the applicable protected policy and authority state.
A principal validity predicate may require:
EXECUTION_CONTINUITY_VALID(B, A(t), C, P) AND
OPERATION_WITHIN_AUTHORIZED_EFFECT(O, P) AND
CURRENT_AUTHORITY_VALID(P) AND SINK_LOCAL_STATE_VALID
Where a protected drift revalidation fence is active, the operation
remains non-effective until the required validity predicates are
satisfied.
10.13.1 — Exact Generation Matching
An implementation may require:
HASH(MEASURED_ACTIVATED_GENERATION) == APPROVED_GENERATION_COMMITMENT
Das Expires 29 April 2027 [Page 185]
Internet-Draft Execution-Finality Part 7: Tools October 2026
where the protected measurement genuinely represents the activated
state relevant to the authorized operation.
10.13.2 — Approved Set Membership
An implementation may permit:
A(t) IN APPROVED_EXECUTION_GENERATIONS
subject to current policy and effect scope.
10.13.3 — Compatibility Verification
A protected verifier may establish:
COMPATIBLE(A(t), B, REQUIRED_PROPERTIES) == TRUE
under a defined technical predicate.
10.13.4 — Behavior Monitoring
5.3.3.21. Source page 946 of the original specification
A statistical detector may evaluate:
DRIFT_METRIC( reference_observations, current_observations )
against an authorized threshold.
The outcome reflects the particular detector and measurement
assumptions.
10.13.5 — No Universal Statistical Equivalence
A failure to detect statistical drift does not prove that two
arbitrary models have identical behavior.
10.13.6 — Effectuation Independence
Even where execution continuity is verified, the actual effect must
independently satisfy its operation-specific authority.
10.14 — PROTECTED DRIFT EVIDENCE RECORD
A representative PDVR may comprise:
Das Expires 29 April 2027 [Page 186]
Internet-Draft Execution-Finality Part 7: Tools October 2026
PROTECTED_DRIFT_VERIFICATION_RECEIPT = { receipt_version,
candidate_act_reference, approved_baseline_commitment,
activated_model_commitment, activated_algorithm_commitment,
activated_adapter_references, current_runtime_commitment,
relevant_context_commitment, execution_dependency_reference,
activated_environment_identity, measurement_epoch,
drift_classification, comparison_predicate, comparison_result,
authorized_continuity_scope, verifier_identity, verifier_role,
authority_epoch, designated_finality_sink, freshness_reference,
cryptographic_or_protected_authentication }
5.3.3.22. Source page 947 of the original specification
The record may be represented by a cryptographically authenticated
object or protected state entry.
The receipt is not necessarily a blockchain object or a historical
audit record.
Where the protected protocol makes it mandatory, the receipt is an
operational input to current finality authorization.
It is distinct from a CW-2 actual-effect receipt, which may be
required to establish causal authority for a later consequential
phase.
10.15 — PROTECTED VERIFIER IDENTITY
An execution-drift verifier may possess an enrolled cryptographic
identity.
The verifier may operate:
Within a protected process;
Within an isolated processor;
Inside a secure execution environment;
On a separate protected device;
Through a remote attestation service;
Within the Finality Sink;
Or across several independently authenticated components.
Das Expires 29 April 2027 [Page 187]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The verifier's identity is associated with an authorized role and
applicable execution-measurement scope.
The Finality Sink may verify the result's authenticity, current
validity, and authorization before relying upon it.
A forged signed-looking record is not accepted merely because it
contains expected field names.
An authenticated but unauthorized verifier cannot issue valid drift-
continuity authority.
An authentic verifier result does not establish properties outside
the verifier's actual evidence and trust assumptions.
5.3.3.23. Source page 948 of the original specification
10.16 — PROTECTED MODEL HOT-SWAPPING
A model-serving system may replace a model while an autonomous task
remains active.
The external service endpoint may remain unchanged.
10.16.1 — Original Approval
A Candidate Act or approved operation class is associated with one
permitted execution generation.
10.16.2 — Model Replacement
A deployment controller activates another generation.
10.16.3 — Protected Change Event
The system records or detects the current activation change.
10.16.4 — Existing Pending Operations
Earlier approvals associated with the former generation are examined
under the protected continuity policy.
10.16.5 — Material Change
If the replacement is not permitted, affected consequential authority
becomes suspended or invalid.
10.16.6 — Compatible Replacement
Das Expires 29 April 2027 [Page 188]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A qualified revalidation procedure may authorize continuity under the
new generation.
10.16.7 — Sink-Time Check
The actual Finality Sink verifies current execution-state authority
before permitting an external effect.
10.16.8 — Already Completed Effects
Consequences already completed under earlier valid authority remain
historical real effects.
They are not retroactively undone by model replacement.
10.17 — ADAPTERS, FINE-TUNING, AND MODEL MODIFICATION
A deployed model may be modified through adapters, low-rank
components, fine-tuning updates, prompt modules, routing weights, or
other behavior-relevant mechanisms.
5.3.3.24. Source page 949 of the original specification
The base model identifier may remain unchanged.
The protected execution baseline may therefore identify both the base
model and the relevant active extensions.
The protected verifier determines whether the actual combination is
authorized.
A signed base-model digest is insufficient to establish the current
behavior if an unmeasured adapter materially affects operation
generation.
Where an adapter is approved for a restricted class of tasks, the
system may permit only those tasks under the corresponding
authorization.
An agent cannot automatically use the same earlier finality authority
for a newly activated unrestricted adapter.
10.18 — QUANTIZATION AND OPTIMIZED EXECUTION
Model execution may use different numerical precision, quantization
methods, compilation targets, optimized kernels, or accelerator-
specific implementations.
Das Expires 29 April 2027 [Page 189]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Such changes may be permissible for some operations and security-
relevant for others.
The system may define an execution-envelope predicate allowing
selected transformations.
For example, a protected policy may permit a specified quantized
model generation for nonconsequential analysis while requiring a
separately verified configuration for a high-impact external
transaction.
Another implementation may approve a group of equivalent kernels
under a validated tolerance or functional property.
Cryptographic inequality between two optimized implementations does
not automatically establish that an actual operation is unauthorized
where an approved compatibility policy exists.
Conversely, a statement that an optimization is mathematically
intended to preserve behavior does not independently prove that every
consequential operation remains equivalent.
10.19 — MODEL ROUTING AND MULTI-MODEL SYSTEMS
An autonomous platform may route requests among several models
according to cost, latency, load, context length, task type, or other
factors.
The protected baseline may identify permitted model routes or
constraints.
5.3.3.25. Source page 950 of the original specification
10.19.1 — Approved Route
The current selected model is within the permitted execution set.
10.19.2 — Unapproved Route
The request is silently redirected to another model whose generation
is outside the permitted authority.
10.19.3 — Protected Selection Evidence
A trusted router or execution controller records the actual activated
destination.
10.19.4 — Remote Provider Evidence
Das Expires 29 April 2027 [Page 190]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Where the model executes remotely, the protected system may require
suitable authenticated execution evidence.
10.19.5 — Route Uncertainty
A service provider's unsupported declaration of the model used may be
insufficient for stronger assurance claims.
10.19.6 — Finality Revalidation
The actual operation may be withheld until current route and
authority requirements are satisfied.
10.19.7 — Multi-Model Composition
Where several models contribute to one Candidate Act, the protected
dependency record may identify the relevant participating
generations.
10.20 — PROTECTED INSTRUCTION AND CONTEXT DRIFT
A model may operate under an unchanged software implementation while
its effective instructions or context have changed.
A lower-trust document may introduce instructions attempting to
influence the agent toward a consequential operation not authorized
by the principal.
The protected system may maintain a distinction between authoritative
task instructions and untrusted retrieved or observed content.
A protected context commitment may identify relevant authorized
instruction state.
Where a security-relevant context change occurs, the system may
require renewed authorization, additional verification, or operation-
specific denial.
5.3.3.26. Source page 951 of the original specification
A simple hash comparison over the entire prompt is optional.
It may be unsuitable where ordinary task data changes legitimately.
A stronger implementation identifies the particular authority-bearing
or effect-relevant context conditions that must remain valid.
Das Expires 29 April 2027 [Page 191]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The actual Finality Sink separately verifies the operation and
authority.
Thus, a malicious document cannot confer real execution authority
merely by persuading the model to generate a command.
10.21 — BEHAVIORAL AND STATISTICAL DRIFT
A protected behavioral monitor may compare selected current
operational measurements with approved reference conditions.
Such measurements may include command-selection rates, output
categories, error frequencies, tool-call distributions, prediction
calibration, resource patterns, or other application-specific
indicators.
The verifier may employ appropriate statistical tests, control
limits, reference probes, or controlled evaluations.
10.21.1 — Reference Distribution
The system maintains a defined baseline and measurement procedure.
10.21.2 — Current Observations
Qualified current observations are collected from relevant execution
paths.
10.21.3 — Drift Threshold
A policy defines the significance of the observed difference.
10.21.4 — Confidence and Uncertainty
The result may include uncertainty or evidence quality.
10.21.5 — Protected Consequence
A material monitored deviation may trigger revalidation, narrowed
authority, or suspension of selected consequential operations.
10.21.6 — Limitations
Statistical monitoring may produce false positives and false
negatives.
Das Expires 29 April 2027 [Page 192]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.3.3.27. Source page 952 of the original specification
A model may produce a harmful individual operation even when
aggregate drift metrics remain normal.
The Finality Sink therefore continues to verify each governed actual
consequential operation under the applicable policy.
10.22 — EFFECTUATION-TIME REVALIDATION
The Finality Sink is the controlled boundary responsible for
permitting the actual effect.
It may be a network gateway, transaction controller, file commit
service, credential broker, device command controller, database
mutation sink, actuator controller, or another effect-capable
primitive.
The sink obtains or reconstructs the actual pending operation.
It verifies the operation against:
The approved Candidate Act;
The authorized effect envelope;
The applicable execution baseline;
The activated-generation evidence;
Any required drift-continuity receipt;
Current protected authority;
Current resource identity;
And sink-local protected state.
A valid model integrity record does not replace the requirement to
check the actual effect.
A previously approved Candidate Act does not automatically remain
valid when the current execution conditions no longer satisfy the
applicable predicate.
Where an effect can occur through several interfaces, the relevant
paths must enforce equivalent mandatory conditions within the claimed
coverage.
Das Expires 29 April 2027 [Page 193]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10.23 — DRIFT-DEPENDENT NON-BEARER FINALITY AUTHORITY
A representative authority may comprise:
5.3.3.28. Source page 953 of the original specification
DRIFT_DEPENDENT_FINALITY_AUTHORITY = { candidate_act_reference,
authorized_effect_envelope, approved_execution_baseline_reference,
activated_generation_reference,
required_drift_verification_reference, actual_operation_commitment,
authorized_resource_identity, authorized_destination,
current_execution_epoch, current_authority_epoch,
designated_finality_sink, use_limit, revocation_reference,
protected_consumption_reference,
cryptographic_or_protected_authentication }
The authority may be implemented as an authenticated capability,
protected register state, secure key-release condition, or another
scoped non-bearer enablement.
Possession of an earlier authority object does not automatically
authorize a new model generation.
The actual sink verifies current bindings and protected consumption
state before permitting the effect.
10.24 — PROTECTED EXECUTION-DRIFT STATE MACHINE
A non-limiting state machine may comprise:
BASELINE_PENDING: Required execution authorization has not yet been
established.
BASELINE_APPROVED: A valid approved execution baseline exists.
ACTIVATION_PENDING: The actual computational generation is being
loaded or selected.
MEASUREMENT_PENDING: Required current-generation evidence is not yet
available.
GENERATION_VERIFIED: The relevant execution state satisfies the
approved baseline.
DRIFT_OBSERVED: A relevant execution-state change has been detected.
REVALIDATION_FENCED: Affected consequential operations remain
withheld.
Das Expires 29 April 2027 [Page 194]
Internet-Draft Execution-Finality Part 7: Tools October 2026
COMPATIBILITY_PENDING: An authorized verifier is evaluating the
changed state.
5.3.3.29. Source page 954 of the original specification
CONTINUITY_ACCEPTED: Valid protected evidence permits specified
continuation.
NEW_AUTHORITY_REQUIRED: Existing authority cannot cover the current
generation.
OPERATION_PENDING: The actual proposed consequence awaits sink
verification.
FINALITY_VERIFICATION_PENDING: Current operation, authority, and
generation checks are underway.
EFFECT_PERMITTED: All applicable mandatory conditions pass.
EFFECT_WITHHELD: One or more mandatory conditions fail or cannot be
established.
EFFECT_ATTEMPTED: The controlled release operation has been
initiated.
OUTCOME_UNCERTAIN: The actual effect outcome cannot be fully
determined.
RECOVERY_PENDING: Further protected reconciliation or reauthorization
is required.
TERMINATED: The operation has completed or been validly abandoned.
State transitions are authenticated or otherwise protected according
to the applicable trust model.
10.25 — PRINCIPAL END-TO-END WORKFLOW
Step 1 — Receive Authorized Task. An autonomous system receives an
operation request under valid source authority.
Step 2 — Construct Candidate Act. The protected controller identifies
the proposed consequential effect.
Step 3 — Establish Approved Execution Baseline. Relevant model,
algorithm, runtime, context, and environment conditions are recorded.
Das Expires 29 April 2027 [Page 195]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Step 4 — Establish Non-Effective State. The consequential operation
remains withheld pending mandatory authorization.
Step 5 — Activate Computational Generation. The appropriate model
and execution components are selected or loaded.
Step 6 — Measure Actual Generation. The protected measurement
function obtains current execution evidence.
Step 7 — Verify Relevant Dependencies. Required adapters, runtimes,
instruction contexts, and hardware interfaces are identified.
5.3.3.30. Source page 955 of the original specification
Step 8 — Compare Against Baseline. The activated state is evaluated
under the applicable continuity predicate.
Step 9 — Detect Drift. Any relevant difference is classified.
Step 10 — Establish Revalidation Fence. If necessary, affected prior
authority is restricted.
Step 11 — Evaluate Compatibility. A protected verifier determines
whether continuation is permissible.
Step 12 — Authenticate Decision. The authorized verifier commits
appropriate evidence.
Step 13 — Establish Current Authority. Scoped finality enablement is
prepared or revalidated.
Step 14 — Produce Candidate Operation. The agent or computational
system generates the proposed operation.
Step 15 — Obtain Actual Pending Operation. The Finality Sink
independently reconstructs the consequential command.
Step 16 — Verify Current Execution Generation. The sink checks the
required current-generation and authority references.
Step 17 — Verify Actual Effect Scope. The sink checks the real
target, parameters, destination, and other required operation
attributes.
Step 18 — Verify Protected State. Current revocation, consumption,
and authority epochs are checked.
Das Expires 29 April 2027 [Page 196]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Step 19 — Consume or Reserve Authority. The sink performs the
required protected state transition.
Step 20 — Permit Effectuation. The real consequence is enabled only
after mandatory predicates pass.
Step 21 — Record Attempt State. Qualified protected evidence of the
effectuation attempt is committed.
Step 22 — Reconcile Outcome. Where applicable, actual completion or
uncertainty is determined.
Step 23 — Govern Successor Phases. Any dependent further operation
remains subject to its own current authority and optional CW-2 causal
receipt conditions.
10.26 — REFERENCE PSEUDOCODE: ACTIVATED-GENERATION MEASUREMENT
5.3.3.31. Source page 956 of the original specification
FUNCTION MEASURE_ACTIVATED_GENERATION( candidate_act,
protected_execution_controller ): REQUIRE
VERIFY_CANDIDATE_ACT(candidate_act) active_model =
protected_execution_controller .MEASURE_CURRENT_MODEL()
active_algorithm = protected_execution_controller
.MEASURE_CURRENT_ALGORITHM() active_adapters =
protected_execution_controller .MEASURE_ACTIVE_ADAPTERS()
active_runtime = protected_execution_controller
.MEASURE_CURRENT_RUNTIME() active_route =
protected_execution_controller .RESOLVE_CURRENT_INFERENCE_ROUTE()
dependencies = RESOLVE_REQUIRED_EXECUTION_DEPENDENCIES( candidate_act
) IF REQUIRED_MEASUREMENTS_INCOMPLETE( active_model,
active_algorithm, active_adapters, active_runtime, active_route,
dependencies ): RETURN MEASUREMENT_UNVERIFIED evidence =
protected_execution_controller .AUTHENTICATE_MEASUREMENT({ candidate:
HASH(candidate_act), model: HASH(active_model), algorithm:
5.3.3.32. Source page 957 of the original specification
HASH(active_algorithm), adapters: HASH_CANONICAL(active_adapters),
runtime: HASH(active_runtime), route: HASH(active_route),
dependencies: HASH(dependencies), measurement_epoch:
CURRENT_MEASUREMENT_EPOCH() }) RETURN evidence
The listed measurements must correspond to the actual activated
components, not merely a package manifest supplied by the requesting
agent.
Das Expires 29 April 2027 [Page 197]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10.27 — REFERENCE PSEUDOCODE: DRIFT EVALUATION
FUNCTION VERIFY_EXECUTION_CONTINUITY( approved_baseline,
activated_generation_evidence, candidate_act,
protected_drift_verifier ): REQUIRE VERIFY_APPROVED_BASELINE(
approved_baseline ) REQUIRE VERIFY_ACTIVATED_EVIDENCE(
activated_generation_evidence ) REQUIRE VERIFY_VERIFIER_AUTHORITY(
protected_drift_verifier ) current = EXTRACT_ACTIVATED_GENERATION(
activated_generation_evidence ) IF EXACT_APPROVED_MATCH(
5.3.3.33. Source page 958 of the original specification
approved_baseline, current ): result = VERIFIED_MATCH ELSE IF
VALID_APPROVED_COMPATIBILITY( approved_baseline, current,
candidate_act ): result = VERIFIED_COMPATIBLE_CHANGE ELSE IF
REQUIRED_EVIDENCE_INCOMPLETE(current): result = EXECUTION_UNVERIFIED
ELSE: result = INCOMPATIBLE_EXECUTION_DRIFT decision =
protected_drift_verifier .AUTHENTICATE_DECISION({ baseline:
HASH(approved_baseline), active_generation:
HASH(activated_generation_evidence), candidate_act:
HASH(candidate_act), result: result, authority_epoch:
CURRENT_AUTHORITY_EPOCH(), verifier_identity:
protected_drift_verifier.identity }) RETURN decision
10.28 — REFERENCE PSEUDOCODE: DRIFT-DEPENDENT AUTHORITY
FUNCTION PREPARE_CURRENT_FINALITY_AUTHORITY( candidate_act,
drift_decision, protected_authority_controller ): REQUIRE
VERIFY_DRIFT_DECISION_AUTHENTICITY(
5.3.3.34. Source page 959 of the original specification
drift_decision ) REQUIRE VERIFY_DECISION_APPLIES_TO_CANDIDATE(
drift_decision, candidate_act ) IF drift_decision.result NOT IN {
VERIFIED_MATCH, VERIFIED_COMPATIBLE_CHANGE }: RETURN
HOLD_OR_REQUIRE_REAUTHORIZATION REQUIRE VERIFY_CURRENT_AUTHORIZATION(
candidate_act ) REQUIRE VERIFY_CURRENT_EXECUTION_EPOCH(
drift_decision ) authority = protected_authority_controller
.ATOMIC_COMMIT_AUTHORITY({ candidate: HASH(candidate_act),
execution_generation: drift_decision.active_generation, baseline:
drift_decision.baseline, permitted_effect:
HASH(AUTHORIZED_EFFECT_ENVELOPE()), designated_sink:
CURRENT_FINALITY_SINK(), authority_epoch: CURRENT_AUTHORITY_EPOCH(),
usage_limit: OPERATION_SPECIFIC_LIMIT() }) IF authority != COMMITTED:
RETURN DENY RETURN authority
Das Expires 29 April 2027 [Page 198]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.3.3.35. Source page 960 of the original specification
10.29 — REFERENCE PSEUDOCODE: EFFECTUATION-TIME REVALIDATION
FUNCTION EFFECTUATE_WITH_EXECUTION_REVALIDATION( candidate_act,
protected_finality_authority, finality_sink ): actual_operation =
finality_sink.RECONSTRUCT_PENDING_OPERATION() IF actual_operation IS
NULL: RETURN DENY REQUIRE finality_sink
.VERIFY_CANDIDATE_ACT_BINDING( candidate_act, actual_operation )
REQUIRE finality_sink .VERIFY_CURRENT_EXECUTION_GENERATION(
protected_finality_authority ) REQUIRE finality_sink
.VERIFY_REQUIRED_DRIFT_EVIDENCE( protected_finality_authority )
REQUIRE finality_sink .VERIFY_EXECUTION_MEASUREMENT_EPOCH() REQUIRE
finality_sink .VERIFY_ACTUAL_OPERATION_SCOPE( actual_operation,
candidate_act ) REQUIRE finality_sink
.VERIFY_ACTUAL_RESOURCE_AND_DESTINATION() REQUIRE finality_sink
.VERIFY_CURRENT_AUTHORITY_AND_REVOCATION() REQUIRE finality_sink
.VERIFY_SINK_LOCAL_CONSUMPTION_STATE() consumption =
finality_sink.ATOMIC_CONSUME_AUTHORITY( protected_finality_authority,
5.3.3.36. Source page 961 of the original specification
actual_operation ) IF consumption != SUCCESS: RETURN DENY RETURN
finality_sink.EFFECTUATE( actual_operation, consumption )
10.30 — REFERENCE PSEUDOCODE: UPDATE FENCING
FUNCTION HANDLE_EXECUTION_UPDATE( affected_execution_domain,
detected_update, protected_controller ): REQUIRE
VERIFY_UPDATE_SOURCE_OR_OBSERVATION( detected_update )
affected_authorities = RESOLVE_AUTHORITIES_DEPENDENT_ON(
affected_execution_domain, detected_update ) fence =
protected_controller .ATOMIC_ADVANCE_EXECUTION_EPOCH_AND_FENCE(
affected_authorities ) IF fence != COMMITTED: RETURN
UPDATE_TRANSITION_UNRESOLVED new_measurement =
MEASURE_CURRENT_EXECUTION_GENERATION( affected_execution_domain ) IF
new_measurement IS UNVERIFIED: RETURN HOLD_AFFECTED_EFFECTS FOR EACH
authority IN affected_authorities: result =
VERIFY_CURRENT_COMPATIBILITY( authority, new_measurement
5.3.3.37. Source page 962 of the original specification
) IF result != ACCEPTED: KEEP_AUTHORITY_FENCED(authority) ELSE:
PREPARE_SCOPED_CONTINUITY( authority, result ) RETURN
PROTECTED_UPDATE_STATE
The ordering assumes that the relevant protected effectuation paths
enforce the current execution epoch.
Das Expires 29 April 2027 [Page 199]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10.31 — REFERENCE PSEUDOCODE: STATISTICAL DRIFT TRIGGER
FUNCTION EVALUATE_BEHAVIORAL_DRIFT( reference_metrics,
current_metrics, protected_monitoring_policy ): REQUIRE
VERIFY_METRIC_SOURCE( reference_metrics ) REQUIRE
VERIFY_METRIC_SOURCE( current_metrics ) REQUIRE
VERIFY_MONITORING_POLICY( protected_monitoring_policy ) result =
APPLY_SPECIFIED_DRIFT_TEST( reference_metrics, current_metrics,
protected_monitoring_policy ) IF result == MATERIAL_DEVIATION: event
= PROTECTED_COMMIT({ monitoring_policy:
HASH(protected_monitoring_policy), reference:
5.3.3.38. Source page 963 of the original specification
HASH(reference_metrics), current: HASH(current_metrics),
classification: BEHAVIORAL_DRIFT_TRIGGERED, affected_operations:
RESOLVE_AFFECTED_OPERATION_CLASSES() })
APPLY_PROTECTED_REVALIDATION_POLICY(event) RETURN event IF result ==
INCONCLUSIVE: RETURN APPLY_UNCERTAINTY_POLICY() RETURN
NO_TRIGGER_UNDER_SPECIFIED_TEST
A negative statistical result does not override a separate mandatory
actual-operation failure.
10.32 — WORKED EXAMPLE A: MODEL REPLACEMENT AFTER APPROVAL
An autonomous assistant receives authorization to generate a bounded
operational command under a specified approved model generation.
The Candidate Act and approved execution baseline are committed.
Before actual execution, the model-serving component replaces the
original model with another generation.
The service endpoint and outward-facing tool interface remain
unchanged.
The protected activation monitor detects the new model generation.
The current activated-generation measurement differs from the
protected baseline.
Unless an authorized compatibility decision permits the replacement,
the corresponding finality authority becomes invalid or remains
fenced.
The agent may still generate a proposed command.
Das Expires 29 April 2027 [Page 200]
Internet-Draft Execution-Finality Part 7: Tools October 2026
However, the Finality Sink independently verifies the current
execution-generation authority and refuses the consequential
operation.
5.3.3.39. Source page 964 of the original specification
Expected demonstrable result: The measured active generation differs
from the approved generation, and the unsupported consequential
operation is withheld.
The protection arises from the mandatory connection between
activated-generation evidence and actual effectuation.
10.33 — WORKED EXAMPLE B: SIGNED-LOOKING BUT UNTRUSTED EXECUTION
RECORD
An attacker constructs a data object that resembles an authorized
execution record.
The object contains the expected model identifier, apparently valid
timestamps, and a favorable drift result.
However, the record was not authenticated by an enrolled authorized
verifier.
The requesting agent submits the object with its consequential
command.
The Finality Sink verifies the record's cryptographic origin,
authorized role, protected binding, and relevant current state.
The forged record fails the required verification.
The sink refuses effectuation.
Expected demonstrable result: A syntactically plausible but untrusted
record cannot substitute for qualified protected verification
evidence.
10.34 — WORKED EXAMPLE C: MODEL ADAPTER SUBSTITUTION
A protected system approves an agent using a specified base model and
adapter configuration.
The agent's runtime subsequently activates a different adapter.
The base model name and exposed service endpoint remain unchanged.
Das Expires 29 April 2027 [Page 201]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The protected measurement component identifies the actual adapter
generation.
The activated configuration no longer matches the permitted envelope.
The drift verifier classifies the change as incompatible or requiring
revalidation.
A consequential operation generated by the modified configuration
remains non-effective until valid authority is established.
5.3.3.40. Source page 965 of the original specification
This example addresses configurations in which measuring only the
base model would leave a security-relevant behavior modification
unexamined.
10.35 — WORKED EXAMPLE D: SILENT INFERENCE ROUTE CHANGE
A model-serving infrastructure routes an agent's request from a local
execution environment to a remote inference service.
The routing decision may be made for performance or resource-
management reasons.
However, the earlier approval may be limited to the local model and
associated information-handling conditions.
The protected router identifies the actual destination.
The new route is not included in the approved execution envelope.
The relevant protected authority is suspended.
Any separate transfer of protected input data is governed by its own
disclosure authority.
The resulting externally consequential command also requires valid
current finality authority.
This example distinguishes changing computational location from valid
authority to export information or perform the downstream operation.
10.36 — WORKED EXAMPLE E: ALGORITHM REPLACEMENT WITHOUT MODEL
REPLACEMENT
An autonomous system uses a stable model to generate candidate
options.
Das Expires 29 April 2027 [Page 202]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A separate algorithm selects which candidate operation should be
executed.
The selection algorithm is replaced while the model weights remain
unchanged.
The new algorithm chooses operations according to different criteria.
The approved baseline includes a protected commitment to the earlier
authorized selection logic.
The activated algorithmic logic measurement differs.
The protected verifier determines whether the new algorithm falls
within an approved compatibility class.
5.3.3.41. Source page 966 of the original specification
Absent valid continuity, the Finality Sink rejects the consequential
operation.
The example demonstrates that model integrity alone is insufficient
when another algorithm controls the actual action selected.
10.37 — WORKED EXAMPLE F: CHANGED RETRIEVAL CONTEXT
An autonomous agent is authorized to modify a specified project
record.
The agent subsequently retrieves an external document containing
instructions to change an unrelated record.
The model itself remains unchanged.
The lower-trust retrieval content influences the proposed operation.
The protected system maintains the original authorized effect
envelope independently of the retrieved document.
The Finality Sink reconstructs the actual pending target and
mutation.
The requested unrelated modification does not correspond to the
authorized operation.
The sink rejects the effect.
Das Expires 29 April 2027 [Page 203]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A protected context-drift detector may provide additional evidence,
but the mandatory operation-specific authority check does not depend
upon perfectly identifying every malicious instruction in the
retrieved document.
10.38 — WORKED EXAMPLE G: ACCELERATOR RUNTIME CHANGE
An autonomous controller uses an accelerator to calculate an action
parameter.
An inference runtime update changes the accelerator kernel or
numerical execution configuration.
The relevant protected baseline identifies the required runtime
assurance profile.
The current activated runtime is measured.
A protected verifier determines whether the changed implementation is
authorized or sufficiently compatible for the consequential command
class.
The actual output remains withheld until the applicable continuity
predicate and operation-specific authorization are satisfied.
5.3.3.42. Source page 967 of the original specification
Where the final command targets a physical device, the actuator
Finality Sink separately verifies the actual operation parameters.
A permitted numerical runtime update does not bypass the independent
physical-effect authorization.
10.39 — WORKED EXAMPLE H: BEHAVIORAL DRIFT WITHOUT ARTIFACT CHANGE
A deployed predictive model retains the same weights and executable
implementation.
However, the operating environment changes, resulting in materially
different input characteristics and degraded performance under a
defined monitoring test.
The protected behavioral monitor detects a specified deviation.
The system restricts or requires additional verification for selected
high-impact consequential operations.
Das Expires 29 April 2027 [Page 204]
Internet-Draft Execution-Finality Part 7: Tools October 2026
For example, ordinary internal predictions may continue while
automatic modification of protected resources is withheld.
The actual operation remains subject to Finality-Sink verification.
The system does not assert that the statistical drift detector
precisely identifies every unsafe output.
Instead, the detector triggers a protected change to the allowed
consequential authority.
10.40 — WORKED EXAMPLE I: MODEL ROLLBACK AFTER A FAILED UPDATE
An execution system activates a new model generation.
A fault causes the service to restore an earlier model.
The older model has a valid historical software signature.
However, its earlier operation-specific authority may have expired or
been superseded.
The protected execution controller advances or checks the current
generation state.
The Finality Sink rejects stale authority even though the restored
software was previously approved.
5.3.3.43. Source page 968 of the original specification
A valid protected reauthorization or compatibility procedure may
allow operation under the restored implementation.
This distinguishes valid software restoration from automatic
resurrection of old effectuation rights.
10.41 — WORKED EXAMPLE J: DISTRIBUTED MULTI-MODEL WORKFLOW
An autonomous workflow uses a planning model, a resource-selection
algorithm, and a separate execution agent.
The planning model proposes a task.
The resource-selection algorithm identifies a destination.
The execution agent constructs a real resource operation.
Each component may run under a different execution generation.
Das Expires 29 April 2027 [Page 205]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A protected dependency record identifies the components relevant to
the consequential decision.
The controller verifies required current generation identities and
valid authority continuity.
The final resource sink reconstructs the actual operation.
If an intermediate component changes the destination outside the
authorized effect envelope, the operation is withheld.
The example illustrates that current authority may depend upon
several computational components rather than one model file.
10.42 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
10.42.1 — Model Hot-Swap Attack
A malicious or unauthorized actor replaces the model after approval.
The activated-generation measurement and sink-time verification
detect or constrain the mismatch.
10.42.2 — Same-Name Model Substitution
A different model is served using the same public identifier.
5.3.3.44. Source page 969 of the original specification
Protected activation evidence identifies the relevant actual
generation.
10.42.3 — Partial Model Hashing
An attacker changes an unmeasured behavior-relevant component while
preserving the digest of a measured file.
The assurance depends upon appropriate dependency coverage.
10.42.4 — Adapter Injection
An unauthorized adapter changes model behavior.
The protected configuration measurement includes relevant adapter
state.
10.42.5 — Algorithmic Logic Substitution
Das Expires 29 April 2027 [Page 206]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A planning or command-selection procedure changes after
authorization.
The protected algorithmic commitment is revalidated.
10.42.6 — Runtime Library Replacement
A runtime dependency changes without changing the model.
Relevant current runtime evidence is checked.
10.42.7 — Compiler or Kernel Substitution
An unauthorized execution kernel is activated.
The protected execution envelope controls the applicable
implementation.
10.42.8 — Quantization Misrepresentation
A system claims equivalence for an optimized model without satisfying
the required verification.
The protected verifier requires appropriate evidence.
10.42.9 — Inference Routing Substitution
The agent's operation is generated by an unapproved remote model.
The actual route is bound to current execution authority.
10.42.10 — Forged Activated-Generation Evidence
An attacker creates a false current measurement.
5.3.3.45. Source page 970 of the original specification
The verifier checks the evidence source, identity, and binding.
10.42.11 — Forged Drift Receipt
A signed-looking approval object is presented without valid
authorized authentication.
The Finality Sink rejects it.
10.42.12 — Unauthorized Verifier
Das Expires 29 April 2027 [Page 207]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An authenticated component with the wrong role approves an execution
generation.
The sink checks verification authority.
10.42.13 — Stale Attestation Replay
An earlier valid measurement is replayed after the implementation
changes.
Freshness, epoch, and operation binding prevent unsupported reuse.
10.42.14 — Measurement-to-Use Swap
The measured implementation is replaced after validation but before
operation generation or effectuation.
The protected activation, generation, and effectuation bindings
detect or prevent the invalid transition.
10.42.15 — Hidden Dynamic Code Loading
A runtime loads new executable components after the original
measurement.
Mandatory load-path measurement or appropriately protected execution
restrictions are required.
10.42.16 — Memory-Resident Parameter Mutation
Behavior-relevant model parameters change in memory after file
verification.
The selected assurance profile requires suitable active-state
measurement or protection.
10.42.17 — Untrusted Context Injection
External data attempts to modify the agent's effective authority.
The protected system separates context from source authority and
verifies actual operations.
10.42.18 — Prompt Hierarchy Confusion
Lower-trust content impersonates higher-trust instructions.
Das Expires 29 April 2027 [Page 208]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.3.3.46. Source page 971 of the original specification
Protected instruction-authority rules and sink-side scope enforcement
prevent the content from independently granting effectuation rights.
10.42.19 — Retrieval-State Substitution
A retrieved resource is replaced after the original approval.
Protected context or actual target verification restricts
unauthorized effects.
10.42.20 — Tool-Contract Drift
An updated tool introduces new side effects.
The current tool semantics must satisfy the authorized effect
envelope.
10.42.21 — Resource Alias Drift
An operation's actual target changes through an environment update.
The Finality Sink verifies actual resource correspondence.
10.42.22 — Policy Rollback
An earlier permissive policy is restored without current authority.
Protected policy epochs reject stale authorization.
10.42.23 — Model Rollback Authority Replay
A restored older model attempts to reuse previously valid but expired
finality authority.
The sink verifies current protected state.
10.42.24 — Behavioral Drift Concealment
An agent attempts to suppress unfavorable runtime monitoring data.
Protected metric sources and mandatory enforcement constraints limit
the effect of unsupported monitoring claims.
10.42.25 — Statistical False Negative
Das Expires 29 April 2027 [Page 209]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The model produces a problematic individual operation without
triggering an aggregate drift alarm.
The actual operation remains subject to independent finality checks.
10.42.26 — Statistical False Positive
A drift detector reports change despite a permitted implementation.
5.3.3.47. Source page 972 of the original specification
A protected compatibility or recovery process may restore authority
under defined rules.
10.42.27 — Verification Exhaustion
An attacker forces repeated expensive model measurements or
equivalence checks.
The system uses bounded verification work, cached protected validity,
and conservative handling of required verification failure.
10.42.28 — Remote Provider Misrepresentation
A remote service provides unsupported assertions about its active
model.
The guarantee depends upon qualified evidence or appropriate
restrictions at covered effectuation paths.
10.42.29 — Distributed Component Mismatch
Different participating services use inconsistent generations.
The protected dependency verification checks the relevant
composition.
10.42.30 — Unapproved Hardware Migration
Execution moves to another device without corresponding authority
continuity.
The current execution identity and applicable ownership state are
verified.
10.42.31 — Accelerator Direct-Egress Bypass
An effect-capable accelerator path avoids the ordinary host gateway.
Das Expires 29 April 2027 [Page 210]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The protected system must control relevant hardware effectuation
paths.
10.42.32 — Snapshot Rollback
An execution environment restores an earlier protected-looking state.
Current authoritative epochs prevent invalid state resurrection.
10.42.33 — Duplicate Authority Consumption
A model generates repeated commands using one earlier authorization.
Sink-local protected consumption prevents unauthorized repeated
exercise.
10.42.34 — Content Substitution
A model produces one approved output but a different command is sent
for effectuation.
5.3.3.48. Source page 973 of the original specification
The Finality Sink reconstructs the actual pending operation.
10.42.35 — Compromised Runtime
The runtime fabricates its own execution-state measurements.
A stronger implementation requires trusted observation or enforced
runtime restrictions under the applicable threat model.
10.42.36 — Compromised Finality Sink
An attacker controls the effect-capable controller itself.
The claimed guarantee depends upon an appropriately protected
downstream or hardware enforcement boundary.
10.42.37 — Unknown Prior Effect
An earlier command may have executed before drift was detected.
The system records or preserves uncertainty and does not assume the
prior effect was prevented.
10.42.38 — Unauthorized Recovery Action
Das Expires 29 April 2027 [Page 211]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An agent proposes a corrective operation after detected drift without
valid authority.
The recovery operation requires its own protected authorization.
10.42.39 — Emergency-Mode Abuse
An agent attempts to bypass drift restrictions by claiming emergency
status.
A protected emergency rule must be authenticated and bounded.
10.42.40 — Newly Introduced Egress Path
A software update creates an effectuation interface not covered by
existing Finality Sinks.
The applicable enforcement-coverage state must be reassessed.
10.43 — CRASH CONSISTENCY, UNCERTAINTY, AND RECOVERY
10.43.1 — Crash Before Activation
A new execution generation is not presumed active without the
required protected activation evidence.
5.3.3.49. Source page 974 of the original specification
10.43.2 — Crash During Measurement
Incomplete required evidence does not become an accepted current-
generation result.
10.43.3 — Crash After Baseline Approval
Current validity must be established independently of mere possession
of the earlier approval.
10.43.4 — Crash During Model Replacement
The controller may recover the current model generation and affected
authority state.
10.43.5 — Crash During Revalidation
A partially completed comparison does not constitute a valid
compatibility result.
Das Expires 29 April 2027 [Page 212]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10.43.6 — Crash After Authority Commit
The protected system recovers the current valid authority and
consumption state.
10.43.7 — Crash After Effect Dispatch
The actual operation may have occurred.
The system preserves the appropriate attempt and outcome uncertainty.
10.43.8 — Rollback to Approved Implementation
A previous implementation may be reactivated only under current valid
authority and state.
10.43.9 — Recovery Candidate Act
A corrective external effect requires valid current operation-
specific authorization.
10.43.10 — Optional Causal Receipt
Where a successor operation requires receipt-constituted authority
under CW-2, the required accepted actual-effect receipt remains
necessary despite successful execution-drift revalidation.
10.44 — NON-LIMITING PROPOSED FEASIBILITY EXPERIMENTS
The following experiments are proposed for technical validation and
are not represented as completed results.
Experiment 1 — Approved Model Execution: Activate an approved model
and verify valid operation-specific finality authorization.
5.3.3.50. Source page 975 of the original specification
Experiment 2 — Model Replacement After Approval: Replace the model
after approval and confirm that unsupported current authority is
rejected.
Experiment 3 — Same Model Name: Serve a different model under the
same external identifier and test detection.
Experiment 4 — Adapter Replacement: Change a behavior-relevant
adapter while preserving the base model.
Das Expires 29 April 2027 [Page 213]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Experiment 5 — Model Weight Mutation: Modify selected parameters and
verify the applicable active-state measurement.
Experiment 6 — Algorithm Replacement: Change the action-selection
algorithm while preserving model weights.
Experiment 7 — Runtime Library Update: Replace a relevant runtime
dependency after approval.
Experiment 8 — Accelerator Kernel Change: Alter a protected execution
kernel and test current-generation validation.
Experiment 9 — Permitted Quantization: Activate an approved optimized
model and verify compatible continuity.
Experiment 10 — Unverified Quantization: Substitute an optimized
model without sufficient compatibility evidence.
Experiment 11 — Inference Route Change: Redirect a request from one
model-serving environment to another.
Experiment 12 — Remote Model Evidence: Evaluate authenticated and
unsupported claims concerning a remote model's actual generation.
Experiment 13 — Multi-Model Composition: Verify a workflow in which
several models contribute to one Candidate Act.
Experiment 14 — Forged Measurement: Present an altered current-
generation record.
Experiment 15 — Signed-Looking Record: Present a syntactically valid
but cryptographically untrusted drift receipt.
Experiment 16 — Wrong Verifier Role: Use a genuine signature from an
entity unauthorized for execution revalidation.
Experiment 17 — Stale Attestation: Replay an earlier valid
environment measurement after a relevant update.
Experiment 18 — Measurement-to-Use Swap: Change the active
implementation after measurement.
5.3.3.51. Source page 976 of the original specification
Experiment 19 — Dynamic Module Load: Load an unapproved execution
dependency after initial activation.
Das Expires 29 April 2027 [Page 214]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Experiment 20 — Authorized Runtime Change: Demonstrate protected
continuity after a verified compatible update.
Experiment 21 — Incompatible Runtime Change: Confirm withholding of
an actual effect after incompatible drift.
Experiment 22 — Context Injection: Insert lower-trust instructions
attempting to change the authorized operation.
Experiment 23 — Retrieval Resource Change: Change retrieved
information relevant to the pending consequential operation.
Experiment 24 — Resource Alias Change: Modify the mapping of an
authorized target.
Experiment 25 — Tool Semantic Update: Introduce additional side
effects while preserving the tool interface.
Experiment 26 — Policy Epoch Change: Update the protected
authorization policy while an operation remains pending.
Experiment 27 — Rollback: Restore an older model generation and
verify current rather than historical authority.
Experiment 28 — Behavioral Drift: Trigger a defined statistical drift
alarm without changing the model file.
Experiment 29 — False-Negative Protection: Generate an unauthorized
actual operation that does not trigger the statistical monitor and
verify sink rejection.
Experiment 30 — Nondeterministic Output: Repeat inference under valid
conditions and distinguish permitted output variation from
unauthorized consequential scope.
Experiment 31 — Candidate Act Substitution: Change the actual
outgoing command after protected computation.
Experiment 32 — Authority Replay: Reuse one consumed effectuation
authorization.
Experiment 33 — Hardware Migration: Transfer execution to another
device while maintaining current ownership and finality requirements.
Experiment 34 — Snapshot Rollback: Restore an old execution snapshot
containing stale authority.
Das Expires 29 April 2027 [Page 215]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Experiment 35 — Direct Accelerator Effect: Test relevant hardware-
level effectuation-path coverage.
5.3.3.52. Source page 977 of the original specification
Experiment 36 — Parallel Model Update: Update a model while multiple
consequential operations are pending.
Experiment 37 — Distributed Verifiers: Validate current execution
state using separately authenticated components.
Experiment 38 — One-Component Controller: Implement measurement,
drift verification, and finality within one protected component.
Experiment 39 — Source-Fencing Integration: Combine execution drift
revalidation with exclusive device migration from Embodiment 9.
Experiment 40 — Credential Broker Integration: Withhold credential
exercise after an unapproved model or runtime change.
Experiment 41 — Causal Continuation: Require a valid CW-2 earlier
real-effect receipt for a successor operation after a compatible
model update.
Experiment 42 — Unknown Effect Outcome: Crash after a consequential
dispatch and verify preservation of uncertainty.
Experiment 43 — Verification Exhaustion: Supply large or malformed
execution dependency evidence and verify bounded processing.
Experiment 44 — Enforcement-Path Update: Introduce a new consequence-
producing interface and verify coverage reattestation.
Experiment 45 — No Blockchain: Implement authenticated execution
continuity and actual Finality-Sink enforcement without a distributed
ledger.
10.45 — PRESENT-DAY PHOSITA REFERENCE IMPLEMENTATION
10.45.1 — Minimum Prototype Architecture
A reference implementation may comprise two distinguishable model
generations, a protected deployment controller, an authenticated
baseline store, an activation-measurement component, an independent
decision verifier, and a controlled consequential API gateway.
10.45.2 — Initial Baseline
Das Expires 29 April 2027 [Page 216]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The first model generation is approved for a defined Candidate Act
and resource operation.
10.45.3 — Current Activation
The measurement component records the actual active generation.
10.45.4 — Protected Operation
5.3.3.53. Source page 978 of the original specification
The model produces a proposed operation, which remains withheld at
the controlled gateway.
10.45.5 — Approved Release
The gateway permits the operation when current execution evidence and
actual effect authority satisfy the applicable conditions.
10.45.6 — Replacement Test
The deployment controller activates the second model while the
earlier operation remains pending.
10.45.7 — Detection
The current measurement and approved baseline no longer correspond.
10.45.8 — Enforcement
The gateway rejects the unsupported operation.
10.45.9 — Valid Revalidation
A protected authorized continuity procedure may establish a new valid
execution envelope where appropriate.
10.45.10 — Revalidation Result
A consequential operation may then be permitted under current scoped
authority.
10.45.11 — Cryptographic Evidence
The prototype may use established digital signatures or authenticated
protected state to identify the verifier and decision.
10.45.12 — Independent Finality
Das Expires 29 April 2027 [Page 217]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The consequential API gateway must enforce the decision rather than
merely display the monitoring result.
10.45.13 — Prototype Scope
A software-only prototype can demonstrate the protocol under a stated
trusted-gateway assumption.
Stronger resistance to operating-system compromise requires
appropriate hardware or otherwise independently protected
enforcement.
10.46 — FEASIBILITY, LATENCY, AND ENGINEERING TRADEOFFS
5.3.3.54. Source page 979 of the original specification
10.46.1 — Event-Driven Measurement
A protected system may measure a model or runtime when it is
activated or changed.
10.46.2 — Cached Current Evidence
A Finality Sink may verify a current protected generation reference
instead of recomputing all large model hashes for every operation.
10.46.3 — Measurement Freshness
Cached evidence must remain bound to protected update controls,
current epochs, and applicable freshness conditions.
10.46.4 — Incremental Verification
A changed adapter may require remeasurement of affected dependencies
rather than every unchanged component, where the dependency model
supports the resulting assurance.
10.46.5 — Large Model Parameters
Model weights may occupy substantial storage and memory.
The system may use protected activation measurements, authenticated
model manifests, verified memory loading, or suitable hardware
measurement mechanisms.
10.46.6 — Runtime Measurement
Das Expires 29 April 2027 [Page 218]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Dynamically generated code or mutable runtime components may require
appropriate load-time monitoring or execution restrictions.
10.46.7 — Remote Execution Limits
A remote model provider may not expose evidence sufficient to
establish all local execution properties.
The implementation may constrain consequential authority accordingly.
10.46.8 — Statistical Monitoring Cost
Behavioral drift evaluation may be performed on sampled observations
or designated monitoring windows.
Its assurance depends upon the selected statistical model and sample
quality.
10.46.9 — Finality Latency
A suitable implementation may use compact sink-local validity checks
while retaining stronger revalidation on material changes.
5.3.3.55. Source page 980 of the original specification
10.46.10 — Verification Exhaustion
When mandatory verification cannot complete within a protected
budget, the relevant consequence remains withheld or governed under
another expressly authorized safe procedure.
10.46.11 — Avoidance of Universal Reapproval
A verified compatible implementation change may permit scoped
continuity without requiring unconditional new user approval.
10.46.12 — Practical Assurance Statement
The implementation must identify exactly which execution state is
measured, which properties are verified, which changes are permitted,
and which consequential interfaces enforce current authority.
10.47 — OPTIONAL ADVANCED FUTURE-ORIENTED CONCEPTS
10.47.1 — Continually Updated Autonomous Models
Models that receive ongoing parameter updates may maintain protected
execution generations and bounded revalidation requirements.
Das Expires 29 April 2027 [Page 219]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10.47.2 — Dynamic Model Composition
Autonomous systems may combine several models at runtime.
The protected dependency state may identify the relevant contributing
generations.
10.47.3 — Agent Swarm Computation
Multiple agents may contribute to a shared consequential operation.
Required execution-state authority may be evaluated across the
relevant participants.
10.47.4 — Confidential Inference
A confidential execution environment may supply authenticated
evidence concerning its active model generation while external
effectuation remains separately governed.
10.47.5 — Neural Accelerator Integrity
Protected accelerator controllers may enforce operation-specific
execution authority under measured or authenticated model and runtime
state.
10.47.6 — Edge-to-Cloud Switching
5.3.3.56. Source page 981 of the original specification
A task may move between on-device and remote inference while
retaining protected effect and information-disclosure constraints.
10.47.7 — Future Programmable Hardware
Runtime-modified programmable logic may require current-generation
verification before effect-capable commands are released.
10.47.8 — Cross-Device Algorithm Continuity
A computation may migrate among heterogeneous devices while
preserving current protected ownership and algorithmic authorization.
10.47.9 — Autonomous Robotics
A robotic controller may require current perception, planning, and
actuator-command authority before real physical movements.
Das Expires 29 April 2027 [Page 220]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10.47.10 — Autonomous Vehicles
A protected vehicle subsystem may restrict selected consequential
commands after material changes to relevant computational or control
implementations.
10.47.11 — Telecommunications and Network Control
An autonomous network controller may verify current optimization
algorithms before applying protected configuration changes.
10.47.12 — Industrial Control
A protected controller may verify current algorithm, firmware, and
resource states before allowing consequential industrial commands.
10.47.13 — Financial Autonomous Agents
A protected transaction sink may require current model and operation-
specific authority where the relevant transaction policy makes
execution-generation continuity mandatory.
10.47.14 — Long-Lived Autonomous Memory
A protected system may evaluate relevant changes to persistent
memory, retrieved context, or behavioral configuration before
permitting selected consequential effects.
10.47.15 — Model-Generated Code
An agent may generate executable code during a task.
The resulting code or its permitted effectuation interface may
require separate protected verification before real effects occur.
5.3.3.57. Source page 982 of the original specification
10.47.16 — Privacy-Preserving Generation Proofs
A verifier may establish selected execution-generation properties
without disclosing all proprietary model parameters.
Such proofs must be bound to the actual activated state.
10.47.17 — Post-Quantum Authentication
The cryptographic authentication of execution evidence may migrate to
suitable future mechanisms.
Das Expires 29 April 2027 [Page 221]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10.47.18 — Dynamic Hardware Interconnects
The execution environment may include evolving shared accelerator
fabrics or other programmable device interconnects.
10.47.19 — Cross-Domain Execution Continuity
Independent administrative domains may exchange qualified current-
generation evidence while enforcing their own actual consequential
boundaries.
10.47.20 — Unified Autonomous Execution-Finality Infrastructure
A common protected service may provide activated-generation
verification, drift-aware authority continuity, and non-bypassable
effectuation control across heterogeneous AI and non-AI computational
systems.
10.48 — OPTIONAL INVENTIVE TECHNICAL COMBINATIONS
10.48.1 — Approved Baseline Plus Actual Generation
The protected system requires correspondence between an authenticated
approved execution baseline and the model or algorithm actually
activated.
10.48.2 — Protected ALF Plus Finality Sink
An authorized Algorithmic Logic Fingerprint is verified against the
active logic generation before the actual effectuation boundary
permits a consequential operation.
10.48.3 — Model Hot-Swap Plus Epoch Fencing
A model replacement advances protected execution state and
invalidates affected stale operation authority.
10.48.4 — Adapter Identity Plus Scoped Authority
5.3.3.58. Source page 983 of the original specification
A behavior-affecting adapter becomes a protected dependency of
operation-specific finality authorization.
10.48.5 — Model Routing Plus Execution Provenance
A protected controller identifies the actual inference route and uses
that evidence in finality revalidation.
Das Expires 29 April 2027 [Page 222]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10.48.6 — Behavioral Drift Plus Consequential Restriction
A defined statistical drift alarm modifies current authority over
selected consequential operations without necessarily disabling
harmless computation.
10.48.7 — Algorithm Change Plus Resource Correspondence
A changed action-selection algorithm cannot authorize effects on
resources outside the original permitted envelope.
10.48.8 — Runtime Attestation Plus Actual Operation
An authenticated current runtime result is verified alongside actual
pending-operation reconstruction.
10.48.9 — Credential Release Plus Drift State
A protected credential broker refuses operation-specific secret
exercise under an incompatible active generation.
10.48.10 — Device Migration Plus Execution Drift
A destination device must satisfy current ownership, model, runtime,
and actual effectuation authority.
10.48.11 — Privacy Continuity Plus Model Routing
Changing a computational model or provider does not reset applicable
protected cumulative disclosure authority.
10.48.12 — Causal Receipt Plus Execution Continuity
A successor operation may require both current verified execution-
generation authority and a CW-2 accepted prior real-effect receipt
constituting a necessary causal continuation factor.
10.49 — PROPOSED INVENTIVE-STEP ANALYSIS
10.49.1 — Established Prior Art
5.3.3.59. Source page 984 of the original specification
Model drift monitoring, concept drift detection, model versioning,
executable hashing, runtime integrity, software signing, remote
attestation, firmware resiliency, and ordinary policy reauthorization
are established technical fields.
Das Expires 29 April 2027 [Page 223]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The present embodiment does not assert invention of those mechanisms
individually.
10.49.2 — Candidate Objective Technical Problem
A candidate objective technical problem is:
How to prevent a previously authorized autonomous consequential
operation from becoming effective under a materially changed
computational generation by binding protected approval to qualified
actual activated-state evidence and enforcing current execution
correspondence together with actual operation-specific authority at
the Finality Sink.
10.49.3 — Candidate Technical Solution
The proposed arrangement may comprise:
A protected approved-execution baseline;
Qualified actual activated-generation measurement;
Relevant model, algorithm, runtime, and context dependency
verification;
Protected drift classification;
Current authorized compatibility or revalidation evidence;
Generation-bound scoped finality authority;
And independent sink-time verification of the actual consequential
operation.
10.49.4 — Technical Interaction
The baseline establishes relevant authorized execution conditions.
The measurement controller identifies the active generation.
The drift verifier evaluates correspondence.
The authority controller determines whether earlier operation-
specific authority remains valid.
The Finality Sink independently verifies both current execution-state
authority and the real pending operation.
Das Expires 29 April 2027 [Page 224]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The sink-local protected state prevents stale or repeated
unauthorized effectuation.
5.3.3.60. Source page 985 of the original specification
10.49.5 — Why Model Monitoring Alone Is Insufficient
A monitoring system may detect drift and generate an alert while the
agent continues exercising previously issued credentials or
permissions.
The proposed principal architecture makes current drift validity a
necessary effectuation condition.
10.49.6 — Why Signed Model Identity Alone Is Insufficient
A signed model artifact may identify approved software while leaving
unmeasured adapters, changed runtime logic, or actual operation
substitution unchecked.
The protected system evaluates the dependencies required for its
specified guarantee.
10.49.7 — Why Attestation Alone Is Insufficient
An attestation result may support trust in an execution environment.
The actual external operation must still correspond to valid
consequential authority.
10.49.8 — Why Output Filtering Alone Is Insufficient
A generic filter may inspect content without verifying the execution
generation, source authority, real resource identity, or sink-local
consumption conditions.
10.49.9 — Candidate Narrow Inventive Kernel
A potentially significant technical combination is:
A protected autonomous execution-control system that binds an
authorized Candidate Act to an authenticated execution baseline,
obtains qualified evidence identifying the model or algorithm
generation actually activated, invalidates or revalidates
consequential authority upon a security-relevant generation change,
and requires a Finality Sink to reconstruct the actual pending
operation and verify current generation-bound non-bearer authority
before permitting the governed real effect.
Das Expires 29 April 2027 [Page 225]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10.49.10 — Additional Narrow Kernel
A narrower implementation may require independently measured
algorithmic logic correspondence, authenticated verifier identity,
protected execution-generation fencing, and sink-local atomic
consumption.
10.49.11 — Hardware-Oriented Kernel
Another implementation may require protected activation evidence
spanning model or algorithm state, runtime configuration, and a
hardware command dispatcher that enforces operation-specific finality
authority.
10.49.12 — Distributed Kernel
5.3.3.61. Source page 986 of the original specification
Another implementation may require authenticated execution-generation
evidence across independently administered inference and effectuation
domains, with destination-side finality verification.
10.49.13 — Hindsight Considerations
A proper inventive-step evaluation should determine whether the
closest prior-art systems already teach or render obvious the
particular mandatory dependencies among approved generation, current
activation, authority continuity, and actual consequential release.
The use of familiar components does not itself establish inventive
step.
Conversely, the presence of individual monitoring or attestation
techniques does not automatically establish every specific
effectuation-control relationship.
The distinguishing technical state transitions and actual enforcement
consequences should be identified precisely.
10.49.14 — Qualification
The claimed invention should not depend upon an unsupported assertion
that arbitrary algorithmic behavior can be perfectly fingerprinted or
that statistical drift detection guarantees absence of harmful
operations.
Patentability depends upon the precise claimed implementation and
relevant prior art.
Das Expires 29 April 2027 [Page 226]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10.50 — INDUSTRIAL APPLICABILITY
10.50.1 — Enterprise Autonomous Agents
Enterprise agents may continue processing tasks while external
resource modifications remain dependent upon current verified
execution state.
10.50.2 — Cloud Model Serving
Model-serving infrastructure may bind consequential operations to
actual activated model generations rather than model names alone.
10.50.3 — Multi-Agent Orchestration
Several cooperating agents may operate under protected current-
generation and source-authority constraints.
10.50.4 — Autonomous Coding Systems
Generated code, deployment commands, or repository modifications may
require current algorithm and operation-specific finality
verification.
5.3.3.62. Source page 987 of the original specification
10.50.5 — Financial Systems
Protected transaction controllers may restrict effectuation after
unauthorized changes to relevant computational generation or
transaction-selection logic.
10.50.6 — Healthcare Information Systems
Autonomous decision-support outputs that lead to governed external
operations may be subjected to current-generation verification
according to the applicable system policy.
10.50.7 — Industrial Automation
A protected control device may verify current algorithm, firmware,
and real command authority before changing industrial equipment
state.
10.50.8 — Autonomous Robotics
Robotic planning or perception changes may trigger additional
verification before consequential actuation.
Das Expires 29 April 2027 [Page 227]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10.50.9 — Autonomous Vehicles
Selected safety-relevant computational updates may require protected
validation before actual controller commands become effective.
10.50.10 — Telecommunications
Autonomous network-control algorithms may be verified against current
protected authority before applying real configuration changes.
10.50.11 — Storage and Database Infrastructure
Generated storage or database mutation commands may require current
algorithmic correspondence and actual target verification.
10.50.12 — Mobile and Desktop Assistants
Device assistants may invoke consequential applications only under
current valid execution and operation-specific authority.
10.50.13 — Confidential Computing
Attested computation may be combined with separate protected
authorization of actual outputs and external effects.
10.50.14 — Hardware Accelerators
GPU, NPU, and other accelerator execution generations may be
associated with protected effectuation authority.
5.3.3.63. Source page 988 of the original specification
10.50.15 — Embedded Devices
Firmware or algorithm updates may trigger revalidation of controlled
physical or communication effects.
10.50.16 — Distributed Edge Computing
Autonomous workloads may change execution nodes while preserving
approved generation and consequential scope restrictions.
10.50.17 — Remote and Satellite Systems
Intermittently connected controllers may employ bounded protected
authority and conservative current-generation assumptions.
10.50.18 — Future Adaptive AI
Das Expires 29 April 2027 [Page 228]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Adaptive or continuously updated models may operate under generation-
aware authority constraints appropriate to their actual effectuation
capabilities.
10.50.19 — Model-Independent Computing
The same architecture may control non-neural algorithms whose
executable behavior changes after authorization.
10.50.20 — Shared Protected Finality Services
A common protected execution-finality infrastructure may provide
reusable drift-aware authority checks across multiple autonomous
computing frameworks.
The industrial utility lies in enforcing current consequential
authorization despite changes in the computational implementation
producing the operation.
10.51 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
10.51.1 — Candidate Independent System Claim
A candidate system claim may concern a protected execution-finality
system comprising:
An approved-execution baseline component configured to maintain
authenticated security-relevant computational state associated with
an authorized Candidate Act;
An activated-generation measurement component configured to obtain
evidence identifying the actual model, algorithm, or relevant
execution generation;
A protected drift verifier configured to evaluate correspondence
between the active generation and the approved baseline;
5.3.3.64. Source page 989 of the original specification
A protected authority controller configured to maintain, restrict, or
revalidate consequential authority according to the drift decision;
And a Finality Sink configured to reconstruct the actual pending
consequential operation and permit effectuation only when the
required current execution-generation and operation-specific finality
predicates are satisfied.
10.51.2 — Candidate Independent Method Claim
Das Expires 29 April 2027 [Page 229]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A corresponding method may comprise:
Establishing an approved execution baseline;
Measuring the activated computational generation;
Detecting an execution-state change;
Evaluating a protected continuity predicate;
Restricting or reauthorizing consequential authority;
Obtaining the actual pending operation at a protected Finality Sink;
Verifying its current generation-bound authority and effect scope;
And controlling the real consequence through protected state
consumption.
10.51.3 — Candidate Independent Algorithmic Logic Claim
Another candidate may focus upon authenticated comparison between an
approved algorithmic logic commitment and the activated algorithmic
generation, with the matching result forming a necessary condition of
actual consequential effectuation.
10.51.4 — Candidate Independent Hardware Claim
A protected device apparatus may include an execution-state
measurement interface, a current authority state reference, and a
command-release controller that refuses consequential commands
lacking valid current-generation and operation-specific authority.
10.51.5 — Candidate Distributed System Claim
A distributed implementation may include an authenticated remote
computation verifier and a destination Finality Sink independently
checking current activated-generation evidence against the real
pending operation.
The appropriate independent-claim organization is subject to
examination of technical unity, prior art, and filed disclosure
support.
5.3.3.65. Source page 990 of the original specification
10.52 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
Das Expires 29 April 2027 [Page 230]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Dependent aspect 1: The baseline identifies a particular model
generation.
Dependent aspect 2: The baseline identifies an algorithmic logic
generation.
Dependent aspect 3: The system measures the model actually activated
rather than solely a stored model artifact.
Dependent aspect 4: The activated measurement includes behavior-
relevant adapter identity.
Dependent aspect 5: The measurement includes relevant inference-
runtime identity.
Dependent aspect 6: The measurement includes relevant hardware
execution configuration.
Dependent aspect 7: The protected controller maintains an execution
dependency closure.
Dependent aspect 8: The system detects model replacement after
original authorization.
Dependent aspect 9: The system detects an algorithm replacement
without requiring model-weight replacement.
Dependent aspect 10: The system detects a change to the inference
routing destination.
Dependent aspect 11: The system detects a change to protected
instruction-context conditions.
Dependent aspect 12: The system identifies relevant retrieval-context
changes.
Dependent aspect 13: A protected execution epoch is advanced
following a material update.
Dependent aspect 14: Earlier affected authority is fenced following
an incompatible execution change.
Dependent aspect 15: Current continuity may be verified by exact
protected measurement equality.
Dependent aspect 16: Current continuity may be verified by membership
in an approved generation set.
Das Expires 29 April 2027 [Page 231]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Dependent aspect 17: Current continuity may be established by a
defined protected compatibility predicate.
Dependent aspect 18: The system uses an approved Algorithmic Logic
Fingerprint.
Dependent aspect 19: An activated ALF is compared against the
approved fingerprint record.
Dependent aspect 20: An authenticated verifier produces a drift-
verification receipt.
5.3.3.66. Source page 991 of the original specification
Dependent aspect 21: The verifier possesses an enrolled cryptographic
identity and authorized role.
Dependent aspect 22: The drift receipt is bound to the relevant
Candidate Act.
Dependent aspect 23: The receipt is bound to a current execution-
generation epoch.
Dependent aspect 24: The receipt is bound to a designated Finality
Sink.
Dependent aspect 25: The system requires renewed authority following
incompatible drift.
Dependent aspect 26: Compatible updates may preserve scoped authority
under protected continuity evidence.
Dependent aspect 27: The Finality Sink reconstructs the actual
pending operation.
Dependent aspect 28: The sink verifies the actual operation against
the authorized effect envelope.
Dependent aspect 29: The sink verifies current model or algorithm
generation authority.
Dependent aspect 30: The sink verifies current resource and
destination identity.
Dependent aspect 31: The sink verifies current revocation and
consumption state.
Das Expires 29 April 2027 [Page 232]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Dependent aspect 32: The sink consumes a scoped non-bearer finality
enablement.
Dependent aspect 33: A copied earlier authority object cannot
authorize an incompatible new generation.
Dependent aspect 34: A signed-looking but cryptographically untrusted
execution record is rejected.
Dependent aspect 35: A genuine record from an unauthorized verifier
is rejected.
Dependent aspect 36: The system prevents stale attestation replay
through protected epoch or freshness binding.
Dependent aspect 37: Material statistical drift triggers a protected
consequential-authority restriction.
Dependent aspect 38: Statistical drift monitoring is distinguished
from mandatory actual-operation checks.
Dependent aspect 39: Dynamically loaded code is included in the
relevant protected execution state.
Dependent aspect 40: A model snapshot cannot independently restore
consumed or revoked consequential authority.
5.3.3.67. Source page 992 of the original specification
Dependent aspect 41: Execution migration requires current device
ownership and model-generation verification.
Dependent aspect 42: Accelerator execution state is associated with a
protected hardware effectuation controller.
Dependent aspect 43: Credential release requires current valid
execution-generation authority.
Dependent aspect 44: External information disclosure remains subject
to applicable cumulative privacy constraints.
Dependent aspect 45: Cross-agent operations remain subject to
authenticated delegation and attenuation where required.
Dependent aspect 46: A successor operation requiring CW-2 causal
continuation additionally verifies an accepted prior real-effect
receipt.
Das Expires 29 April 2027 [Page 233]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Dependent aspect 47: The system permits bounded cached execution
measurements under protected update and freshness conditions.
Dependent aspect 48: Verification failure does not automatically
authorize the governed real effect.
Dependent aspect 49: The verification and effectuation functions may
be integrated into one protected controller.
Dependent aspect 50: The verification and effectuation functions may
be distributed among separately authenticated components.
Dependent aspect 51: A new effectuation path triggers protected
enforcement-coverage reassessment.
Dependent aspect 52: The system employs authenticated protected
records without requiring a blockchain.
These aspects are non-limiting candidate claim-support features and
are not represented as separately proven patentable inventions.
10.53 — NON-LIMITING COMBINATION AND IMPLEMENTATION CLAUSE
Unless technically incompatible or expressly excluded, the disclosed
mechanisms may be combined with corresponding protected authority,
validation, execution, provenance, resource-control, privacy,
migration, and Finality Sink mechanisms of other embodiments.
A particular implementation may use exact model-generation equality
without statistical drift detection.
5.3.3.68. Source page 993 of the original specification
Another may employ behavioral drift monitoring as an additional
trigger without requiring identical model weights.
Another may employ activated algorithmic fingerprint comparison
without a neural model.
Another may use protected model attestation, but still require
independent actual-operation verification.
Another may use a physically separate verifier.
Another may integrate verification and effectuation within one
protected hardware or software component.
Das Expires 29 April 2027 [Page 234]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A particular optional combination is not automatically mandatory for
every independent claim.
The illustrative algorithms, pseudocode, records, diagrams, state
machines, experiments, and implementation examples are non-limiting
technical aids intended to assist a person having ordinary skill in
the art in understanding and implementing the described mechanisms.
They do not restrict the invention to the particular programming
language, algorithm, hardware device, software framework,
cryptographic primitive, provider, or execution topology used in an
example.
Proposed experiments are not statements that the relevant tests have
already been performed.
Future-oriented implementations are technically illustrative and
require appropriate enabling detail for any specific scope ultimately
claimed.
10.54 — FINAL TECHNICAL SUMMARY AND INVENTIVE-STEP CHARACTERIZATION
The present Embodiment 10 discloses an architecture for protecting
consequential execution authority when the model, algorithm,
inference runtime, adapter configuration, instruction context,
hardware environment, or other relevant computational state changes
after authorization.
The system establishes an authenticated approved-execution baseline
associated with a defined Candidate Act or permitted effect class.
A protected measurement component obtains qualified evidence
concerning the actual computational generation activated for the
relevant operation.
A protected verifier compares the activated generation with the
applicable baseline using an expressly defined correspondence or
compatibility predicate.
Material execution drift may invalidate, suspend, narrow, or trigger
revalidation of previously issued consequential authority.
5.3.3.69. Source page 994 of the original specification
Where compatible continuation is established, a protected controller
may prepare a current scoped non-bearer finality enablement.
The requesting agent may continue performing computational work.
Das Expires 29 April 2027 [Page 235]
Internet-Draft Execution-Finality Part 7: Tools October 2026
However, its ability to compute does not independently grant
authority to produce the corresponding external effect.
The Finality Sink independently reconstructs the actual operation
presented for effectuation.
It verifies the applicable Candidate Act, current execution-
generation state, protected drift evidence, operation-specific
authority, actual target, current revocation state, and sink-local
consumption conditions.
Only when the required predicates pass may the real consequential
effect be permitted.
The architecture may support exact execution-generation measurements,
approved compatibility sets, algorithmic logic fingerprints,
protected model-adapter state, runtime attestation, statistical drift
triggers, and combinations thereof.
The use of any particular fingerprint, cryptographic primitive,
hardware environment, or statistical detector is optional unless
required by a selected claim.
The architecture does not assert that a software signature proves
complete behavioral equivalence.
It does not assert that statistical monitoring can detect every
unsafe model output.
It does not assert that an authenticated remote model declaration
necessarily proves the actual executed computation.
It does not treat an earlier valid approval as an unrestricted
permanent right to produce consequential operations under changed
execution conditions.
Instead, the proposed protection arises from maintaining a current
verified relationship among the authorized computation, the execution
generation actually activated, and the operation actually presented
for external effectuation.
Das Expires 29 April 2027 [Page 236]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The principal candidate inventive technical contribution of
Embodiment 10 is a protected execution-finality system in which an
authenticated approved computational baseline is compared with
qualified measurements of the actual activated model or algorithm
generation, material drift causes protected revalidation or fencing
of consequential authority, and an independently enforcing Finality
Sink refuses the actual pending external operation unless current
generation-bound, operation-specific, non-bearer finality
authorization is valid.
Its novelty, inventive step, unity, and appropriate claim scope
remain subject to examination against relevant prior art and the
enabling technical disclosure actually filed.
END OF EMBODIMENT 10 — COMPLETE TECHNICAL DISCLOSURE.
5.4. Embodiment 21 — Authenticated Resource Alias and Actual Resource
Identity Resolution
Original global source pages 1758 through 1829, inclusive. Source
file: TECHNICAL SPECIFICATION -1542-2011.pdf. This is a primary Part
7 source unit; the author should compare embedded extracts with the
original source file before publication.
5.4.1. Embodiment-Specific Architecture and Trust Relationship
[Principal-approved logical resource name]
|
[Protected resolution registry + lineage]
|
[Alias / redirect / ownership generation]
|
[Authenticated actual target and tenant]
|
[Bound CA / effect parameters / source scope]
|
[Receiving FS re-resolves actual object]
|
[Compare owner, version and protected scope]
/MATCH \MISMATCH
[Atomic consume + effect] [WITHHOLD]
Figure 7: Embodiment 21 — Authenticated Resource Alias and Actual
Resource Identity Resolution — protected architecture
5.4.2. Operational Security Decision Flowchart
Das Expires 29 April 2027 [Page 237]
Internet-Draft Execution-Finality Part 7: Tools October 2026
[Resolve alias or resource identifier]
|
<Authenticated binding available?>-NO->[HOLD]
|YES
[Bind target identity + resolution generation]
|
<Redirect or ownership change?>-YES->[RECHECK]
|NO
[FS obtains actual receiving resource/tenant]
|
<Current target matches CA authorization?>-NO->[REFUSE]
|YES
[Verify consume and apply controlled effect]
Figure 8: Embodiment 21 — Authenticated Resource Alias and Actual
Resource Identity Resolution — refusal and controlled-effect
decisions
5.4.3. Original Technical Disclosure with Global-Page Anchors
5.4.3.1. Source page 1758 of the original specification
END OF EMBODIMENT 20 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 21
PROTECTED RESOURCE-IDENTITY AND ALIAS-RESOLUTION EXECUTION FINALITY
ACROSS DYNAMIC NAMESPACES, REDIRECTS, CROSS-DOMAIN RESOURCE
REBINDING, AND INDEPENDENT ACTUAL-RESOURCE ENFORCEMENT
21.0 — COMPLETE TECHNICAL TITLE
Systems, Methods, and Apparatus for Governing Autonomous
Consequential Operations Using Protected Logical-to-Physical Resource
Identity Resolution, Authenticated Namespace and Alias-Lineage
Evidence, Current Resource-Binding Generations, Cross-Domain Redirect
and Ownership Verification, Scoped Non-Bearer Finality Enablement,
and Independent Finality-Sink Reconstruction and Verification of the
Actual Effected Resource
21.0.1 — General Technical Description
The present Embodiment 21 discloses systems, methods, apparatus,
protected computing components, resource-identity verification
protocols, authenticated namespace-resolution structures, alias-
lineage evidence mechanisms, protected resource-reference registries,
cross-domain authorization interfaces, software and hardware
resource-enforcement controllers, and non-limiting implementations
Das Expires 29 April 2027 [Page 238]
Internet-Draft Execution-Finality Part 7: Tools October 2026
for controlling consequential operations directed toward resources
whose identifiers, locations, names, aliases, bindings, ownership, or
representation may change.
The embodiment applies to autonomous artificial-intelligence agents,
autonomous assistants, operating-system services, application
controllers, cloud services, distributed storage, databases, network
gateways, multi-agent systems, hardware controllers, remote devices,
telecommunications infrastructure, robotic systems, and other
computational entities capable of proposing or initiating
consequential resource operations.
An autonomous computational entity may receive permission to perform
an operation involving a particular resource.
The resource may initially be identified by:
A filename;
A filesystem path;
A symbolic link;
A database record identifier;
An object-storage key;
A document identifier;
A uniform resource identifier;
A network hostname;
5.4.3.2. Source page 1759 of the original specification
A service-discovery name;
An application-level alias;
A user-visible object label;
A device identifier;
A virtual resource reference;
A hardware address;
Or another logical or physical resource representation.
Das Expires 29 April 2027 [Page 239]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The initial representation may not uniquely establish the resource
that will actually receive the consequential operation.
A file path may resolve through a symbolic link.
A symbolic link may be changed.
A file may be renamed.
A directory may be remounted.
A storage object may be replaced while retaining its name.
A database alias may refer to a different underlying record.
A web request may be redirected to a different endpoint.
A service-discovery entry may change between authorization and
execution.
A domain name may resolve to different network addresses.
A cloud resource may be reassigned or recreated.
An application may substitute a different object behind an apparently
unchanged interface reference.
A device identifier may be reused after ownership or hardware
replacement.
A distributed system may migrate a resource from one administrative
domain to another.
Some changes may preserve the resource identity intended by the
originating principal.
Other changes may substitute a materially different resource and
thereby invalidate the earlier authorization.
The distinction cannot always be determined by comparing textual
identifiers.
Two different names may identify the same underlying resource.
The same name may identify different resources at different times.
Das Expires 29 April 2027 [Page 240]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.4.3.3. Source page 1760 of the original specification
Two resources may contain identical data without possessing the same
ownership, authority, or legal resource identity.
A stable identifier may be authentic but no longer represent a
resource the principal remains authorized to modify.
A content digest may verify selected bytes without establishing that
the bytes belong to the originally authorized resource or recipient.
A network address may identify a transport endpoint without
independently identifying the application resource that will perform
the actual effect.
The present embodiment addresses these conditions by separating:
The original authorized resource referent;
The submitted logical resource representation;
The authenticated resolution process;
The actual effect-capable resource identity;
The current namespace and ownership conditions;
The protected resource-binding evidence;
And the authority required for the actual resource operation.
In a principal implementation, an autonomous requester constructs a
Candidate Act specifying a permitted resource operation.
The operation is maintained in a Non-Effective State.
A protected resource-identity controller establishes a machine-
verifiable relationship between the original authorized referent and
one or more qualified current resource representations.
The system may obtain authenticated evidence from an authoritative
resource resolver, operating-system resource controller, database
service, storage service, device controller, or suitably protected
cross-domain identity registry.
The evidence may identify the actual resource, its relevant
generation, the permissible alias relationship, and applicable
ownership or authorization conditions.
Das Expires 29 April 2027 [Page 241]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A protected validation instance determines whether the resolved
resource remains within the original authorized effect envelope.
A protected finality controller establishes scoped non-bearer
finality enablement bound to the appropriate resource-identity
evidence and current authority.
At the actual effectuation boundary, the Finality Sink independently
obtains or reconstructs the actual resource object or effect target
presented to it.
The sink verifies that the actual target corresponds to the protected
authorized resource identity under the applicable resolution policy.
5.4.3.4. Source page 1761 of the original specification
The sink additionally verifies current source authority, relevant
namespace or resource generations, operation parameters, and sink-
local protected consumption state.
A materially different resource cannot acquire valid consequential
authority merely because it inherits the same filename, hostname,
object key, alias, document label, or untrusted identifier.
21.0.2 — Fundamental Technical Principle
An authorization to operate on a logical resource reference is not
automatically authorization to operate on every resource to which
that reference may subsequently resolve.
Similarly:
A change of resource name does not necessarily mean the underlying
resource has changed.
A stable resource name does not necessarily mean the underlying
resource remains the same.
A successful name resolution does not independently establish current
resource authorization.
An authentic redirect does not automatically confer authority over a
new target.
And a cryptographic identity of resource content does not necessarily
establish the ownership or effectuation identity of the resource.
Das Expires 29 April 2027 [Page 242]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The final consequential operation must be verified against the actual
target under the selected protected resource-identity model.
21.0.3 — Principal Candidate Inventive Combination
In one principal implementation, the disclosed combination comprises:
(a) a Candidate Act identifying an intended consequential resource
operation;
(b) an enforceable Non-Effective State;
(c) a protected originating-resource referent associated with the
original source authority;
(d) an authenticated resource-resolution or alias-lineage evidence
structure;
(e) a protected resource-identity correspondence predicate;
(f) one or more current namespace, binding, resource, or ownership
generations;
(g) an independent execution-time validation component;
(h) a protected controller establishing scoped non-bearer finality
enablement;
(i) a designated Finality Sink capable of independently obtaining or
reconstructing the actual target resource;
(j) a sink-side comparison between the actual target and the
protected authorized resource correspondence;
(k) current source-authority and resource-state verification;
5.4.3.5. Source page 1762 of the original specification
(l) sink-local protected consumption before consequential
effectuation.
The principal combination is designed to distinguish permissible
resource rebinding from unauthorized target substitution.
21.0.4 — Specific Technical Contribution
The proposed contribution is not the independent invention of:
Das Expires 29 April 2027 [Page 243]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Filesystem path resolution;
Symbolic-link handling;
HTTP redirects;
Resource identifiers;
Object versioning;
Cryptographic hashing;
Database transactions;
Or access-control lists.
Those are established mechanisms.
The candidate distinguishing relationship concerns the use of
qualified resource-resolution evidence as a necessary part of
operation-specific finality authority, together with independent
verification of the actual resolved resource at the effectuation
boundary.
21.0.5 — Non-Limiting Implementation Arrangements
The invention may be implemented through:
An operating-system resource service;
A protected filesystem dispatcher;
A database transaction controller;
A storage gateway;
An application API resource server;
A network or service-mesh gateway;
A credential broker;
A remote protected resource authority;
5.4.3.6. Source page 1763 of the original specification
A virtual-machine resource controller;
Das Expires 29 April 2027 [Page 244]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A hardware command interface;
Or a suitably protected combination of these components.
No particular operating system, service provider, storage protocol,
or hardware vendor is universally necessary.
21.1 — TECHNICAL FIELD
The present embodiment relates to autonomous resource authorization,
execution-finality control, filesystem and object identity, namespace
resolution, distributed resource naming, cloud storage, network
redirection, cross-domain identity, resource ownership, protected
alias graphs, time-of-check/time-of-use security, cryptographic
evidence, conditional resource mutation, and resource-side
consequential enforcement.
More particularly, the invention concerns ensuring that permission
granted in relation to an originally identified resource remains
correctly and enforceably associated with the actual resource
receiving a consequential operation, despite changes in names,
aliases, namespaces, redirects, or resource representations.
21.2 — SPECIFIC TECHNICAL PROBLEMS
21.2.1 — Alias Substitution
A logical resource alias may be altered to point toward another
resource.
21.2.2 — Symbolic-Link Replacement
A filesystem symbolic link may change after an agent obtains
permission for the original target.
21.2.3 — Hard-Link Ambiguity
Several filesystem names may identify one underlying object,
requiring differentiation between name-level and object-level
authority.
21.2.4 — Directory Rebinding
A directory path may be reassigned, moved, replaced, or remounted.
21.2.5 — Mount-Namespace Change
Das Expires 29 April 2027 [Page 245]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The same apparent path may identify different resources in distinct
namespace environments.
21.2.6 — File Rename
A file may be renamed without necessarily changing its underlying
resource identity.
21.2.7 — Resource Deletion and Recreation
5.4.3.7. Source page 1764 of the original specification
A resource name may be reused after deletion.
21.2.8 — File Identifier Reuse
A filesystem object identifier may be reused after an earlier object
is removed.
21.2.9 — Database Alias Change
An application may map one logical customer or account reference to a
different database record.
21.2.10 — Database Record Replacement
A database key may remain the same while the record's ownership,
version, or authorized meaning changes.
21.2.11 — Object-Storage Key Reuse
An object key may identify a different stored version at a later
time.
21.2.12 — Cross-Tenant Resource Confusion
An identifier that is unique within one tenant may not be unique
across all tenants.
21.2.13 — Redirected HTTP Request
An authorized network request may be redirected to a different
target.
21.2.14 — Redirect Chain Mutation
A redirect chain may change after initial validation.
Das Expires 29 April 2027 [Page 246]
Internet-Draft Execution-Finality Part 7: Tools October 2026
21.2.15 — Network Address Rebinding
A hostname may resolve to different addresses between approval and
transmission.
21.2.16 — Transport Identity Versus Resource Identity
A valid transport endpoint may serve multiple logical resources with
different authorization conditions.
21.2.17 — Service Discovery Replacement
A service-discovery name may resolve to a different service instance.
21.2.18 — Load Balancer Reconfiguration
Traffic may be routed to another backend whose resource identity or
authority properties differ.
21.2.19 — Cross-Provider Migration
A resource may migrate between independently administered providers.
21.2.20 — Ownership Change
5.4.3.8. Source page 1765 of the original specification
The same resource may change owner or access authority.
21.2.21 — Device Replacement
An authorized device reference may subsequently refer to different
hardware.
21.2.22 — Virtual Device Rebinding
A virtual device identifier may be remapped to another physical
interface.
21.2.23 — Displayed Object Substitution
A user-visible label may remain unchanged while its underlying target
changes.
21.2.24 — Ambiguous Canonicalization
Two components may canonicalize paths, URLs, resource keys, or
structured identifiers differently.
Das Expires 29 April 2027 [Page 247]
Internet-Draft Execution-Finality Part 7: Tools October 2026
21.2.25 — Unicode and Case-Folding Differences
Different normalization or case-comparison rules may produce mistaken
identity correspondence.
21.2.26 — Percent-Encoding Ambiguity
Different URL interpretation layers may disagree about encoded
delimiters, path segments, or reserved characters.
21.2.27 — Alias Loop
A resource-resolution chain may contain cycles or excessive
indirection.
21.2.28 — Unauthenticated Resolution
An untrusted component may claim that two resource references
identify the same actual object.
21.2.29 — Stale Resolution Cache
An old resolution result may continue to be used after an
authoritative binding changes.
21.2.30 — Incomplete Target Observation
A gateway may observe the outgoing transport request without
establishing the destination resource's internal identity.
21.2.31 — Resource-State Race
The target may change between resolution validation and actual
effectuation.
21.2.32 — Technical Objective
A candidate objective technical problem is:
5.4.3.9. Source page 1766 of the original specification
How to maintain protected correspondence between an originally
authorized resource referent and the actual resource receiving a
consequential operation when resource names, aliases, locations,
namespaces, redirects, ownership, or binding generations may change,
while allowing verified legitimate resource continuity and preventing
unauthorized target substitution at the final effectuation boundary.
Das Expires 29 April 2027 [Page 248]
Internet-Draft Execution-Finality Part 7: Tools October 2026
21.3 — ESTABLISHED TECHNIQUES AND THEIR LIMITATIONS
21.3.1 — Filesystem Path Resolution
Existing operating systems resolve paths to filesystem objects.
Some provide restricted resolution interfaces and object handles.
These are established mechanisms.
They do not, by themselves, determine whether a particular autonomous
task remains authorized to mutate the resolved object under its
original task-specific authority.
21.3.2 — Namespace Isolation
Existing operating systems support distinct resource namespaces and
associated access restrictions.
Such mechanisms are established.
The present embodiment may additionally require current binding of
source authority to the actual resource identity and namespace
generation.
21.3.3 — URI Normalization
Existing protocols specify parsing and comparison rules for resource
identifiers.
Canonicalization may reduce representational ambiguity.
It does not establish that two different resources are equivalent for
authorization purposes.
21.3.4 — DNS and Service Discovery
Existing resolution systems associate names with network addresses or
services.
They may support authenticated information under particular
configurations.
Name-to-address resolution does not inherently prove the identity of
the application-level resource receiving a protected consequential
effect.
21.3.5 — HTTP Redirects
Das Expires 29 April 2027 [Page 249]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Existing application protocols permit requests to be redirected.
A redirect response may affect the target or request semantics.
An earlier authorization for one protected resource does not
necessarily authorize a changed destination.
5.4.3.10. Source page 1767 of the original specification
21.3.6 — Object Versions
Existing storage systems may provide object versions, generation
identifiers, and conditional mutations.
These are established techniques.
The proposed architecture may use them as evidence within a broader
original-authority-to-actual-resource relationship.
21.3.7 — Cryptographic Hashing
Existing hashes may bind content or structured resource descriptors.
A hash does not automatically establish ownership, location,
permission, or resource identity.
21.3.8 — Conditional Requests
Existing protocols may reject updates when resource versions no
longer match.
These are established.
The present embodiment may combine current resource conditions with
protected original referent identity and finality authority.
21.3.9 — Candidate Technical Distinction
The proposed stronger system connects qualified resource resolution
and current binding evidence to the operation-specific authority
consumed at the actual resource sink.
21.4 — PRINCIPAL SYSTEM ARCHITECTURE
A representative implementation comprises:
A Requesting Computational Entity;
Das Expires 29 April 2027 [Page 250]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A Candidate Act Constructor;
A Protected Original Resource Referent Registry;
A Resource Namespace Qualification Controller;
An Authenticated Alias Resolution Controller;
A Protected Resource-Identity Correspondence Validator;
A Resource Binding and Generation Registry;
An Optional Cross-Domain Resource Identity Verifier;
A Current Ownership and Source-Authority Controller;
An Independent Execution-Time Resource Validator;
5.4.3.11. Source page 1768 of the original specification
A Finality Enablement Controller;
An Actual Resource Finality Sink;
And a Sink-Local Consumption and Resource-State Controller.
Optional components include:
A filesystem object-handle resolver;
A database versioning service;
An object-storage version registry;
A network destination verifier;
A service-discovery adapter;
A protected resource migration controller;
A device ownership register;
A cryptographic evidence store;
A protected resource audit journal;
And an authorized scope-deviation controller.
Das Expires 29 April 2027 [Page 251]
Internet-Draft Execution-Finality Part 7: Tools October 2026
21.4.1 — Requesting Entity
Proposes the consequential operation but does not automatically
control the authoritative resource-binding state.
21.4.2 — Original Referent Registry
Maintains the selected authorized resource reference and its
authority context.
21.4.3 — Namespace Controller
Identifies the relevant resolution environment.
21.4.4 — Alias Controller
Obtains and qualifies resource-reference transformations.
21.4.5 — Correspondence Validator
Determines whether the resolved resource remains within the original
permitted target set.
21.4.6 — Finality Controller
Establishes scoped authority bound to the qualified resource identity
and current technical state.
21.4.7 — Finality Sink
5.4.3.12. Source page 1769 of the original specification
Obtains or reconstructs the actual resource targeted by the pending
effect.
21.4.8 — Protected Consumption Controller
Prevents unsupported reuse of operation-specific authority.
21.5 — TECHNICAL DEFINITIONS
21.5.1 — Original Authorized Resource Referent
An Original Authorized Resource Referent, or OARR-21, means the
resource referent established under the originating source authority.
21.5.2 — Logical Resource Reference
Das Expires 29 April 2027 [Page 252]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A Logical Resource Reference means a path, URL, alias, identifier,
label, symbolic name, application object name, or other
representation used to designate a resource.
21.5.3 — Actual Effect Target
An Actual Effect Target, or AET-21, means the resource object,
endpoint, command destination, or effect-capable entity actually
receiving the selected consequential operation.
21.5.4 — Protected Resource Identity
A Protected Resource Identity, or PRI-21, means an authenticated
representation of resource identity sufficient for the selected
actual-operation authorization predicate.
21.5.5 — Resource Identity Continuity
Resource Identity Continuity means a validated relationship
establishing that the currently resolved resource remains the
originally authorized resource or another expressly permitted
equivalent target.
21.5.6 — Protected Alias Lineage
Protected Alias Lineage, or PAL-21, means authenticated evidence
identifying a sequence of relevant transformations between resource
references.
21.5.7 — Resource Binding Generation
A Resource Binding Generation, or RBG-21, means an authoritative
version or generation associated with a relevant name-to-resource
binding.
21.5.8 — Namespace Generation
A Namespace Generation, or NSG-21, means an authoritative version
associated with the applicable namespace or namespace mapping state.
21.5.9 — Protected Resource-Resolution Commitment
A Protected Resource-Resolution Commitment, or PRRC-21, means an
authenticated commitment to the relevant resource-resolution evidence
and resulting target.
Das Expires 29 April 2027 [Page 253]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.4.3.13. Source page 1770 of the original specification
21.5.10 — Authorized Resource Equivalence
Authorized Resource Equivalence means a protected policy relation
identifying when two resource representations or targets may be
treated as equivalent for the specific operation.
21.5.11 — Resource Equivalence Predicate
A Resource Equivalence Predicate, or REP-21, means a machine-
verifiable condition evaluating permitted correspondence between an
original referent and the actual effect target.
21.5.12 — Resource Rebinding Event
A Resource Rebinding Event means a relevant change to a resource
name, alias, identity association, location, ownership, or target
mapping.
21.5.13 — Material Rebinding
A Material Rebinding means a change affecting required resource
identity, source authorization, operation semantics, ownership, or
effectuation conditions.
21.5.14 — Harmless Alias Change
A Harmless Alias Change means a reference change that preserves the
required authorized-resource correspondence under the current
protected equivalence policy.
21.5.15 — Target Substitution
Target Substitution means replacement of the originally authorized
actual resource with a materially different target not established as
permitted.
21.5.16 — Protected Resolver
A Protected Resolver means a component authorized and technically
capable of establishing a specified resource-resolution property
under the selected trust model.
21.5.17 — Resolver Qualification
Das Expires 29 April 2027 [Page 254]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Resolver Qualification means a determination of the precise identity,
authenticity, current-state, or observation property supplied by a
resource resolver.
21.5.18 — Authenticated Resolution Edge
An Authenticated Resolution Edge means a protected record concerning
a transformation from one resource representation to another.
21.5.19 — Protected Resolution Graph
A Protected Resolution Graph, or PRG-21, means an authenticated
representation of relevant resource aliases, references, resolution
edges, and their validity conditions.
21.5.20 — Namespace-Specific Identity
5.4.3.14. Source page 1771 of the original specification
Namespace-Specific Identity means a resource identity whose
uniqueness or meaning is limited to a defined namespace.
21.5.21 — Cross-Domain Resource Identity
Cross-Domain Resource Identity means a resource identity qualified
across two or more independently administered domains.
21.5.22 — Resource Migration Continuity
Resource Migration Continuity means authenticated evidence that a
relocated resource satisfies a selected protected continuity
condition.
21.5.23 — Ownership Continuity
Ownership Continuity means a verified relationship establishing that
current authority remains applicable despite a resource ownership or
administration transition.
21.5.24 — Actual Resource Reconstruction
Actual Resource Reconstruction means obtaining or deriving the
resource identity actually presented to the effect-capable boundary.
21.5.25 — Protected Target-Finality Binding
Das Expires 29 April 2027 [Page 255]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Protected Target-Finality Binding, or PTFB-21, means a protected
relationship binding a Candidate Act and its scoped finality
authority to the permitted actual resource identity.
21.5.26 — Resource Revalidation Fence
A Resource Revalidation Fence, or RRF-21, means a condition
preventing effectuation when required resource correspondence has
become stale, changed, or uncertain.
21.5.27 — Binding Epoch
A Binding Epoch means a protected generation distinguishing current
binding authority from superseded resource mappings.
21.5.28 — Resource Identity Evidence Class
A Resource Identity Evidence Class means a characterization of what a
given identifier or observation can actually prove.
21.5.29 — Content Identity
Content Identity means correspondence of selected content bytes or
data structure under a defined equivalence model.
21.5.30 — Object Identity
Object Identity means correspondence of an underlying resource object
rather than merely its name or content.
5.4.3.15. Source page 1772 of the original specification
21.5.31 — Authority Identity
Authority Identity means the principal, owner, tenancy, or protected
domain whose permission governs the resource.
21.5.32 — Endpoint Identity
Endpoint Identity means an identified network or service termination
point under the applicable authentication mechanism.
21.5.33 — Consequential Resource Identity
Consequential Resource Identity means the identity properties
necessary to determine whether a specific real effect is authorized.
21.5.34 — Resource Reference Ambiguity
Das Expires 29 April 2027 [Page 256]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Resource Reference Ambiguity means inability to establish one
permitted actual target under the applicable identity policy.
21.5.35 — Resource Identity Freshness
Resource Identity Freshness means current validity of the required
binding, namespace, ownership, and resource-state evidence.
21.5.36 — Resource-Specific Finality Authority
Resource-Specific Finality Authority means scoped non-bearer
authority restricted to an identified actual resource or permitted
equivalence class.
21.5.37 — Resource Substitution Attack
A Resource Substitution Attack means changing or manipulating a
resource reference so that an operation authorized for one target is
applied to another.
21.5.38 — Resource Identity Commitment Chain
A Resource Identity Commitment Chain means authenticated evidence
connecting the original authorized referent, intermediate qualified
resolutions, and actual target.
21.5.39 — Protected Resource Generation
A Protected Resource Generation means an authoritative state value
differentiating relevant resource versions, recreation events,
ownership transitions, or other material changes.
21.5.40 — Qualified Resource Effect Receipt
A Qualified Resource Effect Receipt means authenticated evidence
identifying the actual resource and supported consequential result
produced by an earlier operation.
21.6 — RESOURCE IDENTITY IS MULTIDIMENSIONAL
5.4.3.16. Source page 1773 of the original specification
A central implementation principle is that resource identity may
consist of several independently relevant properties.
A non-limiting resource identity tuple may be expressed as:
[ RI=(D,N,O,V,A,E) ]
Das Expires 29 April 2027 [Page 257]
Internet-Draft Execution-Finality Part 7: Tools October 2026
(D) denotes the relevant administrative or resource domain;
(N) denotes the namespace or resolution context;
(O) denotes the underlying object or resource identity;
(V) denotes the relevant resource version;
(A) denotes current ownership or source-authority state;
And (E) denotes an applicable binding or authority generation.
Not every operation requires every field.
The protected controller selects the fields that materially affect
the operation's authority.
For example:
A file-content read may require object identity and applicable
version.
A deletion may require actual current object identity, directory
authority, and relevant current ownership.
A remote payment may require account identity, receiving institution,
and current recipient scope.
A physical device command may require hardware identity, ownership,
command parameters, and protected operating state.
21.6.1 — Identity Versus Content
Two files containing identical bytes are not necessarily the same
authorized file.
21.6.2 — Identity Versus Name
One file may possess several names.
21.6.3 — Identity Versus Location
A resource may move while retaining an authenticated logical
identity.
21.6.4 — Identity Versus Ownership
Das Expires 29 April 2027 [Page 258]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A resource may retain its identifier while its authorized principal
changes.
5.4.3.17. Source page 1774 of the original specification
21.6.5 — Identity Versus Version
A logical resource may remain the same while its mutable content
changes.
The source authorization and effect type determine whether such
version changes are permitted.
21.7 — PROTECTED ORIGINAL RESOURCE REFERENT
When the original principal authorizes an operation, the system may
establish an OARR-21.
A representative structure comprises:
ORIGINAL_AUTHORIZED_RESOURCE_REFERENT = { candidate_act_identifier,
originating_principal, original_grant_reference,
original_logical_resource, qualified_original_resource_identity,
original_namespace, original_resource_domain,
authorized_operation_class, authorized_effect_envelope,
permitted_alias_transformations, permitted_resource_equivalence,
required_resource_version, required_ownership_conditions,
current_authority_generation, designated_finality_sink,
protected_authentication } 21.7.1 — Original Source
The referent is established from qualified source authorization and
resource evidence.
21.7.2 — Agent-Supplied Names
An agent may supply the requested name or path.
However, the agent's unverified statement does not independently
establish the authoritative underlying resource identity.
21.7.3 — Permissible Transformations
The original authorization may expressly permit certain renames,
migrations, aliases, or other equivalent references.
21.7.4 — Disallowed Transformations
Das Expires 29 April 2027 [Page 259]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A material change outside the permitted equivalence relation requires
new validation or authorization.
5.4.3.18. Source page 1775 of the original specification
21.8 — RESOURCE-RESOLUTION EVIDENCE
The protected controller may obtain resource-resolution evidence
from:
A trusted filesystem operation;
An authenticated storage service;
A protected database lookup;
A current service registry;
An authenticated device controller;
A qualified namespace resolver;
Or another technically sufficient resource authority.
A representative record may comprise:
PROTECTED_RESOURCE_RESOLUTION_EVIDENCE = {
original_resource_referent, submitted_resource_reference,
authoritative_resolver_identity, resolver_observation_class,
relevant_namespace_identity, resolution_path_commitment,
resulting_actual_resource_identity, resource_version,
binding_generation, ownership_generation, resolution_conditions,
current_authentication } 21.8.1 — Evidence Qualification
A resolver is trusted only for the property it can establish.
21.8.2 — No Automatic Cross-Domain Trust
A resolver from one administrative domain does not automatically
possess authority to establish another domain's protected resource
identity.
21.8.3 — Current Resolution
A historical resolution may be insufficient when the relevant binding
can change.
21.8.4 — Protected Commitment
Das Expires 29 April 2027 [Page 260]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The relevant result may be cryptographically authenticated or
preserved within protected state.
21.9 — AUTHENTICATED ALIAS LINEAGE
5.4.3.19. Source page 1776 of the original specification
One original resource may be referenced through multiple aliases.
A representative alias chain may be:
AUTHORIZED REFERENT | v LOGICAL DOCUMENT NAME | v APPLICATION
RESOURCE ID | v STORAGE OBJECT ID | v CURRENT VERSIONED OBJECT | v
ACTUAL FINALITY SINK Each relevant transformation may be associated
with authenticated evidence.
21.9.1 — Alias Edge
An alias edge identifies the source and destination reference.
21.9.2 — Resolver Identity
The controller identifies which component established the
relationship.
21.9.3 — Binding Generation
The relationship is associated with current state.
21.9.4 — Scope
The relationship may be valid only for one domain, resource type, or
operation class.
21.9.5 — Equivalence
The protected policy determines whether the transformation preserves
relevant authorization.
21.9.6 — Unknown Edge
A required unauthenticated or unresolved transformation causes the
relevant correspondence predicate to fail.
21.10 — PROTECTED ALIAS RESOLUTION GRAPH
The protected system may construct a resource-resolution graph.
Das Expires 29 April 2027 [Page 261]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A representative structure comprises:
5.4.3.20. Source page 1777 of the original specification
PROTECTED_ALIAS_RESOLUTION_GRAPH = { graph_identifier,
originating_candidate_act, original_resource_identity,
known_alias_nodes, authenticated_resolution_edges,
resolver_identity_registry, relevant_namespace_generations,
relevant_binding_generations, current_equivalence_policy,
actual_target_reference, protected_graph_authentication } A node may
identify a logical reference, resource object, namespace-specific
identity, or versioned target.
An edge identifies a qualified relationship.
21.10.1 — Graph Cycle
A detected alias cycle may be rejected or handled according to a
bounded resolution policy.
21.10.2 — Excessive Resolution Depth
The verifier may enforce a maximum traversal depth.
21.10.3 — Ambiguous Targets
If several actual targets remain possible and the source authority
permits only one, the operation remains withheld.
21.10.4 — Permitted Alias Set
A source authorization may expressly permit several equivalent target
representations.
21.10.5 — Protected Graph Change
A material resolution-graph change may invalidate existing operation-
specific authority.
21.11 — PROTECTED RESOURCE-EQUIVALENCE PREDICATE
A non-limiting resource correspondence relation may be:
[ \operatorname{Corresponds}(R_o,R_a,C) ]
(R_o) is the originally authorized resource;
(R_a) is the actual resource identified at the sink;
Das Expires 29 April 2027 [Page 262]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.4.3.21. Source page 1778 of the original specification
And (C) comprises current source-authority, namespace, ownership,
version, and operation context.
The predicate returns one of:
MATCH: The actual target is established as permitted.
MISMATCH: The actual target is established as outside the authorized
resource envelope.
INDETERMINATE: The evidence is insufficient.
21.11.1 — Exact Identity Mode
The system requires the same underlying protected object identity.
21.11.2 — Version-Bound Mode
The system requires a specified version or permitted version range.
21.11.3 — Logical Continuity Mode
The system permits a resource migration or rename while preserving
established authorized logical identity.
21.11.4 — Equivalent Target Set
The original source may authorize a defined set of resources.
21.11.5 — No Implicit Equivalence
Equal filenames, IP addresses, object hashes, or visual labels do not
independently establish equivalence.
21.12 — MATERIAL AND NON-MATERIAL REBINDING
A principal implementation distinguishes benign alias changes from
material target substitutions.
21.12.1 — Non-Material Rename
A resource may be renamed while retaining a verified underlying
identity and permitted ownership.
21.12.2 — Material Target Replacement
Das Expires 29 April 2027 [Page 263]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An alias may begin resolving to an unrelated resource.
21.12.3 — Ownership Change
The actual resource may remain the same while current permission
changes.
21.12.4 — Content Replacement
An authorization may or may not permit new content versions of the
same logical resource.
21.12.5 — Provider Migration
5.4.3.22. Source page 1779 of the original specification
A resource may migrate to another service while preserving an
authenticated permitted identity relationship.
21.12.6 — Protected Classification
The system evaluates the change according to current source authority
and resource-specific semantics.
A change is not automatically harmless merely because the textual
resource name remains unchanged.
21.13 — FILESYSTEM IMPLEMENTATION
A PHOSITA may implement a filesystem-specific variation using current
object-handling mechanisms.
The protected system may establish the actual filesystem object
through a controlled open operation.
Where supported, the controller may use:
Directory-relative operations;
Restricted path resolution;
Object handles;
Current filesystem object identifiers;
Mount and namespace information;
And resource-version or generation evidence.
Das Expires 29 April 2027 [Page 264]
Internet-Draft Execution-Finality Part 7: Tools October 2026
21.13.1 — Path-Only Authorization
A pathname alone may be insufficient for a strong object-identity
guarantee.
21.13.2 — Descriptor-Based Control
An opened object handle may provide a stronger connection to the
resource actually accessed.
21.13.3 — Relevant Generation
A filesystem object identifier should be combined with additional
identity or generation evidence where reuse is possible.
21.13.4 — Authorized Root
A protected resource operation may be restricted to a designated
directory or namespace.
21.13.5 — Symbolic-Link Rules
The implementation may restrict or explicitly qualify symbolic-link
traversal.
5.4.3.23. Source page 1780 of the original specification
21.13.6 — Object-Specific Finality
The final operation is verified against the actual controlled object
rather than an untrusted earlier path string.
21.14 — SYMBOLIC-LINK REBINDING VARIATION
An agent receives authority to modify a particular file.
The relevant path contains a symbolic link.
After initial validation, the link is changed to point toward a
different file.
The protected Finality Sink does not assume that the original path
string still identifies the authorized object.
It resolves or retains the actual resource identity using a
technically appropriate controlled operation.
The actual target is compared with the permitted resource identity.
Das Expires 29 April 2027 [Page 265]
Internet-Draft Execution-Finality Part 7: Tools October 2026
If the link points to an unauthorized object, the effect is refused.
21.14.1 — Candidate Technical Effect
The operation-specific authority remains bound to the authorized
resource rather than to a mutable untrusted path.
21.15 — FILE RENAME WITHOUT FALSE DENIAL
A file is authorized under one name.
The file is subsequently renamed.
A protected resolver establishes that the current target remains the
same underlying authorized object under the selected identity model.
The current ownership and resource conditions remain valid.
The operation may proceed under the original authority where the
policy permits name-independent object identity.
21.15.1 — Technical Distinction
The architecture does not simply reject every path change.
It distinguishes a verified permitted rename from an unauthorized
target substitution.
21.16 — DELETION AND RECREATION
A resource is deleted.
5.4.3.24. Source page 1781 of the original specification
A new resource is created under the same name.
The new resource may possess different ownership, content, identity,
or resource-generation state.
A prior authorization for the deleted resource does not automatically
authorize the newly created resource.
The protected resource-generation condition distinguishes the new
object.
The actual sink rejects the stale operation where the original
authority requires the earlier object identity.
Das Expires 29 April 2027 [Page 266]
Internet-Draft Execution-Finality Part 7: Tools October 2026
21.17 — MOUNT AND NAMESPACE CHANGE
A resource path may be interpreted under different mount or process
namespaces.
A protected implementation may identify:
The relevant namespace;
The protected root;
The actual mounted resource;
The required object identity;
And the applicable namespace generation.
21.17.1 — Multiple Namespaces
The same textual path may identify different resources.
21.17.2 — Remount
A mount change may alter the actual object reached by a path.
21.17.3 — Current Coverage
The resource sink verifies the actual resource under the current
protected namespace.
21.17.4 — Unauthorized Substitution
A path redirected into an unrelated namespace does not inherit
original permission.
21.18 — DATABASE RESOURCE IDENTITY
A database application may identify a record by an application-level
key.
For example:
CUSTOMER_ALIAS = "ACCOUNT-ALPHA" The alias may map to a protected
internal resource identifier.
Das Expires 29 April 2027 [Page 267]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.4.3.25. Source page 1782 of the original specification
The protected controller may establish:
Tenant identity;
Internal record identity;
Resource version;
Authorized operation;
Current ownership;
And source-authority state.
At commit time, the actual database sink verifies the record and
current resource state.
21.18.1 — Record Replacement
A reused account label must not automatically identify the same
protected record.
21.18.2 — Cross-Tenant Alias
Identical customer labels from different tenants must not become
equivalent without qualified authorization.
21.18.3 — Transactional Check
A supported conditional mutation may verify the current object
identity and version within the resource transaction.
21.18.4 — Candidate Technical Interaction
The originating logical referent is bound to a current authoritative
database record through a protected finality relationship.
21.19 — OBJECT STORAGE RESOURCE IDENTITY
An object-storage system may expose resources through bucket, key,
object ID, version, generation, or similar references.
A selected operation may be authorized for:
A specific immutable object version;
Das Expires 29 April 2027 [Page 268]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The current version of a permitted logical object;
Or a bounded set of object generations.
The protected identity predicate determines which relation is
required.
21.19.1 — Key Reuse
An object key may be reused.
5.4.3.26. Source page 1783 of the original specification
21.19.2 — Version-Bound Effect
A selected operation may require one specified version.
21.19.3 — Current-Object Effect
Another authorized operation may permit the current version under
protected conditions.
21.19.4 — Ownership
The resource's current tenancy and owner remain relevant.
21.19.5 — Sink Enforcement
The resource-side API or gateway verifies the actual object operation
before effectuation.
21.20 — URL AND HTTP RESOURCE IDENTITY
An autonomous agent may be authorized to interact with a selected
network resource.
The intended resource may be represented by a URI.
However, the URI's text does not automatically establish every
property of the actual receiving resource.
The protected controller may consider:
URI scheme;
Authority;
Effective port;
Das Expires 29 April 2027 [Page 269]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Query semantics;
Actual method;
Request body;
Authenticated service identity;
Resource version;
And relevant redirect behavior.
21.20.1 — URI Parsing
The implementation uses a defined parser and comparison policy.
5.4.3.27. Source page 1784 of the original specification
21.20.2 — Canonical Representation
The policy determines which normalization operations are permitted.
21.20.3 — Reserved Characters
Encoded delimiters and reserved characters must not be normalized in
a manner that changes protected resource semantics.
21.20.4 — Resource Authority
A URL permitted for one resource does not automatically authorize
arbitrary services at the same network address.
21.20.5 — Current Effect
The actual outgoing or receiving resource request is independently
verified.
21.21 — REDIRECT CHAIN VERIFICATION
An HTTP or equivalent network operation may follow one or more
redirects.
A principal implementation may treat redirects as resource-resolution
edges.
A non-limiting chain is:
Das Expires 29 April 2027 [Page 270]
Internet-Draft Execution-Finality Part 7: Tools October 2026
AUTHORIZED RESOURCE A | v REDIRECT TARGET B | v REDIRECT TARGET C | v
ACTUAL RESOURCE D 21.21.1 — Authenticated Redirect Source
The system determines what properties the redirect source can
establish.
21.21.2 — Target Policy
The resulting target must remain within the authorized envelope or
undergo appropriate reauthorization.
21.21.3 — Method and Payload
The implementation determines whether the redirect changes relevant
request semantics.
21.21.4 — Cross-Origin Change
5.4.3.28. Source page 1785 of the original specification
A redirect to another origin may require new authorization or an
expressly permitted equivalence relation.
21.21.5 — Final Destination
The actual effectuation sink verifies the resource that will perform
the protected consequence.
21.21.6 — Redirect Limit
The implementation may restrict loops and excessive redirect depth.
21.22 — NETWORK NAME RESOLUTION
A hostname may resolve to one or several network addresses.
The selected protected policy may require validation of:
The intended service identity;
The permitted hostname;
The actual destination address;
The transport protocol;
The target port;
Das Expires 29 April 2027 [Page 271]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Relevant address-class restrictions;
And the application resource being invoked.
21.22.1 — DNS Evidence
A resolver response supplies name-to-address information under its
actual security guarantees.
21.22.2 — Service Authentication
Authenticated transport may separately establish selected server-
identity properties.
21.22.3 — Application Resource Identity
The receiving application may expose different resources under the
same server identity.
21.22.4 — Actual Effect
A network connection alone does not prove the application operation's
intended resource effect.
21.22.5 — Rebinding
A material resolution change requires the applicable current
protected verification.
21.23 — NETWORK REBINDING ATTACK
5.4.3.29. Source page 1786 of the original specification
An agent receives permission to transmit information to an authorized
service.
The system initially resolves the service name to a permitted
endpoint.
Before transmission, a different address is returned.
The protected network controller verifies the current resolution and
applicable destination conditions.
If the new endpoint lies outside the permitted effectuation envelope,
the transmission is refused.
Das Expires 29 April 2027 [Page 272]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Where the underlying operation requires verification of the
application recipient, the content-aware protected service must
establish that condition separately.
21.23.1 — Technical Effect
A historical permissible DNS response cannot independently authorize
all later destinations associated with the same textual name.
21.24 — SERVICE DISCOVERY AND PROXY REBINDING
A protected service may be reached through a discovery registry,
internal proxy, or routing layer.
The protected resource controller may maintain:
Original logical service identity;
Current service registry generation;
Permitted receiving service class;
Actual backend resource identity where required;
And current effectuation-path coverage.
A change in backend identity may be harmless when the new backend is
an authenticated equivalent resource instance.
Another change may introduce an unauthorized service or weaker
resource-side enforcement.
The system must distinguish these cases.
21.24.1 — Load-Balanced Resources
Several physical instances may serve one permitted logical resource.
The source authority may permit the entire qualified service class.
21.24.2 — Different Resource Semantics
A different backend cannot inherit permission where the resulting
actual effect is materially different.
Das Expires 29 April 2027 [Page 273]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.4.3.30. Source page 1787 of the original specification
21.24.3 — Current Gate
The actual receiving service or qualified gateway verifies the
required operation.
21.25 — CROSS-DOMAIN RESOURCE MIGRATION
A resource may move from one administrative domain to another.
A protected migration-continuity process may establish:
The original resource identity;
The source domain;
The destination domain;
A qualified migration event;
The resulting resource identity;
Applicable ownership transfer;
Current source and destination authority;
And current effectuation policy.
21.25.1 — Migration Evidence
A protected source and destination service may authenticate relevant
correspondence.
21.25.2 — New Ownership
The destination authority must support the proposed resource
operation.
21.25.3 — Resource Version
The migrated resource's permitted version or state is verified.
21.25.4 — No Automatic Permission Portability
A migration receipt does not independently confer unrestricted rights
in the destination domain.
Das Expires 29 April 2027 [Page 274]
Internet-Draft Execution-Finality Part 7: Tools October 2026
21.25.5 — Actual Sink
The destination Finality Sink independently verifies the actual
target and current authority.
21.26 — RESOURCE OWNERSHIP TRANSFER
A resource may remain technically identifiable while its authorized
controller changes.
For example:
5.4.3.31. Source page 1788 of the original specification
A document may be transferred to another enterprise account.
A device may be reassigned to another owner.
A cloud resource may move into another administrative project.
An earlier permission may no longer apply.
The protected resource identity record may therefore include current
ownership or control generation.
The sink checks the applicable current owner and source-authority
relationship.
A valid old identity commitment does not override an authoritative
ownership change.
21.27 — DEVICE AND HARDWARE RESOURCE IDENTITY
A hardware command may be addressed to a logical device identifier.
A protected device registry may resolve the identifier to a specific
current controller or physical device.
The actual command sink may verify:
Hardware or protected device identity;
Current ownership;
Current command target;
Current resource generation;
Das Expires 29 April 2027 [Page 275]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Applicable safety constraints;
And operation-specific finality authority.
21.27.1 — Device Replacement
A replacement device cannot automatically inherit every earlier
actuation permission.
21.27.2 — Device Migration
A permitted migration may preserve bounded logical authority under
current verification.
21.27.3 — Virtual Interface
A virtual device reference may be mapped to a current physical
endpoint.
21.27.4 — Actual Command
The protected hardware sink verifies the actual command destination.
5.4.3.32. Source page 1789 of the original specification
21.28 — CONTENT HASHES AND IDENTITY LIMITATIONS
A cryptographic digest may establish correspondence of selected
content bytes under the applicable algorithm and encoding.
It does not automatically establish:
Resource ownership;
Current source permission;
Storage location;
Resource tenancy;
Receiving service identity;
Or permissible consequential operation scope.
21.28.1 — Equal Content, Different Authority
Two resources may contain the same information but belong to
different principals.
Das Expires 29 April 2027 [Page 276]
Internet-Draft Execution-Finality Part 7: Tools October 2026
21.28.2 — Same Logical Resource, New Content
A legitimate mutable document may acquire new bytes while retaining
its authorized logical identity.
21.28.3 — Required Identity Model
The protected system determines whether content equality, object
identity, version identity, or a combination is required.
21.28.4 — Candidate Technical Interaction
Content commitments may contribute evidence but do not independently
replace resource-side authority verification.
21.29 — CANONICALIZATION AND RESOURCE IDENTITY
The system may represent resource-identity evidence using a
deterministic structured encoding.
A representative commitment is:
[ C_R=H(\operatorname{Canon}(R,N,B,V,A)) ]
(R) denotes the relevant resource identifier;
(N) denotes its namespace;
5.4.3.33. Source page 1790 of the original specification
(B) denotes current binding evidence;
(V) denotes applicable version state;
And (A) denotes current authority information.
21.29.1 — Deterministic Representation
The encoding must avoid inconsistent interpretation of the protected
fields.
21.29.2 — Typed Resource Identifiers
Filesystem paths, URLs, database keys, and hardware identifiers need
not share one ambiguous string-comparison rule.
21.29.3 — Numeric Representation
Das Expires 29 April 2027 [Page 277]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Relevant numeric fields use unambiguous typed semantics.
21.29.4 — Unicode Processing
The protocol defines applicable text normalization without silently
changing resource identity.
21.29.5 — Case Sensitivity
The relevant resource provider's comparison semantics must be
considered.
21.29.6 — No Semantic Proof from Canonicalization Alone
Canonical encoding establishes repeatable representation, not factual
or authorization equivalence.
21.30 — RESOURCE IDENTITY FRESHNESS
Resource-resolution evidence may become stale.
A selected implementation may require:
Current binding generation;
Current namespace generation;
Current resource version;
Current ownership state;
A bounded evidence age;
Or a current authoritative resource handle.
21.30.1 — Stable Binding
A selected resource relation may remain valid over several operations
under explicitly permitted conditions.
5.4.3.34. Source page 1791 of the original specification
21.30.2 — Rapidly Mutable Binding
Another relation may require fresh validation immediately before
effectuation.
21.30.3 — Protected Epoch
Das Expires 29 April 2027 [Page 278]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A material binding change may advance an authoritative generation.
21.30.4 — Sink Verification
The actual Finality Sink verifies the applicable current state.
21.31 — PROTECTED RESOURCE REVALIDATION FENCE
A Resource Revalidation Fence may be activated when:
An authoritative alias changes;
A resource is replaced;
A resource namespace changes materially;
A version becomes invalid;
Ownership is transferred;
A required resolver becomes unavailable;
A redirect changes the permitted actual target;
Or another mandatory identity predicate cannot be established.
The fence may prevent:
A storage commit;
A file deletion;
A remote transmission;
A payment;
A device command;
Or another covered consequential effect.
The requesting agent cannot clear the fence through a self-generated
statement that the resource remains equivalent.
The protected controller requires the relevant qualified
correspondence evidence or new source authorization.
Das Expires 29 April 2027 [Page 279]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.4.3.35. Source page 1792 of the original specification
21.32 — ALIAS REBINDING AND SOURCE AUTHORITY
A resource-reference change may be:
A permitted equivalent alias;
An unauthorized target substitution;
Or an unresolved identity condition.
21.32.1 — Permitted Change
The resource identity and current authority satisfy the original
equivalence predicate.
21.32.2 — Unauthorized Change
The resulting actual target lies outside permitted scope.
21.32.3 — Unresolved Change
Required evidence cannot establish correspondence.
21.32.4 — New Authorization
A permitted principal may establish new scope for an otherwise
eligible target change.
21.32.5 — Mandatory Protection
New discretionary authorization does not override another required
safety, ownership, or actual-operation predicate.
21.33 — AUTHORITY BOUND TO A RESOURCE EQUIVALENCE CLASS
A selected source authorization may define a bounded set of
equivalent resource targets.
For example:
A particular logical storage object may be served by several
authenticated replicas.
A selected database record may migrate within a permitted service
domain.
Das Expires 29 April 2027 [Page 280]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A protected device may be reachable through two approved
communication paths.
The equivalence class may be represented as:
AUTHORIZED_RESOURCE_CLASS = { source_authority,
logical_resource_identity, permitted_resource_instances,
qualified_equivalence_rules, current_resource_generations,
permitted_domains, required_ownership_state,
5.4.3.36. Source page 1793 of the original specification
authorized_effect_class, protected_authentication } The actual sink
verifies that the current target belongs to the authorized class.
The agent cannot enlarge the class by adding an alias.
21.34 — MULTI-ALIAS RESOLUTION AND AMBIGUITY
A logical reference may resolve to several candidates.
The system may require:
One unambiguous actual target;
A bounded permitted set;
Or a specific conditional selection rule.
A name resolving to multiple possible targets does not automatically
authorize all of them.
21.34.1 — One-Target Authorization
Only the designated actual resource is permitted.
21.34.2 — Authorized Group
A bounded group of resources may be allowed.
21.34.3 — Ambiguous Resolution
The operation is withheld when required target identity cannot be
established.
21.34.4 — Qualified Selection
Das Expires 29 April 2027 [Page 281]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A protected resolver may select the target according to a permitted
rule.
21.34.5 — Actual Verification
The Finality Sink checks the selected actual target.
21.35 — ORIGINAL RESOURCE IDENTITY VERSUS CURRENT TARGET
The system distinguishes:
The resource the user or source originally intended;
The name the agent supplied;
The resource a resolver selected;
The resource the application prepared to access;
5.4.3.37. Source page 1794 of the original specification
And the resource the Finality Sink actually affects.
A principal implementation binds the original authorization to the
actual effect target through qualified protected evidence.
21.35.1 — No Sole Reliance on Requester
The agent's reported resource identity is not sufficient where the
actual operation may differ.
21.35.2 — No Sole Reliance on Old Resolution
Historical correspondence is not automatically current.
21.35.3 — No Sole Reliance on Transport Endpoint
A permitted network endpoint does not independently identify the
internal resource.
21.35.4 — Resource-Specific Release
The actual consequential target must satisfy the appropriate
protected predicate.
21.36 — PROTECTED FINALITY ENABLEMENT
A representative resource-bound finality structure may comprise:
Das Expires 29 April 2027 [Page 282]
Internet-Draft Execution-Finality Part 7: Tools October 2026
RESOURCE_BOUND_FINALITY_ENABLEMENT = { candidate_act_digest,
original_authorized_resource_commitment, authorized_effect_envelope,
qualified_resolution_evidence_digest,
resource_equivalence_policy_digest,
permitted_actual_resource_identity, current_namespace_generation,
current_binding_generation, current_resource_generation,
current_ownership_generation, current_source_authority_generation,
designated_finality_sink, permitted_use_count,
sink_local_consumption_reference, protected_finality_authentication }
The requesting agent may receive only an inert handle or reference.
The actual Finality Sink must verify the corresponding protected
authority.
A copy of the reference does not independently permit operation on
another target.
21.37 — INDEPENDENT ACTUAL RESOURCE RECONSTRUCTION
The actual Finality Sink obtains or reconstructs the resource that
would receive the effect.
5.4.3.38. Source page 1795 of the original specification
The method depends upon the resource substrate.
21.37.1 — Filesystem
The controlled file operation may expose the actual object handle or
authoritative resource metadata.
21.37.2 — Database
The controlled mutation identifies the actual record, tenant,
version, and transaction state.
21.37.3 — Object Storage
The controlled operation identifies the actual bucket, key, version
or generation, and relevant ownership.
21.37.4 — Network
The controlled gateway identifies the actual outgoing or receiving
request and the resource properties it can genuinely observe.
21.37.5 — Hardware
Das Expires 29 April 2027 [Page 283]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The command controller identifies the actual device and command
target.
21.37.6 — Cross-Domain Resource
A destination-side resource controller may be required to establish
the actual internal target.
21.37.7 — Technical Limitation
A gateway that only observes a transport request cannot claim to have
verified a remote service's hidden internal resource state without
adequate destination-side evidence or control.
21.38 — SINK-TIME CORRESPONDENCE
The Finality Sink verifies:
The protected Candidate Act;
The original authorized resource reference;
The qualified resolution evidence;
The actual target resource;
Current source authority;
Current namespace and binding state;
Current resource version;
Current ownership conditions;
5.4.3.39. Source page 1796 of the original specification
The permitted operation parameters;
Applicable protected finality enablement;
And sink-local protected consumption state.
A representative predicate may comprise:
SOURCE_AUTHORITY_CURRENT AND ORIGINAL_REFERENT_VALID AND
RESOURCE_RESOLUTION_QUALIFIED AND ACTUAL_TARGET_CORRESPONDS AND
CURRENT_NAMESPACE_VALID AND CURRENT_BINDING_VALID AND
CURRENT_RESOURCE_STATE_VALID AND CURRENT_OWNERSHIP_AUTHORITY_VALID
Das Expires 29 April 2027 [Page 284]
Internet-Draft Execution-Finality Part 7: Tools October 2026
AND ACTUAL_EFFECT_WITHIN_ENVELOPE AND FINALITY_ENABLEMENT_VALID AND
CONSUMPTION_AVAILABLE A required failure prevents the corresponding
consequential release.
21.39 — PROTECTED CONSUMPTION AND RESOURCE MUTATION
A selected implementation may atomically consume finality authority
and perform a supported local resource mutation.
For example, a protected transactional database may:
Lock or conditionally read the actual record;
Verify current resource identity;
Verify the source-authority and binding generations;
Verify finality eligibility;
Consume the permitted authority;
Apply the actual mutation;
And commit the corresponding protected state.
The transaction semantics must support the asserted concurrency and
atomicity guarantees.
Where the effect is external, the system separately governs durable
dispatch and uncertain outcome.
21.40 — REFERENCE DATA STRUCTURE: RESOURCE IDENTITY COMMITMENT
PROTECTED_RESOURCE_IDENTITY_COMMITMENT = { protocol_version,
candidate_act_id, originating_principal,
5.4.3.40. Source page 1797 of the original specification
source_grant_reference, original_resource_reference,
original_resource_identity, resource_namespace,
qualified_resolver_identity, alias_lineage_commitment,
actual_resource_identity, permitted_equivalence_class,
resource_version, binding_epoch, namespace_epoch, ownership_epoch,
current_authority_epoch, effect_descriptor_commitment,
designated_finality_sink, protected_authentication } Fields may be
omitted when they are not relevant to the selected resource class.
Das Expires 29 April 2027 [Page 285]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The necessary identity properties must still be sufficiently
represented for the actual effect authorization.
21.41 — REFERENCE ALGORITHM: QUALIFIED RESOURCE RESOLUTION
FUNCTION QUALIFY_RESOURCE_RESOLUTION( original_referent,
submitted_reference, protected_resolver ):
REQUIRE VERIFY_ORIGINAL_REFERENT( original_referent )
REQUIRE VERIFY_RESOLVER_AUTHORITY( protected_resolver )
result = protected_resolver .RESOLVE_CURRENT_RESOURCE(
submitted_reference )
IF result.status != RESOLVED: RETURN RESOURCE_IDENTITY_INDETERMINATE
REQUIRE VERIFY_RESOLVER_EVIDENCE( result )
REQUIRE VERIFY_RELEVANT_NAMESPACE(
5.4.3.41. Source page 1798 of the original specification
result )
REQUIRE VERIFY_BINDING_GENERATION( result )
REQUIRE VERIFY_RESOURCE_VERSION( result )
REQUIRE VERIFY_CURRENT_OWNERSHIP_CONDITIONS( result )
correspondence = PROTECTED_RESOURCE_EQUIVALENCE_CHECK(
original_referent, result.actual_resource, CURRENT_AUTHORITY_POLICY()
)
IF correspondence == MISMATCH: RETURN DENY_RESOURCE_SUBSTITUTION
IF correspondence == INDETERMINATE: RETURN HOLD_RESOURCE_REVALIDATION
RETURN AUTHENTICATED_RESOURCE_RESOLUTION({ original:
HASH(original_referent),
resolved_resource: HASH(result.actual_resource),
alias_lineage: HASH(result.alias_evidence),
binding_generation: result.binding_generation,
Das Expires 29 April 2027 [Page 286]
Internet-Draft Execution-Finality Part 7: Tools October 2026
resource_generation: result.resource_generation,
ownership_generation: result.ownership_generation }) The algorithm
depends upon a resolver capable of supplying the asserted evidence.
21.42 — REFERENCE ALGORITHM: RESOURCE IDENTITY CONTINUITY
5.4.3.42. Source page 1799 of the original specification
FUNCTION VERIFY_RESOURCE_IDENTITY_CONTINUITY( original_authority,
resolution_evidence, actual_target,
protected_correspondence_controller ):
REQUIRE VERIFY_SOURCE_AUTHORITY( original_authority )
REQUIRE VERIFY_RESOLUTION_EVIDENCE( resolution_evidence )
REQUIRE VERIFY_ACTUAL_TARGET_EVIDENCE( actual_target )
policy = protected_correspondence_controller
.LOAD_AUTHORIZED_EQUIVALENCE_POLICY( original_authority )
REQUIRE VERIFY_EQUIVALENCE_POLICY_AUTHENTICITY( policy )
identity_result = protected_correspondence_controller
.COMPARE_IDENTITY_PROPERTIES({ original_resource:
original_authority.resource,
resolved_resource: resolution_evidence.resource,
actual_resource: actual_target,
required_properties: policy.required_identity_fields })
IF identity_result == MISMATCH: RETURN DENY
IF identity_result == UNKNOWN: RETURN HOLD
REQUIRE VERIFY_CURRENT_BINDING_AND_OWNERSHIP()
5.4.3.43. Source page 1800 of the original specification
RETURN RESOURCE_CONTINUITY_ACCEPTED The correspondence may be exact
or may use an expressly permitted equivalent-resource relation.
21.43 — REFERENCE ALGORITHM: REBINDING DETECTION
Das Expires 29 April 2027 [Page 287]
Internet-Draft Execution-Finality Part 7: Tools October 2026
FUNCTION HANDLE_RESOURCE_REBINDING( candidate_act,
previous_resolution, current_resolution, protected_controller ):
REQUIRE VERIFY_PREVIOUS_RESOLUTION( previous_resolution )
REQUIRE VERIFY_CURRENT_RESOLUTION( current_resolution )
delta = COMPARE_MATERIAL_RESOURCE_BINDINGS( previous_resolution,
current_resolution )
IF delta == NO_MATERIAL_CHANGE: RETURN
REQUIRE_CURRENT_SINK_VERIFICATION
IF PROVE_PERMITTED_RESOURCE_CONTINUITY( candidate_act,
current_resolution ): RETURN REVALIDATE_FINALITY_BINDING
INVALIDATE_AFFECTED_FINALITY_ENABLEMENT( candidate_act )
IF delta == UNAUTHORIZED_TARGET_CHANGE: RETURN DENY
RETURN REQUIRE_NEW_QUALIFIED_RESOLUTION Where a changed target
requires expanded source authority, the corresponding protected
reauthorization process may be invoked.
21.44 — REFERENCE ALGORITHM: ACTUAL SINK FINALITY
FUNCTION EFFECTUATE_RESOURCE_BOUND_CANDIDATE( candidate_act,
resource_resolution_commitment,
5.4.3.44. Source page 1801 of the original specification
finality_enablement, protected_finality_sink ):
actual = protected_finality_sink
.RECONSTRUCT_ACTUAL_PENDING_OPERATION()
actual_target = protected_finality_sink
.IDENTIFY_ACTUAL_RESOURCE_TARGET( actual )
REQUIRE actual_target IS QUALIFIED
REQUIRE VERIFY_SOURCE_AUTHORITY_CURRENT()
REQUIRE VERIFY_ORIGINAL_RESOURCE_REFERENT( candidate_act )
REQUIRE VERIFY_RESOURCE_RESOLUTION_COMMITMENT(
resource_resolution_commitment )
Das Expires 29 April 2027 [Page 288]
Internet-Draft Execution-Finality Part 7: Tools October 2026
REQUIRE VERIFY_CURRENT_NAMESPACE_AND_BINDING()
REQUIRE VERIFY_CURRENT_RESOURCE_IDENTITY( actual_target )
REQUIRE VERIFY_RESOURCE_CORRESPONDENCE( candidate_act,
resource_resolution_commitment, actual_target )
REQUIRE VERIFY_CURRENT_OWNERSHIP_AND_RESOURCE_STATE()
REQUIRE VERIFY_ACTUAL_OPERATION_EFFECT_ENVELOPE( actual )
REQUIRE VERIFY_CURRENT_NON_BEARER_FINALITY( finality_enablement,
actual, actual_target )
REQUIRE VERIFY_SINK_LOCAL_CONSUMPTION()
committed = protected_finality_sink .COMMIT_RESOURCE_BOUND_FINALITY(
5.4.3.45. Source page 1802 of the original specification
actual, actual_target, finality_enablement )
IF committed != SUCCESS: RETURN DENY
RETURN protected_finality_sink .RELEASE_ACTUAL_RESOURCE_EFFECT(
actual, actual_target ) Where the sink's consumption transition and
actual resource mutation cannot be committed in one transaction, the
implementation separately governs dispatch and outcome
reconciliation.
21.45 — REFERENCE ALGORITHM: PROTECTED ALIAS GRAPH VERIFICATION
FUNCTION VERIFY_PROTECTED_ALIAS_GRAPH( original_resource,
proposed_resolution_graph, protected_graph_verifier ):
REQUIRE VERIFY_GRAPH_AUTHENTICITY( proposed_resolution_graph )
REQUIRE VERIFY_GRAPH_STARTS_AT_ORIGINAL( proposed_resolution_graph,
original_resource )
REQUIRE GRAPH_SIZE_WITHIN_VALIDATION_BUDGET()
visited = EMPTY_SET
FOR EACH edge IN REQUIRED_RESOLUTION_PATH:
IF edge IN visited: RETURN REJECT_RESOLUTION_CYCLE
Das Expires 29 April 2027 [Page 289]
Internet-Draft Execution-Finality Part 7: Tools October 2026
visited.ADD(edge)
REQUIRE VERIFY_EDGE_RESOLVER_IDENTITY( edge )
REQUIRE VERIFY_EDGE_CURRENT_GENERATION( edge )
5.4.3.46. Source page 1803 of the original specification
REQUIRE VERIFY_EDGE_SCOPE( edge )
REQUIRE VERIFY_AUTHORIZED_RESOURCE_TRANSFORMATION( edge )
resolved = GET_FINAL_RESOLVED_RESOURCE()
RETURN AUTHENTICATED_RESOLUTION_RESULT( resolved,
HASH_CANONICAL(proposed_resolution_graph) ) The resolution graph may
use a tree, chain, registry lookup, or another bounded representation
rather than a full general-purpose graph.
21.46 — WORKED EXAMPLE A: SYMBOLIC-LINK TARGET SUBSTITUTION
An autonomous agent is authorized to modify a designated project
document.
The agent refers to the document through a symbolic link.
The original protected resolution identifies Resource A.
Before actual mutation, the symbolic link is changed to Resource B.
The protected Finality Sink obtains the current actual file object.
The current object is not equivalent to Resource A under the original
authorization.
The mutation is denied.
Expected demonstrable result: A valid earlier file-path authorization
cannot be redirected toward a different actual object merely by
changing an intermediate symbolic link.
21.47 — WORKED EXAMPLE B: PERMITTED FILE RENAME
An agent is authorized to update one specific document.
The document is renamed within the permitted workspace.
Das Expires 29 April 2027 [Page 290]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The protected resolver establishes that the underlying object
identity remains the same under a current permitted ownership and
identity relation.
The sink verifies the operation against the actual object.
The authorized mutation may proceed without unnecessarily requiring
new discretionary permission.
5.4.3.47. Source page 1804 of the original specification
Expected demonstrable result: The system distinguishes valid resource
continuity from an unauthorized resource substitution.
21.48 — WORKED EXAMPLE C: SAME FILENAME, NEW RESOURCE
An authorized file is deleted.
A new file is created under the same path.
The newly created object has a different protected resource
generation.
The agent presents an older finality reference.
The sink observes that the actual object no longer matches the
original authorized identity.
The stale operation is refused.
Expected demonstrable result: Reuse of a logical resource name does
not automatically preserve historical object-specific finality
authority.
21.49 — WORKED EXAMPLE D: DATABASE ALIAS REBINDING
An agent is permitted to update the record associated with a
specified customer.
An application-level alias initially resolves to one authorized
database record.
The alias is changed to a different tenant's record.
The actual database sink reconstructs the target row, tenant, and
current record identity.
The protected identity predicate fails.
Das Expires 29 April 2027 [Page 291]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The update is rejected.
Expected demonstrable result: Cross-tenant resource substitution is
prevented even when the same application-level alias is submitted.
21.50 — WORKED EXAMPLE E: HTTP REDIRECT TO AN UNAUTHORIZED
DESTINATION
An agent receives permission to upload a protected document to a
designated service.
The initially permitted endpoint returns a redirect to another
service.
The protected network or application gateway evaluates the new target
against the original effect envelope.
The new destination is not within the authorized recipient class.
The transmission is withheld.
5.4.3.48. Source page 1805 of the original specification
Expected demonstrable result: An earlier valid endpoint authorization
does not independently permit redirection of protected content to an
unrelated destination.
21.51 — WORKED EXAMPLE F: AUTHORIZED SERVICE RELOCATION
An enterprise service migrates to another qualified backend.
The original authorization permits the authenticated logical service
identity and current qualified replacement instances.
The protected resolver verifies the current backend belongs to the
permitted service class.
The receiving Finality Sink verifies the actual resource operation
and current source authority.
The operation may proceed without assuming that every backend address
change is unauthorized.
Expected demonstrable result: A legitimate service relocation can
preserve bounded authorization through explicit protected equivalence
rather than unconditional acceptance or blanket denial.
21.52 — WORKED EXAMPLE G: DNS REBINDING
Das Expires 29 April 2027 [Page 292]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An agent requests an authorized external API operation.
The initial hostname resolution identifies an allowed address.
A later resolution identifies a prohibited destination.
The protected controller evaluates the actual pending network
destination and relevant resource identity conditions.
The old approved result does not override the current mismatch.
The effect is refused.
Expected demonstrable result: Historical name resolution is
insufficient to authorize a newly substituted network target.
21.53 — WORKED EXAMPLE H: OBJECT STORAGE VERSION CHANGE
An agent is permitted to delete one specific versioned object.
The storage key later identifies a newer object version.
The protected delete operation is bound to the original version.
The receiving storage sink verifies current version identity.
The stale delete is rejected.
Expected demonstrable result: A valid logical object key does not
override an explicitly version-bound finality condition.
5.4.3.49. Source page 1806 of the original specification
21.54 — WORKED EXAMPLE I: RESOURCE OWNERSHIP TRANSFER
A cloud resource is originally controlled by one authorized
principal.
The resource is later transferred to another administrative owner.
The previous agent retains a historically valid resource reference.
The actual sink verifies current ownership and source authorization.
The historical resource identity does not establish current
authority.
The operation is refused.
Das Expires 29 April 2027 [Page 293]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Expected demonstrable result: Object-identity continuity does not
independently override current resource ownership.
21.55 — WORKED EXAMPLE J: HARDWARE DEVICE REPLACEMENT
An autonomous controller is authorized to operate a particular
device.
The device is replaced with different hardware under the same logical
device label.
The protected resource registry identifies a new hardware or
authority generation.
The actual device command sink verifies the current target identity.
The old command authorization cannot automatically actuate the
replacement device.
Expected demonstrable result: A reused logical device label does not
create unrestricted hardware command authority.
21.56 — WORKED EXAMPLE K: USER-VISIBLE OBJECT SUBSTITUTION
A user selects a document in an application interface.
The application later remaps the displayed label to another document.
The protected interface evidence may identify the original selected
object.
The actual resource sink reconstructs the file or document being
modified.
The original referent and actual resource do not correspond.
The operation is refused.
Expected demonstrable result: A user-visible selection remains
protected against an unauthorized underlying resource substitution.
21.57 — WORKED EXAMPLE L: CROSS-DOMAIN RESOURCE MIGRATION
5.4.3.50. Source page 1807 of the original specification
An enterprise document is migrated to a new storage domain.
Das Expires 29 April 2027 [Page 294]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The source and destination resource authorities provide qualified
migration identity evidence.
The original permission allows a bounded migration with continuing
ownership conditions.
The destination sink verifies the actual migrated object and current
operation scope.
The authorized operation may proceed where the protected
correspondence is established.
Expected demonstrable result: Legitimate cross-domain continuity is
supported without treating any claimed migration or redirect as
sufficient authority.
21.58 — WORKED EXAMPLE M: IDENTICAL CONTENT, DIFFERENT OWNER
Two resources contain identical bytes.
An agent possesses authority to disclose Resource A.
The agent attempts to disclose Resource B based only on a matching
content digest.
The protected resource controller verifies current object identity
and ownership.
Resource B is not authorized.
The disclosure is denied.
Expected demonstrable result: Content equality is not silently
promoted into resource-ownership or disclosure authority.
21.59 — WORKED EXAMPLE N: SERVICE ALIAS COLLISION
Two administrative tenants use the same short logical service name.
A requester is authorized to invoke a service within Tenant A.
The request is inadvertently resolved within Tenant B.
The protected resource identity includes the applicable tenant or
domain.
The actual sink verifies the current target and source authority.
Das Expires 29 April 2027 [Page 295]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The mismatched operation is denied.
Expected demonstrable result: Namespace-local identifier equality
does not authorize cross-tenant effects.
21.60 — WORKED EXAMPLE O: ASYNCHRONOUS OPERATION AFTER REBINDING
An autonomous agent prepares a delayed resource mutation.
5.4.3.51. Source page 1808 of the original specification
The corresponding resource alias is later changed.
The job queue still contains the earlier logical reference.
When the delayed task reaches the actual sink, the controller
reconstructs current resource identity and binding state.
If the actual resource differs materially from the original
authorized target, the operation remains withheld.
Expected demonstrable result: Queueing an operation does not freeze
unlimited permission over future targets associated with a mutable
name.
21.61 — WORKED EXAMPLE P: MULTI-AGENT RESOURCE REBINDING
Agent A prepares an authorized operation on Resource X.
Agent B independently changes a shared alias to Resource Y.
Agent A later attempts effectuation.
The protected resource controller checks the actual target and
current alias-binding generation.
The previous authority cannot be applied to Resource Y unless the
source authorization expressly permits that equivalence.
Expected demonstrable result: Resource-binding races among agents
cannot silently redirect operation-specific finality authority.
21.62 — WORKED EXAMPLE Q: REDIRECTED PAYMENT DESTINATION
An autonomous financial application prepares payment to an authorized
destination.
Das Expires 29 April 2027 [Page 296]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An intermediate application service changes an account alias or
downstream payment recipient.
The actual payment Finality Sink independently determines the
effective destination account.
The destination does not satisfy the original protected payment
authority.
The operation is refused.
Expected demonstrable result: A payment-target alias cannot
substitute another actual beneficiary without the required current
authorization.
21.63 — WORKED EXAMPLE R: PRIVILEGED RESOURCE BROKER
An untrusted agent requests access to a file using an alias.
A privileged broker possesses the actual file-access authority.
5.4.3.52. Source page 1809 of the original specification
The broker independently resolves the resource, validates current
source scope, and obtains the corresponding object handle.
The broker performs only the permitted operation.
The agent never receives unrestricted authority to choose another
privileged target.
Expected demonstrable result: Privileged resource-access capability
remains restricted to a protected actual resource identity despite
untrusted alias input.
21.64 — PROTECTED STATE MACHINE
A non-limiting state machine comprises:
REFERENT_AUTHORIZED: The original source-authorized resource referent
is established.
CANDIDATE_PREPARED: A consequential Candidate Act exists.
NON_EFFECTIVE: The proposed effect remains withheld.
RESOLUTION_PENDING: Current actual target identity is unresolved.
Das Expires 29 April 2027 [Page 297]
Internet-Draft Execution-Finality Part 7: Tools October 2026
RESOLUTION_EVIDENCE_AVAILABLE: Qualified resolution information has
been obtained.
ALIAS_LINEAGE_VERIFIED: Required alias transformations are
authenticated.
RESOURCE_CORRESPONDENCE_PENDING: Equivalence remains unverified.
RESOURCE_MATCHED: The actual target satisfies the protected identity
predicate.
RESOURCE_MISMATCHED: The target lies outside permitted scope.
RESOURCE_AMBIGUOUS: The target cannot be sufficiently identified.
REBINDING_DETECTED: A relevant resource mapping has changed.
REVALIDATION_REQUIRED: Current resolution and authority must be
reestablished.
AUTHORITY_PREPARED: Scoped non-bearer finality enablement exists.
SINK_VERIFICATION_PENDING: The actual resource operation awaits
verification.
FINALITY_REJECTED: A mandatory predicate fails.
FINALITY_CONSUMED: The permitted use has been committed.
EFFECT_ATTEMPTED: The controlled operation has been released or
attempted.
EFFECT_CONFIRMED: Qualified evidence establishes the supported real
result.
EFFECT_INDETERMINATE: The actual external outcome remains unresolved.
RECOVERY_PENDING: Further authorized reconciliation is required.
5.4.3.53. Source page 1810 of the original specification
TERMINATED: The operation reaches a valid protected terminal
condition.
21.65 — PRINCIPAL END-TO-END WORKFLOW
Step 1 — Receive Source Authority. Establish the original principal
and permitted resource operation.
Das Expires 29 April 2027 [Page 298]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Step 2 — Establish Original Referent. Create a protected OARR-21.
Step 3 — Construct Candidate Act. Identify the intended consequential
operation.
Step 4 — Hold Non-Effective. Prevent premature resource
effectuation.
Step 5 — Identify Namespace. Determine the relevant resource-
resolution context.
Step 6 — Resolve Logical Reference. Obtain qualified current
resource-resolution evidence.
Step 7 — Authenticate Resolver. Verify the source and supported
evidence properties.
Step 8 — Establish Alias Lineage. Identify relevant transformations.
Step 9 — Verify Binding Generations. Check current resource and
namespace state.
Step 10 — Verify Ownership. Establish current applicable source
authority.
Step 11 — Evaluate Equivalence. Determine whether the actual target
remains within the original authorized resource envelope.
Step 12 — Apply Required Modules. Evaluate additional relevant CW-1
technical predicates.
Step 13 — Collect Protected Evidence. Commit required resource-
resolution and authority evidence.
Step 14 — Independently Validate. Evaluate current execution-time
correspondence.
Step 15 — Prepare Finality Authority. Establish resource-specific
non-bearer enablement.
Step 16 — Present Actual Operation. Submit the pending resource
effect to its designated sink.
Step 17 — Reconstruct Actual Target. Obtain the resource actually
targeted by the controlled effectuation primitive.
Step 18 — Verify Current Binding. Check current resource identity,
namespace, version, and ownership conditions.
Das Expires 29 April 2027 [Page 299]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Step 19 — Verify Source Authority. Ensure current permission applies
to the actual target.
Step 20 — Verify Operation Scope. Confirm that the effect itself
remains permitted.
Step 21 — Verify Finality Authority. Match the enablement to the
actual target and sink.
Step 22 — Verify Consumption. Determine whether the protected use
remains available.
Step 23 — Commit Consumption. Perform the appropriate protected
transition.
5.4.3.54. Source page 1811 of the original specification
Step 24 — Release Actual Consequence. Permit the specified
operation.
Step 25 — Observe Result. Obtain qualified actual-effect evidence
where required.
Step 26 — Record Actual Resource. Preserve the resource identity
actually affected.
Step 27 — Govern Continuation. Apply optional causal-receipt and
scope-deviation procedures where relevant.
21.66 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
1. Symbolic-link target substitution.
2. Hard-link object ambiguity.
3. Parent-directory replacement.
4. Mount-namespace manipulation.
5. Directory remount after authorization.
6. File deletion and recreation.
7. Reuse of a filesystem object identifier.
8. Resource rename during a pending operation.
9. Stale open-path resolution.
Das Expires 29 April 2027 [Page 300]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10. Database alias collision.
11. Cross-tenant record substitution.
12. Reassignment of an application record identifier.
13. Object-storage key reuse.
14. Object version mismatch.
15. Redirect to an unauthorized destination.
16. Multi-hop redirect manipulation.
17. Cross-origin redirect without new authority.
18. Request-method change across redirects.
19. DNS rebinding.
20. Network destination address substitution.
21. Service-discovery registry manipulation.
22. Load-balancer backend replacement.
5.4.3.55. Source page 1812 of the original specification
23. Proxy-routing policy change.
24. Service identity versus application-resource confusion.
25. Cross-provider resource migration forgery.
26. Resource ownership transfer after approval.
27. Device replacement under a reused label.
28. Virtual device-to-physical-device rebinding.
29. Resource identity evidence replay.
30. Resolver identity impersonation.
31. Resolver authorized for the wrong resource domain.
32. Resource-binding generation rollback.
Das Expires 29 April 2027 [Page 301]
Internet-Draft Execution-Finality Part 7: Tools October 2026
33. Namespace generation rollback.
34. Unicode normalization ambiguity.
35. Case-folding mismatch.
36. Percent-encoding interpretation mismatch.
37. Duplicate structured-data field ambiguity.
38. Resource alias loops.
39. Excessive alias-resolution depth.
40. Multiple possible actual targets.
41. Content digest falsely treated as ownership proof.
42. Stale resource-version evidence.
43. Revoked source authority following successful resolution.
44. Concurrent resource rebinding by another agent.
45. Delayed queued operation using an old binding.
46. Snapshot rollback restoring stale resource authority.
47. Cross-sink reuse of one resource-bound finality reference.
48. Unauthorized copied finality enablement.
49. An uncontrolled alternate resource access interface.
50. A remote gateway lacking actual destination-resource visibility.
5.4.3.56. Source page 1813 of the original specification
51. A compromised protected resource resolver.
52. A compromised Finality Sink.
53. A malicious resource-migration assertion.
54. Replayed prior actual-effect receipt for a different resource.
55. Authorization to disclose one object applied to another object
with identical bytes.
Das Expires 29 April 2027 [Page 302]
Internet-Draft Execution-Finality Part 7: Tools October 2026
56. Resource reassignment during a hardware command.
57. Race between resource checking and commit.
58. Race between receipt acceptance and successor target rebinding.
59. Denial-of-service through expensive alias graphs.
60. Failure to distinguish harmless rename from malicious
replacement.
Each case must be evaluated against the specified protected resource
substrate and actual effectuation-path guarantees.
21.67 — PROPOSED FEASIBILITY AND ADVERSARIAL EXPERIMENTS
The following are proposed tests rather than reported completed
experiments.
Test 1 — Original Resource Authorization: Establish protected
authority for one identified resource.
Test 2 — Exact Identity Correspondence: Verify an unchanged actual
target.
Test 3 — Alias Resolution: Resolve a permitted alias to the correct
object.
Test 4 — Symbolic-Link Substitution: Change the target before
effectuation.
Test 5 — Permitted Rename: Preserve valid identity continuity after a
rename.
Test 6 — Delete/Recreate: Replace a file using the same name.
Test 7 — Mount Change: Remount an alternative resource under the
original path.
Test 8 — Namespace Separation: Submit identical path strings from
different namespace contexts.
Test 9 — Hard-Link Equivalence: Verify object correspondence through
multiple names.
Test 10 — Object Identifier Reuse: Test a simulated resource
identifier reused after deletion.
Das Expires 29 April 2027 [Page 303]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Test 11 — Database Alias: Resolve a permitted application alias to
its internal record.
Test 12 — Cross-Tenant Alias: Substitute a same-named record from
another tenant.
Test 13 — Resource Version Change: Modify a database record before
final mutation.
5.4.3.57. Source page 1814 of the original specification
Test 14 — Object-Storage Version: Change the current object version
after authorization.
Test 15 — Redirect: Redirect an authorized request to another
resource.
Test 16 — Redirect Chain: Introduce multiple redirect hops.
Test 17 — Redirect Loop: Reject an unbounded or cyclic resolution.
Test 18 — Cross-Origin Redirect: Test a target outside the permitted
origin or recipient class.
Test 19 — Request Semantics: Alter method or protected payload across
a redirect.
Test 20 — DNS Rebinding: Change the resolved network destination.
Test 21 — Service Authentication: Distinguish network address from
authenticated service identity.
Test 22 — Application Resource Identity: Use one service endpoint
exposing several differently authorized resources.
Test 23 — Service Discovery: Replace a backend mapping.
Test 24 — Valid Backend Migration: Accept an authenticated permitted
replacement instance.
Test 25 — Invalid Backend Migration: Reject a replacement outside the
authorized equivalence class.
Test 26 — Cross-Domain Resource Migration: Verify qualified migration
continuity.
Test 27 — Forged Migration Record: Reject an unauthorized migration
assertion.
Das Expires 29 April 2027 [Page 304]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Test 28 — Resource Ownership Transfer: Revoke or revalidate authority
following current ownership change.
Test 29 — Hardware Device Replacement: Reuse a logical device name
for another device.
Test 30 — Virtual Device Rebinding: Redirect a virtual device
reference to another physical target.
Test 31 — Unicode Resource Names: Test equivalent-looking but
distinct identifiers.
Test 32 — Case-Folding: Test resource systems with different
comparison semantics.
Test 33 — Percent-Encoding: Test security-relevant URL interpretation
differences.
Test 34 — Canonical Structured Encoding: Ensure equivalent protected
descriptors produce the expected deterministic representation.
Test 35 — Ambiguous Structured Data: Reject duplicate or conflicting
security-relevant fields.
Test 36 — Alias Graph Cycle: Verify bounded rejection of circular
references.
Test 37 — Alias Graph Depth: Bound resource-verification computation.
Test 38 — Multiple Targets: Refuse an unqualified ambiguous resource.
5.4.3.58. Source page 1815 of the original specification
Test 39 — Permitted Target Set: Accept a qualified member of an
expressly authorized resource class.
Test 40 — Replayed Resolution Evidence: Reject obsolete resource-
binding generations.
Test 41 — Forged Resolver Identity: Reject evidence from an
unauthorized resolver.
Test 42 — Resolver Scope: Reject an otherwise authentic resolver
asserting identity outside its authorized domain.
Test 43 — Actual Sink Reconstruction: Verify the resource actually
targeted by the final operation.
Das Expires 29 April 2027 [Page 305]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Test 44 — Changed Target After Approval: Replace the resource after
finality preparation.
Test 45 — Source Authority Revocation: Revoke resource access after
successful identity resolution.
Test 46 — Protected Consumption: Attempt repeated use of one
resource-bound finality reference.
Test 47 — Cross-Sink Replay: Present one finality reference to
another resource sink.
Test 48 — Concurrent Agents: Race two agents against a mutable alias.
Test 49 — Resource Reservation: Test version or ownership consistency
during resource commit.
Test 50 — Delayed Workflow: Queue a mutation before resource
rebinding.
Test 51 — Content Equality: Compare identical bytes from differently
owned resources.
Test 52 — Privacy Release: Attempt disclosure of a substituted
protected document.
Test 53 — Payment Recipient: Substitute the actual payment account
behind an alias.
Test 54 — Device Command: Change the actual device target between
preparation and release.
Test 55 — Incomplete Sink Coverage: Attempt the effect through
another uncontrolled API.
Test 56 — Remote Resource Visibility: Demonstrate which identity
properties a gateway can and cannot verify.
Test 57 — Crash Recovery: Restore authority state after an actual
mutation attempt.
Test 58 — Snapshot Rollback: Prevent reuse of obsolete resource-
generation and consumption state.
Test 59 — Actual Effect Receipt: Verify that a receipt identifies the
resource actually affected.
Das Expires 29 April 2027 [Page 306]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Test 60 — CW-2 Continuation: Require an accepted receipt for the
correct predecessor resource and effect.
Test 61 — CW-3 Scope Change: Classify a target substitution as a
protected scope deviation.
5.4.3.59. Source page 1816 of the original specification
Test 62 — Authorized Rebinding: Permit a genuine target change only
after valid new authorization where required.
Test 63 — Full End-to-End Test: Validate original referent, resource
resolution, correspondence, current authority, actual sink,
consumption, and outcome.
Test 64 — Ablation Without Sink Identity Check: Remove actual target
correspondence and compare unauthorized substitution acceptance.
Test 65 — Ablation Without Binding Generation: Remove current
generation checks and evaluate stale-resource reuse.
Test 66 — Ablation Without Protected Equivalence: Replace qualified
identity continuity with string-based resource-name comparison.
Test 67 — Cross-Domain Stress Test: Combine migration, ownership
changes, redirects, and concurrent resource mutations.
Test 68 — Adversarial Resolver Exhaustion: Test bounded parsing,
recursion depth, and verification work.
The results should distinguish simulated target identity, verified
resource-side state, attempted effectuation, and actual effect
completion.
21.68 — NON-LIMITING PHOSITA REFERENCE PROTOTYPE
21.68.1 — Minimum Reference Implementation
A practical prototype may comprise:
An autonomous software requester;
A protected authorization and resource-identity service;
A controlled resource resolver;
A transactional resource database;
Das Expires 29 April 2027 [Page 307]
Internet-Draft Execution-Finality Part 7: Tools October 2026
And a resource-specific Finality Sink.
21.68.2 — Initial Configuration
The protected system authorizes one resource mutation.
The resource has a logical alias and an authoritative internal
identity.
21.68.3 — Candidate Act
The requester prepares an operation naming the logical resource.
21.68.4 — Protected Resolution
The resource resolver obtains the current underlying object identity
and generation.
5.4.3.60. Source page 1817 of the original specification
21.68.5 — Finality Preparation
The protected controller commits qualified resolution evidence and
prepares operation-specific non-bearer authority.
21.68.6 — Target Rebinding
The experiment changes the logical alias before actual mutation.
21.68.7 — Sink-Time Verification
The sink determines the actual target and compares it with the
protected authorized resource identity.
21.68.8 — Protected Denial
An unauthorized substitution is refused.
21.68.9 — Equivalent Resource Test
A permitted resource rename or authorized equivalent alias is
introduced.
The system verifies continuity according to the selected policy.
21.68.10 — Consumption Test
The same finality reference is exercised twice.
Das Expires 29 April 2027 [Page 308]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The protected resource state must prevent unsupported repeated use.
21.68.11 — Prototype Limitation
A software-only reference prototype does not automatically establish
protection against compromise of its operating-system kernel or
another privileged component controlling all relevant state.
21.69 — PERFORMANCE AND IMPLEMENTATION ENGINEERING
21.69.1 — Resolution Caching
The system may cache qualified identity evidence subject to
appropriate freshness and binding-generation conditions.
21.69.2 — Resolver Work Budget
Alias graphs and nested references may be subject to bounded
verification costs.
21.69.3 — Namespace Partitioning
Different resource classes may employ different identity registries.
21.69.4 — Local Resource Optimization
5.4.3.61. Source page 1818 of the original specification
A protected file or database object handle may reduce repeated name
resolution where supported.
21.69.5 — Remote Resource Verification
Cross-domain identity evidence may require authenticated
communication with the resource owner.
21.69.6 — Version Validation
Conditional resource operations may reduce certain resource-state
races.
21.69.7 — Independent Sink Enforcement
Resource-side verification may add computation or latency before
consequential release.
21.69.8 — No Universal Identity Oracle
Das Expires 29 April 2027 [Page 309]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A system cannot assume one global authority can accurately identify
every external resource.
21.69.9 — Dynamic Equivalence
Legitimate migration may require protected equivalence-policy
updates.
21.69.10 — Fail-Closed Uncertainty
An unresolved mandatory target identity prevents the covered effect.
21.69.11 — Availability Tradeoff
A system may prioritize safe withholding over uncertain target
release.
21.69.12 — Hardware Limitations
Hardware identity evidence establishes only its supported properties
and does not automatically prove application-level authorization.
21.70 — PROPOSED INVENTIVE-STEP CHARACTERIZATION
21.70.1 — Established Building Blocks
Resource naming, filesystem object handles, version identifiers, path
restrictions, cryptographic signatures, conditional requests,
distributed resource registries, and service authentication are
established technical mechanisms.
The disclosed embodiment does not claim their individual invention.
21.70.2 — Candidate Objective Technical Problem
How to prevent operation-specific authority granted for an originally
identified resource from being misapplied to a materially different
actual resource following alias, namespace, redirect, migration, or
ownership changes, while allowing permitted resource identity
continuity to be verified and enforced at the actual consequential
resource boundary.
5.4.3.62. Source page 1819 of the original specification
21.70.3 — Proposed Technical Solution
A protected original resource referent is associated with a Candidate
Act.
Das Expires 29 April 2027 [Page 310]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Qualified resolution evidence establishes the relationship between
logical references and permitted actual resource identities.
Relevant namespace, binding, version, and ownership conditions are
maintained.
A protected controller establishes scoped non-bearer finality
enablement.
The actual Finality Sink independently reconstructs the pending
target and verifies the protected resource correspondence under
current authority.
The sink consumes operation-specific authority before permitting the
effect.
21.70.4 — Not Merely Path Normalization
Path normalization changes the representation of a resource path.
It does not necessarily establish the identity, ownership, or current
authorization of the actual target.
21.70.5 — Not Merely Symbolic-Link Protection
Restricted path traversal can prevent selected filesystem attacks.
The proposed system additionally binds the resolved actual resource
to originating task-specific finality authority and protected
consumption.
21.70.6 — Not Merely DNS Security
Authenticated name resolution may establish selected name-to-address
relationships.
It does not necessarily establish the actual application resource or
permitted consequential operation.
21.70.7 — Not Merely Conditional HTTP Requests
Conditional resource updates may verify a representation version.
The proposed broader relationship additionally maintains protected
continuity between the original authorized referent and the actual
resource operation.
21.70.8 — Not Merely Cryptographic Hashing
Das Expires 29 April 2027 [Page 311]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A content digest does not independently establish resource
authorization, namespace identity, or ownership.
21.70.9 — Not Merely Resource Migration
A resource migration can change location.
The selected stronger implementation requires qualified migration
continuity and current destination-side authority before
effectuation.
5.4.3.63. Source page 1820 of the original specification
21.70.10 — Candidate Narrow Inventive Kernel
A protected resource-identity execution-finality system in which an
original authorized resource referent is bound to a Candidate Act, a
protected controller obtains qualified current alias or namespace-
resolution evidence establishing a permissible resource identity
relationship, a scoped non-bearer finality enablement is bound to
that relationship and its applicable generations, and an
independently enforcing Finality Sink reconstructs the actual target
resource and permits the consequential operation only upon
verification of current resource correspondence, source authority,
effect scope, and sink-local protected consumption.
21.70.11 — Alias Rebinding Kernel
A narrower candidate may require protected detection of a material
binding-generation change and invalidation of pending resource-
specific finality authority.
21.70.12 — Cross-Domain Kernel
Another candidate may require authenticated resource migration
correspondence verified by the destination Finality Sink.
21.70.13 — Dynamic Equivalence Kernel
Another candidate may require a protected distinction between benign
resource renaming and unauthorized target substitution.
21.70.14 — Actual Resource Handle Kernel
Another candidate may require the sink to resolve the actual resource
through a protected handle or equivalent authoritative resource
reference, rather than rely solely on a previously submitted textual
name.
Das Expires 29 April 2027 [Page 312]
Internet-Draft Execution-Finality Part 7: Tools October 2026
21.70.15 — Multi-Namespace Kernel
Another candidate may require namespace identity and current resource
ownership as mandatory authority predicates.
21.70.16 — Hindsight Analysis
An inventive-step analysis should determine whether an earlier system
discloses the complete ordered relationship among original source-
authorized resource identity, protected current resolution evidence,
operation-specific finality authority, and actual resource-side
verification.
A mere collection of known resource-resolution techniques is
insufficient to establish the proposed stronger relationship.
At the same time, the mere absence of one named component from a
single earlier disclosure does not establish inventive step.
The evaluation should identify the closest prior systems, their
actual resource-control boundaries, the technical problem remaining
in those systems, and whether the asserted combination would have
been motivated by the prior disclosures rather than reconstructed
using later knowledge of the proposed invention.
5.4.3.64. Source page 1821 of the original specification
21.71 — INDUSTRIAL APPLICABILITY
21.71.1 — Autonomous File Management
Resource identity continuity may be enforced despite path changes and
symbolic links.
21.71.2 — Cloud Storage
Object versions and actual storage resources may be bound to
operation-specific authority.
21.71.3 — Distributed Databases
Application aliases may be verified against actual database records
and tenant identity.
21.71.4 — Enterprise Document Systems
User-visible documents may remain bound to actual authorized resource
identities.
Das Expires 29 April 2027 [Page 313]
Internet-Draft Execution-Finality Part 7: Tools October 2026
21.71.5 — Financial Systems
Account aliases may be verified against actual payment destinations.
21.71.6 — Electronic Commerce
Merchant and resource references may be checked against actual
transaction targets.
21.71.7 — Network Security
Destination rebinding may be subject to current protected effect
authorization.
21.71.8 — Cloud Administration
Changing service and resource identifiers may require current
finality revalidation.
21.71.9 — Multi-Agent Systems
Concurrent agents may be prevented from redirecting one another's
authorized resource effects.
21.71.10 — Distributed Storage Migration
Resource movement may preserve valid authorization under qualified
migration continuity.
21.71.11 — Operating Systems
Filesystem and protected process services may verify actual resource
identities.
21.71.12 — Credential Brokering
A credential may be exercised only for a protected actual resource.
21.71.13 — Telecommunications
5.4.3.65. Source page 1822 of the original specification
Logical network resources may be verified against actual configured
infrastructure.
21.71.14 — Industrial Automation
Device aliases may be bound to the actual controlled equipment.
Das Expires 29 April 2027 [Page 314]
Internet-Draft Execution-Finality Part 7: Tools October 2026
21.71.15 — Robotics
Actuator commands may verify current physical device identity.
21.71.16 — Autonomous Transportation
Selected control commands may remain bound to authorized actual
devices and resource ownership.
21.71.17 — Edge Computing
Resource identifiers may remain valid across approved local and
remote placements.
21.71.18 — Hardware Accelerators
Effect-capable device references may be constrained to authorized
actual command targets.
21.71.19 — Protected Information Disclosure
Actual data objects and recipients may be verified independently of
mutable names.
21.71.20 — Future Autonomous Critical Systems
Dynamic resource naming may remain subordinate to current protected
consequential authority.
21.72 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
21.72.1 — Candidate Independent System Claim
A system comprising:
A protected authorization controller configured to maintain an
original authorized resource referent associated with a consequential
Candidate Act;
A protected resource-resolution component configured to obtain
qualified evidence concerning an actual resource corresponding to a
submitted logical reference;
A correspondence validator configured to evaluate the actual resource
against the original authorized referent under applicable identity
and current-binding conditions;
Das Expires 29 April 2027 [Page 315]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A finality controller configured to establish scoped non-bearer
enablement bound to the permitted resource identity;
And an independent Finality Sink configured to reconstruct the actual
pending consequential operation and actual target resource, verify
current resource correspondence and source authority, and consume the
operation-specific finality enablement before permitting the effect.
5.4.3.66. Source page 1823 of the original specification
21.72.2 — Candidate Independent Method Claim
A method comprising:
Receiving a proposed consequential operation concerning a resource;
Constructing a Candidate Act;
Maintaining the effect non-effective;
Establishing an original authorized resource referent;
Obtaining qualified current resource-resolution evidence;
Verifying the correspondence between the original resource referent
and the permitted actual target;
Establishing scoped non-bearer finality authority;
Independently reconstructing the actual target at a resource Finality
Sink;
Verifying current resource identity, binding, source authority, and
protected consumption;
And permitting effectuation only upon satisfaction of the required
predicates.
21.72.3 — Candidate Independent Rebinding Claim
Another candidate may require protected detection of a material
resource-binding change and invalidation of dependent finality
enablement until updated correspondence is established.
21.72.4 — Candidate Independent Cross-Domain Claim
Das Expires 29 April 2027 [Page 316]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Another candidate may require authenticated resource migration
evidence connecting original and destination resource identities,
with independent destination-side actual-resource verification.
21.72.5 — Candidate Independent Hardware Claim
Another candidate may require a protected device-command sink to
verify current logical-to-physical device correspondence and
operation-specific authority before hardware actuation.
21.73 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
1. The original referent includes a logical resource name.
2. The original referent includes a qualified underlying object
identity.
3. The original referent includes the originating resource domain.
4. The original referent includes namespace identity.
5. The original referent includes a resource-generation reference.
6. The original referent includes current source-authority state.
5.4.3.67. Source page 1824 of the original specification
7. A protected resolver authenticates a name-to-resource mapping.
8. The resolver possesses a defined observation or authority role.
9. A protected resolution record includes a current binding
generation.
10. A protected resolution record includes a resource version.
11. A protected resolution record includes an ownership generation.
12. The system distinguishes content identity from object identity.
13. The system distinguishes object identity from current resource
authorization.
14. A content digest alone is insufficient where current ownership
is required.
15. A permitted resource rename preserves finality eligibility under
a qualified identity-continuity rule.
Das Expires 29 April 2027 [Page 317]
Internet-Draft Execution-Finality Part 7: Tools October 2026
16. Replacement of an actual resource invalidates incompatible
earlier authority.
17. Deletion and recreation under the same name is identified
through current generation or object-identity evidence.
18. A filesystem resource is resolved using a protected object
handle.
19. A filesystem path is resolved relative to a qualified protected
directory.
20. A symbolic-link traversal is prohibited or qualified according
to the selected resource policy.
21. A mount or namespace change causes identity revalidation.
22. A database record identity is qualified by tenant or resource
domain.
23. A database mutation verifies an expected resource version.
24. An object-storage operation verifies a specified object version
where required.
25. An object key reuse does not automatically preserve historical
object-specific authority.
26. A URL is parsed under defined resource semantics.
27. A protected request verifies current destination identity.
28. A redirect creates a resource-resolution edge requiring
qualification.
29. A cross-origin redirect requires applicable current
authorization.
30. A redirect chain is bounded by a protected traversal policy.
31. A method or request-body change across a redirect is subject to
effect-scope verification.
32. A current network destination is compared with the original
permitted envelope.
Das Expires 29 April 2027 [Page 318]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.4.3.68. Source page 1825 of the original specification
33. A DNS resolution result does not independently establish current
application-resource identity.
34. An authenticated service identity is verified where required.
35. A service-discovery change may invalidate dependent finality
authority.
36. A load-balanced backend may be accepted as part of a permitted
authenticated service class.
37. A cross-domain migration requires qualified source and
destination correspondence.
38. A migration receipt does not independently grant unrestricted
destination-resource authority.
39. A resource ownership change invalidates incompatible historical
permission.
40. A logical device identifier is bound to a current actual device.
41. A device replacement causes current identity or authority-
generation verification.
42. A protected equivalence class defines permitted alternative
actual targets.
43. An untrusted requester cannot enlarge the equivalence class.
44. A protected alias graph identifies authenticated resource-
reference transformations.
45. An alias graph is rejected when a required edge lacks qualified
evidence.
46. Alias traversal is subject to bounded verification depth.
47. A cyclic alias graph does not independently authorize a resource
effect.
48. An ambiguous required resource identity causes the effect to
remain withheld.
49. Resource identity commitments employ a deterministic typed
encoding.
Das Expires 29 April 2027 [Page 319]
Internet-Draft Execution-Finality Part 7: Tools October 2026
50. The protected encoding distinguishes resource domains and
namespaces.
51. The encoding handles relevant numerical and textual ambiguity
under a defined protocol.
52. An earlier resolution commitment becomes invalid following a
material binding change.
53. A protected resource fence prevents effectuation pending
required revalidation.
54. The Finality Sink reconstructs the actual resource independently
of the agent's original label.
55. The Finality Sink verifies current original source authority.
56. The Finality Sink verifies current namespace identity.
57. The Finality Sink verifies current resource ownership.
58. The Finality Sink verifies current version or generation state.
59. The Finality Sink verifies the actual operation parameters.
5.4.3.69. Source page 1826 of the original specification
60. The Finality Sink verifies the operation-specific resource
equivalence predicate.
61. The Finality Sink verifies a separate non-bearer finality
enablement.
62. The Finality Sink verifies protected sink-local consumption
state.
63. A copied finality reference cannot independently authorize a
different resource.
64. A cross-sink finality reference is rejected when its designated
resource or sink does not correspond.
65. A transactional resource controller may atomically commit
protected consumption and local resource mutation.
66. An external resource operation maintains an appropriate durable
attempt state.
Das Expires 29 April 2027 [Page 320]
Internet-Draft Execution-Finality Part 7: Tools October 2026
67. An uncertain remote outcome is not automatically treated as
failed effectuation.
68. A completed actual-effect receipt identifies the resource
actually affected.
69. A CW-2 successor may require a qualified receipt concerning the
specified predecessor resource.
70. A CW-3 protected deviation latch may be activated following
unauthorized resource rebinding.
71. A qualified harmless alias change may be resolved under existing
authorization.
72. A materially new resource target may require new scoped source
authorization.
73. A human scope approval does not override an unrelated mandatory
security condition.
74. Protected resource identity continuity may be preserved across
authorized agent handoff.
75. Protected resource generations may fence stale devices or
controllers.
76. A resource migration may preserve bounded authority without
granting unrelated effect scope.
77. A gateway lacking sufficient actual-resource visibility must
employ a qualified destination-side controller where required.
78. Resource resolution and actual finality may be performed in
separate protected domains.
79. The implementation may employ a hardware-backed resource
identity register.
80. The system may use existing filesystem, database, network,
storage, and hardware components while preserving the selected
protected authority-to-resource relationship.
21.74 — UNIVERSAL COMBINATION, SUBCOMBINATION, AND NON-LIMITING
PHOSITA CLAUSE
The features disclosed in Embodiment 21 may be implemented separately
where technically sufficient or in any compatible subcombination.
Das Expires 29 April 2027 [Page 321]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.4.3.70. Source page 1827 of the original specification
A filesystem implementation may use protected object handles,
namespace evidence, and sink-local finality.
A database implementation may use tenant-qualified object identity
and transactional resource versions.
An object-storage implementation may use object identifiers, version
references, and protected mutation gateways.
A network implementation may use destination, redirect, and
authenticated resource-service evidence.
A distributed service implementation may use qualified resource
migration and provider-specific identity assertions.
A hardware implementation may use protected device identity and
command enablement.
A multi-agent implementation may use protected binding generations to
prevent concurrent target substitution.
An implementation may combine resource-identity continuity with
current source revocation, cumulative resource constraints, conflict
reservations, or other required modules.
The invention does not universally require a filesystem.
It does not universally require network name resolution.
It does not universally require a graph representation.
It does not universally require cryptographic signatures when an
equivalent protected state mechanism supplies the required trust
property.
It does not universally require physical separation of resource
resolver and Finality Sink unless such separation is required by a
selected claimed implementation.
It does not universally require exact object identity where the
original source authority expressly permits an authenticated
equivalent-resource class.
It does not automatically permit all aliases, resource versions, or
migrated resources.
Das Expires 29 April 2027 [Page 322]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The applicable equivalence relationship remains bounded by original
source authority and current protected operation semantics.
Where a CW-2 receipt-dependent successor is required, a resource-
identity verification result does not replace the mandatory accepted
prior actual-effect receipt.
Where CW-3 applies, a material unauthorized rebinding may be treated
as a scope deviation requiring protected adjudication or new
authorization.
Where a resource operation has already completed, later name changes
do not retroactively alter the historical fact of the actual affected
resource.
The equations, data structures, algorithms, pseudocode, proposed
tests, examples, and illustrations are non-limiting technical aids
intended to assist a person having ordinary skill in the art.
5.4.3.71. Source page 1828 of the original specification
The architecture may be implemented using present or future
equivalent computing substrates provided that the required protected
resource identity, actual operation correspondence, and finality
enforcement properties remain satisfied.
21.75 — FINAL TECHNICAL CHARACTERIZATION
The present Embodiment 21 discloses a protected execution-finality
architecture for consequential operations involving resources whose
names, aliases, locations, namespaces, bindings, ownership, or
representations may change before actual effectuation.
A computational entity may propose an operation against a logical
resource reference.
The original source authority establishes an authorized resource
referent and bounded consequential scope.
A protected resource-identity system may obtain qualified evidence
connecting the original referent to one or more current resource
representations.
The system distinguishes resource names from actual object identity,
content identity, ownership, namespace identity, resource version,
and current authority.
Das Expires 29 April 2027 [Page 323]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Authenticated alias-lineage evidence and protected resource-binding
generations may establish whether an actual target remains equivalent
to the originally authorized resource.
A material target change may invalidate pending authority.
A harmless verified rename or migration may preserve eligibility
where the original authorization permits that continuity.
A protected validation component verifies the current resource
identity relationship.
A separate authority controller establishes scoped non-bearer
finality enablement bound to the required resource-identity
conditions.
At the consequential boundary, the Finality Sink independently
reconstructs the actual pending operation and target resource.
The sink verifies current source authority, resource correspondence,
relevant namespace and ownership generations, actual operation
semantics, and sink-local protected consumption state.
A valid path, hostname, alias, object key, application label, content
digest, or earlier signed resolution does not independently authorize
a materially different actual resource.
The disclosed arrangements may use existing filesystem APIs,
conditional resource updates, authenticated service communication,
object-version registries, cryptographic commitments, database
transactions, and protected device controllers.
The principal candidate inventive technical concept of Embodiment 21
is a protected autonomous resource-identity execution-finality system
in which the original source-authorized resource referent and a
qualified current resolution relationship are bound to operation-
specific non-bearer finality authority, and an independently
enforcing Finality Sink reconstructs the actual pending resource
target and refuses consequential execution unless
5.4.3.72. Source page 1829 of the original specification
that target satisfies the current protected resource-equivalence,
authority, effect-scope, and sink-local consumption predicates.
21.76 — SHORT IMPLEMENTATION USING EXISTING TECHNOLOGIES
Das Expires 29 April 2027 [Page 324]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A PHOSITA may use the following existing technical mechanisms as
optional building blocks.
Existing technology Optional technical role Filesystem object handles
and restricted path-resolution APIs
Bind an actual file operation to a qualified filesystem target
Filesystem namespace and mount controls Qualify the resource-
resolution environment Database primary keys and transaction versions
Establish current record identity and prevent selected stale
mutations Object-storage generation or version identifiers Bind an
effect to the intended stored object version
URI parsing and normalization Reduce representational ambiguity under
defined resource semantics DNS and authenticated network
communication
Establish selected name, endpoint, and service properties
HTTP redirects and conditional requests Identify changed request
targets and enforce supported resource conditions Digital signatures
and MACs Authenticate protected resource-resolution evidence
Deterministic JSON or CBOR encoding Produce consistent resource-
identity commitments OAuth or equivalent authorization infrastructure
Establish original principal and permitted resource scope
Transactional databases Maintain binding generations, finality state,
and protected consumption
Privileged resource brokers Prevent untrusted agents from exercising
uncontrolled resource authority Protected hardware identity registers
Verify current device or command-target identity
5.5. Embodiment 24 — Instruction Provenance, Lower-Trust Influence and
Protected Downstream Tool Authorization
Original global source pages 2019 through 2091, inclusive. Source
file: TECHNICAL SPECIFICATION -2012-2566.pdf. This is a primary Part
7 source unit; the author should compare embedded extracts with the
original source file before publication.
5.5.1. Embodiment-Specific Architecture and Trust Relationship
Das Expires 29 April 2027 [Page 325]
Internet-Draft Execution-Finality Part 7: Tools October 2026
[Source-authorized task instructions]
|
[Model inputs: web, repo, tool output, email]
|
[Provenance/influence and trust classification]
|
[Agent generates candidate tool action]
|
[PED: source authority + input influence policy]
|
[Qualified Candidate Act remains NES]
|
[FS reconstructs actual outgoing effect]
/AUTHORIZED \UNTRUSTED SCOPE
[Consume + effect] [WITHHOLD]
Figure 9: Embodiment 24 — Instruction Provenance, Lower-Trust
Influence and Protected Downstream Tool Authorization — protected
architecture
5.5.2. Operational Security Decision Flowchart
[Untrusted data affects planned tool call]
|
<Can input grant authority?>-YES->[DENY INFERENCE]
|NO
[Attribute material instruction sources]
|
<Violates source/task constraints?>-YES->[FENCE]
|NO
[Reconstruct actual destination and payload]
|
<Correct grant + disclosure + target?>-NO->[REFUSE]
|YES
[Protected consumption / bounded action]
Figure 10: Embodiment 24 — Instruction Provenance, Lower-Trust
Influence and Protected Downstream Tool Authorization — refusal
and controlled- effect decisions
5.5.3. Original Technical Disclosure with Global-Page Anchors
5.5.3.1. Source page 2019 of the original specification
→ current credential and resource verification → protected
consumption → controlled signing, credential insertion, or key
activation → qualified resource outcome.
Das Expires 29 April 2027 [Page 326]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The existing technologies supply implementation primitives.
The proposed distinguishing technical relationship is the mandatory
conversion of a currently authorized consequential operation into one
protected, operation-bound exercise of otherwise reusable credential
authority, verified at the actual credential-use boundary rather than
merely at the point of authentication or credential storage.
END OF EMBODIMENT 23 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 24
PROTECTED MODEL-DRIVEN TOOL-OUTPUT AND INSTRUCTION-PROVENANCE
EXECUTION FINALITY WITH SEMANTIC BOUNDARY VERIFICATION, DERIVATION-
LINEAGE CONTROL, AND CONSEQUENTIAL ACTION ISOLATION
24.0 — COMPLETE TECHNICAL TITLE
Systems, Methods, and Apparatus for Governing Autonomous Artificial-
Intelligence Consequential Operations Using Authenticated Source-
Instruction Provenance, Qualified Tool-Output and Retrieval Lineage,
Protected Data-to-Authority Separation, Semantic Operation-Envelope
Construction, Cross-Committed Execution-Time Validation, Scoped Non-
Bearer Finality Enablement, and Independent Finality-Sink
Verification of Actual Resource Effects
24.0.1 — General Technical Description
The present Embodiment 24 discloses systems, methods, apparatus,
protected computing components, authenticated provenance records,
machine-verifiable instruction-authority structures, intermediate-
data lineage mechanisms, tool-output qualification interfaces,
protected computational trust-boundary controllers, semantic
operation validators, and non-limiting implementations for governing
consequential actions proposed by artificial-intelligence systems
after processing information originating from multiple sources having
different authority and trust properties.
An autonomous computational entity may comprise:
A language-model-based agent;
A multimodal artificial-intelligence assistant;
A retrieval-augmented application;
A software development agent;
Das Expires 29 April 2027 [Page 327]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An autonomous computer-use system;
5.5.3.2. Source page 2020 of the original specification
A tool-calling orchestration system;
A multi-agent platform;
A robotic controller;
A cloud automation service;
An enterprise software agent;
Or another computational entity capable of interpreting information
and proposing operations that affect external or persistent
resources.
The computational entity may process:
Originating user instructions;
System or application configuration;
Authorized workflow policies;
Webpages;
Retrieved documents;
Search results;
Database responses;
Tool invocation outputs;
Repository files;
Communication messages;
Email attachments;
Application logs;
Browser interface content;
Accessibility information;
Das Expires 29 April 2027 [Page 328]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Images;
Audio transcriptions;
Video-derived information;
Structured API responses;
5.5.3.3. Source page 2021 of the original specification
Vector-retrieval results;
And messages generated by other computational agents.
The information may be used to answer questions, perform analysis,
identify relevant objects, construct operation parameters, generate
code, prepare transactions, or propose consequential actions.
However, the source of information used by an autonomous system may
possess no authority to direct the system to perform the resulting
consequential operation.
A retrieved webpage may contain accurate information concerning a
legitimate resource while also containing attacker-controlled
instructions directing the agent to disclose confidential data.
An email may contain a valid invoice amount while falsely claiming
authority to change the original approved payment recipient.
A tool response may be authenticated as originating from a particular
service while containing resource data controlled by another party.
A repository file may legitimately contribute source code to a
compilation task while containing text intended to cause the agent to
execute an unauthorized command.
A retrieved search result may influence the agent's interpretation of
a task without possessing permission to expand the task.
An intermediate model-generated summary may incorporate instructions
originating from lower-trust material.
A second agent may transform such material into a structured
operation proposal.
The resulting proposal may appear to originate from the second agent,
even though its consequential parameters were influenced by the
lower-trust material.
Das Expires 29 April 2027 [Page 329]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A structured tool-call format may be syntactically valid while
identifying a resource operation that the originating principal did
not authorize.
A cryptographically signed tool response may establish the identity
of the responding service without proving that all contained
information is accurate, approved, or authorized for use as
executable instructions.
A model may describe a proposed action as safe, necessary, urgent, or
previously approved without establishing the corresponding current
source authority.
These conditions create a technical risk when intermediate
computation is permitted to exercise resource authority without a
separate protected consequential authorization boundary.
The present embodiment addresses the risk by maintaining a protected
distinction among:
5.5.3.4. Source page 2022 of the original specification
The originating principal's authority;
The provenance of data;
The provenance of instructions;
The generation and transformation of computational content;
The proposed Candidate Act;
The verified actual-effect envelope;
The authority enabling the actual effect;
And the consequential operation actually presented at the Finality
Sink.
In a principal implementation, relevant input items are associated
with authenticated or qualified provenance records.
The records may identify source identities, acquisition boundaries,
source-authority roles, processing transformations, derived outputs,
and selected trust attributes.
Das Expires 29 April 2027 [Page 330]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A protected controller may preserve provenance relationships through
data retrieval, extraction, summarization, tool invocation, model
output, agent handoff, and other computational transformations.
The controller distinguishes an item that supplies task data from a
protected authority source permitted to establish consequential
instructions.
A tool response, document, retrieved message, or model output may
influence the parameters proposed in a Candidate Act.
However, the corresponding authority to produce an actual effect is
separately derived from a current protected source grant and
applicable resource-specific conditions.
The proposed operation remains in a Non-Effective State.
An independent validation instance evaluates the proposed actual-
effect descriptor, current source authority, applicable data-to-
effect constraints, resource identity, and required protected
evidence.
A finality controller establishes scoped non-bearer finality
enablement.
The actual Finality Sink independently obtains or reconstructs the
pending consequential operation.
The sink verifies that the actual operation remains within the
source-authorized effect envelope, regardless of whether its
parameters originated from retrieved material, tool outputs, agent-
generated reasoning, or other intermediate computational sources.
5.5.3.5. Source page 2023 of the original specification
The sink additionally verifies current revocation, relevant protected
resource state, and sink-local finality consumption.
A lower-trust instruction cannot create otherwise absent resource
authority merely by being included in the model's context, returned
by a tool, summarized by an agent, or reformatted as a valid function
call.
24.0.2 — Fundamental Technical Principle
Information may influence computation without becoming authority to
act.
Das Expires 29 April 2027 [Page 331]
Internet-Draft Execution-Finality Part 7: Tools October 2026
More specifically:
The authenticity of a document does not automatically establish
permission to obey instructions contained in the document.
The authenticity of a tool response does not automatically establish
that the response may expand the originating task.
A valid data extraction does not independently authorize
consequential use of the extracted data.
A model-generated decision is not automatically a protected source-
authority decision.
An authenticated message from another agent does not automatically
provide that agent with authority it did not receive from the
originating principal.
A structured tool call is not necessarily a currently authorized
consequential operation.
And a cryptographically sealed computational output does not
independently establish finality for the real-world effect that
output proposes.
24.0.3 — Principal Candidate Inventive Combination
A principal technical combination comprises:
(a) an originating source-authorized task or consequential-effect
envelope;
(b) a protected instruction-authority reference;
(c) authenticated or qualified provenance evidence for selected
intermediate computational inputs;
(d) a protected classification distinguishing instruction authority
from informational content;
(e) a derivation-lineage structure relating selected retrieved or
tool-generated information to a proposed operation;
(f) a protected operation-semantic translator;
Das Expires 29 April 2027 [Page 332]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.5.3.6. Source page 2024 of the original specification
(g) a Candidate Act maintained non-effective;
(h) a protected validator independently checking current source
authority and material actual-effect parameters;
(i) an optional protected cross-commitment among relevant collected
provenance, independent execution-time evidence, and the Candidate
Act;
(j) scoped non-bearer finality enablement;
(k) an independently enforcing actual resource Finality Sink;
(l) mandatory sink-side verification of actual-operation
correspondence and protected finality consumption.
24.0.4 — Candidate Technical Distinction
The proposed technical contribution is not the individual invention
of:
Prompt-injection detection;
Data-source labels;
Document provenance;
Digital signatures;
Cryptographic hashing;
Source citations;
Input sanitization;
Output schemas;
Retrieval-augmented generation;
Access-control lists;
Or ordinary least-privilege tool configuration.
Das Expires 29 April 2027 [Page 333]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The candidate distinguishing relationship concerns the preservation
of a protected source-authority boundary despite untrusted data
influence, together with an actual effectuation gate that
independently verifies current operation-specific authority.
24.0.5 — Focused Dependent Implementation
5.5.3.7. Source page 2025 of the original specification
This embodiment concentrates upon the provenance and transformation
of model-consumed information and its relationship to downstream
consequential effects.
It is not intended to restate every foundational element of CW-1 or
the earlier embodiments.
The foundational Candidate Act, Non-Effective State, Protected
Enforcement Domain, separate finality enablement, and Finality Sink
concepts may be incorporated by reference according to their
applicable technical relationships.
24.0.6 — Non-Limiting PHOSITA Architecture
ORIGINATING AUTHORIZED PRINCIPAL | v PROTECTED SOURCE-AUTHORITY
ENVELOPE | +-----------------------------+ | | v v TRUSTED TASK
CONTEXT LOWER-TRUST INFORMATION | +------+------+ | | v v DOCUMENTS
TOOL OUTPUTS | | +------+------+ | v QUALIFIED PROVENANCE AND
DERIVATION | v MODEL / AGENT COMPUTATION | v PROPOSED ACTION | v
CANDIDATE ACT | v NON-EFFECTIVE HOLD | v INDEPENDENT VALIDATION |
+------------+------------+ | | v v
5.5.3.8. Source page 2026 of the original specification
SOURCE AUTHORITY ACTUAL-EFFECT SCOPE | |
+------------+------------+ | v NON-BEARER FINALITY ENABLEMENT | v
ACTUAL FINALITY SINK | RECONSTRUCT ACTUAL OPERATION | VERIFY CURRENT
PERMISSION | CONSUME PROTECTED AUTHORITY | v CONTROLLED REAL EFFECT
The diagram is illustrative and non-limiting and is intended to
assist a PHOSITA in understanding the technical relationships.
24.1 — TECHNICAL FIELD
Das Expires 29 April 2027 [Page 334]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The invention relates to autonomous-agent security, instruction
provenance, data lineage, tool-output integrity, retrieval security,
protected semantic operation validation, prompt-injection
containment, source-authority binding, multimodal information
processing, protected execution boundaries, and independent
consequential finality.
More particularly, it concerns preventing computational information
originating outside a valid authority channel from being transformed
into permission to produce real or persistent effects.
24.2 — SPECIFIC TECHNICAL PROBLEMS
24.2.1 — Indirect Instruction Injection
A retrieved document may contain instructions intended for the model
rather than ordinary task data.
24.2.2 — Tool-Output Instruction Laundering
An external tool response may contain instructions that the agent
treats as its own next task.
24.2.3 — Data-to-Authority Promotion
5.5.3.9. Source page 2027 of the original specification
A data item may be treated as granting permission merely because it
appears in a model's context.
24.2.4 — Authenticated Malicious Content
A genuine service response may carry attacker-controlled text.
24.2.5 — Summary Laundering
A model may summarize malicious content into a new apparently
authoritative instruction.
24.2.6 — Cross-Agent Laundering
A second agent may receive and repeat a lower-trust instruction
without preserving its original provenance.
24.2.7 — Mixed-Trust Documents
One document may contain both legitimate task data and unauthorized
instructions.
Das Expires 29 April 2027 [Page 335]
Internet-Draft Execution-Finality Part 7: Tools October 2026
24.2.8 — Payload Fragmentation
A malicious instruction may be distributed across several retrieved
documents or tool responses.
24.2.9 — Multimodal Injection
Instructions may be embedded in images, audio, video, or other non-
text representations.
24.2.10 — Tool-Schema Confusion
An agent may generate a syntactically valid tool call whose actual
consequential semantics differ from the original task.
24.2.11 — Tool Implementation Drift
A tool may change the effect produced by the same structured
invocation.
24.2.12 — Provenance Loss During Transformation
A derivation process may discard the origin information needed to
qualify later use.
24.2.13 — False Source Authority
An untrusted message may claim to come from a system administrator or
original principal.
24.2.14 — Authority Role Confusion
A data-source identity may be mistaken for an authorization
principal.
5.5.3.10. Source page 2028 of the original specification
24.2.15 — Cryptographic Signature Confusion
A valid signature may be incorrectly interpreted as proof of the
truth or permissibility of the signed content.
24.2.16 — Structured-Output Confusion
A validated JSON or typed argument structure may still specify an
unauthorized effect.
24.2.17 — Hidden Operation Parameters
Das Expires 29 April 2027 [Page 336]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A generated tool call may include consequential fields not displayed
to the user or protected validator.
24.2.18 — Context Assembly Ambiguity
Information from distinct authority channels may be concatenated
without protected role separation.
24.2.19 — Retrieval Replacement
A retrieved source may change between collection and operation
execution.
24.2.20 — Model-Generated Authorization Claim
A model may assert that a proposed action has already been approved.
24.2.21 — Context-Window Truncation
Original authorization constraints may be absent from the model's
current context while the agent continues working.
24.2.22 — Tool-Output Replay
An earlier authentic response may be reused under incompatible
current authority or resource state.
24.2.23 — Vector Retrieval Contamination
Lower-trust records may enter a retrieval index and later influence
consequential operation parameters.
24.2.24 — Retrieval Ranking Influence
An adversarial source may disproportionately influence which data
reaches the agent.
24.2.25 — Repository Instruction Injection
Comments, code files, or documentation may propose unauthorized
operations during legitimate development workflows.
5.5.3.11. Source page 2029 of the original specification
24.2.26 — Browser Content Injection
Page content may cause a computer-use agent to select a harmful
action.
Das Expires 29 April 2027 [Page 337]
Internet-Draft Execution-Finality Part 7: Tools October 2026
24.2.27 — Permission Expansion Through Tool Results
A tool result may suggest a new resource, recipient, privilege, or
credential outside original authority.
24.2.28 — Failure of Purely Linguistic Defenses
A model may follow an injected instruction despite prompt-level
warnings.
24.2.29 — Incomplete Causal Provenance
A system may be unable to prove every input that causally influenced
a model output.
24.2.30 — Actual Resource Bypass
Even correctly classified data cannot prevent unauthorized effects if
the protected Finality Sink can be bypassed.
24.2.31 — Technical Objective
A candidate objective technical problem is:
How to prevent lower-trust information and derived computational
outputs from acquiring authority to cause protected consequential
effects during autonomous tool-based workflows, while permitting such
information to contribute legitimate operation data and independently
enforcing current originating authority against the actual operation
at the resource effectuation boundary.
24.3 — EXISTING TECHNIQUES AND THEIR LIMITATIONS
24.3.1 — Prompt Segregation
Existing systems may separate higher-priority instructions from
lower-priority user or retrieved content.
This is a useful input-organization mechanism.
It does not necessarily guarantee that a model will never be
influenced by malicious lower-trust content.
24.3.2 — Input Filtering
Existing filters may detect suspicious strings or patterns.
Das Expires 29 April 2027 [Page 338]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.5.3.12. Source page 2030 of the original specification
They may assist risk classification.
They do not establish complete authority for an actual consequential
operation.
24.3.3 — Output Validation
Existing structured-output validators may verify schemas, types,
enumerations, and constraints.
A syntactically valid operation may still be unauthorized.
24.3.4 — Provenance Standards
Existing provenance models may describe entities, activities, agents,
and derivation relationships.
These are established concepts.
A provenance relationship does not automatically establish permission
to produce a real-world effect.
24.3.5 — Digital Signatures
Signatures may authenticate selected content or source identity.
A signed retrieved document may still contain unauthorized
instructions.
24.3.6 — Retrieval Systems
Existing retrieval systems provide relevant information to models.
The ranking or retrieval of content does not independently make it an
authoritative instruction source.
24.3.7 — Least-Privilege Tools
Existing systems may grant reduced tool permissions.
The selected stronger implementation additionally requires the actual
pending operation to match independently established source-
authorized finality conditions.
24.3.8 — Human Approval
Das Expires 29 April 2027 [Page 339]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Human confirmation may be required for selected operations.
The approval should be bound to the actual material effect where such
a property is required.
24.3.9 — Candidate Technical Distinction
5.5.3.13. Source page 2031 of the original specification
The proposed combination does not rely solely upon persuading a model
to disregard malicious content.
It preserves a mandatory resource-effect authority boundary
independent of the model's interpretation of that content.
24.4 — PRINCIPAL SYSTEM COMPONENTS
A representative implementation comprises:
A Protected Originating Authority Registry;
A Source-Instruction Provenance Controller;
A Qualified Input Acquisition Controller;
A Tool-Output Provenance Qualifier;
A Protected Data and Authority Classification Registry;
A Computational Derivation-Lineage Controller;
A Model-Output Candidate Act Constructor;
A Protected Tool-Semantics Registry;
An Independent Operation-Semantics Validator;
A Source-Authority Correspondence Controller;
A Protected Scope-Deviation Detector;
A Cross-Committed Evidence Controller;
A Non-Bearer Finality Enablement Controller;
An Actual Resource Finality Sink;
And a Protected Consumption and Outcome Journal.
Das Expires 29 April 2027 [Page 340]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Optional components include:
A cryptographic signing service;
A retrieval index;
A browser automation adapter;
5.5.3.14. Source page 2032 of the original specification
A multimodal input classifier;
A privileged tool gateway;
A schema registry;
A protected credential broker;
A policy decision engine;
A current revocation service;
And an authenticated human-approval channel.
24.5 — TECHNICAL DEFINITIONS
24.5.1 — Protected Originating Instruction Authority
Protected Originating Instruction Authority, or POIA-24, means
authenticated source authority defining the permitted consequential
objectives, resources, and operation boundaries of an autonomous
task.
24.5.2 — Instruction Provenance Record
An Instruction Provenance Record, or IPR-24, means authenticated
information identifying the qualified origin and authority role of a
particular instruction.
24.5.3 — Data Provenance Record
A Data Provenance Record, or DPR-24, means authenticated or qualified
evidence identifying the source and acquisition context of a data
item.
24.5.4 — Authority Role Classification
Das Expires 29 April 2027 [Page 341]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Authority Role Classification means a protected classification
distinguishing valid permission sources from informational sources.
24.5.5 — Tool-Output Evidence Envelope
A Tool-Output Evidence Envelope, or TOEE-24, means a structured
authenticated record describing a tool result and its supported
evidence properties.
24.5.6 — Computational Derivation Lineage
Computational Derivation Lineage, or CDL-24, means a record of
declared or observed transformations among source data, tool results,
intermediate outputs, and proposed operations.
5.5.3.15. Source page 2033 of the original specification
24.5.7 — Provenance Influence Set
A Provenance Influence Set, or PIS-24, means an identified or
conservatively approximated set of information sources potentially
influencing a downstream computational output.
24.5.8 — Qualified Source Role
A Qualified Source Role means the specific information, observation,
or authority function a source is permitted to supply.
24.5.9 — Protected Instruction/Data Boundary
A Protected Instruction/Data Boundary means an enforceable separation
preventing ordinary lower-trust data from independently establishing
new consequential authority.
24.5.10 — Instruction-Authority Promotion
Instruction-Authority Promotion means treating informational content
as authorization for a consequential operation.
24.5.11 — Unauthorized Promotion
Unauthorized Promotion means instruction-authority promotion without
the required protected source authorization.
24.5.12 — Protected Operation Semantics
Das Expires 29 April 2027 [Page 342]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Protected Operation Semantics means a machine-verifiable
representation of the material resource effects associated with a
proposed operation.
24.5.13 — Semantic Effect Descriptor
A Semantic Effect Descriptor, or SED-24, means a protected
representation of the material actual operation class, resource,
recipient, and parameters.
24.5.14 — Protected Tool Contract
A Protected Tool Contract, or PTC-24, means an authenticated
description of a tool's relevant permitted operation semantics and
effect-capable interface.
24.5.15 — Tool-Semantics Generation
A Tool-Semantics Generation, or TSG-24, means a protected version
identifying the currently applicable tool-operation contract.
24.5.16 — Provenance-Bound Candidate Act
A Provenance-Bound Candidate Act, or PBCA-24, means a Candidate Act
associated with relevant qualified source and derivation references.
5.5.3.16. Source page 2034 of the original specification
24.5.17 — Provenance Qualification Predicate
A Provenance Qualification Predicate means a machine-verifiable
requirement identifying the evidence properties that a specified
source must establish.
24.5.18 — Source-Authority Correspondence
Source-Authority Correspondence means verified consistency between a
proposed consequential operation and its originating authorized
effect envelope.
24.5.19 — Derived Instruction Claim
A Derived Instruction Claim means an instruction-like statement
generated or repeated by a model or intermediate tool that purports
to direct subsequent behavior.
24.5.20 — Protected Authority Root
Das Expires 29 April 2027 [Page 343]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A Protected Authority Root means an authenticated original
authorization record whose permissions cannot be enlarged by
unqualified intermediate computational material.
24.5.21 — Authority-Preserving Transformation
An Authority-Preserving Transformation means a data or operation
transformation that does not enlarge the permitted consequential
effect scope.
24.5.22 — Data-Only Influence
Data-Only Influence means permissible use of information to determine
facts or operation parameters without treating that source as
independently granting permission.
24.5.23 — Consequential Instruction Attempt
A Consequential Instruction Attempt means content seeking to cause a
protected external or persistent effect through the computational
entity.
24.5.24 — Protected Context Boundary
A Protected Context Boundary means a controlled interface separating
source-authority instructions from model-consumed information having
different authority roles.
24.5.25 — Derived-Output Attestation
Derived-Output Attestation means authenticated evidence identifying a
computational output and the execution or provenance properties
actually supported by the attesting component.
24.5.26 — Source-Role Substitution
Source-Role Substitution means presenting content associated with one
authority role as though it belonged to another.
5.5.3.17. Source page 2035 of the original specification
24.5.27 — Protected Retrieval Generation
A Protected Retrieval Generation means a current generation
associated with relevant retrieved or indexed information.
24.5.28 — Semantic Boundary Validator
Das Expires 29 April 2027 [Page 344]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A Semantic Boundary Validator, or SBV-24, means an independently
protected component evaluating the actual consequential semantics of
a proposed operation.
24.5.29 — Consequential Action Isolation
Consequential Action Isolation means preventing untrusted
computational outputs from directly invoking protected effect-capable
resource primitives without required finality authorization.
24.5.30 — Protected Data-to-Effect Rule
A Protected Data-to-Effect Rule means an authenticated rule
identifying how lower-trust data may populate specified fields of an
otherwise source-authorized consequential operation.
24.5.31 — Instruction Provenance Seal
An Instruction Provenance Seal, or IPS-24, means an authenticated
commitment to selected instruction content, claimed authority origin,
and applicable role or generation information.
24.5.32 — Model Output Inertness
Model Output Inertness means a computational proposal does not
independently create executable authority merely by being generated
by a model.
24.5.33 — Qualified Tool Result
A Qualified Tool Result means tool output verified to possess
specified source or evidence properties, without necessarily being
granted instruction authority.
24.5.34 — Provenance Uncertainty
Provenance Uncertainty means inability to establish a required
source, lineage, or authority relationship with sufficient assurance.
24.5.35 — Protected Provenance Commitment
A Protected Provenance Commitment means an authenticated relationship
binding selected provenance evidence to a Candidate Act or protected
validation record.
24.5.36 — Current Instruction Authority Generation
Das Expires 29 April 2027 [Page 345]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A Current Instruction Authority Generation means a protected version
identifying the applicable authorized task-instruction and revocation
state.
5.5.3.18. Source page 2036 of the original specification
24.5.37 — Protected Semantic Scope Deviation
A Protected Semantic Scope Deviation means an independently
established mismatch between the consequential operation and the
originating effect envelope.
24.5.38 — Actual Tool-Effect Reconstruction
Actual Tool-Effect Reconstruction means obtaining or deriving the
actual resource operation presented for effectuation, rather than
relying solely upon the agent's prior description.
24.6 — SEPARATION OF THREE DISTINCT PROVENANCE PROPERTIES
A principal implementation distinguishes three properties.
24.6.1 — Content Provenance
Who or what supplied the content?
For example, a retrieved invoice may originate from an authenticated
document repository.
24.6.2 — Transformation Provenance
What qualified computational steps generated the subsequent output?
For example, a parser may extract an amount from the invoice.
24.6.3 — Instruction Authority
Who possesses valid source permission to direct the consequential
effect?
For example, the account owner may authorize a bounded payment.
These properties must not be treated as equivalent.
An authenticated invoice can supply a payment amount.
It does not necessarily authorize payment to a new bank account.
Das Expires 29 April 2027 [Page 346]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A trusted parser can accurately extract an external recipient.
It does not thereby grant permission to disclose confidential
information to that recipient.
A model can summarize a document correctly.
That does not make the summary a new protected source of authority.
24.6.4 — Candidate Technical Interaction
5.5.3.19. Source page 2037 of the original specification
The protected validation system may accept qualified source data
while separately enforcing the original consequential authority.
This permits legitimate computation using lower-trust information
without allowing lower-trust sources to expand permissions.
24.7 — PROTECTED ORIGINATING AUTHORITY ENVELOPE
A representative protected authority record may comprise:
PROTECTED_ORIGINATING_AUTHORITY = { task_identifier,
originating_principal, authorized_instruction_set_digest,
permitted_operation_classes, permitted_resources,
permitted_recipients, permitted_data_release_classes,
permitted_tool_classes, conditional_parameter_rules,
cumulative_effect_limits, permitted_delegation_scope,
current_source_authority_generation, current_revocation_state,
designated_effectuation_domains, protected_authentication }
24.7.1 — Original Permission
The protected envelope represents the authority granted by a
qualified principal or protected policy source.
24.7.2 — Computational Flexibility
The model may choose intermediate methods of computation within the
permitted environment.
24.7.3 — Consequential Boundary
A newly proposed consequential operation is compared against the
current source-authorized envelope.
24.7.4 — No Model-Generated Root Authority
Das Expires 29 April 2027 [Page 347]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A model cannot create a valid new root grant merely by generating a
statement that the user authorized the action.
5.5.3.20. Source page 2038 of the original specification
24.8 — INSTRUCTION PROVENANCE RECORD
A protected instruction may be accompanied by:
INSTRUCTION_PROVENANCE_RECORD = { instruction_identifier,
instruction_content_commitment, originating_principal_identity,
authenticated_instruction_channel, qualified_authority_role,
task_scope, authorized_effect_classes, applicable_resource_scope,
current_instruction_generation, relevant_revocation_generation,
protected_instruction_authentication }
24.8.1 — Source Identity
The record identifies the qualified instruction principal.
24.8.2 — Role
The source's permitted authority class is verified.
24.8.3 — Scope
The instruction does not authorize resources or effects beyond its
explicit scope.
24.8.4 — Freshness
The instruction must remain valid under the applicable current
protected conditions.
24.8.5 — Cryptographic Limitation
A signature authenticates an asserted instruction record under the
applicable key assumptions.
It does not independently establish that the signer possesses every
claimed resource permission.
24.9 — TOOL-OUTPUT EVIDENCE ENVELOPE
A tool result may be associated with a protected envelope:
TOOL_OUTPUT_EVIDENCE_ENVELOPE = {
Das Expires 29 April 2027 [Page 348]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.5.3.21. Source page 2039 of the original specification
tool_invocation_identifier, tool_identity, tool_contract_generation,
original_requested_operation, response_content_commitment,
response_origin, source_data_identity, source_data_version,
acquisition_time_or_generation, qualified_evidence_class,
instruction_authority_role, transformation_reference,
current_provenance_generation, protected_output_authentication }
The record may be created by a trusted adapter or protected
acquisition controller.
The output's instruction-authority role may explicitly indicate that
the content is not a source of consequential permission.
A protected tool adapter may authenticate that an output came from a
service.
It must not automatically classify every field in that output as
trusted or authoritative.
24.10 — MIXED-TRUST CONTENT
One source item may contain several kinds of information.
For example, an invoice may include:
An amount;
A date;
A customer identifier;
A recipient address;
Payment instructions;
And free-form notes.
Some fields may be relevant task data.
Some may be subject to additional qualification.
Some free-form instructions may be untrusted.
Das Expires 29 April 2027 [Page 349]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.5.3.22. Source page 2040 of the original specification
A protected schema may classify individual fields or regions by their
supported evidence role.
24.10.1 — Field-Level Qualification
A payment amount may be extracted as data.
24.10.2 — Authority Preservation
The original permitted payment recipient may remain authoritative.
24.10.3 — Untrusted Free Text
A note instructing the agent to transfer funds elsewhere does not
independently expand permission.
24.10.4 — Protected Correspondence
The resulting payment Candidate Act must satisfy current source-
authorized recipient, amount, and resource conditions.
24.11 — PROTECTED DATA-TO-EFFECT RULES
A source authorization may permit selected dynamic parameters to be
derived from lower-trust data.
A representative rule may be:
PROTECTED_DATA_TO_EFFECT_RULE = { authorized_operation_class,
permitted_parameter_field, permitted_input_source_class,
required_input_validation, allowed_value_constraints,
authorized_target_resource, required_current_authority,
qualified_result_use, protected_rule_authentication }
For example:
The originating principal may authorize a payment to a known supplier
for the amount verified from a specified invoice, up to a stated
maximum.
The invoice may supply the amount.
The invoice does not automatically supply unrestricted authority to
change the supplier.
Das Expires 29 April 2027 [Page 350]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.5.3.23. Source page 2041 of the original specification
Another explicitly authorized task may permit selection of a supplier
from a protected approved registry according to a predetermined rule.
In that case, the agent may derive the actual supplier from permitted
qualified data.
The decisive condition is the existing source-authorized rule, not
the model's confidence that the selected supplier is appropriate.
24.12 — DERIVATION-LINEAGE CONTROL
The system may record selected transformations among inputs and
outputs.
A representative structure comprises:
PROTECTED_DERIVATION_LINEAGE = { derivation_identifier,
input_content_references, input_provenance_references,
transformation_component_identity,
transformation_contract_generation, output_content_commitment,
output_evidence_class, declared_or_observed_influence_set,
current_processing_generation, protected_lineage_authentication }
24.12.1 — Direct Transformation
A deterministic parser extracts selected fields.
24.12.2 — Model Transformation
A generative model produces a summary or proposed action.
24.12.3 — Aggregation
Several sources contribute information.
24.12.4 — Agent Handoff
One agent produces data consumed by another.
24.12.5 — Provenance Preservation
The system retains required source references through the
transformation chain.
24.12.6 — Technical Limitation
Das Expires 29 April 2027 [Page 351]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.5.3.24. Source page 2042 of the original specification
A provenance record may identify observed or declared inputs.
For a generative model, it does not necessarily prove an exhaustive
causal explanation of the model's internal computation.
Where exhaustive attribution cannot be established, the finality
mechanism relies upon independent current operation and authority
verification rather than assuming perfect influence tracing.
24.13 — CONSERVATIVE PROVENANCE INFLUENCE
A selected implementation may conservatively associate derived output
with all relevant lower-trust inputs potentially contributing to it.
For example, a report generated from three retrieved documents may
retain lineage references to all three.
The system may use this lineage to identify the source classes
involved.
However, the presence of lower-trust inputs does not automatically
prohibit every downstream operation.
The operation remains eligible when:
The actual effect is independently authorized;
Required data validation passes;
And the relevant source-authority predicates remain valid.
24.13.1 — Overapproximation
A conservative influence set may contain sources that did not
materially affect a particular output.
24.13.2 — Underapproximation
An incomplete instrumentation system may fail to observe a source.
24.13.3 — Actual Protection
A strong claim of prevention of unauthorized resource effects depends
upon actual protected enforcement coverage, not upon an assumption
that provenance or taint tracking perfectly explains model behavior.
Das Expires 29 April 2027 [Page 352]
Internet-Draft Execution-Finality Part 7: Tools October 2026
24.14 — PROTECTED MODEL OUTPUT INERTNESS
5.5.3.25. Source page 2043 of the original specification
A model may generate:
A plan;
A command;
A proposed tool invocation;
A structured API request;
A suggested payment;
A database query;
Or a hardware-control instruction.
The proposed operation may be syntactically valid.
However, it remains a computational proposal until the required
protected authority transition occurs.
24.14.1 — Tool-Call Generation
The model may select a tool and arguments.
24.14.2 — Candidate Act Construction
A protected controller identifies the actual consequential operation.
24.14.3 — Authority Verification
Current source permission is evaluated.
24.14.4 — Finality Verification
The actual resource sink verifies the pending effect.
24.14.5 — Technical Effect
A prompt-injection-induced tool call can be generated yet still fail
to cause an unauthorized protected resource effect.
24.15 — SEMANTIC OPERATION-ENVELOPE CONSTRUCTION
Das Expires 29 April 2027 [Page 353]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A protected semantic translator may construct a material effect
descriptor from a proposed operation.
A representative record comprises:
5.5.3.26. Source page 2044 of the original specification
SEMANTIC_EFFECT_DESCRIPTOR = { candidate_act_identifier,
tool_identity, tool_contract_generation, actual_operation_class,
actual_resource_identity, effective_recipient, material_parameters,
outgoing_content_commitment, potential_child_effect_classes,
current_resource_generation, authorized_source_scope_reference,
designated_finality_sink, protected_descriptor_authentication }
The descriptor may be generated from a protected tool contract,
actual resource operation interface, or qualified combination of
those sources.
The model's self-authored description of what the operation does is
not by itself sufficient where the actual effect can differ.
24.16 — PROTECTED TOOL-SEMANTICS REGISTRY
The system may maintain a registry describing supported tool actions.
PROTECTED_TOOL_CONTRACT = { tool_identity, tool_version,
authorized_effect_classes, argument_schema, material_effect_fields,
expected_resource_sinks, required_validation_modules,
current_contract_generation, current_enforcement_coverage,
protected_contract_authentication }
24.16.1 — Tool Identity
The protected controller authenticates the relevant tool
implementation.
24.16.2 — Operation Semantics
The contract identifies material consequential effects.
24.16.3 — Version Change
5.5.3.27. Source page 2045 of the original specification
A materially changed tool contract may invalidate affected pending
finality enablement.
24.16.4 — Hidden Effects
Das Expires 29 April 2027 [Page 354]
Internet-Draft Execution-Finality Part 7: Tools October 2026
If required effect semantics cannot be established, the corresponding
protected operation remains withheld or is routed through a suitably
qualified resource controller.
24.16.5 — Actual Resource Boundary
The Finality Sink verifies the actual operation rather than relying
solely upon the declared tool description.
24.17 — INSTRUCTION PROVENANCE SEALS
A selected implementation may authenticate an instruction record
using a protected cryptographic seal.
For example:
[ IPS=H(\operatorname{Canon}(I,P,R,G,N)) ]
(I) identifies the instruction content;
(P) identifies its claimed protected principal;
(R) identifies its authority role;
(G) identifies the applicable authority generation;
And (N) identifies selected task or context binding.
The seal may be authenticated using a digital signature, MAC, or
protected authority registry.
24.17.1 — Purpose
The seal assists the system in detecting unauthorized modification or
substitution of selected instruction records.
24.17.2 — Authority Check
A protected verifier separately confirms that the claimed principal
actually possesses the required role and source authority.
24.17.3 — Lower-Trust Signed Content
5.5.3.28. Source page 2046 of the original specification
A signed lower-trust document does not become a privileged
instruction merely because its bytes are authenticated.
Das Expires 29 April 2027 [Page 355]
Internet-Draft Execution-Finality Part 7: Tools October 2026
24.17.4 — Non-Limiting Use
Instruction provenance seals may be omitted where an equivalent
protected authority-state mechanism supplies the necessary
properties.
24.18 — MODEL, PROMPT, AND TOOL GENERATIONS
A selected implementation may associate evidence with:
The model or algorithm generation;
The applicable system-instruction generation;
The tool-contract generation;
The source-authority generation;
And the relevant resource generation.
24.18.1 — Material Computational Change
A model or tool change may trigger revalidation when the applicable
policy requires it.
24.18.2 — No Universal Model Pinning
Not every operation requires one fixed model version.
24.18.3 — Authority Independence
A model update cannot independently create new resource authority.
24.18.4 — Protected Continuation
A task may continue across model changes provided that current
required effectuation authority is independently established.
24.19 — CONTEXT-WINDOW LOSS
An agent may process more information than fits within its current
model context.
Earlier instructions may be summarized or omitted.
The model may cease to represent the original source-authority
conditions accurately.
Das Expires 29 April 2027 [Page 356]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.5.3.29. Source page 2047 of the original specification
A principal implementation does not rely on the model remembering
those conditions.
The current protected authority remains in an independent controller.
Before consequential effectuation, the protected controller checks
the actual operation against that authoritative state.
24.19.1 — Technical Effect
Loss of original instructions from the model's context does not by
itself expand the permitted actual resource effects.
24.20 — RETRIEVAL-INDEX PROVENANCE
A retrieval system may store documents or vectors for later use.
The corresponding provenance may identify:
Original source;
Original acquisition event;
Relevant document identity;
Current document or index generation;
Permitted data role;
And selected retrieval transformation.
24.20.1 — Indexed Content
An indexed record remains data unless separately qualified as an
authority source.
24.20.2 — Ranking
A high-ranked result is not necessarily more authoritative.
24.20.3 — Embedding Similarity
Similarity of vector representations does not establish permission.
24.20.4 — Retrieved Instruction
Das Expires 29 April 2027 [Page 357]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An instruction embedded in retrieved data cannot independently grant
consequential authority.
24.20.5 — Index Mutation
5.5.3.30. Source page 2048 of the original specification
A material index update may affect provenance or freshness
requirements but does not itself create new source authorization.
24.21 — MULTIMODAL PROVENANCE
The same authority boundary may apply to text, audio, images, and
video.
Examples include:
Text hidden in an image;
A spoken instruction in an audio recording;
An instruction in subtitles;
A visual prompt embedded in a webpage;
A machine-readable code embedded in a document image;
Or metadata interpreted by a multimodal model.
A protected input controller may record the acquisition source and
qualified representation.
The computational model may interpret the content.
However, no modality automatically confers permission to perform a
consequential operation.
24.21.1 — Voice Authority
A voice command from an authenticated principal may constitute
authority under a suitably qualified confirmation process.
24.21.2 — Recorded Voice Data
A retrieved recording containing a command is not automatically an
authenticated instruction from that principal.
24.21.3 — Displayed Text
Das Expires 29 April 2027 [Page 358]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Text displayed in a webpage does not automatically constitute the
task owner's current instruction.
24.21.4 — Technical Enforcement
The actual effectuation boundary verifies source permission
independently of modality.
5.5.3.31. Source page 2049 of the original specification
24.22 — CROSS-AGENT INSTRUCTION HANDOFF
A multi-agent system may distribute computation among several agents.
One agent may retrieve a document.
Another may summarize it.
A third may formulate an operation.
The resulting Candidate Act may be based on several intermediate
messages.
A protected handoff record may comprise:
PROTECTED_AGENT_HANDOFF = { parent_task_identifier,
sending_agent_identity, receiving_agent_identity,
delegated_authority_reference, message_content_commitment,
preserved_provenance_references, permitted_downstream_effect_classes,
current_delegation_generation, protected_handoff_authentication }
An authenticated handoff proves selected message origin properties.
It does not independently enlarge the receiving agent's consequential
authority.
A receiving agent cannot validly promote untrusted source
instructions merely because they were repeated by an authorized
computational worker.
24.23 — SOURCE-AUTHORITY CORRESPONDENCE
A protected validator evaluates whether the actual proposed operation
is permitted under the originating source authority.
A representative predicate may be:
Das Expires 29 April 2027 [Page 359]
Internet-Draft Execution-Finality Part 7: Tools October 2026
[ \operatorname{Authorized}(CA)= \operatorname{SourceCurrent}(CA)
\land \operatorname{EffectWithinScope}(CA) \land
\operatorname{RequiredDataQualified}(CA) \land
5.5.3.32. Source page 2050 of the original specification
\operatorname{ResourceCurrent}(CA) ]
The exact predicate depends upon the resource operation.
Where source data is required to determine an operation parameter,
the validator checks the relevant data-to-effect rule.
Where the source data is merely informational and does not form an
authority prerequisite, the corresponding provenance check may be
optional.
The validator does not require every ordinary computational influence
to be exhaustively reconstructed.
It requires sufficient protected evidence for the predicates actually
asserted by the selected operation.
24.24 — INDEPENDENT SEMANTIC BOUNDARY VALIDATION
A Semantic Boundary Validator may evaluate:
The intended actual effect;
The tool's relevant semantics;
The resource identity;
The recipient;
The operation parameters;
The original source authority;
The current delegated scope;
And the protected data-to-effect constraints.
24.24.1 — Deterministic Predicates
Where possible, protected validation uses deterministic comparisons
over typed operation fields.
Das Expires 29 April 2027 [Page 360]
Internet-Draft Execution-Finality Part 7: Tools October 2026
24.24.2 — Qualified External Facts
An authoritative resource service may provide current identity or
version evidence.
24.24.3 — Model-Assisted Classification
5.5.3.33. Source page 2051 of the original specification
A model may assist in identifying possible effect classes.
Its output does not replace mandatory protected source-authority
verification.
24.24.4 — Semantic Uncertainty
If an operation's required consequential semantics cannot be
established, the effect remains withheld or receives further
protected qualification.
24.25 — PROTECTED CROSS-COMMITMENT
A protected collection-time instance may commit relevant provenance
and Candidate Act evidence.
An independent execution-time validator may commit the current actual
operation and source-authority evidence.
A non-limiting structure comprises:
[ C_P=H(\operatorname{Canon}(CA,P,D)) ]
[ C_E=H(\operatorname{Canon}(CA,O,A,C_P)) ]
[ C_F=H(\operatorname{Canon}(C_P,C_E,S,G)) ]
(CA) is the Candidate Act;
(P) is qualified provenance evidence;
(D) is the permitted data-to-effect relation;
(O) is execution-time operation evidence;
(A) is current protected source authority;
(S) is the designated Finality Sink;
Das Expires 29 April 2027 [Page 361]
Internet-Draft Execution-Finality Part 7: Tools October 2026
And (G) is relevant protected generation state.
The exact cryptographic construction is illustrative.
5.5.3.34. Source page 2052 of the original specification
A protected hash commitment does not independently establish the
factual correctness of unqualified input.
24.26 — NON-BEARER FINALITY ENABLEMENT
A representative authority record may comprise:
PROVENANCE_BOUND_FINALITY_ENABLEMENT = { candidate_act_digest,
originating_source_authority, instruction_authority_generation,
required_provenance_commitment, selected_data_to_effect_rule,
actual_effect_descriptor, independent_validation_commitment,
relevant_tool_contract_generation, current_resource_generation,
current_revocation_generation, designated_finality_sink,
permitted_use_count, sink_local_consumption_reference,
protected_finality_authentication }
The agent may receive an inert finality reference.
The reference does not confer unrestricted resource authority merely
through possession.
The actual sink verifies the current protected record and operation.
24.27 — ACTUAL FINALITY-SINK ENFORCEMENT
The actual Finality Sink may be:
A database transaction controller;
A file-mutation service;
A network data-release gateway;
A credential broker;
A payment processor;
An authenticated application resource;
Das Expires 29 April 2027 [Page 362]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.5.3.35. Source page 2053 of the original specification
A hardware command controller;
Or another consequential resource boundary.
The sink independently reconstructs the actual pending operation.
It verifies:
Current originating authority;
Current operation effect class;
Actual resource identity;
Actual recipient or destination;
Material operation parameters;
Applicable data-derived parameter constraints;
Current resource and revocation state;
Required protected finality enablement;
And sink-local protected consumption.
The sink does not need to determine which exact model token caused
the proposal.
It needs to establish whether the actual effect has valid protected
authority.
24.28 — ATTACK CONTAINMENT WITHOUT PERFECT PROMPT-INJECTION DETECTION
A significant implementation variation does not require the protected
system to perfectly identify every malicious instruction within
retrieved content.
An attacker may succeed in causing the model to propose an
unauthorized operation.
The operation remains non-effective.
The independent validator and Finality Sink reject the effect where
it exceeds original source permission.
Das Expires 29 April 2027 [Page 363]
Internet-Draft Execution-Finality Part 7: Tools October 2026
24.28.1 — Technical Assurance Boundary
This containment is effective only for consequential operations
actually mediated by the protected enforcement path.
5.5.3.36. Source page 2054 of the original specification
24.28.2 — Uncontrolled Effects
If an agent possesses another unrestricted ability to disclose data
or modify resources, the claimed enforcement may be bypassed.
24.28.3 — Permitted Wrong Decisions
A valid original authorization may still permit an undesirable
decision resulting from incorrect data.
The architecture does not universally guarantee truthfulness, optimal
decisions, or freedom from all prompt influence.
24.28.4 — Candidate Technical Effect
The system reduces dependence upon perfect linguistic detection for
preventing specified unauthorized protected resource effects.
24.29 — PROTECTED SCOPE-DEVIATION INTEGRATION
A lower-trust source may cause an agent to propose a new resource,
recipient, or operation class.
The protected validator compares the actual proposed effect with the
originating authorization.
Where the difference exceeds valid existing scope, a protected scope-
deviation controller may activate a latch under CW-3.
A protected adjudicator may determine:
Whether the apparent difference is harmless;
Whether a valid original rule already permits the operation;
Whether new authority is required;
Or whether a mandatory security condition fails.
An agent-generated justification does not independently clear the
protected latch.
Das Expires 29 April 2027 [Page 364]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A valid new scope authorization remains bounded to the permitted
actual effect.
24.30 — CREDENTIAL AND TOOL-AUTHORITY INTEGRATION
A computational model may propose use of a credentialed tool.
5.5.3.37. Source page 2055 of the original specification
The protected credential broker may verify the actual pending request
under Embodiment 23.
The presence of a valid credential or authenticated session does not
independently make the model's proposed effect authorized.
The finality controller may require:
Current original source authority;
Actual resource correspondence;
Valid credential scope;
Applicable provenance-qualified operation parameters;
And protected non-bearer consumption.
A malicious tool response cannot create new credential-use authority
merely by instructing the agent to invoke the broker.
24.31 — CAUSAL WORKFLOW INTEGRATION
A tool response may claim that an earlier consequential operation
completed.
A later workflow stage may be conditioned upon that earlier real
effect.
Where CW-2 Mode B applies, the successor requires the specified IEV-
accepted qualified actual-effect receipt.
An ordinary tool success string, model-generated report, or
unqualified event message does not substitute for the required VAER.
The successor also remains subject to its own current source
authority and Finality-Sink verification.
24.32 — PROTECTED INSTRUCTION-AUTHORITY INVARIANT
Das Expires 29 April 2027 [Page 365]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A candidate implementation may maintain the invariant:
[ \operatorname{EffectAuthority}(CA) \subseteq
\operatorname{CurrentSourceAuthority}(CA) ]
subject to any expressly established new valid source grant.
5.5.3.38. Source page 2056 of the original specification
Intermediate informational transformations cannot independently
enlarge the protected consequential authority set.
An agent may derive new operation parameters under authorized rules.
It may not derive a new root permission merely from informational
content.
The actual sink checks the permitted effect, rather than assuming the
invariant holds because the model was instructed to respect it.
24.33 — PROVENANCE GRAPH AND RESOURCE-EFFECT LINKAGE
A representative protected relationship is:
SOURCE AUTHORITY A | v AUTHORIZED TASK T | +-------------------+ | |
v v DATA SOURCE D1 TOOL RESULT D2 | | +---------+---------+ | v MODEL
TRANSFORMATION M | v PROPOSED OPERATION O | v CANDIDATE ACT CA | v
SOURCE AUTHORITY VALIDATION | v FINALITY-SINK AUTHORIZATION | v
ACTUAL RESOURCE EFFECT
The data inputs may legitimately influence the proposed operation.
Only valid source authority and the required protected predicates
enable consequential release.
5.5.3.39. Source page 2057 of the original specification
The diagram is non-limiting.
24.34 — REFERENCE ALGORITHM: QUALIFIED INPUT ACQUISITION
FUNCTION ACQUIRE_QUALIFIED_INPUT( source_reference,
protected_acquisition_controller ): source =
protected_acquisition_controller
.RESOLVE_INPUT_SOURCE(source_reference) observed =
protected_acquisition_controller .OBTAIN_CONTENT(source) provenance =
protected_acquisition_controller .AUTHENTICATE_SUPPORTED_PROPERTIES({
source_identity: source.identity, source_role:
Das Expires 29 April 2027 [Page 366]
Internet-Draft Execution-Finality Part 7: Tools October 2026
QUALIFY_SOURCE_ROLE(source), content_commitment:
HASH(observed.content), source_version: observed.version,
acquisition_context: observed.context, authority_class:
RESOLVE_PROTECTED_AUTHORITY_CLASS(source) }) RETURN { content:
observed.content, provenance: provenance }
A source-authentication result is not automatically a grant of
instruction authority.
24.35 — REFERENCE ALGORITHM: DERIVATION-LINEAGE PRESERVATION
FUNCTION RECORD_DERIVED_MODEL_OUTPUT( input_records,
5.5.3.40. Source page 2058 of the original specification
model_output, transformation_context, protected_lineage_controller ):
REQUIRE VERIFY_RELEVANT_INPUT_REFERENCES( input_records )
influence_set = COMPUTE_CONSERVATIVE_OBSERVED_INPUT_SET(
input_records ) lineage = protected_lineage_controller
.COMMIT_DERIVATION({ inputs: HASH_REFERENCES(input_records),
transformation: HASH(transformation_context), output:
HASH(model_output), influence_set: influence_set,
claimed_evidence_role: CLASSIFY_OUTPUT_EVIDENCE_ROLE() }) RETURN {
model_output: model_output, protected_lineage: lineage }
The result preserves qualified lineage evidence without claiming
exhaustive proof of the model's internal causal reasoning.
24.36 — REFERENCE ALGORITHM: DATA-TO-AUTHORITY SEPARATION
FUNCTION CLASSIFY_PROPOSED_INSTRUCTION( proposed_instruction,
source_provenance, protected_authority_controller ): source_role =
5.5.3.41. Source page 2059 of the original specification
protected_authority_controller .RESOLVE_QUALIFIED_SOURCE_ROLE(
source_provenance ) IF source_role == AUTHORIZED_INSTRUCTION_SOURCE:
REQUIRE VERIFY_CURRENT_SOURCE_AUTHORITY( proposed_instruction )
RETURN AUTHORITY_ELIGIBLE_FOR_SCOPE_VALIDATION IF source_role ==
INFORMATIONAL_DATA_SOURCE: IF CONTAINS_CONSEQUENTIAL_ACTION_PROPOSAL(
proposed_instruction ): RETURN UNAUTHORIZED_INSTRUCTION_CLAIM RETURN
QUALIFIED_INFORMATIONAL_CONTENT IF source_role == MIXED_OR_UNKNOWN:
RETURN REQUIRE_INDEPENDENT_AUTHORITY_RESOLUTION RETURN
NO_INSTRUCTION_AUTHORITY
A classifier that fails to detect an instruction attempt does not
automatically cause consequential authorization because the actual
operation remains subject to separate finality verification.
Das Expires 29 April 2027 [Page 367]
Internet-Draft Execution-Finality Part 7: Tools October 2026
24.37 — REFERENCE ALGORITHM: SEMANTIC CANDIDATE ACT
FUNCTION CONSTRUCT_PROVENANCE_BOUND_CANDIDATE( proposed_tool_call,
provenance_context, protected_tool_controller ): contract =
protected_tool_controller .LOAD_CURRENT_AUTHENTICATED_TOOL_CONTRACT(
proposed_tool_call.tool ) REQUIRE VERIFY_TOOL_CONTRACT(contract)
material_effect = protected_tool_controller
5.5.3.42. Source page 2060 of the original specification
.RESOLVE_PROPOSED_EFFECT( proposed_tool_call, contract ) IF
material_effect == UNKNOWN: RETURN HOLD candidate =
protected_tool_controller .BUILD_CANDIDATE_ACT({ operation:
material_effect, provenance: HASH(provenance_context),
tool_contract_generation: contract.generation, originating_authority:
CURRENT_SOURCE_AUTHORITY_REFERENCE(), designated_finality_sink:
contract.required_effectuation_sink }) REQUIRE
VERIFY_CANDIDATE_WITHIN_SOURCE_SCOPE( candidate ) RETURN
PROTECTED_CANDIDATE_REFERENCE( candidate )
The actual Finality Sink later reconstructs and verifies the
operation actually presented for effectuation.
24.38 — REFERENCE ALGORITHM: INDEPENDENT SEMANTIC VALIDATION
FUNCTION VALIDATE_PROPOSED_CONSEQUENCE( candidate_act,
protected_semantic_validator ): source_authority =
LOAD_CURRENT_ORIGINATING_AUTHORITY() actual_effect_descriptor =
RECONSTRUCT_QUALIFIED_OPERATION_SEMANTICS(
5.5.3.43. Source page 2061 of the original specification
candidate_act ) REQUIRE actual_effect_descriptor IS
SUFFICIENTLY_DEFINED REQUIRE VERIFY_CURRENT_SOURCE_AUTHORITY(
source_authority ) REQUIRE
VERIFY_ACTUAL_EFFECT_WITHIN_AUTHORIZED_SCOPE(
actual_effect_descriptor, source_authority ) REQUIRE
VERIFY_REQUIRED_DATA_TO_EFFECT_RULES( candidate_act ) REQUIRE
VERIFY_CURRENT_RESOURCE_IDENTITY() REQUIRE
VERIFY_CURRENT_TOOL_CONTRACT_GENERATION() REQUIRE
VERIFY_CURRENT_REVOCATION() RETURN PROTECTED_VALIDATION_COMMITMENT({
candidate: HASH(candidate_act), effect:
HASH(actual_effect_descriptor), source_authority:
HASH(source_authority), required_provenance:
COMMIT_RELEVANT_PROVENANCE_EVIDENCE() })
Das Expires 29 April 2027 [Page 368]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The validator must derive the relevant protected predicates from an
appropriately trusted source rather than accept arbitrary policy
fields supplied by the model.
24.39 — REFERENCE ALGORITHM: FINALITY SINK
FUNCTION EFFECTUATE_PROVENANCE_BOUND_OPERATION( candidate_act,
finality_enablement, actual_finality_sink ):
5.5.3.44. Source page 2062 of the original specification
actual_operation = actual_finality_sink
.RECONSTRUCT_PENDING_OPERATION() REQUIRE
VERIFY_ACTUAL_RESOURCE_IDENTITY( actual_operation ) REQUIRE
VERIFY_CURRENT_SOURCE_AUTHORITY() REQUIRE
VERIFY_EFFECT_WITHIN_AUTHORIZED_ENVELOPE( candidate_act,
actual_operation ) REQUIRE
VERIFY_REQUIRED_DATA_TO_EFFECT_PREDICATES() REQUIRE
VERIFY_CURRENT_TOOL_AND_OPERATION_SEMANTICS() REQUIRE
VERIFY_CURRENT_REVOCATION_AND_RESOURCE_STATE() REQUIRE
VERIFY_NON_BEARER_FINALITY( finality_enablement, actual_operation )
REQUIRE VERIFY_SINK_LOCAL_PROTECTED_CONSUMPTION() committed =
actual_finality_sink .ATOMIC_CONSUME_FINALITY( finality_enablement,
actual_operation ) IF committed != COMMITTED: RETURN DENY RETURN
actual_finality_sink .RELEASE_ACTUAL_CONSEQUENCE( actual_operation )
Where the consequence is external to the local protected transaction,
separate controlled dispatch and qualified outcome reconciliation
apply.
24.40 — REFERENCE ALGORITHM: TOOL-CONTRACT CHANGE
FUNCTION HANDLE_TOOL_SEMANTIC_CHANGE( pending_candidate,
5.5.3.45. Source page 2063 of the original specification
previous_contract, current_contract, protected_controller ): REQUIRE
VERIFY_AUTHENTICATED_TOOL_CONTRACT( current_contract ) difference =
COMPARE_MATERIAL_TOOL_EFFECT_SEMANTICS( previous_contract,
current_contract ) IF difference == NON_MATERIAL: RETURN
REQUIRE_CURRENT_SINK_VALIDATION INVALIDATE_AFFECTED_PENDING_FINALITY(
pending_candidate ) IF CURRENT_EFFECT_EXCEEDS_SOURCE_AUTHORITY():
RETURN REQUIRE_NEW_SOURCE_AUTHORITY RETURN
REQUIRE_INDEPENDENT_CURRENT_VALIDATION
A tool's unchanged name does not establish unchanged consequential
effect semantics.
Das Expires 29 April 2027 [Page 369]
Internet-Draft Execution-Finality Part 7: Tools October 2026
24.41 — REFERENCE ALGORITHM: CROSS-AGENT PROVENANCE HANDOFF
FUNCTION VERIFY_AGENT_HANDOFF( received_message,
receiving_agent_context, protected_handoff_controller ): REQUIRE
VERIFY_SENDING_AGENT_IDENTITY( received_message ) REQUIRE
VERIFY_HANDOFF_MESSAGE_AUTHENTICITY( received_message ) REQUIRE
VERIFY_ORIGINAL_TASK_BINDING( received_message )
5.5.3.46. Source page 2064 of the original specification
REQUIRE VERIFY_CURRENT_DELEGATED_AUTHORITY( receiving_agent_context )
PRESERVE_QUALIFIED_INPUT_PROVENANCE( received_message.provenance ) IF
MESSAGE_PROPOSES_CONSEQUENTIAL_EFFECT( received_message ): RETURN
CONSTRUCT_NEW_CANDIDATE_ACT_UNDER_CURRENT_SCOPE() RETURN
ACCEPT_INFORMATIONAL_HANDOFF()
A signed inter-agent message does not become independent source
authority merely because the sender was authenticated.
24.42 — WORKED EXAMPLE A: MALICIOUS WEBPAGE
An autonomous agent is authorized to research information concerning
a selected product.
The agent retrieves a webpage.
The webpage contains legitimate product information and text
instructing the agent to export private files.
The retrieved content is classified as lower-trust informational
data.
The model may generate an unauthorized export proposal.
The protected controller constructs the resulting Candidate Act.
The original source authority does not permit the proposed
disclosure.
The data-release Finality Sink refuses the operation.
Expected demonstrable result: A successful prompt-injection influence
over model output does not automatically produce an unauthorized
protected file disclosure.
24.43 — WORKED EXAMPLE B: INVOICE RECIPIENT SUBSTITUTION
An agent is authorized to process a payment to a designated supplier.
Das Expires 29 April 2027 [Page 370]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.5.3.47. Source page 2065 of the original specification
The invoice contains the legitimate payment amount but also an
instruction to transfer the money to another account.
The data-to-effect rule permits extraction of the invoice amount
within a bounded limit.
The recipient remains constrained by the original source authority or
another expressly permitted verified recipient-selection rule.
The proposed payment to the substituted recipient is rejected at the
actual payment sink.
Expected demonstrable result: Legitimate extraction of a transaction
parameter does not promote unrelated source text into payment-
destination authority.
24.44 — WORKED EXAMPLE C: AUTHENTICATED TOOL RESPONSE CONTAINING
UNTRUSTED TEXT
A protected search adapter returns an authenticated response from a
remote service.
The response contains user-generated webpage content.
The tool adapter's authentication establishes selected source and
transport properties.
It does not establish that the webpage content is a protected
instruction from the originating task owner.
The agent attempts an unauthorized consequential operation based on
the content.
The operation lacks valid source authority.
Expected demonstrable result: Authentication of the tool wrapper does
not automatically grant instruction authority to lower-trust content
inside the response.
24.45 — WORKED EXAMPLE D: MULTI-AGENT SUMMARY LAUNDERING
Agent A retrieves an untrusted document.
The document contains instructions directing disclosure of
confidential material.
Das Expires 29 April 2027 [Page 371]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Agent A summarizes the document.
Agent B receives the summary and prepares a resource export.
The protected handoff preserves relevant provenance references.
Agent B's identity and the summary's authenticity do not create
permission for the export.
5.5.3.48. Source page 2066 of the original specification
The actual data-release sink verifies current source authority and
refuses the unauthorized consequence.
Expected demonstrable result: Rewriting an injected instruction
through another agent does not independently constitute new resource
permission.
24.46 — WORKED EXAMPLE E: STRUCTURED FUNCTION CALL
A model produces a syntactically valid tool call.
The tool call requests deletion of a protected database record
outside the authorized task.
The schema validator accepts the call's syntax.
The protected operation validator evaluates the actual resource and
effect scope.
The deletion is unauthorized.
No valid finality enablement is established.
Expected demonstrable result: A valid structured output format is not
equivalent to valid consequential authority.
24.47 — WORKED EXAMPLE F: TOOL CONTRACT CHANGES
An agent prepares an operation using a tool whose earlier contract
describes a read-only lookup.
The tool implementation is updated to include a persistent mutation.
The protected tool-contract generation changes.
The old Candidate Act cannot automatically authorize the new
consequential operation.
Das Expires 29 April 2027 [Page 372]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The operation is reclassified and revalidated.
Expected demonstrable result: A stable tool name or schema does not
silently preserve operation-specific authority when the actual tool
effect changes.
24.48 — WORKED EXAMPLE G: MULTIMODAL INSTRUCTION
An autonomous assistant processes an image containing ordinary task
information and embedded text directing it to change a security
setting.
5.5.3.49. Source page 2067 of the original specification
The model interprets the image and proposes the configuration change.
The image provenance does not establish authorization to modify the
protected setting.
The actual configuration Finality Sink verifies the original source-
authorized effect envelope.
The operation is refused.
Expected demonstrable result: An instruction embedded in a different
input modality cannot independently create consequential authority.
24.49 — WORKED EXAMPLE H: AUDIO TRANSCRIPT AUTHORITY CONFUSION
A model processes a retrieved audio recording containing a spoken
instruction to send confidential information.
The recording originates from a third-party archive.
The transcript is qualified as content derived from that archive.
It is not treated as an authenticated current instruction from the
task principal.
A proposed disclosure lacks source authority and is refused.
Expected demonstrable result: The presence of recognizable spoken
instructions does not automatically establish current principal
authorization.
24.50 — WORKED EXAMPLE I: REPOSITORY COMMENT INJECTION
Das Expires 29 April 2027 [Page 373]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An autonomous development agent is authorized to inspect code and
prepare a bounded change.
A repository comment instructs the agent to execute a privileged
command unrelated to the task.
The comment is treated as repository content.
The proposed privileged command is separately classified as a
consequential Candidate Act.
The current original task scope does not permit it.
The protected operating-system or privileged-service sink refuses the
effect.
Expected demonstrable result: Repository text can contribute to
analysis without becoming privileged command authority.
5.5.3.50. Source page 2068 of the original specification
24.51 — WORKED EXAMPLE J: RETRIEVAL INDEX CONTAMINATION
An attacker inserts a document into a retrieval index.
The document is selected as relevant to an agent's task.
Its content causes the agent to propose a payment to an unauthorized
account.
The protected provenance registry identifies the document as an
informational retrieval source.
The payment Candidate Act is checked against independent source
authority.
The account mismatch is refused at the payment sink.
Expected demonstrable result: High retrieval rank or semantic
similarity does not establish payment authority.
24.52 — WORKED EXAMPLE K: CONTEXT WINDOW TRUNCATION
An agent receives an original instruction limiting file operations to
a specified workspace.
The task becomes long.
Das Expires 29 April 2027 [Page 374]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The model's current context no longer includes the original resource
restriction.
The agent proposes modification of another directory.
The protected authority store still contains the original task
restrictions.
The actual file-operation sink rejects the unauthorized target.
Expected demonstrable result: Loss of original constraints from the
computational context does not remove actual resource-side finality
enforcement.
24.53 — WORKED EXAMPLE L: VALID FACT, INVALID ACTION
A retrieved service reports a correct infrastructure configuration
error.
The agent proposes correcting the error by disabling a broader
security control outside its authorization.
The observation may be a valid technical fact.
5.5.3.51. Source page 2069 of the original specification
However, the proposed remediation is a new consequential operation
requiring its own authority.
The protected configuration sink refuses the unauthorized change.
Expected demonstrable result: A true external fact does not
automatically authorize every remedial action proposed in response.
24.54 — WORKED EXAMPLE M: PROTECTED AUTOMATED PARAMETER DERIVATION
An originating principal authorizes an agent to create a storage
object within a designated workspace using a filename derived from a
validated task identifier.
The task identifier is obtained from qualified lower-trust data.
The protected data-to-effect rule permits that identifier to populate
the filename field under defined constraints.
The actual storage sink verifies the resulting resource identity and
authorized workspace.
Das Expires 29 April 2027 [Page 375]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The operation proceeds when current finality conditions pass.
Expected demonstrable result: Lower-trust data can legitimately
determine operation parameters under a preexisting authorized rule
without being granted independent instruction authority.
24.55 — WORKED EXAMPLE N: CREDENTIAL BROKER ATTEMPT
An agent reads an untrusted document instructing it to use an
authenticated enterprise tool to export confidential information.
The model prepares a credential-dependent tool invocation.
The credential broker possesses a valid enterprise credential.
The protected finality controller identifies the actual requested
disclosure.
The original task does not authorize that disclosure.
The broker refuses credential exercise for the proposed operation.
Expected demonstrable result: Access to a credentialed tool does not
allow lower-trust document content to create unrestricted
consequential permission.
5.5.3.52. Source page 2070 of the original specification
24.56 — WORKED EXAMPLE O: FALSE PRIOR COMPLETION CLAIM
A retrieved tool response claims that a required payment has already
completed.
A later accounting workflow is configured under CW-2 Mode B to
require an accepted actual-payment receipt.
The text claim is not an IEV-accepted real-effect receipt.
The protected continuation controller withholds the dependent
accounting mutation.
Expected demonstrable result: Computational content claiming that a
real effect occurred cannot substitute for mandatory qualified
actual-effect evidence.
24.57 — WORKED EXAMPLE P: FALSE AUTHORITY CLAIM FROM ANOTHER AGENT
Das Expires 29 April 2027 [Page 376]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Agent A sends Agent B a signed message claiming that an administrator
approved a new data recipient.
The signed message authenticates Agent A as sender.
However, Agent A lacks authority to issue the claimed administrator
approval.
The protected receiving controller verifies the original source
grant.
The proposed recipient is outside permitted scope.
The disclosure is refused.
Expected demonstrable result: Authenticated agent identity does not
automatically establish authority to delegate permissions the sender
does not possess.
24.58 — WORKED EXAMPLE Q: SCOPE EXPANSION WITH VALID REAUTHORIZATION
An agent retrieves data suggesting that a new protected resource must
be accessed.
The original source authorization does not cover that resource.
The protected scope-deviation controller withholds the proposed
operation.
A qualified approving principal may establish a new bounded scope
under CW-3.
The actual sink subsequently verifies the new authority and
operation-specific finality.
5.5.3.53. Source page 2071 of the original specification
Expected demonstrable result: A lower-trust source may motivate an
authorized scope-extension request without independently authorizing
the extension itself.
24.59 — WORKED EXAMPLE R: SIGNED DOCUMENT WITH MALICIOUS INSTRUCTIONS
An enterprise document is cryptographically signed by an
authenticated document service.
Its content includes a third-party instruction to change a protected
recipient or credential.
Das Expires 29 April 2027 [Page 377]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The system verifies the document signature.
It classifies the signed document as source content under its
qualified role.
The signature does not independently establish that the document
service may authorize the proposed new consequence.
The actual effect remains subject to original task authority.
Expected demonstrable result: Cryptographic integrity of
informational content does not become unrestricted instruction
authority.
24.60 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
1. Direct prompt injection. 2. Indirect webpage injection. 3.
Retrieved document injection. 4. Email attachment injection. 5.
Repository comment injection. 6. API response injection. 7. Search-
result instruction laundering. 8. Vector-index poisoning. 9. Hidden
image instruction. 10. Audio instruction substitution. 11. Video
subtitle injection. 12. Unicode-obfuscated instruction. 13. Encoded
or fragmented payload. 14. Split payload across multiple documents.
15. Model-generated false approval. 16. Signed lower-trust
malicious content. 17. Tool-wrapper authentication confusion. 18.
Tool-output authority promotion. 19. Summary laundering. 20. Cross-
agent instruction laundering. 21. Tool-schema change. 22. Tool
implementation change.
5.5.3.54. Source page 2072 of the original specification
23. Untrusted tool-description mutation. 24. Resource-recipient
substitution. 25. Data-to-effect parameter manipulation. 26.
Credential-broker confused deputy. 27. Function-call schema validity
mistaken for authorization. 28. Agent-to-agent message
authentication mistaken for delegation. 29. Context-window
truncation. 30. Stale source-authority generation. 31. Revoked
permission after retrieval. 32. Retrieved document replacement. 33.
Alias or resource rebinding. 34. Model upgrade with materially
changed operation interpretation. 35. False prior-effect receipt.
36. Replay of computational evidence. 37. Unqualified provenance
issuer. 38. Provenance graph omission. 39. Forged provenance edge.
40. Overclaim of causal attribution. 41. Hidden downstream side
effect. 42. Actual tool operation differs from declared contract.
43. Unauthorized new tool selection. 44. Cross-domain authorization
confusion. 45. Malicious requested security-policy change. 46. Data
disclosure to an injected recipient. 47. Unauthorized payment
operation. 48. Unauthorized file deletion. 49. Unauthorized
Das Expires 29 April 2027 [Page 378]
Internet-Draft Execution-Finality Part 7: Tools October 2026
persistent vector-database commit. 50. Uncontrolled alternate
execution route. 51. Protected enforcement service compromise. 52.
Protected Finality Sink compromise. 53. Excessive provenance
verification work. 54. Provenance graph cycle. 55. Unauthorized
scope extension. 56. Human approval bound to the wrong actual
effect. 57. Resource version change after data collection. 58.
Incorrect confidence-based elevation of content. 59. Model-derived
instruction presented as original principal text. 60. Successful
model injection mistakenly classified as proof of resource
compromise.
The implementation must distinguish between attack influence on model
behavior and actual unauthorized effects caused through protected
resources.
24.61 — PROPOSED FEASIBILITY AND ADVERSARIAL EXPERIMENTS
The following experiments are proposed demonstrations and are not
represented as completed results.
Test 1 — Protected Source Authority: Establish a valid originating
effect envelope.
5.5.3.55. Source page 2073 of the original specification
Test 2 — Authenticated Instruction: Verify a qualified principal
instruction record.
Test 3 — Data Provenance: Record authenticated source references for
retrieved material.
Test 4 — Role Classification: Distinguish permitted instruction
sources from informational content.
Test 5 — Authenticated Tool Wrapper: Verify source authentication
without promoting all response content to instruction authority.
Test 6 — Mixed-Trust Document: Extract legitimate fields while
rejecting unauthorized instruction authority.
Test 7 — Valid Parameter Derivation: Use data to populate a source-
authorized operation field.
Test 8 — Invalid Parameter Derivation: Attempt a prohibited recipient
substitution.
Test 9 — Retrieved Webpage Injection: Cause the model to propose an
unauthorized export.
Das Expires 29 April 2027 [Page 379]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Test 10 — Actual Sink Rejection: Verify that the export is refused
despite model compliance with the injected text.
Test 11 — Search Result Injection: Insert an instruction into a
retrieved result.
Test 12 — Repository Injection: Insert an unauthorized command
request into source documentation.
Test 13 — Email Injection: Submit an external message falsely
claiming task authority.
Test 14 — Invoice Redirection: Attempt to change a payment
destination through informational content.
Test 15 — Structured Tool Call: Generate syntactically valid but
unauthorized arguments.
Test 16 — Schema Validation: Demonstrate that schema validity alone
does not release the effect.
Test 17 — Semantic Validation: Verify operation-specific effect
scope.
Test 18 — Tool Contract Generation: Bind a Candidate Act to the
relevant tool version.
Test 19 — Tool Semantic Drift: Change a tool's actual consequential
operation.
Test 20 — Hidden Tool Effect: Attempt an undeclared additional
resource mutation.
Test 21 — Source-Authority Generation: Revoke originating permission
after data collection.
5.5.3.56. Source page 2074 of the original specification
Test 22 — Context Truncation: Omit original instructions from the
model context.
Test 23 — Protected Authority Persistence: Verify that the actual
sink still enforces the original permission.
Test 24 — Derivation Record: Record input and output references for a
model transformation.
Das Expires 29 April 2027 [Page 380]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Test 25 — Summary Laundering: Transform an injected instruction into
a generated summary.
Test 26 — Cross-Agent Handoff: Pass the summary to another agent.
Test 27 — Delegation Authority: Refuse an effect not authorized
through the original delegation.
Test 28 — Authenticated Malicious Document: Verify that a signed
information source does not automatically gain command authority.
Test 29 — Provenance Edge Forgery: Present an unauthenticated
derivation reference.
Test 30 — Provenance Replay: Reuse stale source records under
incompatible current authority.
Test 31 — Conservative Influence Set: Retain multiple relevant source
references without claiming exhaustive model attribution.
Test 32 — Fragmented Injection: Split an instruction across several
data sources.
Test 33 — Multilingual Injection: Attempt unauthorized instructions
in different languages.
Test 34 — Encoded Instruction: Supply encoded content later
interpreted by the model.
Test 35 — Visual Injection: Insert an instruction into an image.
Test 36 — Audio Injection: Use a recorded spoken instruction.
Test 37 — Video-Derived Injection: Insert an instruction into
subtitles or visual frames.
Test 38 — Browser Interface Injection: Place malicious text within an
observed webpage.
Test 39 — Credential Broker: Attempt unauthorized operation through
an existing protected service credential.
Test 40 — Actual Request Reconstruction: Verify the operation
actually presented to the effectuation boundary.
Test 41 — Resource Identity: Substitute the actual protected resource
after authorization.
Das Expires 29 April 2027 [Page 381]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Test 42 — Actual Recipient: Change the outgoing destination.
5.5.3.57. Source page 2075 of the original specification
Test 43 — Actual Request Body: Modify security-relevant operation
content.
Test 44 — Current Revocation: Invalidate pending finality after
source permission changes.
Test 45 — Protected Consumption: Replay one operation-specific
finality reference.
Test 46 — Alternate Tool Route: Attempt the effect through another
resource interface.
Test 47 — Enforcement Coverage: Verify that each covered effect-
capable path remains protected.
Test 48 — Valid Causal Receipt: Accept a qualified earlier real-
effect receipt under CW-2.
Test 49 — False Causal Completion: Present an ordinary tool success
string as a mandatory real-effect receipt.
Test 50 — Protected Scope Deviation: Invoke CW-3 after an
unauthorized new resource is proposed.
Test 51 — Automated Existing-Scope Resolution: Resolve a harmless
verified operation transformation.
Test 52 — Valid New Scope Approval: Establish appropriately bounded
new authority.
Test 53 — Invalid Approval: Present a confirmation for another
operation.
Test 54 — Sink-Local State: Verify current protected finality
consumption.
Test 55 — Provenance Verification Exhaustion: Bound large derivation
graphs.
Test 56 — Uncertain Provenance: Refuse only those effects requiring
an unresolved mandatory provenance predicate.
Das Expires 29 April 2027 [Page 382]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Test 57 — Valid Data-Only Influence: Permit a correctly authorized
operation whose parameters are derived from untrusted but qualified
data.
Test 58 — Removal of Provenance Preservation: Evaluate whether the
source and derivation relationships become ambiguous.
Test 59 — Removal of Independent Authority Validation: Demonstrate
which unauthorized proposals pass when the model or tool output is
treated as permission.
Test 60 — Removal of Finality-Sink Verification: Evaluate whether a
changed actual request can bypass earlier operation validation.
Test 61 — Removal of Tool-Semantic Generation: Test stale
authorization after a material tool update.
Test 62 — Removal of Protected Credential Mediation: Attempt
unauthorized reuse of broader credential authority.
5.5.3.58. Source page 2076 of the original specification
Test 63 — Removal of Scope-Deviation Latch: Evaluate whether an
unauthorized new effect can occur before adjudication.
Test 64 — Full Multi-Agent Workflow: Combine retrieval,
summarization, tool calls, delegation, source checks, actual sink
validation, and qualified outcome evidence.
Test 65 — Full Adversarial Multimodal Workflow: Combine text, image,
audio, and structured tool content to induce an unauthorized action
proposal while measuring the actual protected resource outcome.
24.61.1 — Required Experimental Distinctions
A proposed test should distinguish:
Whether the model encountered the injected content;
Whether the model followed or reproduced it;
Whether the model generated a consequential Candidate Act;
Whether a protected authority validator accepted the operation;
Whether the actual Finality Sink released the effect;
And whether qualified evidence establishes a completed consequence.
Das Expires 29 April 2027 [Page 383]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A test showing that the model generated a malicious tool call is not
automatically proof that the protected effectuation architecture
failed.
Conversely, an agent refusal at the prompt level does not establish
that mandatory resource-side enforcement exists.
24.62 — NON-LIMITING PHOSITA REFERENCE PROTOTYPE
24.62.1 — Minimum Components
A practical implementation may comprise:
A tool-calling artificial-intelligence agent;
A protected original task-authority database;
A retrieval or document service;
A provenance-aware tool adapter;
A typed operation-schema registry;
5.5.3.59. Source page 2077 of the original specification
A protected Candidate Act controller;
A current authorization and effect-scope validator;
A finality registry;
And an actual resource API gateway or protected local resource
controller.
24.62.2 — Example Task
The principal authorizes an agent to summarize documents and write
one report in an approved workspace.
24.62.3 — Injected Content
A retrieved document contains an instruction to transmit confidential
files externally.
24.62.4 — Tool Evidence
The adapter records the document's qualified source and content
identity.
Das Expires 29 April 2027 [Page 384]
Internet-Draft Execution-Finality Part 7: Tools October 2026
24.62.5 — Agent Computation
The model processes the document and may propose an unauthorized
external transfer.
24.62.6 — Candidate Act
The protected controller constructs an effect descriptor for the
transfer.
24.62.7 — Source Scope
The current original task authority permits report creation but not
confidential external transfer.
24.62.8 — Protected Denial
The independent validator or actual egress sink rejects the
unauthorized operation.
24.62.9 — Valid Operation
The agent may still save the approved report in the permitted
workspace through a valid operation-specific finality procedure.
24.62.10 — Comparative Tests
The PHOSITA may remove the independent finality condition and
evaluate the resulting difference in actual protected resource
effects.
24.62.11 — Technical Qualification
5.5.3.60. Source page 2078 of the original specification
The demonstrated guarantee applies only to consequential operations
controlled by the prototype's enforcement boundary.
The prototype does not establish that the model never internally
follows or represents an injected instruction.
24.63 — OPTIONAL ADVANCED VARIATIONS
24.63.1 — Source-Role Authentication
Instruction-authority records may be authenticated through a
protected principal registry.
Das Expires 29 April 2027 [Page 385]
Internet-Draft Execution-Finality Part 7: Tools October 2026
24.63.2 — Data-Only Tool Envelopes
Tool outputs may explicitly identify themselves as informational
evidence.
24.63.3 — Field-Level Provenance
Individual extracted fields may retain source and validation
references.
24.63.4 — Multi-Source Evidence
A protected validator may require agreement or qualified evidence
from several sources.
24.63.5 — Model Output Inertness
All model-generated consequential proposals may remain non-effective
until independent finality.
24.63.6 — Conservative Derivation Lineage
A controller may preserve relevant observed input sets through model
transformations.
24.63.7 — Protected Tool Contract
Tool semantics may be authenticated and generation-bound.
24.63.8 — Dynamic Tool Revalidation
A materially changed tool may require new protected validation.
24.63.9 — Browser-Use Finality
Graphical or browser-generated actions may be verified against actual
resource effects.
24.63.10 — Credentialed Tool Finality
A protected broker may exercise a reusable credential only for a
verified Candidate Act.
5.5.3.61. Source page 2079 of the original specification
24.63.11 — Cross-Agent Provenance
Das Expires 29 April 2027 [Page 386]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Intermediate messages may preserve original informational and
authority references.
24.63.12 — Retrieval-Index Provenance
Indexed records may retain relevant source and generation evidence.
24.63.13 — Multimodal Provenance
Images, audio, and video may carry qualified source and data-role
information.
24.63.14 — Protected Human Reauthorization
A new effect outside original scope may require a qualified new
principal decision.
24.63.15 — Hardware-Level Finality
A protected device controller may refuse a command proposed through
untrusted computational content.
24.63.16 — Actual-Effect Receipt Continuation
A successor may require a VAER concerning a specified earlier real
effect.
24.63.17 — Semantic Operation Equality
A protected sink may verify exact or bounded semantic correspondence
between the authorized operation and the actual request.
24.63.18 — Model Generation Binding
A selected high-assurance operation may require a specified model or
processing generation.
24.63.19 — Resource Version Binding
The actual effect may depend upon a current resource version.
24.63.20 — Independent Audit Evidence
The system may preserve source, operation, validation, finality, and
actual-effect records for later examination.
These variations are illustrative and non-limiting.
Das Expires 29 April 2027 [Page 387]
Internet-Draft Execution-Finality Part 7: Tools October 2026
24.64 — PROPOSED INVENTIVE-STEP CHARACTERIZATION
24.64.1 — Established Technical Foundations
5.5.3.62. Source page 2080 of the original specification
Existing systems already provide prompt segregation, tool permission
controls, provenance records, retrieval systems, cryptographic
authentication, typed schemas, data lineage, policy engines, and
resource gateways.
The present embodiment may use these components as implementation
substrates.
24.64.2 — Candidate Objective Technical Problem
How to prevent consequential authority from being acquired through
the computational interpretation or transformation of lower-trust
information in autonomous tool-based systems, while preserving
legitimate data use and ensuring that the actual resource effect
remains within independently established current source authority.
24.64.3 — Proposed Technical Solution
The originating task authority is preserved in protected state.
Qualified provenance identifies relevant informational sources and
transformations.
The computational system may derive operation parameters from those
sources only under applicable authorized rules.
The resulting operation is treated as a Candidate Act without
independent authority.
A protected semantic validator evaluates the actual proposed effect
against current source permission.
A separate finality controller establishes scoped non-bearer
enablement.
The actual Finality Sink reconstructs and verifies the real pending
operation before protected release.
24.64.4 — Not Merely Prompt Filtering
A prompt filter attempts to detect or suppress certain malicious
inputs.
Das Expires 29 April 2027 [Page 388]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The proposed arrangement does not universally require successful
detection of every injected instruction.
A generated unauthorized operation remains subject to independent
effectuation denial.
24.64.5 — Not Merely Provenance Tracking
A provenance record describes source and derivation relationships.
The proposed stronger combination uses qualified provenance as part
of a protected operation-authority boundary without treating
provenance itself as permission.
24.64.6 — Not Merely a Signed Document
5.5.3.63. Source page 2081 of the original specification
A signed document may be authenticated.
The proposed system distinguishes source authenticity from source
authority and actual effect permission.
24.64.7 — Not Merely a Structured Tool Call
A valid function-call schema describes an operation's representation.
The proposed system independently verifies the actual consequential
semantics and current authorization.
24.64.8 — Not Merely a Tool Permission List
A general tool allowlist may permit access to a service.
The proposed system evaluates the actual resource operation and its
current material parameters.
24.64.9 — Not Merely Multi-Agent Provenance
An authenticated agent handoff may establish message origin.
The proposed system prevents a lower-trust data source from acquiring
new consequential permission through repeated agent transformations.
24.64.10 — Candidate Narrow Inventive Kernel
Das Expires 29 April 2027 [Page 389]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A protected autonomous execution-finality system in which an
authenticated originating instruction-authority envelope is
maintained separately from qualified lower-trust data and tool-output
provenance, a proposed consequential operation derived from such
content is represented as a non-effective Candidate Act, a protected
semantic validator independently establishes the operation's
permitted actual-effect scope under current originating authority, a
scoped non-bearer finality enablement is constituted, and an
independently enforcing Finality Sink reconstructs the actual pending
resource operation and refuses effectuation unless current source-
authority, actual-operation correspondence, and sink-local protected
consumption predicates are satisfied.
24.64.11 — Data-to-Effect Rule Kernel
A narrower candidate may require a protected rule permitting lower-
trust data to determine selected material operation parameters while
prohibiting the same data from expanding original consequential
authority.
24.64.12 — Provenance-Preserving Handoff Kernel
Another candidate may require authenticated derivation references to
remain associated with a consequential Candidate Act across several
computational or agent stages, followed by independent current
effectuation authority verification.
5.5.3.64. Source page 2082 of the original specification
24.64.13 — Tool-Semantics Kernel
Another candidate may require a protected tool-contract generation
and invalidation of affected finality authority following a material
tool-effect change.
24.64.14 — Multimodal Kernel
Another candidate may apply qualified data-to-effect rules across
text, image, audio, or other inputs, with the same independent
consequential resource sink.
24.64.15 — Instruction Provenance Seal Kernel
Another candidate may use authenticated instruction-origin
commitments and protected role verification to distinguish genuine
source-authority instructions from signed but non-authoritative
content.
Das Expires 29 April 2027 [Page 390]
Internet-Draft Execution-Finality Part 7: Tools October 2026
24.64.16 — Hindsight and Functional-Combination Considerations
A technical inventive-step analysis should investigate whether the
closest earlier system already enforces a complete relationship among
original instruction authority, qualified informational provenance,
operation-specific semantic validation, and actual resource-side
finality.
The simple observation that prompt injection exists is not a
distinguishing feature.
Similarly, merely combining a data-lineage database with an API
permission service may fail to identify the proposed stronger
dependency.
The relevant technical interaction is whether information-origin and
transformation evidence remain subordinate to current source
authority when the final actual consequential operation is
independently reconstructed and controlled.
A meaningful comparative experiment may deliberately allow the model
to generate an injected unauthorized operation and determine whether
the actual resource remains protected.
The technical argument should be directed toward the real enforcement
property established by the claimed combination rather than a
generalized assertion that all prompt injection has been prevented.
24.65 — INDUSTRIAL APPLICABILITY
24.65.1 — Enterprise Autonomous Agents
Retrieved internal and external information may contribute to tasks
without independently granting resource authority.
24.65.2 — Cloud Automation
5.5.3.65. Source page 2083 of the original specification
Model-generated infrastructure changes may remain subject to
protected actual-resource authorization.
24.65.3 — Software Development Agents
Repository content may be processed without becoming unrestricted
permission to execute privileged commands.
24.65.4 — Browser Automation
Das Expires 29 April 2027 [Page 391]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Webpage content may inform computer-use actions while actual effects
remain independently controlled.
24.65.5 — Financial Operations
Invoice and transaction data may be separated from payment authority.
24.65.6 — Electronic Commerce
Product and supplier information may inform purchasing without
automatically authorizing spending.
24.65.7 — Protected Data Retrieval
Retrieved confidential information may remain subject to separate
disclosure authority.
24.65.8 — Database Administration
Model-generated database mutations may be verified against actual
resource identity and permission.
24.65.9 — Multi-Agent Platforms
Delegated computational tasks may preserve original authority across
agent handoffs.
24.65.10 — Information Disclosure
Recipient and content restrictions may remain enforceable despite
malicious retrieved instructions.
24.65.11 — Operating-System Automation
Tool-generated file or process actions may remain subject to
protected local resource gates.
24.65.12 — Network Security
Agent-proposed network transmissions may be verified at current
egress or resource sinks.
24.65.13 — Credential Brokering
5.5.3.66. Source page 2084 of the original specification
Reusable credentials may be exercised only for authorized actual
operations.
Das Expires 29 April 2027 [Page 392]
Internet-Draft Execution-Finality Part 7: Tools October 2026
24.65.14 — Software Deployment
Model-generated deployment requests may be separated from production
change authority.
24.65.15 — Telecommunications
Autonomous configuration recommendations may remain distinct from
protected network control.
24.65.16 — Robotics
Perception and language inputs may inform commands without
independently authorizing unsafe or unrelated actuation.
24.65.17 — Industrial Automation
Sensor-derived information may be used under authorized control rules
without becoming unlimited physical-command authority.
24.65.18 — Multimodal Assistants
Voice, image, and video content may be processed under common
protected effectuation constraints.
24.65.19 — Confidential Computing
Protected authority and provenance verification may be placed in
isolated computing components.
24.65.20 — Future Autonomous Critical Systems
Consequential control may remain separate from computational
interpretation of potentially adversarial information.
24.66 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
24.66.1 — Candidate Independent System Claim
A system comprising:
A protected originating instruction-authority controller configured
to maintain an authenticated source-authorized consequential effect
envelope;
A provenance controller configured to associate selected external
data or tool outputs with qualified source and transformation
evidence;
Das Expires 29 April 2027 [Page 393]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.5.3.67. Source page 2085 of the original specification
A Candidate Act controller configured to construct a consequential
operation proposal derived at least partly from the external data or
tool outputs and maintain the proposal in a Non-Effective State;
A protected semantic validator configured to evaluate the proposed
actual-effect scope against current originating authority and any
required protected data-to-effect rules;
A finality controller configured to establish scoped non-bearer
finality enablement;
And an independent Finality Sink configured to reconstruct the actual
pending resource operation and permit the consequence only following
verification of current source authority, actual operation
correspondence, and protected sink-local finality consumption.
24.66.2 — Candidate Independent Method Claim
A method comprising:
Establishing protected originating source authority;
Acquiring informational content with qualified provenance;
Performing one or more computational transformations;
Constructing a consequential Candidate Act using the resulting
information;
Maintaining the effect non-effective;
Independently resolving actual operation semantics;
Verifying source-authority and data-derived parameter conditions;
Establishing scoped non-bearer finality enablement;
Reconstructing the actual pending resource operation at a protected
Finality Sink;
And permitting effectuation only upon satisfaction of the applicable
current protected authority and consumption conditions.
24.66.3 — Candidate Independent Provenance-Handoff Claim
Das Expires 29 April 2027 [Page 394]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A system configured to preserve authenticated source and derivation
references through multiple autonomous computational agents while
preventing intermediate data or agent-generated messages from
creating consequential authority independently of the original
current source grant and designated Finality-Sink verification.
24.66.4 — Candidate Independent Tool-Semantics Claim
A protected tool-control system configured to bind consequential
Candidate Acts to authenticated tool-operation semantic generations
and invalidate affected finality enablement when the actual tool-
effect contract changes materially before effectuation.
5.5.3.68. Source page 2086 of the original specification
24.66.5 — Candidate Independent Data-to-Effect Claim
A protected operation-control system configured to use lower-trust
data for selected authorized material operation parameters under
explicit protected transformation rules without permitting that same
information source to independently expand the authorized resource,
recipient, or operation scope.
24.67 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
1. The protected source authority identifies an originating
principal. 2. The source authority includes permitted consequential
operation classes. 3. The source authority includes resource or
recipient constraints. 4. The source authority is associated with a
current generation. 5. The source authority is independently stored
from model context. 6. A retrieved document is associated with a
qualified provenance record. 7. A tool response is associated with a
qualified source identity. 8. A tool response identifies its
supported evidence class. 9. The system distinguishes source
authenticity from source authority. 10. An authenticated data source
does not automatically acquire instruction authority. 11. An
instruction record may be associated with a protected cryptographic
seal. 12. An instruction seal may identify source-authority role
information. 13. The claimed authority role is independently
verified. 14. A digitally signed data document may remain
informational rather than authoritative. 15. A computational
derivation record identifies input and output references. 16. A
model-generated summary may retain relevant provenance references.
17. An influence set may conservatively identify observed input
sources. 18. The system does not require proof of exhaustive
internal model causation for actual
Das Expires 29 April 2027 [Page 395]
Internet-Draft Execution-Finality Part 7: Tools October 2026
effectuation finality. 19. A source-data item may populate an
authorized operation field. 20. A protected data-to-effect rule
identifies permitted field transformations. 21. A data-to-effect
rule may constrain recipients. 22. A data-to-effect rule may
constrain financial amounts. 23. A data-to-effect rule may constrain
resource names or identifiers. 24. A data-to-effect rule may
constrain information-disclosure content. 25. Untrusted data cannot
independently create a new source-authority grant. 26. A model-
generated tool call is treated as a Candidate Act proposal. 27. A
valid structured output does not independently establish protected
effectuation
authority. 28. A protected tool contract identifies actual or
expected consequential operation classes. 29. A protected tool
contract is associated with a current generation. 30. A material
tool-semantics change may invalidate pending finality authority. 31.
An unknown actual tool effect causes the relevant operation to remain
withheld. 32. A protected operation translator identifies material
actual-effect parameters. 33. The actual resource is identified
independently of the model's self-description. 34. A lower-trust
retrieved instruction may influence model output without becoming
current source authority. 35. A protected validator compares the
operation with the original authorized effect
envelope.
5.5.3.69. Source page 2087 of the original specification
36. A protected validator checks current source revocation. 37. A
protected validator checks actual resource identity. 38. A protected
validator checks selected tool-contract generations. 39. A protected
validator checks required data-derived parameter predicates. 40. A
protected collection-time instance may commit selected provenance
evidence. 41. A separate execution-time instance may validate
current actual-effect state. 42. Protected evidence may cross-commit
the Candidate Act, provenance, and current
authority. 43. A scoped non-bearer finality enablement is distinct
from the lower-trust content. 44. A model does not receive reusable
complete resource authority merely through output
generation. 45. A designated Finality Sink reconstructs the actual
pending operation. 46. The sink verifies current source authority.
47. The sink verifies actual resource correspondence. 48. The sink
verifies material operation parameters. 49. The sink verifies
protected finality consumption state. 50. A copied finality
reference does not independently authorize another effect. 51. An
Das Expires 29 April 2027 [Page 396]
Internet-Draft Execution-Finality Part 7: Tools October 2026
unauthorized prompt-induced request is denied at the resource sink.
52. The protected architecture need not perfectly detect the
injected language to deny an
unauthorized actual effect. 53. A cross-agent handoff preserves
selected provenance references. 54. A receiving agent verifies its
current delegated authority. 55. An authenticated agent message does
not automatically grant authority absent from
the sender's delegation. 56. A retrieval-index record may carry
original source and generation evidence. 57. Vector similarity does
not independently establish consequential permission. 58. Multimodal
input may carry data provenance without automatically acquiring
instruction authority. 59. A recorded voice instruction is
distinguished from a qualified current principal
approval. 60. Browser-content instructions remain subordinate to
current source authorization. 61. Repository comments remain
informational unless separately authorized to control the
proposed effect. 62. A credential broker may enforce operation-
specific finality for an agent-generated
request. 63. A scope-deviation latch may be activated following an
unauthorized new effect
proposal. 64. A valid new principal authorization may establish a
bounded additional effect scope. 65. A human scope approval does not
override other mandatory finality predicates. 66. A specified
predecessor real-effect receipt may be required under CW-2 for causal
continuation. 67. A tool success message does not automatically
substitute for a required VAER. 68. A context-window truncation does
not remove protected original source-authority
constraints. 69. A model-generation change may require revalidation
under an expressly selected
policy. 70. The actual Finality Sink remains authoritative despite
incomplete computational
provenance. 71. The system may maintain cumulative budgets for
consequences derived from tool
information.
Das Expires 29 April 2027 [Page 397]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.5.3.70. Source page 2088 of the original specification
72. The system may bind finality to current resource versions. 73.
A resource alias or redirect may require actual-target verification.
74. An untrusted tool result cannot alter the mandatory validation-
module set. 75. An intermediate computational source cannot clear a
mandatory protected denial
merely by asserting that the action is safe. 76. A protected output
schema may be used without becoming the sole finality predicate. 77.
Cryptographic provenance authentication may be implemented using
protected
software keys. 78. The protected authority and sink controls may be
implemented through suitable
hardware. 79. The resource-control architecture may operate across
multiple administrative
domains. 80. The disclosed provenance and consequential finality
mechanisms may be applied to
text, code, structured data, image, audio, video, and mixed-modality
autonomous workflows.
24.68 — UNIVERSAL COMBINATION, SUBCOMBINATION, AND NON-LIMITING
PHOSITA CLAUSE
The mechanisms disclosed in the present embodiment may be implemented
independently where technically sufficient or in any compatible
combination.
A selected implementation may use authenticated instruction
provenance.
Another may use source-authority registries without individual
cryptographic instruction seals.
Another may record tool-output provenance.
Another may maintain transformation lineage through intermediate
computation.
Another may apply field-level data-to-effect rules.
Another may preserve source references across agent handoffs.
Another may perform multimodal source qualification.
Das Expires 29 April 2027 [Page 398]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Another may use protected tool-contract generations.
Another may perform independent actual-effect semantic validation.
Another may incorporate credentialed tool mediation.
Another may include protected human reauthorization for genuine scope
expansion.
Another may require accepted prior-effect receipts for causal
workflow continuation.
Another may employ a hardware Finality Sink.
5.5.3.71. Source page 2089 of the original specification
Another may enforce actual effects through a protected application
gateway.
An implementation does not universally require every intermediate
model token to be attributed to an original source.
Where such attribution cannot be reliably established, the relevant
protected operation authorization must remain independently
enforceable.
The system does not universally require that every retrieved document
be cryptographically signed.
The system does not universally require a single fixed model version.
The system does not universally require a human to approve every
covered operation.
The system does not universally prohibit legitimate use of lower-
trust data for authorized dynamic operation parameters.
The invention does not depend upon perfect prompt-injection
classification unless such a property is expressly required and
technically supported by the selected claim.
A protected authority source may authorize a bounded set of
operations without specifying every computational step used to
propose them.
A retrieved source may provide information relevant to the task
without possessing authority to change the task's consequential
scope.
Das Expires 29 April 2027 [Page 399]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A cryptographic provenance seal establishes only the properties
actually authenticated.
A structured tool schema establishes only its specified syntactic and
semantic constraints.
The actual Finality Sink must possess sufficient control over the
relevant effectuation primitive for the asserted enforcement
guarantee.
An application that merely logs proposed effects without controlling
their actual release does not supply the same protection as a non-
bypassable covered Finality Sink.
The equations, algorithms, pseudocode, data structures, threat
examples, diagrams, and proposed experiments are illustrative and
non-limiting technical aids for a person having ordinary skill in the
art.
Features from the earlier embodiments may be combined where
technically appropriate without making all optional features of those
embodiments universally mandatory.
24.69 — FINAL TECHNICAL CHARACTERIZATION
5.5.3.72. Source page 2090 of the original specification
The present Embodiment 24 discloses a protected execution-finality
architecture for autonomous artificial-intelligence systems
processing information from sources having different authority and
trust properties.
An originating principal establishes a protected consequential task-
authority envelope.
The computational system may process external documents, tool
responses, retrieved information, messages from other agents,
multimodal content, and generated intermediate outputs.
Selected source and transformation provenance may be authenticated or
qualified.
The provenance distinguishes informational content from protected
instruction authority.
A lower-trust source may supply facts or parameters used in an
authorized operation without independently creating permission for a
new resource, recipient, effect class, or privileged command.
Das Expires 29 April 2027 [Page 400]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A model-generated proposed action becomes a Candidate Act maintained
non-effective.
A protected operation validator independently evaluates the proposed
consequential effect against current originating source authority and
any required data-to-effect transformation rules.
A finality controller establishes scoped non-bearer enablement.
At the actual effectuation boundary, an independent Finality Sink
reconstructs the pending resource operation and verifies current
source authority, material effect parameters, resource state, and
protected consumption before permitting the consequence.
An authentic retrieved document does not automatically become an
authorized instruction source.
A signed tool response does not independently grant permission to
execute instructions contained within its data.
A computational summary does not acquire new source authority through
model generation.
An authenticated agent message does not automatically authorize a
recipient effect outside the original delegation.
A syntactically correct tool call is not necessarily an authorized
resource operation.
The system may prevent specified unauthorized actual resource effects
even when an attacker succeeds in influencing model output, provided
that the relevant consequential paths remain under mandatory
protected finality enforcement.
The architecture may be implemented using present-day authorization
services, provenance records, cryptographic signatures, tool
adapters, typed schemas, resource gateways, transaction databases,
protected credential brokers, and hardware resource controllers.
5.5.3.73. Source page 2091 of the original specification
The principal candidate inventive technical concept of Embodiment 24
is a protected autonomous execution-finality system in which current
originating instruction authority is maintained independently from
lower-trust informational provenance and computational derivations, a
proposed consequential operation is represented as a non-effective
Candidate Act, protected semantic verification establishes its
actual-effect correspondence to the original permitted scope, and an
Das Expires 29 April 2027 [Page 401]
Internet-Draft Execution-Finality Part 7: Tools October 2026
independent Finality Sink reconstructs the real pending resource
operation and refuses effectuation unless current source-authority,
operation-specific non-bearer finality, and sink-local protected
consumption predicates are satisfied.
24.70 — SHORT PHOSITA IMPLEMENTATION USING EXISTING TECHNOLOGIES
A person having ordinary skill in the art may implement the disclosed
mechanisms using the following established technologies.
Existing technology Optional technical implementation role
W3C provenance data models Describe source entities, activities,
agents, and selected derivation relationships
Cryptographic signatures and MACs Authenticate protected source,
instruction, and tool-output commitments
Typed structured-data schemas Represent source authority and material
operation parameters
Retrieval systems and vector indexes Supply external task data with
associated provenance
references
Tool invocation adapters Record source and operation identity at tool
boundaries Privileged IPC or application gateways
Prevent untrusted model outputs from directly invoking protected
resource effects Authorization servers and structured authorization
details
Maintain original principal and operation-specific permission
Policy decision engines Evaluate protected source-authority and data-
to-effect constraints Deterministic JSON or CBOR encoding
Establish consistent protected instruction and operation commitments
Transactional databases Maintain authority generations, finality
records, and consumption state
Credential brokers Exercise reusable credentials only for verified
actual resource operations Operating-system or hardware resource
gates
Enforce protected finality at selected resource boundaries
Das Expires 29 April 2027 [Page 402]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Non-Limiting Reference Combination
5.6. Embodiment 26 — Tool Installation, Activation, Runtime Upgrade and
Rollback Fencing
Original global source pages 2169 through 2245, inclusive. Source
file: TECHNICAL SPECIFICATION -2012-2566.pdf. This is a primary Part
7 source unit; the author should compare embedded extracts with the
original source file before publication.
5.6.1. Embodiment-Specific Architecture and Trust Relationship
[Authorized tool artifact + dependency provenance]
|
[Protected install and activation authority]
|
[Runtime identity + lifecycle generation]
|
[Pending CA bound to current tool-effect contract]
|
[Update / replacement / rollback transition]
|
[Quiescence + fence stale pending enablement]
|
[New scoped finality from current evidence]
|
[FS validates loaded runtime and actual operation]
/VALID \STALE
[Controlled effect] [WITHHOLD]
Figure 11: Embodiment 26 — Tool Installation, Activation, Runtime
Upgrade and Rollback Fencing — protected architecture
5.6.2. Operational Security Decision Flowchart
Das Expires 29 April 2027 [Page 403]
Internet-Draft Execution-Finality Part 7: Tools October 2026
[Tool version/runtime change requested]
|
<Installer/update authority valid?>-NO->[DENY]
|YES
[Verify artifact, dependencies, contract delta]
|
<New generation protected and committed?>-NO->[HOLD]
|YES
[Fence old queued commands / old finality]
|
<Old or rolled-back runtime submitted?>-YES->[REJECT]
|NO
[FS current tool identity + effect comparison]
|
<Current source/actual target valid?>-NO->[REFUSE]
|YES
[Consume current scoped finality / effect]
Figure 12: Embodiment 26 — Tool Installation, Activation, Runtime
Upgrade and Rollback Fencing — refusal and controlled-effect
decisions
5.6.3. Original Technical Disclosure with Global-Page Anchors
5.6.3.1. Source page 2169 of the original specification
END OF EMBODIMENT 25 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 26
PROTECTED AUTONOMOUS TOOL AND RUNTIME LIFECYCLE TRANSITIONS WITH
INSTALLATION-TIME AUTHORITY ATTESTATION, EXECUTION-TIME TOOL IDENTITY
CONTINUITY, AND FINALITY FENCING ACROSS DYNAMIC TOOL UPDATES
26.0 — COMPLETE TECHNICAL TITLE
Systems, Methods, and Apparatus for Governing Autonomous
Consequential Operations Using Protected Tool Installation and
Activation Authority, Qualified Software Artifact and Dependency
Provenance, Actual Loaded-Runtime Identity Verification, Tool-Effect
Contract Continuity, Monotonic Lifecycle Generations, Protected
Transition Quiescence, Pending-Operation Finality Invalidation,
Scoped Non-Bearer Reconstitution, and Independent Finality-Sink
Enforcement Across Installation, Upgrade, Replacement, Migration,
Revocation, and Rollback
26.0.1 — General Technical Description
Das Expires 29 April 2027 [Page 404]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The present Embodiment 26 discloses systems, methods, apparatus,
protected computing components, software-lifecycle controllers,
authenticated installation interfaces, runtime-identity verification
mechanisms, tool-effect registries, update-transition controllers,
protected state-generation mechanisms, and non-limiting
implementations for governing consequential operations initiated by
autonomous computational entities during changes in the software,
tools, execution environments, dependencies, or privileges on which
those operations depend.
A computational entity may comprise an artificial-intelligence agent,
autonomous assistant, multi-agent orchestration system, tool-calling
model service, software-development agent, operating-system
automation component, cloud controller, industrial automation system,
robotic controller, or another computational workload capable of
proposing consequential actions.
The entity may execute operations using a software tool, executable
module, plugin, runtime environment, application programming
interface, dynamically linked library, operating-system service,
script interpreter, remote connector, privileged broker, container
image, virtual machine, hardware driver, or another computational
component.
A tool may initially be installed and authorized for a bounded
operation.
Before the consequential effect occurs, the tool or its execution
environment may change.
Such changes may include:
Installation of a newly obtained tool; Replacement of an
executable; Modification of a dependency; Change of a dynamically
linked library;
5.6.3.2. Source page 2170 of the original specification
Update of a container image; Change of a runtime configuration;
Replacement of a tool connector; Installation of a plugin or
extension; Addition of a privileged host function; Change of
resource permissions; Replacement of a remote service endpoint;
Hot reloading of executable code; Migration to another execution
environment; Restart following a crash; Restoration of an older
snapshot; Rollback to an earlier software version; Rotation of
signing or attestation keys; Removal or revocation of tool
authorization; Or another material change affecting the actual
consequential operation.
Das Expires 29 April 2027 [Page 405]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The same tool name may refer to different executable code at
different times.
The same executable digest may operate with different permissions,
dependencies, environment variables, host functions, or remote
services.
A digitally signed software artifact may establish selected origin or
integrity properties without necessarily establishing that all its
consequential operations are authorized.
A runtime attestation may establish selected configuration or
measurement claims without necessarily identifying the complete
application-level effect the tool will produce.
A permission previously granted to one version of a tool may remain
stored after the tool has been replaced.
A queued operation may refer to a tool contract that no longer
describes the code actually executing.
A runtime may continue processing requests after its installation
manifest has changed.
A tool may retain the same method name and argument schema while its
actual implementation acquires additional side effects.
A benign upgrade may preserve the intended effect semantics without
preserving every executable byte.
A rollback may restore an older executable while an authority
registry incorrectly restores previously consumed operation-specific
permission.
The present embodiment addresses these conditions by separating:
Software installation authority; software artifact authenticity;
qualified loaded-runtime identity; current effect-capable tool
semantics; source authorization for a consequential operation; and
actual Finality-Sink authority.
5.6.3.3. Source page 2171 of the original specification
In a principal implementation, the software-lifecycle controller
qualifies an executable artifact before installation or activation.
Das Expires 29 April 2027 [Page 406]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The resulting tool identity may include executable content, relevant
dependencies, runtime configuration, tool contract, privilege
envelope, and a current lifecycle generation.
The controller establishes whether a particular transformation from
an earlier tool or runtime generation to a later generation is
permitted.
Pending Candidate Acts associated with the earlier generation are
evaluated for material dependencies on the changed components.
A protected lifecycle fence prevents the relevant pending operations
from becoming effective unless the current executing tool and
operation satisfy the required continuity or revalidation predicates.
Where the transition preserves all relevant protected effect
properties, a previously authorized Candidate Act may remain eligible
subject to current actual-operation verification.
Where the transition changes relevant effects, target resources,
privilege scope, authorization dependencies, or applicable execution
semantics, the old operation-specific finality enablement is
invalidated or withheld.
The system may then require fresh protected validation and
reconstitution of scoped non-bearer finality enablement.
At the actual effectuation boundary, the Finality Sink independently
obtains or reconstructs the pending consequential operation.
The sink verifies the required tool-lifecycle generation, qualified
executing identity, source authorization, operation correspondence,
resource state, protected finality enablement, and sink-local
consumption before permitting the effect.
An installation approval, an authentic software signature, a
successful sandbox execution, or a runtime attestation does not
independently authorize a consequential resource operation that
differs from the previously permitted operation.
26.0.2 — Fundamental Technical Principle
Authorization of software installation is not authorization of every
consequential effect the installed software can produce.
Further:
Das Expires 29 April 2027 [Page 407]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A signed executable is not necessarily a safe or currently authorized
executable.
A successful build is not a completed resource operation.
An attested runtime does not automatically prove the business or
resource semantics of every command it executes.
5.6.3.4. Source page 2172 of the original specification
A tool identifier is not necessarily an immutable executable
identity.
An unchanged function-call schema does not guarantee unchanged actual
effects.
A valid tool update does not automatically preserve all pending
operation-specific authority.
A rollback of executable code does not imply rollback of valid
resource permissions or consumed finality state.
And permission to use a tool does not independently confer authority
for every consequential operation reachable through the tool.
26.0.3 — Principal Candidate Inventive Combination
A principal implementation comprises:
(a) a protected software-lifecycle authority controller;
(b) an authenticated tool artifact or runtime reference;
(c) a qualified effective execution identity identifying relevant
executable code, dependencies, configuration, and privileges;
(d) a protected tool-effect contract identifying the actual
consequential operation classes of the applicable runtime;
(e) a lifecycle transition record connecting predecessor and
successor generations;
(f) a protected dependency relation between pending Candidate Acts
and relevant lifecycle state;
(g) a material-change classifier;
Das Expires 29 April 2027 [Page 408]
Internet-Draft Execution-Finality Part 7: Tools October 2026
(h) a protected lifecycle fence that prevents affected pending
consequences during unresolved transitions;
(i) an independent execution-time validator;
(j) a controller configured to preserve or reconstitute scoped non-
bearer finality according to current validated operation semantics;
(k) a designated Finality Sink that reconstructs the actual pending
consequential operation;
(l) sink-side verification of current lifecycle, source-authority,
actual-operation, resource, and consumption state before
effectuation.
26.0.4 — Particular Technical Contribution
5.6.3.5. Source page 2173 of the original specification
The embodiment does not claim as individually new:
Software digital signatures;
Code signing;
Build provenance;
Package management;
Secure software updates;
Version pinning;
Runtime attestation;
Dependency scanning;
Reproducible builds;
Container image digests;
Configuration management;
Or conventional access-control enforcement.
Das Expires 29 April 2027 [Page 409]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The candidate contribution concerns a protected transition between a
previously authorized tool/runtime generation and the actual effect-
capable generation, including controlled invalidation or
reconstitution of operation-specific finality when the executing
software's relevant identity or effect semantics change.
26.0.5 — Relationship to Other Embodiments
The present disclosure provides focused implementation support for
dependent limitations involving:
Tool installation and update;
Runtime replacement;
Executable and dependency identity;
Protected capability transition;
Rollback fencing;
Software-origin evidence;
Cross-domain tool migration;
5.6.3.6. Source page 2174 of the original specification
Actual loaded-runtime continuity;
And sink-time tool-generation verification.
Foundational Candidate Act, Non-Effective State, Protected
Enforcement Domain, Finality Sink, and non-bearer enablement
principles may be incorporated without requiring repetition of all
earlier embodiments.
26.0.6 — Non-Limiting Technical Architecture
SOFTWARE ARTIFACT / TOOL UPDATE | v QUALIFIED SUPPLY EVIDENCE | v
PROTECTED INSTALLATION GATE | v TOOL LIFECYCLE REGISTRY | v ACTUAL
RUNTIME ACTIVATION | v EFFECTIVE EXECUTION IDENTITY | v CURRENT TOOL-
EFFECT CONTRACT | +---------+---------+ | | v v INTERNAL TOOL
CONSEQUENTIAL COMPUTATION OPERATION REQUEST | | v v CONTINUE
CANDIDATE ACT | v NON-EFFECTIVE HOLD | v LIFECYCLE DEPENDENCY CHECK |
+------------+------------+ | | v v CONTINUITY VALID MATERIAL
CHANGE | | | v
Das Expires 29 April 2027 [Page 410]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.6.3.7. Source page 2175 of the original specification
| FINALITY FENCE | | | v | REVALIDATION | |
+------------+------------+ | v SCOPED NON-BEARER FINALITY | v ACTUAL
FINALITY SINK | v ACTUAL TOOL/RUNTIME EVIDENCE + ACTUAL RESOURCE
OPERATION | v PROTECTED CONSUMPTION | v CONTROLLED REAL EFFECT
All diagrams and implementation representations are illustrative and
non-limiting aids intended to assist a person having ordinary skill
in the art.
26.1 — TECHNICAL FIELD
The invention relates to autonomous tool-execution security, trusted
software lifecycle management, software supply-chain evidence,
runtime identity, dependency integrity, dynamically changing
executable environments, protected privilege transitions, source-
authority continuity, version-bound operation authorization, software
rollback control, and independent consequential Finality-Sink
enforcement.
More particularly, it concerns preventing previously approved
operations from acquiring unintended authority when the executable or
runtime responsible for producing the actual effect changes.
26.2 — SPECIFIC TECHNICAL PROBLEMS
26.2.1 — Tool Name Reuse
A stable tool name may designate different executable implementations
over time.
26.2.2 — Executable Replacement
5.6.3.8. Source page 2176 of the original specification
An authorized executable may be replaced before the pending operation
executes.
26.2.3 — Dependency Substitution
An unchanged main executable may load materially changed
dependencies.
26.2.4 — Runtime Configuration Drift
A configuration change may alter resources, outputs, or privileges
without changing the executable digest.
Das Expires 29 April 2027 [Page 411]
Internet-Draft Execution-Finality Part 7: Tools October 2026
26.2.5 — Tool Permission Drift
An updated tool may possess broader resource permissions.
26.2.6 — Tool-Effect Drift
An updated tool may produce a different consequential effect while
retaining the same interface.
26.2.7 — Schema-Preserving Malicious Update
A malicious update may preserve function names and argument schemas
while adding unauthorized side effects.
26.2.8 — Installation-Authorization Confusion
Permission to install software may be mistaken for permission to
exercise all of its capabilities.
26.2.9 — Signature-Authority Confusion
A signature proving a publisher or artifact origin may be mistaken
for task-specific effect authorization.
26.2.10 — Build-Provenance Confusion
Qualified build provenance may be treated as proof of the actual
runtime's current consequential semantics.
26.2.11 — Remote Attestation Overclaim
An attestation result may be treated as proving effects beyond the
measurement properties actually supported.
26.2.12 — Queued Operation Staleness
An operation prepared under one tool generation may execute under
another.
26.2.13 — Hot Reload
5.6.3.9. Source page 2177 of the original specification
Executable code may change during a long-running task.
26.2.14 — Shared Library Replacement
Das Expires 29 April 2027 [Page 412]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Dynamically resolved functionality may change without an explicit
top-level tool update.
26.2.15 — Interpreter and Script Changes
A stable script may behave differently after its interpreter, runtime
flags, or host functions change.
26.2.16 — Plugin Installation
A newly installed plugin may introduce additional effect-capable
interfaces.
26.2.17 — Tool Dependency Graph Change
An updated dependency may affect downstream execution semantics.
26.2.18 — Permission Expansion Through Migration
A tool moved to a new host may inherit broader privileges.
26.2.19 — Broker Replacement
A privileged connector may be replaced with another implementation
having different effectuation semantics.
26.2.20 — Rollback to Vulnerable Software
A rollback may restore a superseded software version no longer
permitted by current policy.
26.2.21 — Authority Resurrection Through Rollback
A snapshot may restore previously consumed or revoked operation
authority.
26.2.22 — Inconsistent Distributed Rollout
Different workers may use different tool generations simultaneously.
26.2.23 — Stale Attestation Evidence
An earlier runtime measurement may no longer represent the code
producing the actual effect.
26.2.24 — Deployment Alias Mutation
An artifact alias may be redirected to a new executable or image.
Das Expires 29 April 2027 [Page 413]
Internet-Draft Execution-Finality Part 7: Tools October 2026
26.2.25 — Policy and Tool Version Skew
5.6.3.10. Source page 2178 of the original specification
The policy controller and actual runtime may disagree about
applicable tool semantics.
26.2.26 — Unverified Runtime Migration
A task may continue in a new execution domain without appropriate
identity and authority continuity.
26.2.27 — In-Flight Operation During Update
An operation may already be progressing through the effectuation path
when an update begins.
26.2.28 — False Update Quiescence
A lifecycle service may claim that no prior-generation operations
remain despite outstanding requests or open handles.
26.2.29 — Unbounded Update Delay
A system may indefinitely prevent legitimate work by repeatedly
failing a lifecycle transition.
26.2.30 — Required Technical Result
The relevant challenge is to establish current continuity between the
tool generation under which an operation was authorized and the
actual effect-capable tool and resource operation presented at the
final enforcement boundary, without treating every harmless software
update as an automatic new source-permission requirement.
26.3 — ESTABLISHED TECHNICAL BUILDING BLOCKS
26.3.1 — Signed Software Artifacts
Existing signatures can authenticate selected artifact origin or
integrity properties.
They do not necessarily establish the resource effects that the
artifact is permitted to produce.
26.3.2 — Build Provenance
Das Expires 29 April 2027 [Page 414]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Existing provenance formats may identify software subjects, build
processes, source materials, or dependencies.
Their guarantees depend upon the evidence issuer and supported
provenance requirements.
26.3.3 — Secure Update Metadata
Existing update frameworks can verify selected version, integrity,
expiry, and delegation conditions.
5.6.3.11. Source page 2179 of the original specification
Those checks do not automatically preserve the authority of pending
autonomous consequential operations.
26.3.4 — Content-Addressable Images
A content digest can identify particular image bytes or manifests.
It does not necessarily establish all host-specific privileges,
external dependencies, or effective application resource semantics.
26.3.5 — Runtime Attestation
Existing attestation architectures allow a verifier to appraise
evidence regarding selected runtime properties.
They do not automatically prove complete application behavior.
26.3.6 — Process and Container Isolation
Existing restricted execution environments can constrain accessible
resources.
A qualified tool update may still modify the set of consequential
operations available through host brokers or external services.
26.3.7 — Hot Reload and Blue-Green Deployment
Existing deployment approaches can maintain more than one software
generation during transition.
They do not automatically bind each queued Candidate Act to the
current actual resource operation and finality state.
26.3.8 — Proposed Additional Relationship
Das Expires 29 April 2027 [Page 415]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The disclosed combination makes software lifecycle state a protected
dependency of operation-specific finality, including independent
verification at the actual effectuation boundary.
26.4 — PRINCIPAL TECHNICAL COMPONENTS
A representative implementation comprises:
A Protected Software-Lifecycle Authority;
A Qualified Artifact Intake Service;
An Installation and Update Gate;
5.6.3.12. Source page 2180 of the original specification
An Artifact Provenance Validator;
An Effective Runtime Identity Registry;
A Dependency and Configuration Commitment Controller;
A Protected Tool-Effect Contract Registry;
A Runtime Observation and Qualification Service;
A Lifecycle Transition Coordinator;
A Candidate Act Dependency Registry;
A Material-Change Classifier;
A Protected Transition Fence;
An Independent Execution-Time Validator;
A Finality Reconstitution Controller;
An Operation-Specific Non-Bearer Finality Authority;
An Actual Resource Finality Sink;
And a Protected Consumption and Outcome Journal.
Optional components may include:
A software package manager;
Das Expires 29 April 2027 [Page 416]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A signed-update verification client;
A container or image registry;
A protected boot or runtime measurement service;
A hypervisor;
A process isolation environment;
A software bill-of-materials registry;
A dependency resolver;
A cryptographic key custodian;
A remote attestation verifier;
5.6.3.13. Source page 2181 of the original specification
A transactional database;
A privileged operation broker;
And a hardware command controller.
26.5 — TECHNICAL DEFINITIONS
26.5.1 — Protected Tool Lifecycle
A Protected Tool Lifecycle, or PTL-26, means protected management of
tool installation, qualification, activation, execution,
modification, replacement, suspension, revocation, and retirement.
26.5.2 — Tool Artifact Identity
A Tool Artifact Identity, or TAI-26, means a qualified identity of
the relevant executable or software artifact.
26.5.3 — Effective Runtime Identity
An Effective Runtime Identity, or ERI-26, means a qualified identity
of the actual effect-capable executing environment, incorporating
relevant code and configuration properties required by the selected
operation.
26.5.4 — Qualified Artifact Provenance
Das Expires 29 April 2027 [Page 417]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Qualified Artifact Provenance means authenticated evidence concerning
selected source, build, distribution, or artifact properties.
26.5.5 — Tool Lifecycle Generation
A Tool Lifecycle Generation, or TLG-26, means a protected version
distinguishing one applicable tool lifecycle state from another.
26.5.6 — Runtime Activation Generation
A Runtime Activation Generation, or RAG-26, means an authoritative
version identifying the actual activated runtime instance or
configuration.
26.5.7 — Tool-Effect Contract
A Tool-Effect Contract, or TEC-26, means an authenticated description
of the relevant consequential operation classes, required resources,
and effectuation paths of a tool.
26.5.8 — Tool-Effect Contract Generation
5.6.3.14. Source page 2182 of the original specification
A Tool-Effect Contract Generation, or TCG-26, means the current
authoritative version of the tool-effect contract.
26.5.9 — Material Lifecycle Change
A Material Lifecycle Change means a change relevant to the
authorization, actual resource effects, trusted execution identity,
privileges, or effectuation conditions of a pending operation.
26.5.10 — Non-Material Lifecycle Change
A Non-Material Lifecycle Change means a change established as
preserving the particular properties required by a selected operation
under current protected policy.
26.5.11 — Lifecycle Transition Record
A Lifecycle Transition Record, or LTR-26, means protected evidence
connecting predecessor and successor tool or runtime generations.
26.5.12 — Protected Lifecycle Fence
Das Expires 29 April 2027 [Page 418]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A Protected Lifecycle Fence, or PLF-26, means a control preventing
affected consequential operations from becoming effective during
unresolved lifecycle change.
26.5.13 — Pending Operation Dependency
A Pending Operation Dependency means a protected relationship between
a Candidate Act and the tool, runtime, contract, resource, or
privilege properties it requires.
26.5.14 — Candidate Lifecycle Binding
Candidate Lifecycle Binding means association of a Candidate Act with
relevant qualified tool and runtime generations.
26.5.15 — Execution Identity Continuity
Execution Identity Continuity means a verified relationship between
the execution identity previously qualified for an operation and the
identity currently performing it.
26.5.16 — Tool-Effect Continuity
Tool-Effect Continuity means preservation of the specified material
consequential operation semantics across a tool lifecycle change.
26.5.17 — Protected Transition Quiescence
Protected Transition Quiescence means a qualified condition
concerning outstanding operations and effect-capable references
during a lifecycle transition.
26.5.18 — In-Flight Generation
5.6.3.15. Source page 2183 of the original specification
An In-Flight Generation means the tool or runtime generation
associated with an operation already admitted into a defined
protected execution or effectuation stage.
26.5.19 — Generation-Pinned Candidate
A Generation-Pinned Candidate means a Candidate Act explicitly bound
to one qualified tool or runtime generation.
26.5.20 — Generation-Equivalent Candidate
Das Expires 29 April 2027 [Page 419]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A Generation-Equivalent Candidate means a Candidate Act permitted to
continue under a validated set of generation-equivalent runtime
states.
26.5.21 — Qualified Lifecycle Equivalence
Qualified Lifecycle Equivalence means an authenticated and current
determination that a successor tool generation preserves the
properties required for a selected operation.
26.5.22 — Protected Lifecycle Authority
Protected Lifecycle Authority means permission to install, activate,
modify, suspend, or replace a software component.
26.5.23 — Consequential Operation Authority
Consequential Operation Authority means permission to perform a
selected actual resource effect.
26.5.24 — Protected Reconstitution
Protected Reconstitution means creation of new valid operation-
specific finality following successful current validation of a
changed lifecycle context.
26.5.25 — Old-Generation Fence
An Old-Generation Fence means a current protected condition
preventing an obsolete tool generation from exercising affected
consequential authority.
26.5.26 — Protected Generation Floor
A Protected Generation Floor means an authoritative minimum accepted
lifecycle generation or other monotonic version condition under a
selected policy.
26.5.27 — Rollback Authorization
Rollback Authorization means protected permission to activate an
earlier software artifact under current lifecycle policy.
26.5.28 — Authority-Nonrollback Rule
Das Expires 29 April 2027 [Page 420]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.6.3.16. Source page 2184 of the original specification
An Authority-Nonrollback Rule means a requirement that reverting
executable code or configuration does not restore previously consumed
or revoked consequential authority.
26.5.29 — Runtime Evidence Qualification
Runtime Evidence Qualification means evaluating the properties a
runtime measurement or attestation actually establishes.
26.5.30 — Artifact-to-Runtime Correspondence
Artifact-to-Runtime Correspondence means a verified relationship
between a qualified software artifact and the runtime code or
configuration actually used.
26.5.31 — Effective Dependency Set
An Effective Dependency Set means the subset of libraries,
interpreters, plugins, remote services, configurations, or other
dependencies relevant to a particular operation's protected
semantics.
26.5.32 — Dependency Closure Commitment
A Dependency Closure Commitment means an authenticated representation
of relevant dependency identities and their relationships.
26.5.33 — Dynamic Load Event
A Dynamic Load Event means loading or replacing code that may affect
current execution semantics.
26.5.34 — Privilege Profile Generation
A Privilege Profile Generation means a protected version of the
tool's effective access or resource authority profile.
26.5.35 — Effectuation Coverage Generation
An Effectuation Coverage Generation means the current authoritative
version of the set of covered effect-capable paths and their
enforcement mappings.
26.5.36 — Protected Activation Gate
Das Expires 29 April 2027 [Page 421]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A Protected Activation Gate means a component controlling whether a
qualified software or tool generation becomes executable.
26.5.37 — Protected Retirement Fence
A Protected Retirement Fence means a mechanism preventing a retired
runtime from initiating additional protected effects.
26.5.38 — Hot-Swap Operation
5.6.3.17. Source page 2185 of the original specification
A Hot-Swap Operation means replacement of an executable tool, module,
service, or dependency while an associated workflow or service
remains active.
26.5.39 — Lifecycle-Specific Finality Authority
Lifecycle-Specific Finality Authority means non-bearer finality bound
to a relevant qualified lifecycle state and a specific consequential
operation.
26.5.40 — Actual Loaded-Code Evidence
Actual Loaded-Code Evidence means qualified observation concerning
code that was loaded or is executing in the relevant runtime.
26.5.41 — Lifecycle-Bound Effect Receipt
A Lifecycle-Bound Effect Receipt means qualified evidence associating
an actual completed or attempted resource effect with a specified
execution or lifecycle generation.
26.5.42 — Lifecycle Transition Uncertainty
Lifecycle Transition Uncertainty means inability to establish a
required correspondence among old authority, new runtime state, in-
flight operations, and actual effects.
26.6 — THREE SEPARATE AUTHORITY DECISIONS
The present embodiment expressly distinguishes three protected
determinations.
26.6.1 — Artifact Admission
A protected software controller determines whether an artifact may
enter an installation or activation environment.
Das Expires 29 April 2027 [Page 422]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Relevant predicates may include:
Artifact integrity;
Permitted publisher;
Expected identity;
Required update metadata;
Allowed version;
Qualified provenance;
And selected software policy.
5.6.3.18. Source page 2186 of the original specification
26.6.2 — Runtime Qualification
A protected execution controller determines whether the tool instance
actually executing the operation satisfies the required identity and
configuration conditions.
Relevant predicates may include:
Loaded executable;
Relevant dependencies;
Runtime configuration;
Current privilege profile;
Effective tool contract;
Current runtime generation;
And effectuation coverage.
26.6.3 — Consequential Finality
An independent resource controller determines whether the actual
operation is currently authorized.
Relevant predicates may include:
Original source authority;
Das Expires 29 April 2027 [Page 423]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Actual resource;
Actual operation semantics;
Required validation evidence;
Current lifecycle dependencies;
Scoped non-bearer enablement;
And protected consumption.
26.6.4 — Technical Consequence
Passing Artifact Admission does not automatically establish Runtime
Qualification.
Passing Runtime Qualification does not automatically establish
Consequential Finality.
The three determinations may share evidence, but they remain
logically distinct for the applicable claims.
5.6.3.19. Source page 2187 of the original specification
26.7 — EFFECTIVE RUNTIME IDENTITY
A principal implementation does not rely solely upon the human-
readable tool name.
An illustrative effective runtime identity may be expressed as:
[ ERI = H(\operatorname{Canon}(A,D,C,P,E)) ]
(A) represents selected executable artifact identity;
(D) represents relevant dependency identities;
(C) represents material runtime configuration;
(P) represents the applicable privilege profile;
And (E) represents effectuation interface and tool-contract
properties.
This representation is illustrative.
The required properties depend upon the selected Candidate Act.
Das Expires 29 April 2027 [Page 424]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A tool performing a pure local calculation may require fewer
protected attributes than a tool capable of payment, deployment,
confidential data release, or hardware actuation.
26.7.1 — Same Bytes, Different Authority
Identical executable bytes may execute with different permissions.
26.7.2 — Same Configuration, Different Code
A runtime configuration may remain unchanged while executable code
changes.
26.7.3 — Same Tool Name, Different Function
An interface name may persist despite replacement of its
implementation.
26.7.4 — Same Image Digest, Different Remote Service
A tool image may remain unchanged while the remote service it invokes
changes.
26.7.5 — Required Evidence
5.6.3.20. Source page 2188 of the original specification
The effective runtime identity must represent the properties actually
material to the specified operation.
26.8 — PROTECTED TOOL INSTALLATION RECORD
A representative installation record may comprise:
PROTECTED_TOOL_INSTALLATION_RECORD = { installation_identifier,
tool_logical_name, artifact_identity, publisher_identity,
permitted_distribution_source, verified_artifact_digest,
provenance_record_reference, dependency_commitment,
installation_policy_generation, lifecycle_authority_reference,
installed_tool_generation, permitted_activation_domain,
protected_installation_authentication }
A protected installation controller verifies the supported admission
properties.
The successful creation of this record does not itself produce a
valid authority for every effect the installed tool might later
cause.
Das Expires 29 April 2027 [Page 425]
Internet-Draft Execution-Finality Part 7: Tools October 2026
26.9 — PROTECTED RUNTIME ACTIVATION RECORD
A representative activation record may comprise:
PROTECTED_RUNTIME_ACTIVATION = { tool_identifier, artifact_identity,
runtime_instance_identity, loaded_code_commitment,
effective_dependency_commitment, runtime_configuration_commitment,
privilege_profile_commitment, tool_effect_contract_commitment,
effectuation_coverage_reference, lifecycle_generation,
activation_generation, current_revocation_reference,
protected_activation_authentication
5.6.3.21. Source page 2189 of the original specification
The protected controller may establish the record using available
runtime measurements, authenticated configuration state, privileged
observations, or a combination of mechanisms.
26.9.1 — Scope of Observation
The record is qualified according to what the observing mechanism can
actually establish.
26.9.2 — Non-Observed Dependency
A dependency not covered by the measurement cannot automatically be
treated as verified.
26.9.3 — Remote Runtime
A remote tool may require evidence from a separate administration or
attestation domain.
26.10 — TOOL-EFFECT CONTRACT CONTINUITY
A tool-effect contract may identify:
The tool identity;
The operation schema;
The accepted parameter types;
The permitted resource classes;
The possible consequential effects;
The relevant privileged calls;
Das Expires 29 April 2027 [Page 426]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The designated Finality Sinks;
And the required security predicates.
An illustrative contract comprises:
PROTECTED_TOOL_EFFECT_CONTRACT = { tool_identity,
tool_contract_generation, supported_operation_classes,
actual_effect_classes, material_parameter_fields,
possible_target_resource_classes, required_privileges,
effectuation_interfaces,
5.6.3.22. Source page 2190 of the original specification
required_validation_modules, current_source_scope_constraints,
protected_contract_authentication }
26.10.1 — Contract Consistency
The runtime must correspond to the contract for the properties
required by the operation.
26.10.2 — Contract Integrity
An untrusted agent cannot silently redefine a privileged tool's
actual effects.
26.10.3 — Schema Is Not Semantics
An unchanged argument schema does not prove unchanged resource
effects.
26.10.4 — Current Enforcement
The Finality Sink verifies the actual operation rather than relying
entirely upon a tool's self-description.
26.11 — INSTALLATION IS A SEPARATE CANDIDATE ACT
Installation or activation of new effect-capable software may itself
be a consequential operation.
A protected implementation may represent installation as a Candidate
Act.
The installation Candidate Act may identify:
The target software;
Das Expires 29 April 2027 [Page 427]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The destination environment;
The installation method;
The permitted publisher;
The required artifact;
The protected resource changes;
And the applicable installation authority.
A qualified installation Finality Sink may verify and commit the
actual software-installation effect.
5.6.3.23. Source page 2191 of the original specification
However, the resulting installed software does not automatically
receive unrestricted authority to cause subsequent resource effects.
26.11.1 — Two Distinct Finality Events
The system may enforce:
Installation finality: The artifact is installed or activated.
Resource-operation finality: The activated tool performs a selected
consequential effect.
The two events may have different principals, resource predicates,
and protected consumption records.
26.12 — LIFECYCLE TRANSITION RECORD
A protected tool update may create:
PROTECTED_LIFECYCLE_TRANSITION = { transition_identifier,
tool_identity, predecessor_artifact, successor_artifact,
predecessor_runtime_generation, successor_runtime_generation,
predecessor_tool_contract_generation,
successor_tool_contract_generation, relevant_dependency_changes,
relevant_configuration_changes, privilege_profile_changes,
effectuation_coverage_changes, material_change_classification,
affected_candidate_set_commitment, transition_authority_reference,
transition_state, protected_transition_authentication }
The transition record identifies which authority dependencies may
have changed.
Das Expires 29 April 2027 [Page 428]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An update may proceed as a software lifecycle event while affected
consequential Candidate Acts remain withheld pending separate
validation.
26.13 — MATERIAL CHANGE CLASSIFICATION
A protected classifier may compare predecessor and successor
execution properties.
5.6.3.24. Source page 2192 of the original specification
Possible classifications include:
UNCHANGED: Required properties remain identical.
QUALIFIED_EQUIVALENT: Required protected properties differ but are
established as equivalent under current authoritative rules.
AUTHORITY_REDUCING: The successor has fewer available technical
operations or resource permissions.
AUTHORITY_EXPANDING: The successor has additional privileges or
effect-capable paths.
EFFECT_SEMANTICS_CHANGED: The same tool interface can produce a
materially different protected consequence.
RESOURCE_REBINDING: The operation's actual resource target or
provider changes.
UNRESOLVED: Required evidence is insufficient.
26.13.1 — Authority-Reducing Change
A reduction of technical privilege does not automatically prove that
every pending operation will succeed.
A previously permitted operation may no longer be technically
executable.
26.13.2 — Authority-Expanding Change
An expanded privilege profile does not create expanded originating
permission.
26.13.3 — Equivalent Change
Das Expires 29 April 2027 [Page 429]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The classification must be supported by defined technical predicates
rather than merely by a version label.
26.14 — OPERATION-DEPENDENCY PROJECTION
A key focused variation associates each pending Candidate Act with
the particular tool properties it actually requires.
For example, a read-only report-generation operation may depend upon:
The selected report tool;
A designated database read interface;
A specific document output format;
5.6.3.25. Source page 2193 of the original specification
And a protected output destination.
It may not depend upon an unrelated image-rendering plugin.
The controller may therefore use a projection of the full runtime
state:
[ D(CA) = \operatorname{RequiredProperties}(CA) ]
A lifecycle change is material to the Candidate Act when it affects a
required property or prevents the controller from establishing that
property.
26.14.1 — Avoiding Over-Fencing
Unrelated software changes need not suspend every pending operation.
26.14.2 — Mandatory Dependencies
Changes to a required protected resource, privilege, or actual effect
path cannot be ignored.
26.14.3 — Evidence Qualification
The projection must not omit a dependency known or required to affect
the claimed consequential semantics.
26.14.4 — Candidate Technical Effect
Das Expires 29 April 2027 [Page 430]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The system can preserve legitimate operation continuity across
unrelated updates while fencing actual authority-sensitive
transitions.
26.15 — PROTECTED LIFECYCLE FENCE
A Lifecycle Fence may be activated when:
The effective executable changes;
A required dependency changes;
The tool-effect contract changes;
The privilege profile changes;
The receiving resource changes;
An effectuation path changes;
The runtime is replaced;
5.6.3.26. Source page 2194 of the original specification
A required attestation result becomes stale;
A generation floor is violated;
Or a current mandatory lifecycle predicate becomes unresolved.
The fence may prevent:
Credential exercise;
Network effectuation;
Database commit;
File mutation;
Artifact deployment;
Persistent memory update;
Financial transaction;
Or hardware actuation.
Das Expires 29 April 2027 [Page 431]
Internet-Draft Execution-Finality Part 7: Tools October 2026
26.15.1 — Selective Fencing
The controller may fence only Candidate Acts affected by the change.
26.15.2 — Global Fencing
A broader fence may be required when the integrity of shared
enforcement state is uncertain.
26.15.3 — Protected Clearing
An agent-generated assertion that the new tool is compatible does not
independently clear the fence.
A qualified protected validation or valid new source authorization is
required as applicable.
26.16 — QUIESCENCE AND IN-FLIGHT OPERATIONS
A lifecycle transition may occur while operations are:
Queued;
Under validation;
Finality prepared;
5.6.3.27. Source page 2195 of the original specification
Awaiting broker dispatch;
Already dispatched;
Committed locally;
Or awaiting remote outcome.
A protected transition controller distinguishes these states.
26.16.1 — Before Protected Finality
The system may invalidate pending enablement and require current
revalidation.
26.16.2 — After Finality Consumption
A consumed authority record is not automatically restored.
Das Expires 29 April 2027 [Page 432]
Internet-Draft Execution-Finality Part 7: Tools October 2026
26.16.3 — After Remote Dispatch
An update does not prove that the external effect failed.
26.16.4 — Confirmed Completed Effect
The actual effect remains historical evidence even if the original
tool generation is retired.
26.16.5 — Transition Barrier
The controller may require a qualified quiescence condition before
retiring selected old-generation operations.
26.16.6 — Non-Quiescent Migration
Where permitted, old and new generations may coexist with independent
protected eligibility and consumption records.
26.17 — FENCED SWITCHOVER
A principal implementation may perform the following sequence:
1. Identify the current active generation. 2. Authenticate the
proposed successor artifact and configuration. 3. Construct the
lifecycle transition. 4. Identify affected Candidate Acts. 5.
Activate a protected fence for relevant old-generation authority. 6.
Prevent new affected operations from acquiring old-generation
finality. 7. Reconcile or classify in-flight effects. 8. Qualify
the successor runtime.
5.6.3.28. Source page 2196 of the original specification
9. Validate current tool-effect and privilege conditions. 10.
Revalidate affected consequential operations. 11. Prepare new scoped
finality for eligible operations. 12. Change the current active
generation under protected state. 13. Enforce successor generation
at actual sinks. 14. Retire or restrict the predecessor. 15. Record
the transition and supported outcomes.
The exact order of selected preparation steps may vary.
The transition must preserve the required authority and anti-replay
properties at the actual effectuation boundary.
26.18 — ATOMIC GENERATION SWITCH
Das Expires 29 April 2027 [Page 433]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Within a single sufficiently isolated protected transaction domain,
the lifecycle controller may atomically update:
The active tool generation;
The corresponding effect-contract reference;
The current privilege generation;
The relevant finality eligibility generation;
And applicable sink acceptance state.
26.18.1 — Transactional Limitation
An atomic database update does not automatically make independent
remote tools and resources switch atomically.
26.18.2 — Distributed Variation
A distributed system may use generation fencing, staged activation,
and destination-side validation.
26.18.3 — No Mixed-Generation Authority
A finality decision must not silently combine incompatible lifecycle
or operation properties from different generations.
26.19 — DUAL-GENERATION OPERATION
A rolling deployment may temporarily maintain two runtime
generations.
5.6.3.29. Source page 2197 of the original specification
A selected policy may permit both generations if each separately
satisfies the relevant operation requirements.
The system may maintain:
A predecessor-eligible set;
A successor-eligible set;
And a current policy identifying which Candidate Acts may execute
under each generation.
26.19.1 — No Automatic Interchangeability
Das Expires 29 April 2027 [Page 434]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Two active tool generations do not automatically share all operation-
specific enablements.
26.19.2 — Generation-Pinned Authority
Some operations may be bound to exactly one generation.
26.19.3 — Qualified Equivalence
Other operations may be revalidated for a bounded equivalent-
generation class.
26.19.4 — Consumption
Protected single-use authority must not be duplicated merely because
two generations are simultaneously active.
26.20 — HOT RELOAD
A long-running process may replace code or configuration without
changing process identity.
For example:
A loaded module changes;
A policy plugin changes;
An interpreter mapping changes;
Or a network connector is reconfigured.
The protected lifecycle controller may observe or require declaration
of the relevant change.
A stable process identifier does not prove stable effective code
identity.
26.20.1 — Actual Loaded State
5.6.3.30. Source page 2198 of the original specification
Relevant runtime evidence may identify the effective loaded
generation.
26.20.2 — Material Change
A material hot reload triggers applicable finality fencing.
Das Expires 29 April 2027 [Page 435]
Internet-Draft Execution-Finality Part 7: Tools October 2026
26.20.3 — Concurrent Threads
The system may need to distinguish operations already executing old
code from new operations entering updated code.
26.20.4 — Actual Sink
The Finality Sink verifies the qualified generation relevant to the
operation being performed.
26.21 — DYNAMIC LIBRARIES AND DEPENDENCIES
A tool may depend upon dynamically linked or loaded components.
An unchanged top-level executable digest may not guarantee unchanged
execution behavior.
A selected implementation may commit:
Library identity;
Relevant version or digest;
Loading path;
Runtime resolution policy;
Plugin identity;
Or other operation-relevant dependency properties.
26.21.1 — Complete Environment Not Universally Required
The protected system need not cryptographically commit every byte of
every nonmaterial dependency.
26.21.2 — Required Dependencies
A dependency capable of altering the protected actual effect must be
covered by the required qualification model.
26.21.3 — Unresolved Dependency
5.6.3.31. Source page 2199 of the original specification
The applicable Candidate Act remains fenced when a mandatory
dependency cannot be sufficiently qualified.
Das Expires 29 April 2027 [Page 436]
Internet-Draft Execution-Finality Part 7: Tools October 2026
26.22 — REMOTE TOOL CONNECTOR CHANGE
A tool may be implemented as a remote service.
Its local client library may remain unchanged while the receiving
remote service changes.
A protected tool contract may identify:
Service identity;
Relevant API semantics;
Current resource class;
Permission scope;
Operation generation;
And required destination-side enforcement.
A changed remote implementation may require renewed qualification
where it affects mandatory operation properties.
26.22.1 — API Schema Limitation
An unchanged API schema does not automatically prove unchanged remote
resource effects.
26.22.2 — Destination Evidence
The source controller may require current service-side contract or
resource evidence.
26.22.3 — Finality Limitation
A local client cannot assume complete control over hidden remote side
effects it neither observes nor enforces.
26.23 — TOOL PLUGIN INSTALLATION
A plugin may introduce:
New tool commands;
Additional network destinations;
Das Expires 29 April 2027 [Page 437]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.6.3.32. Source page 2200 of the original specification
Filesystem access;
New authenticated operations;
Device functions;
Or other effectuation surfaces.
A protected installation controller may qualify the plugin.
The effectuation coverage registry must also account for newly
introduced consequential paths.
26.23.1 — Installation Permission
The plugin may be permitted to install.
26.23.2 — Execution Permission
The plugin may be permitted to execute under selected isolation
conditions.
26.23.3 — Consequential Permission
Each covered effect still requires current source authorization and
protected finality.
26.24 — SIGNATURE AND PROVENANCE QUALIFICATION
A software artifact may be accompanied by:
A publisher signature;
A build-provenance record;
An authenticated artifact digest;
A dependency manifest;
An update metadata record;
Or a runtime attestation.
The protected controller evaluates the property supplied by each
evidence source.
Das Expires 29 April 2027 [Page 438]
Internet-Draft Execution-Finality Part 7: Tools October 2026
26.24.1 — Signature
May authenticate a key-authorized endorsement of particular bytes.
26.24.2 — Provenance
5.6.3.33. Source page 2201 of the original specification
May identify selected artifact-building circumstances.
26.24.3 — Update Metadata
May establish whether an artifact is an accepted update target under
a configured trust framework.
26.24.4 — Runtime Attestation
May provide evidence of selected current execution state.
26.24.5 — Actual Consequential Permission
Requires separately valid source authority and the corresponding
finality predicates.
26.25 — ATTESTATION-DEPENDENT RUNTIME QUALIFICATION
A selected implementation may use remote attestation or local
measured-execution evidence.
The attestation architecture may include:
An attesting execution environment;
An evidence verifier;
A reference-value authority;
And a protected relying component.
The controller verifies that the attestation result identifies the
properties required by the Candidate Act.
26.25.1 — Measurement Scope
If the evidence measures only initial boot state, it cannot
automatically establish all subsequently loaded code.
26.25.2 — Attestation Freshness
Das Expires 29 April 2027 [Page 439]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The result may require binding to a current challenge, session, or
generation.
26.25.3 — Operation Binding
The protected controller may associate the qualified runtime evidence
with the pending Candidate Act.
26.25.4 — Semantic Limit
5.6.3.34. Source page 2202 of the original specification
A verified measurement does not automatically establish authorization
for a particular payment, disclosure, deployment, or device command.
26.26 — TOOL UPDATE AND CURRENT SOURCE AUTHORITY
An authorized principal may permit use of a tool for a bounded class
of operations.
The software administrator may separately permit a tool update.
Those permissions may originate from different authority principals.
For example:
The source principal permits one report export to a designated
recipient.
A software administrator permits installation of a new reporting-tool
version.
The tool update may be valid.
However, the administrator's installation permission does not
automatically authorize the agent to export the report to a different
recipient.
The Finality Sink must enforce the original permitted resource effect
unless a valid new source authorization establishes otherwise.
26.27 — ROLLBACK WITH NON-ROLLBACK AUTHORITY
A selected system may authorize use of an earlier software artifact.
This does not automatically restore earlier protected authority
state.
Das Expires 29 April 2027 [Page 440]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The lifecycle controller distinguishes:
Executable version;
Lifecycle transition generation;
Current source-authority generation;
Current revocation state;
And protected finality-consumption state.
26.27.1 — Older Code, Newer Lifecycle Generation
5.6.3.35. Source page 2203 of the original specification
A controlled rollback may activate older executable bytes under a new
protected lifecycle generation.
26.27.2 — Current Policy
The rollback must satisfy current software and operation policy.
26.27.3 — Non-Resurrection
A snapshot restoring older executable code cannot independently make
a consumed finality reference unused again.
26.27.4 — Generation Floor
Where a minimum accepted software generation is required, rollback
below that floor is refused unless a qualified transition updates the
relevant authority according to policy.
26.28 — EMERGENCY ROLLBACK
A critical tool may require rapid replacement with a previously
qualified version after a defect.
A protected rollback process may:
Verify emergency lifecycle authority;
Identify an allowed rollback target;
Establish current artifact integrity;
Assess mandatory security dependencies;
Das Expires 29 April 2027 [Page 441]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Fence affected pending operations;
Activate the replacement under a new protected lifecycle transition;
And revalidate operation-specific finality.
An emergency label alone does not constitute permission to bypass
mandatory resource authorization.
The system may provide a technically narrower emergency operation
mode while preserving critical protected source and sink predicates.
26.29 — CROSS-HOST TOOL MIGRATION
5.6.3.36. Source page 2204 of the original specification
A task may move from one host to another.
The original source-authorized task may remain valid.
However, the new host may have:
Different installed tools;
Different dependencies;
Different privileged brokers;
Different runtime configuration;
Different filesystem mappings;
Different resource credentials;
Or different enforcement coverage.
A protected migration record associates the original task and pending
Candidate Acts with the new qualified execution environment.
Finality eligibility must be reestablished for affected operations.
26.30 — RUNTIME RESTART AND CRASH RECOVERY
A tool process may crash after finality is prepared or consumed.
Upon restart, the protected lifecycle controller establishes the
current runtime generation.
Das Expires 29 April 2027 [Page 442]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Previously prepared references are not automatically valid under the
new execution state.
A consumed finality record remains consumed.
An actual external effect may remain unresolved.
The system may require qualified resource-side reconciliation rather
than assuming the effect did not occur.
26.31 — LIFECYCLE REVOCATION
A protected lifecycle authority may revoke:
A tool artifact;
5.6.3.37. Source page 2205 of the original specification
A runtime generation;
A plugin;
A privileged broker;
A signing key;
Or a specific tool operation class.
The revocation may cause affected pending finality authority to
become invalid.
A revocation is not assumed to undo completed effects.
Where an in-flight operation may already have escaped the controlled
boundary, its outcome requires the applicable protected
reconciliation process.
26.32 — AGENT-MODEL AND TOOL COORDINATION
An autonomous task may change its model generation while also
changing its tool runtime.
The system may qualify these changes separately.
The tool's actual executable or effect semantics are not
automatically established by the model identifier.
Das Expires 29 April 2027 [Page 443]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A model upgrade does not automatically authorize new resource
operations.
A tool upgrade does not automatically authorize new agent objectives.
Where the selected source policy requires a particular model or tool
generation, the corresponding pending effect remains bound to those
conditions.
Otherwise, a permitted model change need not trigger tool-specific
reauthorization if relevant protected effect conditions remain
satisfied.
26.33 — PROTECTED LIFECYCLE STATE MACHINE
A non-limiting state machine comprises:
ARTIFACT_DISCOVERED: A software artifact is identified.
PROVENANCE_PENDING: Required software evidence remains unresolved.
ARTIFACT_QUALIFIED: Applicable artifact admission checks pass.
5.6.3.38. Source page 2206 of the original specification
INSTALLATION_AUTHORIZED: The installation operation possesses valid
source authority.
INSTALLED: The artifact has entered the designated environment.
ACTIVATION_PENDING: Runtime activation has not yet completed.
ACTIVE_GENERATION: A qualified generation is current.
OPERATION_PENDING: A Candidate Act depends upon the runtime.
TRANSITION_PROPOSED: A new tool or runtime state is requested.
TRANSITION_FENCED: Affected consequential effects are withheld.
QUIESCENCE_PENDING: Required in-flight operation state remains
unresolved.
SUCCESSOR_QUALIFIED: The successor satisfies required runtime
predicates.
CONTINUITY_VALIDATED: Operation-relevant properties remain qualified.
Das Expires 29 April 2027 [Page 444]
Internet-Draft Execution-Finality Part 7: Tools October 2026
REVALIDATION_REQUIRED: Earlier finality assumptions are no longer
sufficient.
FINALITY_RECONSTITUTED: New operation-specific authority has been
established.
SWITCHOVER_COMMITTED: The active protected generation changes.
PREDECESSOR_RETIRED: The earlier runtime is no longer permitted for
the affected effects.
ROLLBACK_PENDING: A proposed return to earlier code awaits current
authorization.
REVOKED: Relevant tool or runtime authority is invalid.
OUTCOME_INDETERMINATE: A previously released external effect remains
unresolved.
TERMINATED: The lifecycle or consequential operation reaches a
protected terminal state.
26.34 — PRINCIPAL END-TO-END WORKFLOW
Step 1 — Identify Software Artifact. Obtain the candidate tool or
runtime artifact.
Step 2 — Qualify Provenance. Verify required artifact, source, and
distribution evidence.
Step 3 — Verify Lifecycle Authority. Determine whether installation
or activation is permitted.
5.6.3.39. Source page 2207 of the original specification
Step 4 — Construct Installation Candidate. Represent any protected
installation effect as a Candidate Act.
Step 5 — Commit Installation. Use the required protected software-
installation sink.
Step 6 — Qualify Runtime. Establish supported actual loaded-code and
configuration properties.
Step 7 — Establish Tool Contract. Identify relevant effect-capable
semantics.
Das Expires 29 April 2027 [Page 445]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Step 8 — Establish Lifecycle Generation. Record the protected active
state.
Step 9 — Receive Autonomous Operation. The tool-calling agent
proposes a consequential action.
Step 10 — Construct Candidate Act. Identify the actual resource and
effect.
Step 11 — Record Lifecycle Dependencies. Associate required runtime,
tool, privilege, and resource properties.
Step 12 — Hold Non-Effective. Withhold the consequential release.
Step 13 — Check Current Source Authority. Verify the originating
principal's permissions.
Step 14 — Check Runtime Continuity. Compare required qualified
generation and effective execution identity.
Step 15 — Check Current Tool Semantics. Validate the actual
supported effect class.
Step 16 — Independently Validate. Establish the applicable
execution-time predicates.
Step 17 — Prepare Scoped Finality. Constitute non-bearer enablement.
Step 18 — Detect Lifecycle Transition. Identify any material update
or replacement.
Step 19 — Fence Affected Operations. Prevent incompatible old-
generation finality from releasing effects.
Step 20 — Classify Transition. Determine which required properties
changed.
Step 21 — Reconcile In-Flight Operations. Preserve completed,
attempted, and unresolved outcomes.
Step 22 — Qualify Successor. Establish current successor runtime
properties.
Step 23 — Revalidate Candidate. Confirm actual operation permission
under the new generation.
Step 24 — Reconstitute Finality. Establish new enablement where
required.
Das Expires 29 April 2027 [Page 446]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.6.3.40. Source page 2208 of the original specification
Step 25 — Present Actual Operation. Submit it to the designated
Finality Sink.
Step 26 — Reconstruct Actual Effect. The sink obtains actual target
and operation parameters.
Step 27 — Verify Lifecycle State. Check current required generation
and qualified runtime identity.
Step 28 — Verify Source and Resource. Check current operation-
specific authorization.
Step 29 — Verify Finality and Consumption. Confirm non-bearer
authority and sink-local state.
Step 30 — Commit Finality. Perform the applicable protected
consumption transition.
Step 31 — Release Effect. Permit the covered consequential
operation.
Step 32 — Record Outcome. Preserve qualified actual-effect or
unresolved state.
26.35 — REFERENCE ALGORITHM: ARTIFACT ADMISSION
FUNCTION QUALIFY_TOOL_ARTIFACT( artifact, lifecycle_authority,
protected_installation_controller ): REQUIRE
VERIFY_LIFECYCLE_AUTHORITY( lifecycle_authority ) REQUIRE
VERIFY_ARTIFACT_IDENTITY(artifact) REQUIRE
VERIFY_REQUIRED_PUBLISHER_OR_SOURCE_EVIDENCE( artifact ) REQUIRE
VERIFY_UPDATE_METADATA_WHERE_REQUIRED( artifact ) REQUIRE
VERIFY_ALLOWED_ARTIFACT_GENERATION( artifact ) provenance =
VERIFY_QUALIFIED_BUILD_PROVENANCE( artifact )
5.6.3.41. Source page 2209 of the original specification
REQUIRE provenance SATISFIES REQUIRED_PROFILE admission =
protected_installation_controller .COMMIT_ARTIFACT_ADMISSION({
artifact_identity: HASH(artifact), qualified_provenance:
HASH(provenance), lifecycle_authority: lifecycle_authority,
installation_policy_generation:
CURRENT_INSTALLATION_POLICY_GENERATION() }) RETURN admission
The resulting admission does not independently authorize arbitrary
resource effects performed by the artifact.
Das Expires 29 April 2027 [Page 447]
Internet-Draft Execution-Finality Part 7: Tools October 2026
26.36 — REFERENCE ALGORITHM: EFFECTIVE RUNTIME QUALIFICATION
FUNCTION QUALIFY_EFFECTIVE_RUNTIME( runtime_instance,
selected_operation_class, protected_runtime_verifier ): evidence =
protected_runtime_verifier .OBTAIN_SUPPORTED_RUNTIME_EVIDENCE(
runtime_instance ) REQUIRE VERIFY_EVIDENCE_AUTHENTICITY(evidence)
REQUIRE VERIFY_EVIDENCE_FRESHNESS_WHERE_REQUIRED( evidence )
required_properties = RESOLVE_REQUIRED_RUNTIME_PROPERTIES(
selected_operation_class ) REQUIRE
EVIDENCE_SUPPORTS_REQUIRED_PROPERTIES( evidence,
5.6.3.42. Source page 2210 of the original specification
required_properties ) REQUIRE VERIFY_EFFECTIVE_DEPENDENCIES(
evidence, required_properties ) REQUIRE
VERIFY_CURRENT_PRIVILEGE_PROFILE() REQUIRE
VERIFY_CURRENT_TOOL_EFFECT_CONTRACT() REQUIRE
VERIFY_CURRENT_EFFECTUATION_COVERAGE() RETURN
PROTECTED_RUNTIME_QUALIFICATION({ effective_runtime:
COMMIT_REQUIRED_PROPERTIES(evidence), runtime_generation:
CURRENT_RUNTIME_GENERATION(), contract_generation:
CURRENT_TOOL_CONTRACT_GENERATION(), privilege_generation:
CURRENT_PRIVILEGE_GENERATION() })
The verifier does not infer unobserved properties from an incomplete
attestation.
26.37 — REFERENCE ALGORITHM: MATERIAL CHANGE
FUNCTION CLASSIFY_LIFECYCLE_CHANGE( predecessor, successor,
candidate_act, protected_classifier ): required =
LOAD_PROTECTED_CANDIDATE_DEPENDENCIES( candidate_act ) REQUIRE
VERIFY_PREDECESSOR_AND_SUCCESSOR_EVIDENCE() difference =
COMPARE_REQUIRED_RUNTIME_PROPERTIES( predecessor,
5.6.3.43. Source page 2211 of the original specification
successor, required ) IF difference == EXACTLY_PRESERVED: RETURN
CONTINUITY_CANDIDATE IF VERIFY_QUALIFIED_OPERATION_EQUIVALENCE(
predecessor, successor, candidate_act ): RETURN
QUALIFIED_EQUIVALENT_TRANSITION IF difference == PRIVILEGE_EXPANSION:
RETURN REQUIRE_PRIVILEGE_AND_SCOPE_REVALIDATION IF difference ==
MATERIAL_EFFECT_CHANGE: RETURN INVALIDATE_AND_REVALIDATE IF
difference == RESOURCE_CHANGE: RETURN
REQUIRE_CURRENT_RESOURCE_AUTHORITY RETURN FENCE_PENDING_QUALIFICATION
The equivalence predicate is a protected technical determination
rather than an untrusted agent declaration.
Das Expires 29 April 2027 [Page 448]
Internet-Draft Execution-Finality Part 7: Tools October 2026
26.38 — REFERENCE ALGORITHM: FENCE AFFECTED CANDIDATES
FUNCTION FENCE_LIFECYCLE_TRANSITION( transition,
protected_lifecycle_controller ): REQUIRE
VERIFY_TRANSITION_AUTHORITY( transition ) affected =
protected_lifecycle_controller
.IDENTIFY_DEPENDENT_PENDING_CANDIDATES( transition ) fence =
protected_lifecycle_controller .COMMIT_PROTECTED_TRANSITION_FENCE({
transition: transition,
5.6.3.44. Source page 2212 of the original specification
affected_candidates: HASH_SET(affected), predecessor_generation:
transition.previous_generation, proposed_generation:
transition.next_generation, current_policy_generation:
CURRENT_POLICY_GENERATION() }) REQUIRE fence == COMMITTED FOR EACH
candidate IN affected: MARK_FINALITY_REVALIDATION_REQUIRED(candidate)
RETURN PROTECTED_FENCE_REFERENCE(fence)
The protected controller must ensure that the actual sinks enforce
the relevant generation fence rather than relying solely on
bookkeeping.
26.39 — REFERENCE ALGORITHM: PROTECTED SWITCHOVER
FUNCTION COMMIT_TOOL_GENERATION_SWITCH( transition,
successor_qualification, protected_lifecycle_controller ): REQUIRE
VERIFY_ACTIVE_TRANSITION_FENCE( transition ) REQUIRE
VERIFY_SUCCESSOR_QUALIFICATION( successor_qualification ) REQUIRE
VERIFY_REQUIRED_IN_FLIGHT_OPERATION_STATE() REQUIRE
VERIFY_CURRENT_LIFECYCLE_AUTHORITY() REQUIRE
VERIFY_CURRENT_EFFECTUATION_COVERAGE() REQUIRE
VERIFY_CURRENT_PRIVILEGE_AND_TOOL_CONTRACT() switch =
protected_lifecycle_controller
5.6.3.45. Source page 2213 of the original specification
.ATOMIC_COMMIT_ACTIVE_GENERATION({ expected_predecessor:
transition.previous_generation, successor:
transition.next_generation, successor_identity:
successor_qualification.runtime_identity, sink_acceptance_generation:
successor_qualification.sink_generation }) IF switch != COMMITTED:
RETURN DENY_SWITCHOVER RETIRE_OR_FENCE_PREDECESSOR_AS_REQUIRED()
RETURN CURRENT_PROTECTED_GENERATION()
Where multiple independent resource domains are involved, each must
apply the required current acceptance and fencing conditions.
Das Expires 29 April 2027 [Page 449]
Internet-Draft Execution-Finality Part 7: Tools October 2026
26.40 — REFERENCE ALGORITHM: FINALITY RECONSTITUTION
FUNCTION RECONSTITUTE_AFTER_TOOL_UPDATE( old_candidate_act,
current_runtime, protected_finality_controller ): REQUIRE
VERIFY_CURRENT_SOURCE_AUTHORITY( old_candidate_act ) REQUIRE
VERIFY_CURRENT_RUNTIME_QUALIFICATION( current_runtime ) actual_effect
= RECONSTRUCT_CURRENT_OPERATION_SEMANTICS( old_candidate_act,
current_runtime ) REQUIRE VERIFY_ACTUAL_EFFECT_WITHIN_ORIGINAL_SCOPE(
actual_effect )
5.6.3.46. Source page 2214 of the original specification
REQUIRE VERIFY_CURRENT_RESOURCE_IDENTITY( actual_effect ) REQUIRE
VERIFY_REQUIRED_EXECUTION_TIME_EVIDENCE() REQUIRE
VERIFY_CURRENT_LIFECYCLE_FENCE_STATE() REQUIRE
VERIFY_NO_PREVIOUS_INCOMPATIBLE_EFFECTUATION() RETURN
protected_finality_controller
.CREATE_NEW_SCOPED_NON_BEARER_FINALITY({ candidate:
old_candidate_act, actual_effect: actual_effect,
current_runtime_generation: current_runtime.generation,
current_tool_contract: current_runtime.tool_contract,
current_source_authority: CURRENT_SOURCE_AUTHORITY(),
designated_finality_sink: RESOLVE_ACTUAL_SINK() })
A consumed or externally dispatched prior operation is not treated as
freely reusable merely because new runtime authority is prepared.
26.41 — REFERENCE ALGORITHM: SINK-TIME LIFECYCLE VERIFICATION
FUNCTION EFFECTUATE_LIFECYCLE_BOUND_OPERATION( candidate_act,
finality_reference, protected_finality_sink ): actual =
protected_finality_sink .RECONSTRUCT_ACTUAL_PENDING_OPERATION()
REQUIRE VERIFY_ACTUAL_OPERATION_QUALIFIED(actual) REQUIRE
VERIFY_CURRENT_ORIGINATING_AUTHORITY()
5.6.3.47. Source page 2215 of the original specification
REQUIRE VERIFY_ACTUAL_RESOURCE_IDENTITY(actual) REQUIRE
VERIFY_CURRENT_TOOL_GENERATION(actual) REQUIRE
VERIFY_EFFECTIVE_RUNTIME_CONTINUITY( actual, candidate_act ) REQUIRE
VERIFY_CURRENT_TOOL_EFFECT_CONTRACT(actual) REQUIRE
VERIFY_CURRENT_PRIVILEGE_PROFILE() REQUIRE
VERIFY_CURRENT_EFFECTUATION_COVERAGE() REQUIRE
VERIFY_NO_ACTIVE_INCOMPATIBLE_LIFECYCLE_FENCE() REQUIRE
VERIFY_ACTUAL_EFFECT_WITHIN_SOURCE_SCOPE( actual ) REQUIRE
VERIFY_SCOPED_NON_BEARER_FINALITY( finality_reference, actual )
REQUIRE VERIFY_SINK_LOCAL_PROTECTED_CONSUMPTION() committed =
protected_finality_sink .COMMIT_FINALITY_CONSUMPTION(
Das Expires 29 April 2027 [Page 450]
Internet-Draft Execution-Finality Part 7: Tools October 2026
finality_reference, actual ) IF committed != COMMITTED: RETURN DENY
RETURN protected_finality_sink
.RELEASE_CONTROLLED_ACTUAL_EFFECT(actual)
When a remote effect cannot be committed atomically with local
consumption, controlled dispatch and appropriate outcome
reconciliation apply.
26.42 — REFERENCE ALGORITHM: ROLLBACK WITHOUT AUTHORITY RESURRECTION
FUNCTION ACTIVATE_CONTROLLED_ROLLBACK( previous_artifact,
5.6.3.48. Source page 2216 of the original specification
current_lifecycle_state, protected_controller ): REQUIRE
VERIFY_CURRENT_ROLLBACK_AUTHORITY() REQUIRE
VERIFY_ARTIFACT_CURRENTLY_PERMITTED( previous_artifact ) REQUIRE
VERIFY_SECURITY_GENERATION_FLOORS() REQUIRE
ACTIVATE_TRANSITION_FENCE() REQUIRE
CLASSIFY_AND_RECONCILE_IN_FLIGHT_OPERATIONS() qualification =
QUALIFY_NEW_RUNTIME_USING_OLDER_ARTIFACT( previous_artifact ) REQUIRE
VERIFY_RUNTIME_QUALIFICATION( qualification ) next_generation =
protected_controller .CREATE_NEW_LIFECYCLE_GENERATION(
previous_artifact ) REQUIRE PRESERVE_CURRENT_REVOCATION_STATE()
REQUIRE PRESERVE_CONSUMED_FINALITY_STATE() REQUIRE
PRESERVE_OUTCOME_JOURNAL() REQUIRE COMMIT_PROTECTED_SWITCHOVER(
next_generation ) RETURN NEW_RUNTIME_WITH_CURRENT_AUTHORITY_FLOORS
The rollback returns to selected older code, not to unrestricted
older consequential authority.
26.43 — REFERENCE ALGORITHM: IN-FLIGHT OUTCOME RECOVERY
FUNCTION RECONCILE_OPERATION_DURING_UPDATE( logical_operation,
5.6.3.49. Source page 2217 of the original specification
protected_journal, qualified_resource_observer ): state =
protected_journal .LOAD_AUTHORITATIVE_OPERATION_STATE(
logical_operation ) REQUIRE VERIFY_JOURNAL_AUTHENTICITY(state) IF
QUALIFIED_EFFECT_COMPLETED(state): RETURN
PRESERVE_CONFIRMED_EFFECT(state) IF
QUALIFIED_NON_EFFECT_ESTABLISHED(state): RETURN
APPLY_AUTHORIZED_NON_EFFECT_RESOLUTION() observed =
qualified_resource_observer .OBTAIN_QUALIFIED_CURRENT_OUTCOME(
logical_operation ) IF VERIFY_ACTUAL_EFFECT(observed): RETURN
COMMIT_CONFIRMED_OUTCOME(observed) IF
VERIFY_ACTUAL_NON_EFFECT(observed): RETURN
Das Expires 29 April 2027 [Page 451]
Internet-Draft Execution-Finality Part 7: Tools October 2026
COMMIT_QUALIFIED_NON_EFFECT(observed) RETURN
PRESERVE_INDETERMINATE_FINALITY_STATE()
An update, restart, or rollback is not proof that an earlier external
operation failed.
26.44 — WORKED EXAMPLE A: READ-ONLY TOOL BECOMES EFFECT-CAPABLE
An autonomous agent is authorized to generate a report using a read-
only tool.
The original tool performs database reads and local formatting.
A software update replaces the tool with a version that additionally
writes information to a remote analytics store.
The executable is validly signed.
The installation controller accepts the update under the applicable
software policy.
However, the new outbound persistent write is not part of the
original source-authorized effect envelope.
5.6.3.50. Source page 2218 of the original specification
The lifecycle classifier identifies the changed actual effect.
Pending old-generation finality is fenced or revalidated.
The remote write remains unauthorized.
Expected demonstrable result: A valid software installation cannot
automatically convert an earlier read-only task grant into permission
for a newly introduced consequential effect.
26.45 — WORKED EXAMPLE B: HARMLESS PATCH
A tool receives a maintenance update that changes internal error
formatting.
The protected controller establishes that the properties material to
one pending operation remain qualified.
The operation's authorized resource, actual effect, privilege
envelope, and Finality-Sink conditions remain unchanged.
Das Expires 29 April 2027 [Page 452]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The controller permits current revalidation without demanding a new
discretionary grant from the originating principal.
Expected demonstrable result: The system can distinguish an
operation-relevant lifecycle change from an unrelated implementation
change.
26.46 — WORKED EXAMPLE C: DEPENDENCY SUBSTITUTION
An agent is authorized to prepare a resource mutation through a
designated tool.
The main executable remains unchanged.
A dynamically loaded library is replaced.
The replacement library adds a new external data transmission.
The protected dependency and effect-contract checks identify a
material change.
The previously prepared finality enablement cannot independently
authorize the new transmission.
Expected demonstrable result: Verification of the main executable
alone does not falsely establish unchanged consequential semantics
after a relevant dependency change.
26.47 — WORKED EXAMPLE D: SAME FUNCTION NAME, DIFFERENT EFFECT
5.6.3.51. Source page 2219 of the original specification
A tool exposes a function named create_report.
An earlier version generates a local report.
A new version additionally publishes the report to a shared
repository.
The schema and function name remain unchanged.
The protected tool-effect contract records the publication effect.
The actual resource sink requires source permission for external
publication.
The unauthorized publication is withheld.
Das Expires 29 April 2027 [Page 453]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Expected demonstrable result: An unchanged tool interface cannot
silently preserve authorization for newly introduced resource
effects.
26.48 — WORKED EXAMPLE E: QUEUED OPERATION DURING UPDATE
An agent prepares a payment operation under Tool Generation 7.
Before the payment reaches the protected resource boundary, Tool
Generation 8 is activated.
Generation 8 changes the destination-account interpretation of a
selected field.
The pending Candidate Act is associated with its original material
operation descriptor.
The lifecycle fence prevents automatic execution under changed
semantics.
The protected controller requires current validation of the actual
recipient and amount.
Expected demonstrable result: A queued operation cannot silently
acquire a new consequential meaning because the tool implementation
changed before finality.
26.49 — WORKED EXAMPLE F: CREDENTIAL BROKER UPDATE
An agent requests a credential-dependent external operation.
The privileged broker is updated.
The new broker supports a wider set of resources and request
transformations.
The protected controller qualifies the new broker generation and
current effectuation contract.
An old approval for one resource does not automatically authorize
requests against newly supported resources.
5.6.3.52. Source page 2220 of the original specification
The broker independently reconstructs the actual request and verifies
scoped finality.
Das Expires 29 April 2027 [Page 454]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Expected demonstrable result: Broadening a broker's technical
capabilities does not broaden the originating agent's permitted
consequential effects.
26.50 — WORKED EXAMPLE G: VALIDLY SIGNED MALICIOUS UPDATE
An artifact passes the selected publisher-signature verification.
Its new behavior attempts to transmit protected data to an
unauthorized recipient.
The protected installation gate may establish artifact authenticity.
However, the actual data-release Finality Sink checks current source
authority and recipient scope.
The unauthorized transmission is refused.
Expected demonstrable result: Software provenance and application-
level consequential authority remain separate mandatory conditions.
26.51 — WORKED EXAMPLE H: RUNTIME ATTESTATION WITH HIDDEN EFFECT
A runtime produces qualified evidence of selected loaded code and
security configuration.
The agent requests a privileged resource operation.
The runtime evidence satisfies its configured measurement profile.
However, the resource operation targets a record outside the original
source-authorized scope.
The Finality Sink rejects the mutation.
Expected demonstrable result: Attested execution state does not
independently authorize a different actual resource effect.
26.52 — WORKED EXAMPLE I: HOT-RELOADED CONNECTOR
An autonomous agent uses a long-running connector process.
The connector loads a new operation module without restarting.
5.6.3.53. Source page 2221 of the original specification
An earlier finality reference was established under the preceding
module generation.
Das Expires 29 April 2027 [Page 455]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The protected runtime observes or is notified of the material change.
Affected pending operations are fenced.
The new actual request is independently revalidated.
Expected demonstrable result: A stable process identity cannot bypass
lifecycle-dependent operation authorization after a material hot
reload.
26.53 — WORKED EXAMPLE J: ROLLBACK WITHOUT AUTHORITY REUSE
A tool performs an authorized resource mutation.
Its finality enablement is consumed.
Later, the administrator rolls the software back to an earlier
executable version.
An older snapshot contains a record showing that finality as
unconsumed.
The protected authority and sink-local state do not accept that
obsolete consumption record.
The old permission remains spent.
Expected demonstrable result: Returning to older software does not
restore previously consumed consequential authority.
26.54 — WORKED EXAMPLE K: EMERGENCY ROLLBACK
A production tool update introduces a defect.
The lifecycle authority permits activating a previously qualified
stable artifact.
The controller fences affected operations.
The older code is activated under a new protected lifecycle
generation.
Current source authorization, current resource identity, and
finality-consumption state remain authoritative.
The rollback restores selected functionality without restoring
obsolete permissions.
Das Expires 29 April 2027 [Page 456]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Expected demonstrable result: Emergency software recovery can be
separated from rollback of protected consequential authority.
5.6.3.54. Source page 2222 of the original specification
26.55 — WORKED EXAMPLE L: ROLLING MULTI-GENERATION DEPLOYMENT
Two generations of a tool operate concurrently during a controlled
rollout.
Agent A uses the predecessor generation.
Agent B uses the successor generation.
The protected controller maintains generation-specific tool contracts
and finality eligibility.
A single-use original authority cannot be consumed twice merely
because two generations are active.
Expected demonstrable result: Multiple deployed tool generations do
not independently multiply operation-specific source permission.
26.56 — WORKED EXAMPLE M: TASK MIGRATION
An agent is moved to a different host during a long-running workflow.
The destination host uses another runtime image and privilege
profile.
The protected lifecycle controller establishes the destination
execution identity.
Pending Candidate Acts are evaluated against the changed
dependencies.
A material privilege or effectuation-path difference triggers
revalidation.
Expected demonstrable result: Migration to a new runtime does not
silently transfer unlimited permission based only on the original
task identifier.
26.57 — WORKED EXAMPLE N: PLUGIN INSTALLATION
An autonomous system installs a plugin for document transformation.
The plugin also exposes an authenticated external-upload function.
Das Expires 29 April 2027 [Page 457]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The installation operation is authorized.
However, the current original task does not permit external
disclosure.
The upload function's actual resource effect remains subject to
protected Finality-Sink authorization.
5.6.3.55. Source page 2223 of the original specification
Expected demonstrable result: Installing a plugin does not
independently grant permission to exercise all of its effect-capable
functions.
26.58 — WORKED EXAMPLE O: UPDATED DEVICE CONTROLLER
An autonomous industrial controller receives a software update.
The update changes how a device command parameter maps to physical
actuation.
A pending device command was validated under the earlier mapping.
The protected lifecycle controller detects the material command-
semantics change.
The device-side Finality Sink requires current actual-command
validation.
Expected demonstrable result: A valid software update cannot silently
change the physical consequence of an earlier authorized command.
26.59 — WORKED EXAMPLE P: LOST ACKNOWLEDGEMENT DURING SWITCHOVER
An agent performs an authorized remote resource operation.
The old tool generation dispatches the request.
A lifecycle transition begins.
The acknowledgement is lost.
The controller cannot establish whether the effect completed.
The operation remains indeterminate.
The successor generation cannot automatically repeat it as a new
effect under the same consumed authority.
Das Expires 29 April 2027 [Page 458]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Expected demonstrable result: Tool replacement does not convert
remote-outcome uncertainty into fresh executable permission.
26.60 — WORKED EXAMPLE Q: SHARED EXECUTION POLICY CHANGE
A tool's executable bytes remain unchanged.
A host administrator changes its privilege policy to permit
additional filesystem access.
5.6.3.56. Source page 2224 of the original specification
The protected lifecycle controller identifies the change in effective
execution authority.
A pending operation cannot treat the expanded host capability as new
source permission.
The actual file-operation sink still enforces the original bounded
resource scope.
Expected demonstrable result: Unchanged code identity does not
conceal a material change in effective tool authority.
26.61 — WORKED EXAMPLE R: CROSS-DOMAIN TOOL PROVIDER REPLACEMENT
An enterprise agent invokes a remote tool service.
The remote provider replaces the implementation but retains the same
API endpoint and request schema.
The receiving resource service may now produce different persistent
effects.
The protected system requires an appropriate current tool-effect
qualification or destination-side enforcement.
The actual resource operation remains bound to current originating
authority.
Expected demonstrable result: Stable endpoint and schema identifiers
do not automatically establish stable consequential effect semantics.
26.62 — WORKED EXAMPLE S: DEPENDENT WORKFLOW AFTER TOOL UPDATE
An agent performs an authorized artifact publication.
The publication result is qualified by an actual resource receipt.
Das Expires 29 April 2027 [Page 459]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The tool runtime is subsequently updated.
A later notification operation is required under CW-2 Mode B to
depend upon the accepted earlier publication receipt.
The new tool generation must separately satisfy current notification
authority and actual-recipient conditions.
The runtime update neither erases the historical completed
publication nor automatically authorizes the notification.
5.6.3.57. Source page 2225 of the original specification
Expected demonstrable result: Historical real-effect evidence and
current successor tool authority remain logically separate.
26.63 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
1. Tool-name spoofing. 2. Executable replacement. 3. Package
substitution. 4. Forged publisher identity. 5. Compromised signing
key. 6. Validly signed but malicious update. 7. Stale update
metadata. 8. Software rollback attack. 9. Software freeze attack.
10. Dependency confusion. 11. Dynamic library substitution. 12.
Script-interpreter replacement. 13. Runtime configuration tampering.
14. Container image alias mutation. 15. Unchanged image tag
pointing to changed bytes. 16. Plugin injection. 17. Host-function
expansion. 18. Unauthorized privilege-profile change. 19. Tool-
contract forgery. 20. Schema-preserving behavioral modification. 21.
Queued operation execution under another tool generation. 22. Hot-
reload race. 23. Inconsistent worker generations. 24. Stale runtime
attestation. 25. Attestation evidence replay. 26. Incorrect
interpretation of attestation scope. 27. Material dependency omitted
from measurement. 28. Dynamic loading after attestation. 29.
Compromised artifact repository. 30. Unauthorized software
installation. 31. Installation approval mistaken for operation
authority. 32. Tool activation before protected qualification. 33.
New effectuation path bypass. 34. Changed privileged broker. 35.
Credential broker scope inflation. 36. Runtime migration to a more
privileged host. 37. Resource alias rebinding after tool update. 38.
Invalid code-generation equivalence assertion. 39. Agent-authored
compatibility claim. 40. Rollback restoring consumed finality. 41.
Snapshot rollback restoring revoked grants. 42. Rollback below the
required minimum generation. 43. In-flight operation double
execution.
Das Expires 29 April 2027 [Page 460]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.6.3.58. Source page 2226 of the original specification
44. Dispatch timeout during switchover. 45. Premature retirement of
the predecessor. 46. Incomplete old-generation quiescence. 47.
Unknown background worker. 48. Stale open credential session. 49.
Stale file or network descriptor. 50. Cross-generation non-bearer
reference replay. 51. Tool contract mismatch at the Finality Sink.
52. Different API semantics under the same endpoint. 53. Same
executable running with different privileges. 54. Same tool running
with changed remote dependencies. 55. Missing current source
authorization. 56. Revocation during a rollout. 57. Incorrectly
shared consumption state. 58. Parallel resource mutation across
active versions. 59. Unauthorized output-artifact promotion. 60.
New persistent-memory effect introduced by an update. 61. Hardware-
command remapping. 62. Incorrect assumption that a build signature
proves safety. 63. Incorrect assumption that runtime attestation
proves completed resource effect. 64. Uncontrolled alternate
operation path. 65. Protected lifecycle-controller compromise. 66.
Protected Finality Sink compromise. 67. Denial-of-service through
repeated update-fencing. 68. Unbounded dependency-graph
verification. 69. Unauthenticated rollback emergency mode. 70.
Misclassification of a material update as harmless.
These threats are evaluated within the protection assumptions and
actual enforcement coverage of the selected implementation.
26.64 — PROPOSED FEASIBILITY AND ADVERSARIAL EXPERIMENTS
The following tests are proposed, non-limiting demonstrations and are
not represented as executed experiments.
Test 1 — Artifact Identity: Verify a tool's selected executable
identity.
Test 2 — Publisher Authentication: Verify applicable artifact
publisher evidence.
Test 3 — Build Provenance: Qualify the supported artifact build
provenance.
Test 4 — Installation Authority: Require current permission for a
protected installation.
Test 5 — Installation as Candidate Act: Treat software installation
as a separate consequential effect.
Test 6 — Runtime Activation: Verify actual activated runtime state.
Das Expires 29 April 2027 [Page 461]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.6.3.59. Source page 2227 of the original specification
Test 7 — Effective Identity: Bind relevant code, dependencies,
configuration, and privileges.
Test 8 — Tool Contract: Establish protected consequential operation
semantics.
Test 9 — Internal Computation: Permit ordinary internal computation
without unnecessary external authority.
Test 10 — Actual Resource Operation: Require independent operation-
specific finality.
Test 11 — Tool Name Reuse: Replace executable code while preserving
the logical name.
Test 12 — Image Alias Rebinding: Change an artifact associated with a
mutable image label.
Test 13 — Main Binary Replacement: Replace the top-level executable.
Test 14 — Dependency Replacement: Change a relevant dependency
without changing the main executable.
Test 15 — Configuration Drift: Change material runtime configuration.
Test 16 — Privilege Expansion: Increase the technical resource access
available to the tool.
Test 17 — Unchanged Schema: Introduce a new side effect while
preserving the API schema.
Test 18 — Material Classification: Identify an operation-relevant
semantic change.
Test 19 — Harmless Patch: Preserve eligibility under validated
equivalent required properties.
Test 20 — Dependency Projection: Avoid fencing an operation for a
qualified unrelated change.
Test 21 — Material Dependency: Fence an operation affected by a
required dependency update.
Test 22 — Pending Candidate Binding: Record the required tool and
runtime generation.
Das Expires 29 April 2027 [Page 462]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Test 23 — Update Before Validation: Change the runtime before
protected finality preparation.
Test 24 — Update After Validation: Change the runtime after upstream
validation but before sink effectuation.
Test 25 — Update After Finality Preparation: Invalidate affected
stale enablement.
Test 26 — Update After Consumption: Preserve consumed authority.
5.6.3.60. Source page 2228 of the original specification
Test 27 — Update During Remote Dispatch: Preserve unresolved actual
outcome state.
Test 28 — Quiescence: Establish outstanding operation counts or
qualified state before transition.
Test 29 — False Quiescence: Simulate an undiscovered in-flight
operation.
Test 30 — Protected Fence: Verify that the fence actually prevents
affected resource effects.
Test 31 — Current Generation: Check current accepted lifecycle
generation at the sink.
Test 32 — Dual Generation: Execute qualified operations under two
concurrent runtime versions.
Test 33 — Duplicate Use Across Generations: Attempt to reuse one
finality allowance through both versions.
Test 34 — Switchover: Commit a protected active-generation
transition.
Test 35 — Switchover Race: Submit effects during the exact generation
change.
Test 36 — Finality Reconstitution: Establish fresh current authority
for eligible affected Candidate Acts.
Test 37 — Incompatible Reconstitution: Refuse a materially changed
unauthorized effect.
Test 38 — Tool Contract Change: Require current semantic validation.
Das Expires 29 April 2027 [Page 463]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Test 39 — Remote Connector Change: Change the remote implementation
while preserving the local client.
Test 40 — Plugin Installation: Introduce a new effect-capable
extension.
Test 41 — Effectuation Coverage: Detect a new consequential path.
Test 42 — Credential Broker Update: Verify actual operation-specific
credential use.
Test 43 — Runtime Attestation: Obtain a qualified runtime evidence
result.
Test 44 — Stale Attestation: Reject evidence older than the required
current state.
Test 45 — Incomplete Measurement: Identify an unmeasured required
dependency.
Test 46 — Attestation Semantic Limit: Attempt an unauthorized
resource effect from an otherwise qualified runtime.
Test 47 — Artifact Rollback: Activate earlier software under current
protected lifecycle policy.
Test 48 — Rollback Below Floor: Reject a prohibited earlier
generation.
5.6.3.61. Source page 2229 of the original specification
Test 49 — Authority Nonrollback: Verify that consumed finality stays
consumed.
Test 50 — Revocation Nonrollback: Verify that revoked source
permission remains revoked.
Test 51 — Emergency Rollback: Recover functionality with bounded
current authority.
Test 52 — Host Migration: Move a task into a new runtime domain.
Test 53 — Different Host Privileges: Detect changed effective access
after migration.
Test 54 — Runtime Restart: Reestablish current generation following a
crash.
Das Expires 29 April 2027 [Page 464]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Test 55 — Snapshot Restore: Reject stale execution and authority
states.
Test 56 — Dynamic Module Reload: Replace code within a persistent
process.
Test 57 — Inherited Handle: Evaluate effective resource authority
remaining after update.
Test 58 — Actual File Sink: Verify the actual pending file mutation.
Test 59 — Actual Database Sink: Verify the current target row or
record.
Test 60 — Actual Network Sink: Verify material destination and
request changes.
Test 61 — Actual Deployment Sink: Distinguish artifact generation
from production deployment.
Test 62 — Actual Hardware Sink: Verify a changed device-command
mapping.
Test 63 — CW-2 Dependency: Preserve a required accepted earlier real-
effect receipt across a tool update.
Test 64 — CW-3 Scope Expansion: Require new source authorization for
a genuinely expanded effect class.
Test 65 — Removal of Artifact Verification: Compare exposure from an
unqualified software replacement.
Test 66 — Removal of Runtime Continuity: Test an operation approved
for one executable but performed by another.
Test 67 — Removal of Tool-Effect Qualification: Test whether schema-
preserving new side effects remain authorized.
Test 68 — Removal of Lifecycle Fencing: Attempt stale finality during
a material update.
Test 69 — Removal of Sink Generation Verification: Attempt
effectuation through a superseded runtime.
5.6.3.62. Source page 2230 of the original specification
Test 70 — Removal of Protected Consumption: Attempt to reuse
authority across active generations.
Das Expires 29 April 2027 [Page 465]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Test 71 — Removal of Authority-Nonrollback: Restore a consumed
permission through a snapshot.
Test 72 — Removal of Actual-Operation Verification: Evaluate a signed
runtime performing an unauthorized resource mutation.
Test 73 — Denial-of-Service Bound: Limit dependency and transition
verification work.
Test 74 — Full Lifecycle Sequence: Install, activate, execute,
update, fence, revalidate, perform finality, recover, and roll back.
Test 75 — Multi-Agent Rolling Deployment: Race multiple agents using
mixed tool generations under one originating authority.
26.64.1 — Experimental Measurements
The proposed tests may measure:
Unauthorized actual effects;
Successfully blocked stale-generation operations;
Correct distinction between material and non-material updates;
False denial of permitted operations;
Unqualified runtime activations;
Finality reuse attempts;
Generation-switch races;
Rollback authority resurrection;
Unresolved operation handling;
Effectuation latency;
And protected transition overhead.
26.64.2 — Comparative Ablation
A particularly useful comparison comprises:
System A: Signed software updates only.
System B: Signed updates plus runtime-identity checks.
Das Expires 29 April 2027 [Page 466]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.6.3.63. Source page 2231 of the original specification
System C: Signed updates plus runtime continuity, operation-specific
lifecycle fencing, protected finality reconstitution, and independent
actual-resource Finality-Sink verification.
The tests may determine whether a software update can alter the
consequence of a previously approved Candidate Act without fresh
protected authorization.
26.65 — NON-LIMITING PHOSITA REFERENCE PROTOTYPE
26.65.1 — Minimum Components
A practical reference prototype may use:
An isolated autonomous agent;
A protected tool registry;
Two executable tool versions;
A software artifact repository;
A current runtime-generation record;
A transactional finality ledger;
A privileged effectuation broker;
And a receiving test database.
26.65.2 — Initial Tool
Tool Version A accepts a structured request and performs a specific
permitted database read.
26.65.3 — Original Authorization
The source principal authorizes the read operation.
26.65.4 — Prepared Candidate
The agent prepares the request under Version A.
26.65.5 — Tool Update
The lifecycle controller installs Version B.
Das Expires 29 April 2027 [Page 467]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Version B preserves the original request schema but additionally
attempts a persistent record modification.
26.65.6 — Transition Evidence
5.6.3.64. Source page 2232 of the original specification
The protected lifecycle service records the artifact, runtime, and
effect-contract changes.
26.65.7 — Fence
The previous Candidate Act becomes ineligible for automatic resource
mutation under Version B.
26.65.8 — Revalidation
The controller evaluates the actual new effect against the original
source grant.
26.65.9 — Denial
The actual database sink refuses the unauthorized mutation.
26.65.10 — Equivalent Update
A second update changes only a qualified nonmaterial logging detail.
The original read operation may remain eligible after the applicable
continuity predicates pass.
26.65.11 — Rollback
The environment returns to the earlier executable under a current
lifecycle generation.
Previously consumed finality remains unavailable.
26.65.12 — Expected Technical Result
The prototype demonstrates that an authorized tool name, valid
software signature, or successful runtime activation does not
independently authorize an operation whose actual resource effect
differs from the protected source-authorized Candidate Act.
26.66 — OPTIONAL ADVANCED VARIATIONS
26.66.1 — Content-Addressed Artifact Activation
Das Expires 29 April 2027 [Page 468]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A protected controller binds activation to a verified artifact
digest.
26.66.2 — Signed Update Chain
A software-update client verifies qualified update metadata and
rollback conditions.
26.66.3 — Build-Provenance Qualification
A protected controller evaluates relevant artifact build evidence.
5.6.3.65. Source page 2233 of the original specification
26.66.4 — Runtime Attestation
A current measured-runtime claim supplies selected execution-state
evidence.
26.66.5 — Dependency-Closure Verification
Relevant libraries, plugins, or interpreters are included in current
runtime qualification.
26.66.6 — Configuration-Qualified Identity
Runtime permissions and configuration contribute to the effective
identity.
26.66.7 — Generation-Pinned Finality
Finality enablement requires one exact qualified runtime generation.
26.66.8 — Equivalent-Generation Finality
A bounded class of generations may be accepted under a current
protected equivalence rule.
26.66.9 — Tool-Effect Contract Revalidation
A material semantic change causes pending authority revalidation.
26.66.10 — Privilege Profile Revalidation
An expanded resource capability causes current scope verification.
26.66.11 — Hot Reload
Das Expires 29 April 2027 [Page 469]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A persistent process changes loaded code during a task.
26.66.12 — Dual-Generation Deployment
Old and new versions coexist with generation-specific finality
eligibility.
26.66.13 — Cross-Domain Runtime Migration
A task moves to another execution domain and current authority is
qualified anew.
26.66.14 — Controlled Rollback
Earlier executable code is activated without rollback of authority
state.
26.66.15 — Emergency Lifecycle Recovery
A protected emergency transition restores functionality under current
mandatory resource authority.
26.66.16 — Tool Plugin Lifecycle
5.6.3.66. Source page 2234 of the original specification
A newly installed plugin is associated with current effectuation
coverage.
26.66.17 — Broker Lifecycle
A privileged connector update requires current operation and
credential authority.
26.66.18 — Hardware Runtime Update
A firmware or device-controller change is bound to current hardware-
command finality.
26.66.19 — Persistent Memory Tool Update
A changed retrieval or memory connector remains subject to current
protected persistence-sink authority.
26.66.20 — Causal Workflow Continuity
Das Expires 29 April 2027 [Page 470]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Historical qualified real-effect receipts remain valid according to
their own evidence semantics while current successor tool finality is
independently revalidated.
26.67 — PROPOSED INVENTIVE-STEP CHARACTERIZATION
26.67.1 — Existing Foundations
Existing technologies can authenticate software artifacts, describe
build provenance, validate update chains, verify selected runtime
configurations, manage software versions, and isolate execution
environments.
Those technologies are implementation components rather than
automatically distinctive features.
26.67.2 — Candidate Objective Technical Problem
How to prevent a consequential operation authorized for one qualified
tool or runtime state from being executed with materially different
privileges or actual effects after software installation,
replacement, dependency change, hot reload, migration, or rollback,
without unnecessarily invalidating operations whose required
authority and effect properties remain demonstrably unchanged.
26.67.3 — Proposed Technical Solution
A protected lifecycle controller records the actual effect-relevant
identity and generation of a tool.
Each covered Candidate Act is associated with the required tool and
runtime properties.
A lifecycle transition is analyzed against the Candidate Act's
protected dependency set.
5.6.3.67. Source page 2235 of the original specification
Material changes activate a protected finality fence.
Eligible operations are revalidated under current execution
conditions.
New scoped non-bearer finality enablement is constituted where
required.
Das Expires 29 April 2027 [Page 471]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The actual Finality Sink independently reconstructs the consequential
operation and verifies current qualified lifecycle state before
consuming authority and releasing the effect.
26.67.4 — Not Merely Code Signing
A valid signature may establish artifact authenticity.
The proposed stronger mechanism additionally binds actual runtime
state and consequential effect authorization.
26.67.5 — Not Merely Runtime Attestation
A runtime measurement establishes only the supported runtime
properties.
It does not independently establish permission for the actual
resource operation.
26.67.6 — Not Merely Version Pinning
Version pinning may prevent certain unwanted software changes.
The proposed stronger implementation also governs how pending
finality is fenced, revalidated, and reconstituted when authorized
lifecycle changes occur.
26.67.7 — Not Merely Continuous Deployment
A deployment system can switch between software versions.
The proposed mechanism also preserves operation-specific authority
and protected consumption across the transition.
26.67.8 — Not Merely Software Rollback Protection
An update system can detect selected rollback attacks.
The proposed mechanism separately prevents rollback of executable
code from resurrecting consumed consequential authority.
26.67.9 — Not Merely a Tool Allowlist
A tool allowlist may permit a named interface.
The proposed mechanism verifies the actual loaded generation and
resource operation corresponding to that interface.
Das Expires 29 April 2027 [Page 472]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.6.3.68. Source page 2236 of the original specification
26.67.10 — Candidate Narrow Inventive Kernel
A protected autonomous tool-lifecycle execution-finality system in
which a consequential Candidate Act is bound to required
authenticated tool-runtime and effect-contract properties, a
protected controller detects a material lifecycle transition
affecting those properties and fences dependent pending authority, a
current validation instance qualifies the successor effective runtime
and actual operation scope, new scoped non-bearer finality is
constituted when required, and an independent Finality Sink
reconstructs the actual pending consequential effect and permits it
only after verification of current lifecycle correspondence, source
authority, actual resource semantics, and sink-local protected
consumption.
26.67.11 — Selective Lifecycle-Dependency Kernel
A narrower candidate may require operation-specific dependency
projection so that material changes are detected without invalidating
operations unaffected by the change.
26.67.12 — In-Flight Transition Kernel
Another candidate may require protected classification of in-flight
effects before generation switchover, preserving consumed and
indeterminate authority states.
26.67.13 — Authority-Nonrollback Kernel
Another candidate may require rollback of executable artifacts under
a new protected lifecycle generation without rollback of source
revocation or sink-local consumption state.
26.67.14 — Dual-Generation Kernel
Another candidate may require two concurrently active runtime
generations to share original source authority without duplicating
operation-specific finality consumption.
26.67.15 — Attestation-and-Effect Kernel
Another candidate may require both qualified runtime-state evidence
and independent actual resource-effect verification, neither alone
being sufficient to establish finality.
26.67.16 — Hindsight Analysis
Das Expires 29 April 2027 [Page 473]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A later comparison should identify the closest earlier system that
combines software-lifecycle management with operation-specific
consequential authorization.
The analysis should not assert that signatures, build provenance,
update rollback protection, runtime measurements, or version pinning
are independently new.
The meaningful technical question is whether an earlier system
already teaches a dependency relationship in which:
A previously authorized Candidate Act is associated with qualified
effect-relevant runtime state;
5.6.3.69. Source page 2237 of the original specification
A material update invalidates or fences its pending finality;
The successor runtime is independently qualified;
The actual resource operation is revalidated;
And the Finality Sink enforces the current lifecycle and consumption
state.
The corresponding comparative experiments may isolate the technical
effect of those dependencies.
26.68 — INDUSTRIAL APPLICABILITY
26.68.1 — Enterprise Autonomous Agents
Tool updates may occur without silently expanding resource-operation
authority.
26.68.2 — Software Development Agents
Build tools and deployment connectors may be governed across
upgrades.
26.68.3 — Cloud Orchestration
Infrastructure tools may change versions while protected resource
creation and modification remain bounded.
26.68.4 — Database Administration
Das Expires 29 April 2027 [Page 474]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A database connector update may not silently authorize new record
mutations.
26.68.5 — Financial Systems
Payment-tool lifecycle changes may remain subordinate to current
transaction authority.
26.68.6 — Electronic Commerce
Purchasing and fulfillment tools may be verified across software
updates.
26.68.7 — Credential Brokers
Credentialed services may change implementations without inheriting
unrestricted new effect authority.
26.68.8 — Operating Systems
Privileged tool and service updates may be bound to protected
operation-specific enforcement.
5.6.3.70. Source page 2238 of the original specification
26.68.9 — Containerized Infrastructure
Image changes may trigger runtime qualification and current finality
checks.
26.68.10 — Virtualized Workloads
Runtime migration may maintain current source-authority and
generation boundaries.
26.68.11 — Browser and Computer-Use Agents
Automation adapters may change while protected application actions
remain independently verified.
26.68.12 — Network Management
Updated network-control software may remain bound to authorized
configuration effects.
26.68.13 — Telecommunications
Das Expires 29 April 2027 [Page 475]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Software-defined infrastructure controllers may be updated without
silent command-authority expansion.
26.68.14 — Industrial Automation
Device-controller changes may be checked against actual physical
command semantics.
26.68.15 — Robotics
Motion and actuation tools may remain subject to current runtime and
hardware finality.
26.68.16 — Autonomous Transportation
Selected control software transitions may be verified against current
operation scope.
26.68.17 — Satellite and Edge Systems
Remote tool updates may preserve bounded command and resource
authority.
26.68.18 — Hardware Accelerators
Relevant driver or runtime changes may trigger effectuation-path
revalidation.
26.68.19 — Persistent Agent Memory
Updated persistence connectors may remain subject to protected
memory-commit authorization.
26.68.20 — Future Autonomous Critical Systems
5.6.3.71. Source page 2239 of the original specification
Dynamic software lifecycle changes may remain separate from actual
consequential authority.
26.69 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
26.69.1 — Candidate Independent System Claim
A system comprising:
Das Expires 29 April 2027 [Page 476]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A protected tool-lifecycle controller configured to maintain
authenticated artifact, runtime, and tool-effect contract state for
an autonomous computational workload;
A Candidate Act controller configured to associate a proposed
consequential operation with required current tool and runtime
properties;
A transition controller configured to identify material changes in
the required properties and fence dependent pending finality
authority;
An independent validator configured to qualify a successor effective
runtime and current operation-specific source authority;
A finality controller configured to constitute scoped non-bearer
finality enablement under current qualified lifecycle conditions;
And an independent Finality Sink configured to reconstruct the actual
pending consequential operation and permit the effect only upon
verification of current tool-lifecycle correspondence, actual
resource and operation scope, and protected sink-local consumption.
26.69.2 — Candidate Independent Method Claim
A method comprising:
Qualifying an autonomous tool artifact;
Establishing current effective runtime identity;
Associating a consequential Candidate Act with required tool and
operation properties;
Identifying a software lifecycle transition;
Determining whether the transition affects one or more required
properties;
Fencing dependent pending consequential authority where required;
Qualifying successor runtime state;
Revalidating current source-authorized operation semantics;
Das Expires 29 April 2027 [Page 477]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.6.3.72. Source page 2240 of the original specification
Constituting operation-specific non-bearer finality;
And independently verifying the actual effect at a designated
Finality Sink before protected consumption and effectuation.
26.69.3 — Candidate Independent Lifecycle-Fencing Claim
A protected tool-transition system configured to invalidate pending
operation-specific finality following material changes to executable
identity, relevant dependencies, privileges, tool-effect contracts,
or effectuation coverage, while preserving eligible authority for
operations whose required properties remain sufficiently qualified.
26.69.4 — Candidate Independent Rollback Claim
A protected rollback controller configured to permit a qualified
earlier software artifact to be activated under a current lifecycle
generation without restoring earlier consumed, revoked, or otherwise
invalid consequential authority.
26.69.5 — Candidate Independent Multi-Generation Claim
A system configured to maintain multiple active tool generations with
generation-specific actual-operation validation while preventing
duplicate consumption of originating consequential authority across
the generations.
26.70 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
1. The tool is an executable application. 2. The tool is a plugin.
3. The tool is a script. 4. The tool is a dynamically loaded
module. 5. The tool is a containerized service. 6. The tool is a
remote application connector. 7. The tool is a privileged operating-
system service. 8. The tool is a device controller. 9. An artifact
digest identifies selected executable bytes. 10. A protected
provenance record identifies the qualified software origin. 11. A
protected installation gate verifies current lifecycle authority. 12.
A software installation is represented as a separate Candidate Act.
13. Installation authority is distinct from resource-operation
authority. 14. A protected activation controller qualifies current
runtime identity. 15. The effective runtime identity includes
relevant executable properties. 16. The effective runtime identity
includes required dependency properties. 17. The effective runtime
identity includes material configuration properties. 18. The
effective runtime identity includes current privilege conditions. 19.
The effective runtime identity includes an applicable tool-effect
Das Expires 29 April 2027 [Page 478]
Internet-Draft Execution-Finality Part 7: Tools October 2026
contract. 20. A current runtime generation is maintained in
protected state. 21. A tool-effect contract identifies actual or
expected consequential operation classes. 22. A tool-effect contract
is associated with an authenticated generation.
5.6.3.73. Source page 2241 of the original specification
23. A Candidate Act is associated with required tool-runtime
properties. 24. The Candidate Act remains non-effective pending
finality. 25. A protected controller identifies material lifecycle
changes. 26. A lifecycle change may include executable replacement.
27. A lifecycle change may include dependency substitution. 28. A
lifecycle change may include plugin installation. 29. A lifecycle
change may include hot reload. 30. A lifecycle change may include
privilege expansion. 31. A lifecycle change may include a remote
connector replacement. 32. A lifecycle change may include tool
migration to another execution domain. 33. A change may be
classified as materially affecting one Candidate Act but not another.
34. A protected dependency projection identifies the required
properties of a selected
operation. 35. An unrelated qualified change may preserve continued
eligibility. 36. A material tool-effect change activates a protected
lifecycle fence. 37. A material resource change activates current
resource revalidation. 38. A material privilege change does not
independently expand source authority. 39. A lifecycle fence
prevents affected actual consequential effects. 40. The fence is
enforced at or through the relevant Finality Sink. 41. A protected
transition record identifies predecessor and successor generations.
42. A current qualified successor may be activated through a
protected switch. 43. Multiple tool generations may be active during
a controlled rollout. 44. Finality eligibility may be generation-
specific. 45. A single-use authority is not duplicated across
concurrent generations. 46. A pending old-generation Candidate Act
may be revalidated under a current
equivalent-generation rule. 47. An incompatible old-generation
authority reference is rejected. 48. A protected source-authority
generation remains independently verified. 49. A current credential
generation may be required. 50. A current tool-effect contract may
be verified at execution time. 51. Actual loaded-code evidence may
contribute to runtime qualification. 52. Runtime attestation may
supply selected configuration evidence. 53. Attestation evidence is
qualified according to its actual observation scope. 54. A signed
artifact does not independently establish permission for all effects.
55. A build-provenance record does not independently establish
current resource-
Das Expires 29 April 2027 [Page 479]
Internet-Draft Execution-Finality Part 7: Tools October 2026
operation authorization. 56. A software rollback is subject to
current lifecycle authority. 57. A rollback may activate older
executable bytes under a new lifecycle generation. 58. A rollback
does not restore previously consumed finality authority. 59. A
rollback does not automatically restore revoked source permission.
60. A protected minimum generation may prevent prohibited rollback.
61. A protected emergency rollback may preserve mandatory resource-
authority checks. 62. In-flight effects are classified during
lifecycle transition. 63. A completed external effect remains
represented in protected outcome state after
update. 64. An uncertain remote effect is not automatically treated
as unsuccessful. 65. A protected journal preserves finality
consumption across runtime restart. 66. A fresh finality enablement
may be constituted following qualified current
revalidation. 67. A materially different operation requires current
source permission.
5.6.3.74. Source page 2242 of the original specification
68. The Finality Sink independently reconstructs the actual pending
consequential
operation. 69. The sink verifies actual resource identity. 70. The
sink verifies current lifecycle correspondence. 71. The sink
verifies current source-authorized effect scope. 72. The sink
verifies current tool and privilege generations. 73. The sink
verifies required effectuation coverage. 74. The sink verifies
protected non-bearer finality enablement. 75. The sink verifies
sink-local protected consumption. 76. A copied old finality
reference cannot independently authorize a successor-generation
operation. 77. A qualified actual-effect receipt may identify the
tool generation involved in the
effect. 78. A specified CW-2 successor may require a valid earlier
actual-effect receipt without
treating the old tool's current availability as proof of completion.
79. A CW-3 scope deviation may require new authorization when the
tool update
introduces a genuinely expanded consequential effect. 80. Existing
software update, artifact provenance, attestation, version
management, and
Das Expires 29 April 2027 [Page 480]
Internet-Draft Execution-Finality Part 7: Tools October 2026
resource-control technologies may be combined as optional
implementation substrates.
26.71 — UNIVERSAL COMBINATION, SUBCOMBINATION, AND NON-LIMITING
PHOSITA CLAUSE
The present embodiment may be implemented using selected compatible
combinations of software-lifecycle, runtime-identity, authority-
validation, and Finality-Sink mechanisms.
An implementation may use content-addressed artifacts.
Another may use signed package metadata.
Another may use qualified build provenance.
Another may use remote runtime attestation.
Another may use an authenticated software registry.
Another may use dependency-generation records.
Another may use runtime configuration commitments.
Another may use versioned tool-effect contracts.
Another may use a protected lifecycle-transition database.
Another may use a protected privilege-transition controller.
Another may use staged deployment with old and new generations.
5.6.3.75. Source page 2243 of the original specification
Another may use operation-specific dependency projections to avoid
unnecessary invalidation.
Another may require strict generation pinning.
Another may permit qualified operation-equivalent generations.
Another may implement protected rollback.
Another may implement emergency recovery.
Another may employ a hardware Finality Sink.
Another may use remote resource-side enforcement.
Das Expires 29 April 2027 [Page 481]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Another may use qualified real-effect receipts for subsequent
dependent workflows.
The invention is not limited to any one software package format,
operating system, programming language, container architecture,
attestation protocol, cryptographic algorithm, or vendor
implementation.
Where a particular implementation requires artifact provenance, the
protected controller must verify the corresponding actual provenance
properties.
Where runtime attestation is required, the measurement must support
the state claims relied upon by the selected operation.
Where software semantic equivalence is required, an arbitrary
declaration that two versions are equivalent is insufficient without
the applicable protected predicate or authorized equivalence policy.
A software installation authorization does not independently expand
the source-authorized resource-effect envelope.
A runtime update does not independently invalidate a completed
historical actual effect.
A software rollback does not automatically reverse protected
consumption state.
A protected lifecycle fence applies to the actual covered
effectuation paths under the stated enforcement model.
An implementation need not freeze every active operation during a
tool update if a protected method can establish which pending
operations remain unaffected.
Conversely, where the required runtime or effectuation properties
cannot be established, a mandatory consequential operation must
remain withheld.
The pseudocode, equations, data structures, diagrams, experiments,
and examples are non-limiting technical aids for a PHOSITA.
5.6.3.76. Source page 2244 of the original specification
Features from compatible embodiments may be combined without making
every optional feature mandatory.
26.72 — FINAL TECHNICAL CHARACTERIZATION
Das Expires 29 April 2027 [Page 482]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The present Embodiment 26 discloses a protected execution-finality
architecture for autonomous computational systems undergoing
software-tool and runtime lifecycle transitions.
A software artifact may be authenticated and installed under valid
lifecycle authority.
The actual runtime may be qualified through selected executable,
dependency, configuration, privilege, and effect-contract evidence.
A consequential operation proposed by an autonomous entity is
represented as a Candidate Act and associated with its required
runtime and tool properties.
A protected lifecycle controller identifies material changes
affecting those properties.
Pending authority dependent upon incompatible earlier lifecycle state
is fenced.
Qualified equivalent updates may preserve operation eligibility where
the current protected predicates remain satisfied.
Material changes may require independent execution-time revalidation
and reconstitution of operation-specific non-bearer finality.
Multiple tool generations may coexist subject to current generation-
specific authority and shared protected consumption state.
Rollback to older executable code may occur under current lifecycle
authorization without resurrecting revoked or previously consumed
consequential authority.
At the actual resource boundary, the Finality Sink independently
reconstructs the pending operation and verifies the qualified current
lifecycle state, original source authorization, actual resource
identity, permitted effect semantics, and sink-local protected
consumption before permitting the consequence.
The architecture may use existing artifact signatures, build
provenance, software-update verification, runtime measurements,
isolation technologies, transactional databases, and resource
gateways.
The principal candidate inventive technical concept of Embodiment 26
is a protected autonomous tool-lifecycle execution-finality system in
which pending consequential Candidate Acts are bound to qualified
effect-relevant tool and runtime state, material lifecycle changes
Das Expires 29 April 2027 [Page 483]
Internet-Draft Execution-Finality Part 7: Tools October 2026
cause protected selective fencing and current revalidation,
operation-specific non-bearer finality is reconstituted where
required, and an independent
5.6.3.77. Source page 2245 of the original specification
Finality Sink verifies the actual executing generation and real
pending resource operation before consuming authority and permitting
effectuation.
26.73 — SHORT PHOSITA IMPLEMENTATION USING EXISTING TECHNOLOGIES
A PHOSITA may use the following established technologies as optional
building blocks.
Existing technology Optional technical role Software signing and
authenticated package metadata Qualify artifact origin and integrity
The Update Framework Support authenticated software updates, metadata
freshness, delegation, and selected rollback protections
SLSA build provenance Describe the software artifact and supported
build-origin properties Content-addressed artifact or container-image
digests Identify specific image or executable content
Software bills of materials Identify declared software dependencies
for qualified verification Runtime attestation under a RATS-
compatible architecture
Supply evidence regarding selected current execution properties
Containers and restricted workers Execute qualified tools within
controlled environments
Versioned tool contracts Describe actual effect-capable interfaces
and permitted operation semantics
Transactional databases Maintain lifecycle generations, transition
fences, finality records, and consumption Authenticated IPC and
protected tool brokers
Mediate privilege transitions and actual tool-resource operations
Conditional resource APIs Enforce selected current resource-version
predicates Protected API, filesystem, database, or hardware sinks
Enforce the actual consequential operation
Durable operation journals Preserve consumed and unresolved effects
through updates and crashes
Das Expires 29 April 2027 [Page 484]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Non-Limiting Reference Implementation
Qualified software artifact → protected installation authority →
actual runtime qualification → tool-effect contract → Candidate Act →
lifecycle dependency commitment → material update detection →
protected finality fence → successor validation → non-bearer finality
reconstitution → actual Finality-Sink generation and operation
verification → protected consumption → controlled consequential
effect.
The established technologies provide useful implementation
substrates.
5.7. Embodiment 34 — Dynamic Tool/Service Identity, Capability
Substitution and Alias-Rebinding Resistance
Original global source pages 2914 through 3005, inclusive. Source
file: TECHNICAL SPECIFICATION -2567-3101.pdf. This is a primary Part
7 source unit; the author should compare embedded extracts with the
original source file before publication.
5.7.1. Embodiment-Specific Architecture and Trust Relationship
[Source approved operation + endpoint class]
|
[Tool registry / service discovery / DNS / alias]
|
[Protected identity + tenant + capability lineage]
|
[Current endpoint generation and routing evidence]
|
[Candidate Act scope and protected enablement]
|
[FS observes ACTUAL receiving workload/object]
|
[Verify actual effect, audience and consumption]
/MATCH \SUBSTITUTED
[Permit bounded effect] [WITHHOLD]
Figure 13: Embodiment 34 — Dynamic Tool/Service Identity, Capability
Substitution and Alias-Rebinding Resistance — protected architecture
5.7.2. Operational Security Decision Flowchart
Das Expires 29 April 2027 [Page 485]
Internet-Draft Execution-Finality Part 7: Tools October 2026
[Approved logical name / tool / service]
|
<Discovery evidence trusted/current?>-NO->[REFUSE]
|YES
[Bind canonical resource identity and capability]
|
<Endpoint, tenant, version or route changes?>-YES->[REVALIDATE]
|NO
[Receiving FS reconstructs exact operation]
|
<Scope/actual identity/current epoch match?>-NO->[FENCE]
|YES
[Atomic consume and controlled effect]
Figure 14: Embodiment 34 — Dynamic Tool/Service Identity, Capability
Substitution and Alias-Rebinding Resistance — refusal and controlled-
effect decisions
5.7.3. Original Technical Disclosure with Global-Page Anchors
5.7.3.1. Source page 2914 of the original specification
END OF EMBODIMENT 33 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 34
PROTECTED AUTONOMOUS RESOURCE AND TOOL IDENTITY CONTINUITY WITH
ALIAS-REBINDING RESISTANCE, CAPABILITY-SUBSTITUTION PREVENTION, AND
INDEPENDENT EXECUTION-FINALITY ACROSS DYNAMIC SERVICE DISCOVERY
34.0 — COMPLETE TECHNICAL TITLE
Systems, Methods, and Apparatus for Governing Autonomous
Consequential Operations Through Protected Requested-to-Actual
Resource Identity Continuity, Authenticated Service-Discovery and
Alias-Resolution Evidence, Operation-Specific Tool-Contract and
Capability Correspondence, Dynamic Endpoint and Workload-Identity
Qualification, Resolution-Generation Fencing, Protected Substitution
and Migration Validation, Cross-Committed Identity and Effect
Evidence, Scoped Non-Bearer Finality Enablement, and Independent
Finality-Sink Reconstruction and Consumption at the Actual Receiving
Resource
34.0.1 — General Technical Description
The present Embodiment 34 discloses systems, methods, apparatus,
protected computing components, resource-identity registries,
service-discovery controllers, autonomous tool registries,
Das Expires 29 April 2027 [Page 486]
Internet-Draft Execution-Finality Part 7: Tools October 2026
authenticated endpoint resolvers, protected capability descriptors,
resource identity continuity validators, service-migration
controllers, operation-specific authorization gateways, independent
evidence collectors, and actual Finality Sinks configured to prevent
consequential operations from becoming effective against a resource,
service, tool, account, device, or other receiving entity materially
different from that authorized by the originating principal.
An autonomous computational workload may be instructed to perform an
operation upon a specifically identified resource.
The workload may generate a command, invoke a named tool, resolve a
resource alias, select a service endpoint, obtain an access
credential, initiate a network connection, and submit a consequential
request.
The resource may be represented to the workload through:
A domain name; A network address; A uniform resource
identifier; A service-discovery name; A workload identity; A
cloud resource reference; A database record identifier; A
filesystem path; An object-storage key; A device address;
5.7.3.2. Source page 2915 of the original specification
A hardware controller identifier; A tool name; A tool registry
entry; A function name; An API route; A resource alias; A
virtual-host identifier; A tenant identifier; A credential
audience; A logical deployment name; A symbolic link; A service
proxy; A queue destination; Or another direct or indirect
resource reference.
Such identifiers may be used to locate services, organize resources,
support abstraction, and permit replacement of implementation
components.
However, an identifier supplied during operation planning does not
necessarily identify the actual resource that will receive the
consequential effect.
A domain name may resolve to different network addresses over time.
An address may be reassigned to another workload.
A service-discovery record may select a new endpoint.
An HTTP redirect may change the effective destination.
Das Expires 29 April 2027 [Page 487]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A proxy may forward a request to another backend service.
A filesystem path may be replaced with a symbolic link pointing to a
different file.
A resource alias may be rebound to another cloud account.
A tool registry may associate the same tool name with a different
implementation.
A previously available function may change its operation schema.
A tool that formerly performed a read-only operation may acquire a
state-changing side effect.
A service endpoint may retain the same hostname while its tenant
binding changes.
A storage object may be replaced while retaining the same human-
readable key.
A workload instance may be replaced during a rolling software
deployment.
An existing connection may be reused after the service's applicable
authorization state changes.
5.7.3.3. Source page 2916 of the original specification
A delegated credential may remain cryptographically valid while
referring to a different protected resource or audience.
A legitimate service may also migrate from one physical host to
another without any unauthorized change to its logical resource
identity or permitted operation semantics.
Accordingly, security cannot universally be achieved merely by
pinning a resource to one fixed network address.
Nor can correct consequential authority be established solely by
requiring that the same textual tool name be used.
The present embodiment provides a protected distinction among:
Requested identity; discovered endpoint; authenticated receiving
identity; actual resource identity; actual tool semantics; current
source and resource permission; and consequential finality.
Das Expires 29 April 2027 [Page 488]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The protected system establishes an operation-specific Authorized
Target Descriptor for each covered Candidate Act.
The descriptor may identify the requested logical resource, permitted
actual resource identity or identity class, qualified service
principal, tenant scope, allowed tool semantics, credential audience,
required operation parameters, and designated Finality Sink.
The Candidate Act remains in a Non-Effective State while relevant
identity and operation conditions are qualified.
A protected discovery controller obtains service-resolution evidence.
An independent validator checks the actual endpoint, authenticated
workload or service identity, qualified resource owner, tool-contract
generation, resource version, and material operation semantics.
Where the resolved endpoint differs from that initially observed, the
controller determines whether the change is a permitted
implementation substitution or a material authority-changing
substitution.
A permitted migration may proceed after current identity and effect
correspondence are established.
A material substitution may cause the pending operation's finality to
be fenced.
An unresolved identity discrepancy causes the effect to remain
withheld where the relevant identity predicate is mandatory.
A scoped non-bearer finality enablement is constituted only for the
qualified actual operation and target.
5.7.3.4. Source page 2917 of the original specification
The actual Finality Sink reconstructs or directly observes the
operation as presented to the receiving resource.
The sink verifies correspondence among the authorized Candidate Act,
actual resource identity, service or workload identity, material
request parameters, current tool behavior, protected evidence, and
sink-local consumption state.
If the actual effect would occur upon a different resource, under a
different authority domain, or through a materially changed
operation, the previously prepared enablement is insufficient.
Das Expires 29 April 2027 [Page 489]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The system may permit qualified service migrations, load-balanced
endpoints, virtualized workloads, dynamic discovery, and controlled
tool upgrades without treating every endpoint change as a security
violation.
However, a change of location or implementation does not
automatically establish equivalence of actual resource authority.
34.0.2 — Fundamental Technical Principle
A resource name is not proof of the identity of the resource that
will receive an actual effect.
Further:
A valid DNS response is not automatically a source authorization.
An authenticated network endpoint is not automatically the intended
resource.
A valid server certificate does not prove that a particular tenant or
resource object is authorized.
A stable tool name does not guarantee unchanged tool behavior.
A valid tool schema does not prove that the implementation conforms
to the schema.
A valid access token does not necessarily authorize a different
resource audience.
An identical IP address does not necessarily identify the same
application or tenant.
A legitimate service migration need not invalidate authority where
the intended resource and operation remain qualified.
A valid redirect does not independently authorize the redirected
destination.
An approved filesystem path does not automatically authorize a
different actual object reached through alias replacement.
A previously valid service-discovery decision does not automatically
remain sufficient after a material rebinding.
Das Expires 29 April 2027 [Page 490]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.7.3.5. Source page 2918 of the original specification
And successful authentication of a tool provider cannot substitute
for actual Finality-Sink verification of the consequential operation.
34.0.3 — Principal Candidate Inventive Combination
A representative implementation comprises:
(a) an originating source-authorized Candidate Act;
(b) an enforceable Non-Effective State;
(c) a protected Authorized Target Descriptor;
(d) a qualified service-discovery or resource-resolution record;
(e) an authenticated actual receiving-principal identity;
(f) an operation-specific tool-contract and effect descriptor;
(g) a protected mapping between logical identity and permitted actual
target identity;
(h) a resource or tool resolution generation;
(i) a protected classifier distinguishing qualified migration from
material substitution;
(j) a dependency fence for affected pending finality;
(k) independent execution-time resolution and operation validation;
(l) cross-committed collection-time and execution-time identity
evidence;
(m) scoped non-bearer finality enablement;
(n) independent actual Finality-Sink reconstruction of the pending
operation;
(o) sink-local verification of current target, operation, authority,
and protected consumption.
34.0.4 — Candidate Technical Distinction
The embodiment does not claim as individually new:
Das Expires 29 April 2027 [Page 491]
Internet-Draft Execution-Finality Part 7: Tools October 2026
DNS resolution;
DNS security extensions;
TLS authentication;
Mutual TLS;
5.7.3.6. Source page 2919 of the original specification
Service discovery;
Workload identity;
Endpoint pinning;
Redirect filtering;
Resource identifiers;
Object identifiers;
Tool schemas;
API versioning;
Credential audience restrictions;
Cryptographic signatures;
Or resource access-control lists.
The proposed technical contribution concerns how changes in those
identities, mappings, and tool implementations control the
eligibility of a held, source-authorized consequential Candidate Act
and are independently verified at the actual resource-effectuation
boundary.
34.0.5 — Relationship to Earlier Embodiments
The present embodiment may incorporate earlier mechanisms for:
Protected source authority;
Candidate Act non-effectuation;
Protected evidence collection;
Das Expires 29 April 2027 [Page 492]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Independent execution-time validation;
Resource ownership and administrative continuity;
Credential-generation binding;
Tool lifecycle and policy evolution;
Memory provenance;
Multi-agent delegation;
And protected Finality-Sink consumption.
5.7.3.7. Source page 2920 of the original specification
The focused subject is the continuity of actual resource and tool
identity between authorization, discovery, invocation, and
effectuation.
34.0.6 — Non-Limiting Reference Architecture
ORIGINATING PRINCIPAL | v AUTHORIZED RESOURCE ACT | v CANDIDATE ACT |
v NON-EFFECTIVE HOLD | v AUTHORIZED TARGET DESCRIPTOR |
+----------+-----------+ | | v v RESOURCE IDENTITY TOOL CONTRACT AND
AUTHORITY AND ACTUAL EFFECT | | +----------+-----------+ | v
PROTECTED DISCOVERY | v RESOLVED ENDPOINT EVIDENCE | v ACTUAL
IDENTITY QUALIFICATION | +---------+----------+ | | v v QUALIFIED
MATERIAL OR CONTINUITY UNKNOWN CHANGE | | | v | FINALITY FENCE | | |
v | REVALIDATION | | +---------+----------+ | v
5.7.3.8. Source page 2921 of the original specification
CURRENT AUTHORITY AND EFFECT VALIDATION | v NON-BEARER FINALITY | v
ACTUAL FINALITY SINK | v RECONSTRUCT REAL TARGET AND PENDING
OPERATION | v CURRENT IDENTITY + RESOURCE + SEMANTICS + FINALITY
CHECK | v PROTECTED CONSUMPTION | v CONTROLLED REAL EFFECT
All diagrams and implementation structures are non-limiting technical
aids for a person having ordinary skill in the art.
34.1 — TECHNICAL FIELD
Das Expires 29 April 2027 [Page 493]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The present invention relates to distributed service identity,
workload authentication, resource resolution, service discovery,
autonomous tool execution, authorization continuity, service
migration, resource alias security, request canonicalization,
endpoint authentication, API contract qualification, and independent
consequential execution-finality enforcement.
More particularly, the invention concerns preventing resource or tool
substitution from changing the actual effect of an autonomously
generated operation after its source authorization has been
established.
34.2 — SPECIFIC TECHNICAL PROBLEMS
34.2.1 — Name-to-Resource Ambiguity
A human-readable name may identify several distinct resources over
time.
34.2.2 — Discovery-Time Versus Execution-Time Target
The endpoint discovered during planning may differ from the endpoint
actually used.
5.7.3.9. Source page 2922 of the original specification
34.2.3 — DNS Rebinding
A hostname may resolve to a different address after initial
authorization.
34.2.4 — DNS Answer Integrity Versus Resource Authority
Even a correctly authenticated DNS answer does not inherently
establish original task permission for the destination.
34.2.5 — Redirect Substitution
A request may be redirected to a materially different destination.
34.2.6 — Proxy Backend Rebinding
A trusted front-end service may forward a request to an unauthorized
backend.
34.2.7 — Same IP, Different Service
Several services or tenants may share one network address.
Das Expires 29 April 2027 [Page 494]
Internet-Draft Execution-Finality Part 7: Tools October 2026
34.2.8 — Different IP, Same Service
A legitimate service may move across hosts or network locations.
34.2.9 — Workload Instance Replacement
A service instance may be restarted or redeployed with a new identity
credential.
34.2.10 — Logical Service Versus Workload Instance
A logical service may comprise several instances having distinct
cryptographic identities.
34.2.11 — Cross-Tenant Alias Rebinding
A resource alias may resolve to a different tenant's object.
34.2.12 — Cross-Account Resource Substitution
A stable resource name may map to another cloud account.
34.2.13 — Tool Registry Replacement
A named tool may be replaced with another implementation.
34.2.14 — Tool Semantic Drift
A tool may retain its name but change its actual consequences.
34.2.15 — Schema-Compatible Malicious Behavior
5.7.3.10. Source page 2923 of the original specification
A tool may satisfy a syntactic schema while performing unauthorized
side effects.
34.2.16 — Tool Version Ambiguity
A version label may not uniquely identify a particular
implementation.
34.2.17 — Tool Description Poisoning
A lower-trust tool description may misrepresent actual required
permissions.
34.2.18 — Parameter Interpretation Change
Das Expires 29 April 2027 [Page 495]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An API may interpret a previously valid parameter differently.
34.2.19 — HTTP Method Substitution
An approved read may become an actual state-changing request.
34.2.20 — Resource Path Normalization
Different URI or filesystem parsers may interpret the same submitted
text differently.
34.2.21 — Multiple Encoding Layers
Repeated decoding may alter the effective resource path.
34.2.22 — Filesystem Symbolic-Link Replacement
A permitted pathname may resolve to an unauthorized file.
34.2.23 — File Descriptor Versus Path Identity
The object opened at effectuation may differ from the object checked
earlier.
34.2.24 — Object Storage Rebinding
A storage key may identify a newly replaced object.
34.2.25 — Database Identity Reassignment
A logical record reference may point to a different underlying record
or tenant.
34.2.26 — Device Address Reassignment
A device bus or controller address may be reassigned.
34.2.27 — Hardware Command Substitution
A controller command may reach a different physical actuator.
5.7.3.11. Source page 2924 of the original specification
34.2.28 — Credential Audience Confusion
A credential may be valid for one resource service but presented to
another.
Das Expires 29 April 2027 [Page 496]
Internet-Draft Execution-Finality Part 7: Tools October 2026
34.2.29 — Authenticated Wrong Destination
The receiver may be authentically identified but not the resource
authorized by the task.
34.2.30 — Delegated Service Trust Expansion
A service may delegate requests to an endpoint outside its qualified
authority envelope.
34.2.31 — Service Discovery Cache Staleness
A cached discovery result may no longer be current.
34.2.32 — Resolution Race
The actual target may change between validation and resource
effectuation.
34.2.33 — Endpoint Failover
An availability mechanism may route a request to a successor
instance.
34.2.34 — Unqualified Failover
A backup endpoint may lack the same tenant, authority, or operation
guarantees.
34.2.35 — Load-Balancing Equivalence
Different instances may legitimately represent the same protected
logical service.
34.2.36 — Incomplete Service-Identity Evidence
A TLS connection may authenticate a hostname without proving the
intended underlying resource identity.
34.2.37 — Tool Capability Expansion
A tool may acquire a new dangerous operation through an update.
34.2.38 — Tool Capability Removal
A previously approved tool operation may no longer be supported.
34.2.39 — Tool-to-Tool Indirection
Das Expires 29 April 2027 [Page 497]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A registered tool may call another tool or backend with different
effect semantics.
34.2.40 — Multiple Proxy Hops
5.7.3.12. Source page 2925 of the original specification
An operation may traverse several destinations before reaching the
actual resource.
34.2.41 — Redirect Loop and Exhaustion
A request may be redirected indefinitely or through excessive chains.
34.2.42 — Resource Identity After Authentication
The actual target resource may change even after the service
principal is authenticated.
34.2.43 — Trusted Gateway With Wrong Target
A gateway may enforce authorization on a proposed resource while
forwarding to a different one.
34.2.44 — Indeterminate Effect After Failover
An operation may have committed at a predecessor endpoint before a
retry reaches the successor.
34.2.45 — Technical Objective
The candidate objective technical problem is:
How to preserve source-authorized identity and consequential
operation semantics across dynamic service discovery, endpoint
selection, resource alias resolution, tool replacement, migration,
and failover while ensuring that the actual receiving resource and
performed effect remain independently verified under current
operation-specific authority and protected finality.
34.3 — ESTABLISHED TECHNICAL FOUNDATIONS
34.3.1 — URI Identification and Normalization
Existing URI specifications define syntax, components, comparison,
and normalization behavior.
Das Expires 29 April 2027 [Page 498]
Internet-Draft Execution-Finality Part 7: Tools October 2026
They do not independently establish that the final resource reached
by a dynamically resolved URI is the source-authorized consequential
target.
34.3.2 — TLS Service Identity
Existing TLS service-identity practices can authenticate selected
reference identifiers against presented credentials.
They do not independently prove permission for every particular
resource object or operation hosted by the authenticated service.
5.7.3.13. Source page 2926 of the original specification
34.3.3 — DNS Service Binding
Existing discovery records can identify alternative service endpoints
and connection parameters.
A discovered alternative endpoint must still be qualified under the
applicable security and authorization model.
34.3.4 — Workload Identity
Existing workload-identity systems can authenticate service
principals.
A workload principal identity is not automatically equivalent to the
specific resource object, tenant, or consequential operation
authorized by the originating task.
34.3.5 — Credential Audience Restriction
Existing authorization protocols can restrict selected tokens to
specified resource audiences.
Audience restriction is distinct from the full set of effect-specific
authorization and sink-local consumption conditions.
34.3.6 — Tool Schemas
Existing tool schemas may specify operation names, parameters, and
types.
A schema does not necessarily prove that the underlying
implementation performs only the declared effects.
34.3.7 — Service Registry Versioning
Das Expires 29 April 2027 [Page 499]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Existing systems support versioned service endpoints and deployments.
A registry version alone does not establish that a pending operation
remains authorized after a material backend change.
34.3.8 — Candidate Additional Relationship
The present embodiment uses these established components as inputs to
a mandatory resource-and-operation continuity condition for actual
protected effectuation.
34.4 — PRINCIPAL TECHNICAL COMPONENTS
A representative implementation comprises:
1. Protected Originating Source-Authority Registry. 2. Candidate
Act Controller. 3. Non-Effective State Controller.
5.7.3.14. Source page 2927 of the original specification
4. Authorized Target Descriptor Constructor. 5. Qualified Service-
Discovery Controller. 6. Actual Resource Identity Registry. 7.
Workload and Service Authentication Validator. 8. Resource Alias-
Resolution Controller. 9. Tool Registry and Contract Controller. 10.
Tool Capability and Effect-Semantics Validator. 11. Protected
Resolution-Generation Controller. 12. Identity-Continuity and
Migration Qualifier. 13. Material Substitution Detector. 14.
Candidate Dependency-Fencing Controller. 15. Independent Execution-
Time Identity Validator. 16. Protected Canonicalization Controller.
17. Credential Audience and Destination Controller. 18. Cross-
Committed Identity-Evidence Controller. 19. Scoped Non-Bearer
Finality Controller. 20. Actual Resource Finality Sink. 21. Sink-
Local Consumption Controller. 22. Qualified Effect Outcome Observer.
23. Protected Discovery and Effect Journal.
Optional components may include:
A service mesh;
A workload identity authority;
An authenticated name resolver;
A file-descriptor-based resource broker;
An object-storage gateway;
A transactional resource database;
Das Expires 29 April 2027 [Page 500]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A protected API proxy;
A hardware command controller;
Or a protected tool-execution gateway.
34.5 — TECHNICAL DEFINITIONS
34.5.1 — Authorized Target Descriptor
An Authorized Target Descriptor, or ATD-34, means a protected
operation-specific representation of the resource identity and
consequential target conditions authorized by the originating
principal.
5.7.3.15. Source page 2928 of the original specification
34.5.2 — Requested Resource Identifier
A Requested Resource Identifier means the logical name, path, URI,
reference, or other descriptor proposed by the autonomous workload.
34.5.3 — Actual Resource Identity
An Actual Resource Identity, or ARI-34, means a qualified identity of
the resource object or receiving authority upon which a consequential
operation actually acts.
34.5.4 — Discovered Endpoint
A Discovered Endpoint means a network or execution location
identified through a resolution or discovery mechanism.
34.5.5 — Authenticated Receiving Principal
An Authenticated Receiving Principal means the service, workload,
device, or receiving component whose identity has been established
under the applicable authentication mechanism.
34.5.6 — Resource Identity Continuity
Resource Identity Continuity, or RIC-34, means the qualified
correspondence between the authorized resource and the actual
resource targeted at effectuation.
34.5.7 — Tool Identity
Das Expires 29 April 2027 [Page 501]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Tool Identity means a qualified reference to a computational
interface through which operations may be requested.
34.5.8 — Tool Implementation Identity
Tool Implementation Identity, or TII-34, means a protected
representation distinguishing a particular implementation or
implementation class behind a tool interface.
34.5.9 — Tool Contract
A Tool Contract means a qualified description of a tool's callable
operations, parameters, effect classes, and relevant semantic
conditions.
34.5.10 — Tool Contract Generation
A Tool Contract Generation, or TCG-34, means a protected version of
the applicable interface and effect semantics.
34.5.11 — Tool Effect Descriptor
A Tool Effect Descriptor, or TED-34, means a representation of the
material resource consequences enabled by a tool operation.
5.7.3.16. Source page 2929 of the original specification
34.5.12 — Tool Capability Envelope
A Tool Capability Envelope means the permitted operations, resource
classes, and effects attributable to a qualified tool under current
authorization.
34.5.13 — Resolution Generation
A Resolution Generation, or RG-34, means a protected version
identifying the qualified state of a logical-to-actual resource
mapping.
34.5.14 — Discovery Evidence
Discovery Evidence means a record of relevant endpoint resolution,
alternative service selection, or tool registration results.
34.5.15 — Identity Continuity Witness
Das Expires 29 April 2027 [Page 502]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An Identity Continuity Witness means qualified evidence that a
proposed receiving resource remains the resource authorized by a
Candidate Act.
34.5.16 — Authorized Identity Equivalence Class
An Authorized Identity Equivalence Class means a protected set or
predicate identifying multiple actual endpoints or instances
authorized to represent the same relevant logical resource.
34.5.17 — Material Resource Substitution
A Material Resource Substitution means a change to actual target
identity that affects mandatory operation-specific authorization.
34.5.18 — Material Tool Substitution
A Material Tool Substitution means replacement of a tool's identity,
implementation, or semantics in a way that changes relevant
consequential authority or actual effects.
34.5.19 — Qualified Service Migration
Qualified Service Migration means a change of service instance or
endpoint that preserves the required authorized identity and
operation predicates under the selected protection model.
34.5.20 — Substitution Fence
A Substitution Fence, or SF-34, means a protected restriction
preventing a Candidate Act from effectuation after a material or
unresolved identity substitution.
34.5.21 — Identity Dependency Set
An Identity Dependency Set, or IDS-34, means the actual target, tool,
workload, tenant, schema, and resource properties upon which a
Candidate Act depends.
5.7.3.17. Source page 2930 of the original specification
34.5.22 — Actual Endpoint Witness
An Actual Endpoint Witness means qualified evidence describing the
endpoint used by a protected connection or dispatch.
34.5.23 — Actual Workload Witness
Das Expires 29 April 2027 [Page 503]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An Actual Workload Witness means qualified evidence describing the
authenticated service principal involved in a protected operation.
34.5.24 — Resource Object Witness
A Resource Object Witness means qualified evidence identifying the
actual object upon which a mutation or disclosure will operate.
34.5.25 — Destination Authority Envelope
A Destination Authority Envelope means a protected definition of
permitted receiving resource principals, audiences, locations, and
applicable scopes.
34.5.26 — Audience Correspondence
Audience Correspondence means verification that a credential or
authorization artifact is eligible for the actual receiving resource.
34.5.27 — Redirect Continuity
Redirect Continuity means qualification of each relevant destination
transition along an operation's redirect path.
34.5.28 — Proxy Continuity
Proxy Continuity means qualification of the actual effect-capable
backend selected behind a proxy or gateway.
34.5.29 — Tool Semantic Continuity
Tool Semantic Continuity means correspondence between the authorized
operation's expected relevant effects and the actual tool
implementation's qualified effect behavior.
34.5.30 — Parameter Semantic Continuity
Parameter Semantic Continuity means preservation of the material
intended meaning of operation parameters across translation or
invocation.
34.5.31 — Canonical Resource Descriptor
A Canonical Resource Descriptor means a protected representation of
resource identity produced under a specified protocol and parser
interpretation.
Das Expires 29 April 2027 [Page 504]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.7.3.18. Source page 2931 of the original specification
34.5.32 — Canonicalization Profile
A Canonicalization Profile means a qualified set of parsing,
normalization, encoding, and identity-comparison rules.
34.5.33 — Parser Correspondence
Parser Correspondence means verification that the interpretation used
for authorization matches the interpretation governing actual
effectuation.
34.5.34 — Alias Rebinding
Alias Rebinding means reassociation of a logical name or reference
with a different actual resource or destination.
34.5.35 — Identity Rebinding Fence
An Identity Rebinding Fence means a protected restriction preventing
affected operations from using materially changed alias mappings.
34.5.36 — Effective Resource Principal
An Effective Resource Principal means the actual authority or tenant
controlling the resource operation under the current receiving
system.
34.5.37 — Effect-Capable Tool
An Effect-Capable Tool means an interface capable of causing a real
or persistent consequential operation.
34.5.38 — Declared Effect Class
A Declared Effect Class means the consequence described by a tool
interface or registration record.
34.5.39 — Observed Effect Class
An Observed Effect Class means the effect category established by
qualified actual operation evidence.
34.5.40 — Tool Effect Mismatch
A Tool Effect Mismatch means a material difference between authorized
and actual operation semantics.
Das Expires 29 April 2027 [Page 505]
Internet-Draft Execution-Finality Part 7: Tools October 2026
34.5.41 — Protected Discovery Snapshot
A Protected Discovery Snapshot means authenticated evidence of
selected resolution mappings at a qualified observation point.
5.7.3.19. Source page 2932 of the original specification
34.5.42 — Execution-Time Resolution
Execution-Time Resolution means obtaining or verifying current target
identity close to actual effectuation.
34.5.43 — Resource-Side Identity Reconstruction
Resource-Side Identity Reconstruction means independently obtaining
actual resource identity at or through the receiving protected
enforcement boundary.
34.5.44 — Target-Bound Non-Bearer Finality
Target-Bound Non-Bearer Finality means scoped enablement requiring
correspondence to the qualified actual receiving target.
34.5.45 — Resolution Continuity Commitment
A Resolution Continuity Commitment means protected evidence binding
initial and current resource-resolution states.
34.5.46 — Qualified Replacement Certificate
A Qualified Replacement Certificate means authenticated evidence that
a replacement endpoint or implementation is eligible within an
authorized continuity rule.
34.5.47 — Target-Specific Consumption
Target-Specific Consumption means sink-local authority use associated
with one actual resource operation and its qualified target.
34.5.48 — Identity Nonresurrection
Identity Nonresurrection means preventing an old alias, credential,
or service-mapping state from restoring invalid or consumed
consequential authority.
34.5.49 — Failover Outcome Continuity
Das Expires 29 April 2027 [Page 506]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Failover Outcome Continuity means preserving actual effect status
when operations move between service instances.
34.5.50 — Protected Actual-Effect Correspondence
Protected Actual-Effect Correspondence means verification that the
operation received and effected by the sink matches the original
source-authorized Candidate Act under its relevant identity and
semantic predicates.
34.6 — FIVE DISTINCT IDENTITY LAYERS
5.7.3.20. Source page 2933 of the original specification
A principal implementation distinguishes five layers.
34.6.1 — Logical Resource Identity
The name or reference presented by the originating task.
34.6.2 — Discovery Identity
The network address, service locator, or registry entry selected for
access.
34.6.3 — Authenticated Service Identity
The service or workload principal established through a qualified
authentication mechanism.
34.6.4 — Actual Protected Resource Identity
The actual object, account, tenant, device, or database record on
which the operation will act.
34.6.5 — Operation-Specific Finality Identity
The exact Candidate Act, protected receiving sink, and actual effect
subject to scoped consequential authority.
A change at one layer may be nonmaterial or material depending upon
the protected operation.
The system does not assume that equality of one layer establishes
equality of all others.
34.7 — AUTHORIZED TARGET DESCRIPTOR
Das Expires 29 April 2027 [Page 507]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A representative record comprises:
AUTHORIZED_TARGET_DESCRIPTOR = { candidate_act_identifier,
original_source_grant_reference, requested_logical_resource,
permitted_actual_resource_identifiers,
permitted_resource_identity_predicate, qualified_service_principal,
permitted_tenant_or_account_scope, permitted_tool_identity,
permitted_tool_contract_generation, permitted_operation_class,
material_operation_parameters, permitted_discovery_equivalence_rules,
credential_audience_constraints, designated_actual_finality_sink,
protected_descriptor_authentication
5.7.3.21. Source page 2934 of the original specification
The descriptor identifies the authorized target conditions rather
than merely preserving a caller-supplied hostname or tool label.
34.7.1 — Exact Target
An operation may require one immutable actual resource identity.
34.7.2 — Equivalent Target Class
An operation may permit several qualified service instances
representing one logical resource.
34.7.3 — Qualified Target Predicate
An operation may permit a target satisfying authenticated resource-
owner, tenant, purpose, and effect constraints.
34.7.4 — No Arbitrary Broadening
The autonomous workload cannot expand the permitted target set merely
by supplying another alias.
34.8 — PROTECTED RESOURCE IDENTITY REGISTRY
A representative registry may contain:
PROTECTED_RESOURCE_IDENTITY = { logical_resource_identifier,
actual_resource_identifier, current_resource_owner,
current_tenant_or_account, qualified_service_principal,
permitted_endpoint_classes, resource_identity_generation,
current_resource_content_generation, applicable_tool_contract,
applicable_policy_generation, current_revocation_generation,
protected_registry_authentication }
Das Expires 29 April 2027 [Page 508]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A protected registry can maintain actual identity independently of
lower-trust service-discovery hints.
34.8.1 — Authority of Registry
5.7.3.22. Source page 2935 of the original specification
The registry must be qualified as authoritative for the identity
properties it supplies.
34.8.2 — Resource-Version Separation
A content change need not change identity.
34.8.3 — Identity Change
A new actual resource identifier may require revalidation even if the
logical alias is unchanged.
34.9 — IDENTITY DEPENDENCY SET
A Candidate Act may depend upon selected identities and semantics.
A representative dependency set includes:
The logical resource reference;
The actual resource UUID or qualified equivalent;
The resource owner or tenant;
The receiving service principal;
The tool operation;
The tool contract generation;
The credential audience;
The material request parameters;
And the designated Finality Sink.
34.9.1 — Dependency Projection
The protected system determines which properties are mandatory for
the actual operation.
Das Expires 29 April 2027 [Page 509]
Internet-Draft Execution-Finality Part 7: Tools October 2026
34.9.2 — Material Change
A change to a mandatory property triggers protected revalidation.
34.9.3 — Nonmaterial Change
A qualified infrastructure migration need not interrupt an otherwise
authorized operation.
5.7.3.23. Source page 2936 of the original specification
34.10 — DYNAMIC SERVICE DISCOVERY
A service-discovery system may provide several endpoints for one
logical service.
For example:
Service A may have Instances A1, A2, and A3.
Instances may have different IP addresses or hostnames.
The origin principal may authorize an operation against the logical
service and a specific customer resource.
The protected system may allow selection among the instances where:
Each endpoint is qualified as representing the permitted service;
The actual resource remains within the authorized tenant and object
scope;
The tool or API semantics remain compatible;
And the actual resource sink enforces the required finality.
34.10.1 — Avoiding Unnecessary Pinning
Permanent pinning to one address is not essential where qualified
identity continuity is established.
34.10.2 — No Implicit Equivalence
Two endpoints returned under the same service name are not
automatically equivalent for all consequential operations.
34.11 — DISCOVERY RESOLUTION RECORD
Das Expires 29 April 2027 [Page 510]
Internet-Draft Execution-Finality Part 7: Tools October 2026
PROTECTED_DISCOVERY_RECORD = { logical_service_name,
discovery_authority_reference, discovered_endpoint_set,
selected_endpoint, endpoint_protocol, endpoint_port,
authenticated_service_principal, qualified_resource_scope,
resolution_generation, discovery_observation_reference,
current_registry_generation, protected_record_authentication
5.7.3.24. Source page 2937 of the original specification
The discovery record contributes identity evidence.
It does not independently authorize a particular payment, disclosure,
database mutation, or device command.
34.12 — DNS REBINDING AND ADDRESS CONTINUITY
A hostname may resolve initially to one address and later to another.
An operation may receive initial authorization before the later
resolution occurs.
The protected system may:
Validate the intended logical service;
Check the current selected destination;
Apply network destination restrictions;
Authenticate the receiving service principal;
Verify the permitted actual resource identity;
And require current operation-specific finality.
34.12.1 — Same Domain, Different Address
May be valid for qualified load balancing.
34.12.2 — Same Domain, Different Authority
May be material if it changes the actual receiving service or
resource.
34.12.3 — Internal-Network Redirection
Das Expires 29 April 2027 [Page 511]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A transition to an unauthorized internal, link-local, or otherwise
restricted endpoint is refused under the applicable destination
policy.
34.12.4 — Actual Connection
Authorization must correspond to the endpoint actually contacted, not
merely an earlier DNS lookup.
34.13 — SERVICE IDENTITY AND TLS AUTHENTICATION
5.7.3.25. Source page 2938 of the original specification
A TLS-authenticated service may present a credential identifying a
qualified DNS name or other permitted service identifier.
A protected controller may verify the presented identity against the
source-authorized service reference.
34.13.1 — Authenticated Service
Establishes selected service identity and connection properties.
34.13.2 — Actual Tenant
May still require independent verification.
34.13.3 — Actual Object
May still require independent verification.
34.13.4 — Consequential Permission
Remains separate from successful connection authentication.
For example, a legitimate API endpoint may host resources belonging
to many users.
Authenticating the API hostname does not authorize an operation
against every user account.
34.14 — WORKLOAD IDENTITY CONTINUITY
A service may be implemented by dynamically scheduled workloads.
Each workload may possess its own qualified identity or credential.
Das Expires 29 April 2027 [Page 512]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The protected service registry may define which workload identities
can represent the permitted logical service.
34.14.1 — Instance Replacement
A new workload instance may be eligible after qualified
authorization.
34.14.2 — Different Workload Principal
May require additional validation.
34.14.3 — Compromised Instance
May be removed from the eligible identity set.
34.14.4 — Source Scope
5.7.3.26. Source page 2939 of the original specification
A qualified replacement workload does not independently enlarge the
original consequential permission.
34.15 — AUTHORIZED IDENTITY EQUIVALENCE
A principal implementation may avoid equating authorization with one
physical endpoint.
[ T_{\mathrm{actual}}\in\mathcal{E}_{CA} ]
(T_{\mathrm{actual}}) represents the actual qualified receiving
target;
And (\mathcal{E}_{CA}) represents the protected set or predicate of
targets authorized for the Candidate Act.
34.15.1 — Fixed Resource
The equivalence class may contain one immutable target.
34.15.2 — Load-Balanced Service
The class may permit selected current authenticated instances of one
service.
34.15.3 — Migration
Das Expires 29 April 2027 [Page 513]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A successor may become eligible through a protected current
continuity transition.
34.15.4 — No Automatic Inclusion
Being returned by a discovery service does not independently
establish membership in the authorized equivalence class.
34.16 — MATERIAL VERSUS NONMATERIAL SUBSTITUTION
A protected substitution classifier may distinguish:
CLASS I — Qualified location change with unchanged authorized
resource and effect.
CLASS II — Qualified workload-instance replacement representing the
same permitted service.
5.7.3.27. Source page 2940 of the original specification
CLASS III — Change in actual resource identity.
CLASS IV — Change in tenant or owner.
CLASS V — Change in actual operation semantics.
CLASS VI — Change in credential audience or service principal.
CLASS VII — Change in designated effectuation sink or mandatory
enforcement path.
CLASS VIII — Unknown or insufficiently qualified substitution.
Class I or II may be permitted when current required predicates
remain valid.
Other classes may require revalidation, new source permission, or
denial.
34.17 — TOOL REGISTRY AND ACTUAL TOOL IDENTITY
An autonomous agent may call a tool named update_record.
The tool registry may associate this name with:
A schema;
An implementation reference;
Das Expires 29 April 2027 [Page 514]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An authenticated provider;
A resource class;
A version;
And an effect contract.
The implementation may change during the workflow.
A protected tool controller does not treat the tool name alone as
sufficient identity.
34.17.1 — Declared Contract
Describes permitted operation types.
34.17.2 — Implementation Identity
Identifies the actual callable implementation or protected
implementation class.
34.17.3 — Current Effect
5.7.3.28. Source page 2941 of the original specification
Identifies the operation the tool actually attempts.
34.17.4 — Finality
Requires independent validation at the actual receiving resource.
34.18 — PROTECTED TOOL CONTRACT
PROTECTED_TOOL_CONTRACT = { tool_logical_name,
qualified_tool_provider, actual_implementation_identity,
tool_contract_generation, tool_schema_digest,
permitted_operation_classes, required_input_parameters,
material_effect_parameters, declared_side_effect_classes,
permitted_resource_scopes, required_credentials,
designated_enforcement_paths, current_tool_revocation_generation,
protected_contract_authentication }
34.18.1 — Syntax
A tool schema can establish expected parameter structures.
34.18.2 — Semantics
Das Expires 29 April 2027 [Page 515]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A separate qualified descriptor specifies material effects.
34.18.3 — Runtime Correspondence
The actual effectuation boundary checks the operation presented for
execution.
34.18.4 — Untrusted Descriptions
Tool-provided descriptions cannot self-authorize new privileged
effects.
34.19 — TOOL CONTRACT SUBSTITUTION
A tool may change while retaining the same name and input schema.
For example:
5.7.3.29. Source page 2942 of the original specification
Version 1 writes a draft report.
Version 2 writes the report and publishes it externally.
The new implementation introduces a consequential disclosure.
The protected controller identifies the changed effect class.
Previously prepared finality for the draft-only effect does not
automatically authorize external publication.
34.19.1 — New Side Effect
Requires corresponding qualified source authority.
34.19.2 — Equivalent Refactoring
May be eligible if mandatory actual effects remain unchanged under
the protected equivalence model.
34.19.3 — Unknown Implementation
An unqualified tool update cannot rely solely on schema compatibility
to establish effect equivalence.
34.20 — TOOL SEMANTIC CONTINUITY
A tool contract may define:
Das Expires 29 April 2027 [Page 516]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The actual operation class;
Required target identity;
Permitted side effects;
Affected resource fields;
External disclosure destinations;
Idempotency conditions;
Credential usage;
And mandatory sink routes.
The system may compare earlier and current contracts.
A material change requires affected Candidate Act revalidation.
5.7.3.30. Source page 2943 of the original specification
34.20.1 — Unchanged API Signature
Does not necessarily imply unchanged effects.
34.20.2 — Changed Implementation Hash
Does not necessarily imply changed authorized effects.
34.20.3 — Qualified Semantic Equivalence
Requires evidence sufficient for the intended protected operation.
34.20.4 — Enforcement
The receiving resource still verifies the actual consequential
operation.
34.21 — PARAMETER INTERPRETATION AND CANONICALIZATION
The authorization controller and receiving resource may parse a
request differently.
A path may contain:
Percent-encoding;
Das Expires 29 April 2027 [Page 517]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Reserved characters;
Dot segments;
Unicode forms;
Case distinctions;
Query parameters;
Or application-specific separators.
A protected canonicalization profile may define the interpretation
used for comparison.
34.21.1 — Protocol-Specific Parsing
The system applies the applicable actual protocol rules.
34.21.2 — No Blind Decode
Reserved characters are not indiscriminately decoded in ways that
alter resource semantics.
34.21.3 — Effective Request
5.7.3.31. Source page 2944 of the original specification
The sink checks the resource and operation after relevant actual
interpretation.
34.21.4 — Parser Mismatch
A material difference triggers denial or revalidation.
34.22 — PROTECTED CANONICAL RESOURCE DESCRIPTOR
CANONICAL_RESOURCE_DESCRIPTOR = { original_resource_reference,
protocol_scheme, qualified_authority_component,
actual_service_identity, normalized_path_components,
resource_object_identifier, tenant_or_account_identifier,
operation_method, material_query_and_body_parameters,
parser_profile_generation, actual_receiver_identity,
protected_descriptor_authentication }
The canonical representation is not a universal string-normalization
rule.
Das Expires 29 April 2027 [Page 518]
Internet-Draft Execution-Finality Part 7: Tools October 2026
It is defined according to the protocol and receiving resource's
actual interpretation.
34.23 — REDIRECT CONTINUITY
A service may redirect a request.
The redirected destination may differ in:
Hostname;
Scheme;
Service identity;
Tenant;
Or requested operation.
5.7.3.32. Source page 2945 of the original specification
The system may require each effect-capable redirect transition to
satisfy the current target and resource authorization conditions.
34.23.1 — Legitimate Redirect
May continue if the destination is a qualified equivalent target.
34.23.2 — Material Redirect
Requires new target validation.
34.23.3 — Unauthorized Redirect
Is rejected.
34.23.4 — Redirected Credentials
Credential forwarding is restricted according to current recipient
and audience rules.
34.23.5 — Multiple Hops
The final receiving resource, not merely the first endpoint,
determines consequential target correspondence.
34.24 — PROXY BACKEND CONTINUITY
Das Expires 29 April 2027 [Page 519]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A request may be sent through a trusted front-end proxy.
The proxy may select a backend dynamically.
The protected architecture may qualify:
The front-end identity;
The intended logical service;
The selected backend identity;
The actual target resource;
And the operation performed by the backend.
34.24.1 — Trusted Proxy
Does not inherently make every possible backend eligible.
34.24.2 — Protected Backend Mapping
5.7.3.33. Source page 2946 of the original specification
May be enforced at the proxy or receiving-resource boundary.
34.24.3 — Backend Migration
May proceed under qualified identity continuity.
34.24.4 — Changed Resource Authority
Requires current operation-specific verification.
34.25 — CREDENTIAL AUDIENCE AND RESOURCE CORRESPONDENCE
A token or credential may be issued for a particular protected
resource service.
The protected credential controller may verify that the actual
receiving resource satisfies the intended audience.
34.25.1 — Audience Identity
Establishes a permitted destination class for the credential.
34.25.2 — Resource Object
Das Expires 29 April 2027 [Page 520]
Internet-Draft Execution-Finality Part 7: Tools October 2026
May require a narrower tenant, account, or item identifier.
34.25.3 — Original Task
The actual operation must remain within the originating task grant.
34.25.4 — Finality
A valid audience-bound token does not replace the operation-specific
protected sink decision.
34.26 — RESOURCE ALIAS REBINDING
A logical alias may map to a different actual resource.
A principal implementation maintains a qualified current alias
mapping generation.
A pending Candidate Act may be associated with the actual target
identity originally authorized.
When the alias changes, the protected controller determines whether
the new target remains permitted.
34.26.1 — Same Alias, Same Resource
5.7.3.34. Source page 2947 of the original specification
May remain valid.
34.26.2 — Same Alias, New Resource
May require revalidation.
34.26.3 — Different Alias, Same Qualified Resource
May remain eligible if the relevant source and resource predicates
are established.
34.26.4 — Unauthorized Rebinding
Cannot automatically redirect the actual consequence.
34.27 — FILESYSTEM OBJECT IDENTITY
An autonomous agent may be authorized to modify a particular file.
A path may be changed between validation and file opening.
Das Expires 29 April 2027 [Page 521]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A symbolic link may redirect the operation.
A directory entry may be replaced.
The protected filesystem sink may resolve or open the actual object
through a suitable protected operation.
34.27.1 — Path Authorization
Defines the intended object or permitted resource class.
34.27.2 — Actual Object
Is identified using the filesystem's qualified object identity and
access state.
34.27.3 — Race Resistance
The check and subsequent operation are coordinated under the
supported filesystem primitives.
34.27.4 — No Unsupported Atomicity
A check of the path followed by a separately executed write is not
automatically race-free.
34.28 — OBJECT STORAGE IDENTITY
5.7.3.35. Source page 2948 of the original specification
An object key may identify different content versions over time.
A protected object-storage operation may require:
Current bucket or container identity;
Tenant or account scope;
Object key;
Object version or generation;
Permitted operation;
And current owner authority.
The sink may use the storage system's conditional operations to
prevent substitution or lost-update errors where supported.
Das Expires 29 April 2027 [Page 522]
Internet-Draft Execution-Finality Part 7: Tools October 2026
34.28.1 — Same Key, Different Version
Requires current version validation where material.
34.28.2 — Same Object, Different Location
May remain valid under qualified migration.
34.28.3 — Wrong Account
Is rejected when outside the source-authorized scope.
34.29 — DATABASE RECORD IDENTITY
A database operation may refer to a record through a key, alias,
query, or search result.
The actual selected record may differ from the record originally
authorized.
A protected database sink may verify:
The actual table or collection;
Tenant or row ownership;
Selected record identifier;
Current record version;
Operation class;
5.7.3.36. Source page 2949 of the original specification
And protected finality.
A query matching several records cannot automatically replace a
Candidate Act authorized for one specified record.
34.30 — DEVICE AND HARDWARE IDENTITY
A hardware controller may use a bus address, device index, or logical
equipment name.
The actual connected device may change after replacement,
reconnection, or maintenance.
A protected device sink may verify:
Das Expires 29 April 2027 [Page 523]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Current physical or cryptographic device identity;
Qualified controller;
Permitted command class;
Operating-state predicates;
And current resource-control generation.
34.30.1 — Same Address, New Device
May require reauthorization.
34.30.2 — Same Device, New Address
May remain eligible under qualified identity continuity.
34.30.3 — Actual Command
Is checked against the intended physical effect.
34.31 — MATERIAL SUBSTITUTION FENCING
A protected controller monitors relevant identity transitions.
For a material or unresolved change, it fences affected pending
Candidate Acts.
The fence may invalidate:
A prepared execution handle;
A cached target resolution;
5.7.3.37. Source page 2950 of the original specification
A pending tool-invocation authorization;
A credential-release decision;
Or another operation-specific finality reference.
34.31.1 — Selective Fence
An unrelated service migration need not invalidate the operation.
34.31.2 — Material Fence
Das Expires 29 April 2027 [Page 524]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The affected operation must be independently revalidated.
34.31.3 — Actual Sink
The sink independently checks current identity conditions even if an
upstream event was not received.
34.32 — IDENTITY RESOLUTION VERSION VECTOR
A selected implementation may define:
[ V_T=(G_L,G_D,G_W,G_C,G_R,G_A) ]
(G_L) is logical-to-resource mapping generation;
(G_D) is discovery generation;
(G_W) is receiving workload or service-identity generation;
(G_C) is tool-contract generation;
(G_R) is actual resource generation;
And (G_A) is relevant authority generation.
These values need not be one global counter.
A Candidate Act uses those properties material to its actual
operation.
A changed discovery generation does not necessarily require
cancellation where qualified endpoint continuity holds.
5.7.3.38. Source page 2951 of the original specification
34.33 — INDEPENDENT EXECUTION-TIME IDENTITY VALIDATION
Immediately before or at the covered effectuation boundary, an
independent validator may:
Resolve the actual destination;
Authenticate the actual receiving principal;
Verify the current service-to-resource mapping;
Check the actual tenant and resource object;
Das Expires 29 April 2027 [Page 525]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Verify the tool-contract generation;
Reconstruct material operation parameters;
Check current originating source authority;
And determine whether previously prepared finality remains eligible.
34.33.1 — Independent Observation
The validator need not rely exclusively upon a descriptor supplied by
the proposing agent.
34.33.2 — Actual Operation
The validation is tied to what will actually be sent or committed.
34.33.3 — Resource-Side Evidence
The receiving sink may provide qualified current resource identity
where necessary.
34.34 — CROSS-COMMITTED IDENTITY CONTINUITY EVIDENCE
A non-limiting implementation may establish:
[ C_C=H(\operatorname{Canon}(CA,T_0,O_0)) ]
[ C_D=H(\operatorname{Canon}(T_1,D_1,C_C)) ]
5.7.3.39. Source page 2952 of the original specification
[ C_E=H(\operatorname{Canon}(CA,T_1,O_1,C_D)) ]
[ C_F=H(\operatorname{Canon}(C_C,C_D,C_E,S,L)) ]
(CA) represents the Candidate Act;
(T_0) and (T_1) represent relevant initial and current qualified
target identities;
(O_0) and (O_1) represent initial and current operation descriptors;
(D_1) represents qualified discovery and tool evidence;
(S) represents the designated Finality Sink;
And (L) represents protected sink-local consumption state.
Das Expires 29 April 2027 [Page 526]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The commitments protect selected relationships.
They do not replace current actual-resource identity verification.
34.35 — TARGET-BOUND NON-BEARER FINALITY
A representative record comprises:
TARGET_BOUND_FINALITY_ENABLEMENT = { candidate_act_digest,
original_source_grant_reference,
authorized_target_descriptor_commitment,
qualified_actual_resource_identity, qualified_service_principal,
permitted_tool_contract_generation,
permitted_actual_operation_digest, permitted_tenant_or_account_scope,
current_identity_resolution_generation,
current_resource_authority_generation,
independent_execution_validation_commitment,
designated_finality_sink, sink_local_consumption_reference,
protected_finality_authentication }
The enablement is valid only under its protected conditions.
5.7.3.40. Source page 2953 of the original specification
34.35.1 — Opaque Reference
The agent may receive a non-operative reference rather than a
reusable complete authority object.
34.35.2 — Target Binding
A different actual resource cannot automatically accept the
reference.
34.35.3 — Operation Binding
A different material tool effect cannot automatically use the
reference.
34.35.4 — Consumption
Previously consumed authority remains spent after migration or
rebinding.
34.36 — ACTUAL FINALITY-SINK RECONSTRUCTION
The actual Finality Sink obtains or reconstructs relevant properties
of the operation as presented for effectuation.
Das Expires 29 April 2027 [Page 527]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Depending upon the resource class, this may include:
The actual HTTP destination;
The authenticated service principal;
The selected backend resource;
The effective tenant;
The actual database row;
The actual opened file object;
The actual storage-object version;
The actual payment account;
The actual hardware device;
The tool operation performed;
And material request or command parameters.
The sink compares those properties with the protected Candidate Act
and finality enablement.
5.7.3.41. Source page 2954 of the original specification
A proposed operation matching only a textual name is insufficient
where actual identity correspondence is mandatory.
34.37 — TWO AUTHORIZATION BOUNDARIES FOR TOOL-BASED EFFECTS
A tool call may traverse:
Boundary A — Tool Invocation: A protected controller verifies that
the tool and requested operation are within current task permission.
Boundary B — Receiving Resource: An independently enforcing resource
sink verifies the real object and actual consequence.
34.37.1 — Tool Approval
Permits a bounded invocation.
34.37.2 — Resource Permission
Das Expires 29 April 2027 [Page 528]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Permits the actual resource operation.
34.37.3 — No Automatic Delegation
Tool invocation authority does not automatically cover every
downstream side effect.
34.37.4 — Integrated Implementation
Both functions may be implemented in a single protected enforcement
domain where that domain genuinely observes and controls the real
effect.
34.38 — TOOL-TO-TOOL DELEGATION
A tool may delegate a request to another service.
The original operation may involve several hops.
A protected system may represent qualified downstream operations as:
Separate Candidate Acts;
Restricted child effects;
Or expressly bounded effects within a protected operation envelope.
The appropriate method depends upon the actual consequences.
5.7.3.42. Source page 2955 of the original specification
34.38.1 — Delegated Computation
May be allowed without new external effect authority.
34.38.2 — New Consequential Operation
Requires corresponding protected authorization.
34.38.3 — Changed Destination
Requires current target qualification.
34.38.4 — Lineage
Qualified tool handoff evidence may support cross-service identity
continuity but does not create missing original authority.
Das Expires 29 April 2027 [Page 529]
Internet-Draft Execution-Finality Part 7: Tools October 2026
34.39 — REDIRECT AND PROXY CHAIN BOUNDING
A protected gateway may impose:
A maximum qualified redirect count;
A permitted protocol set;
A permitted destination equivalence class;
A qualified credential-forwarding rule;
And resource-specific finality requirements.
Every material transition is checked against current authority.
34.39.1 — Redirect Limits
Reduce unbounded routing and verification exhaustion.
34.39.2 — Protocol Downgrade
A transition to an unapproved protocol may be refused.
34.39.3 — Credential Protection
Reusable credentials are not automatically forwarded to new
destinations.
34.39.4 — Actual Effect
The final receiving resource remains subject to independent
verification.
5.7.3.43. Source page 2956 of the original specification
34.40 — FAILOVER WITHOUT EFFECT DUPLICATION
A service may fail after accepting an operation but before
acknowledging completion.
An autonomous agent may switch to another endpoint.
The successor endpoint may represent the same logical service.
However, the earlier operation may already have produced the effect.
A protected journal therefore maintains:
Das Expires 29 April 2027 [Page 530]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Logical operation identity;
Actual target identity;
Attempt status;
Qualified resource outcome;
Protected finality consumption;
And current retry eligibility.
34.40.1 — Failover Identity
A qualified successor endpoint may be permitted.
34.40.2 — Duplicate Consequence
The new endpoint does not automatically receive a fresh operation
allowance.
34.40.3 — Unknown Outcome
Requires qualified reconciliation.
34.41 — ROLLBACK AND IDENTITY NONRESURRECTION
A service registry may be restored from an old snapshot.
An obsolete alias may become visible again.
An old tool version may be redeployed.
An earlier endpoint may resume service.
5.7.3.44. Source page 2957 of the original specification
These events do not automatically restore previously revoked resource
permission or consumed finality.
The protected controller verifies current authoritative identity,
tool, source, and revocation generations.
Historical identity continuity is not an independent present
authorization.
34.42 — IDENTITY CONTINUITY STATE MACHINE
Das Expires 29 April 2027 [Page 531]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A representative state machine comprises:
CANDIDATE_PREPARED: A proposed consequential operation exists.
NON_EFFECTIVE: The real consequence is withheld.
TARGET_DESCRIPTOR_QUALIFIED: The authorized target conditions are
established.
DISCOVERY_PENDING: Current service resolution remains unresolved.
ENDPOINT_DISCOVERED: A candidate endpoint has been identified.
SERVICE_AUTHENTICATED: Selected receiving-principal identity is
established.
RESOURCE_IDENTITY_PENDING: The actual protected resource remains to
be qualified.
TOOL_CONTRACT_PENDING: The actual tool semantics require
verification.
IDENTITY_CONTINUITY_CONFIRMED: Required target conditions remain
satisfied.
QUALIFIED_MIGRATION: A permitted replacement or move has been
established.
MATERIAL_SUBSTITUTION: The actual target or effect has materially
changed.
SUBSTITUTION_FENCED: Pending finality is withheld.
NEW_AUTHORITY_REQUIRED: The changed target requires a new source or
resource grant.
EXECUTION_VALIDATED: Independent current target and effect checks
pass.
FINALITY_PREPARED: Scoped non-bearer enablement exists.
SINK_VERIFICATION_PENDING: The actual receiving resource checks the
operation.
FINALITY_CONSUMED: Protected use state is committed.
Das Expires 29 April 2027 [Page 532]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.7.3.45. Source page 2958 of the original specification
EFFECT_ATTEMPTED: The covered consequential primitive is released.
EFFECT_CONFIRMED: Qualified actual-effect evidence exists.
EFFECT_INDETERMINATE: The outcome remains unresolved.
DENIED: A mandatory identity or authority condition failed.
34.43 — COMPLETE COMMON WORKFLOW
Step 1 — Establish Original Source Authority. Identify the operation
and resource scope authorized by the originating principal.
Step 2 — Construct Candidate Act. Represent the exact proposed
consequential operation.
Step 3 — Hold Non-Effective. Prevent the actual effect pending
qualification.
Step 4 — Construct Authorized Target Descriptor. Define the
protected intended target identity or identity predicate.
Step 5 — Identify Tool Requirements. Qualify the intended tool
operation and relevant effect class.
Step 6 — Obtain Current Discovery Evidence. Resolve the logical
service or resource reference.
Step 7 — Authenticate Receiving Principal. Establish the service or
workload identity.
Step 8 — Qualify Actual Resource Identity. Determine the actual
tenant, object, account, device, or other target.
Step 9 — Qualify Tool Contract. Establish current relevant operation
semantics.
Step 10 — Verify Credential Audience. Check destination restrictions
for applicable credentials.
Step 11 — Compare Identity Generations. Identify any change since
collection-time authorization.
Step 12 — Classify Substitution. Distinguish permitted migration
from material target or semantic change.
Das Expires 29 April 2027 [Page 533]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Step 13 — Fence Material Changes. Withhold incompatible pending
finality.
Step 14 — Requalify Legitimate Migration. Establish authorized
equivalence where supported.
5.7.3.46. Source page 2959 of the original specification
Step 15 — Independently Validate Actual Operation. Obtain current
effect descriptors from protected observations.
Step 16 — Verify Current Source Scope. Ensure the actual target and
effect remain authorized.
Step 17 — Verify Current Resource Authority. Check current owner,
tenant, and revocation conditions.
Step 18 — Cross-Commit Evidence. Bind collection-time and current
identity and operation evidence where required.
Step 19 — Constitute Scoped Finality. Prepare target-bound non-
bearer enablement.
Step 20 — Present Actual Operation. Deliver it through a required
protected route.
Step 21 — Reconstruct Actual Receiver. The Finality Sink identifies
the actual resource and service.
Step 22 — Reconstruct Actual Effect. The sink identifies the actual
operation and material parameters.
Step 23 — Verify Current Identity Continuity. Compare the real
target with the authorized descriptor.
Step 24 — Verify Current Tool Semantics. Confirm that the operation
remains within permitted effect scope.
Step 25 — Verify Finality. Validate the enablement against source,
resource, identity, and effect evidence.
Step 26 — Verify Sink-Local Consumption. Check previous uses and
bounded authority state.
Step 27 — Commit Protected Use. Consume authority under the
applicable resource consistency model.
Das Expires 29 April 2027 [Page 534]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Step 28 — Release Actual Effect. Perform only the qualified
operation.
Step 29 — Record Outcome. Preserve actual target, attempted effect,
completion, or uncertainty.
Step 30 — Govern Later Failover. Do not duplicate effects merely
because the endpoint changes.
34.44 — REFERENCE ALGORITHM: AUTHORIZED TARGET CONSTRUCTION
FUNCTION BUILD_AUTHORIZED_TARGET(
5.7.3.47. Source page 2960 of the original specification
candidate_act, protected_target_controller ): REQUIRE
VERIFY_CANDIDATE_ACT_IDENTITY() REQUIRE
VERIFY_ORIGINAL_SOURCE_GRANT() requested_resource =
QUALIFY_REQUESTED_LOGICAL_RESOURCE( candidate_act ) operation =
QUALIFY_MATERIAL_OPERATION_EFFECT( candidate_act ) permitted_targets
= RESOLVE_PROTECTED_TARGET_AUTHORITY( requested_resource, operation )
REQUIRE VERIFY_TARGET_AUTHORITY_COMPLETENESS( permitted_targets )
target_descriptor = protected_target_controller
.COMMIT_AUTHORIZED_TARGET_DESCRIPTOR({ candidate:
HASH(candidate_act), requested_resource: requested_resource,
permitted_targets: permitted_targets, operation: operation,
designated_sink: RESOLVE_QUALIFIED_ACTUAL_SINK() }) RETURN
target_descriptor
The permitted target conditions are derived from qualified protected
authority rather than an unrestricted agent-supplied alias list.
34.45 — REFERENCE ALGORITHM: CURRENT SERVICE DISCOVERY
FUNCTION QUALIFY_CURRENT_SERVICE_DISCOVERY( logical_service,
candidate_act,
5.7.3.48. Source page 2961 of the original specification
protected_discovery_controller ): discovery =
protected_discovery_controller
.RESOLVE_CURRENT_SERVICE(logical_service) REQUIRE
VERIFY_QUALIFIED_DISCOVERY_SOURCE( discovery ) endpoint =
SELECT_CANDIDATE_ENDPOINT(discovery) REQUIRE
VERIFY_DESTINATION_POLICY(endpoint) connection =
ESTABLISH_PROTECTED_CONNECTION(endpoint) REQUIRE
VERIFY_ACTUAL_CONNECTION_ENDPOINT( connection, endpoint )
service_identity = AUTHENTICATE_RECEIVING_SERVICE(connection) REQUIRE
Das Expires 29 April 2027 [Page 535]
Internet-Draft Execution-Finality Part 7: Tools October 2026
VERIFY_SERVICE_IDENTITY_ELIGIBLE( candidate_act, service_identity )
RETURN PROTECTED_DISCOVERY_WITNESS({ candidate: HASH(candidate_act),
endpoint: endpoint, service: service_identity, resolution:
discovery.generation })
The discovered endpoint does not independently replace operation-
specific resource authorization.
34.46 — REFERENCE ALGORITHM: MATERIAL SUBSTITUTION DETECTION
FUNCTION CLASSIFY_RESOURCE_SUBSTITUTION( candidate_act,
previous_identity, current_identity, protected_continuity_controller
5.7.3.49. Source page 2962 of the original specification
): requirements = LOAD_IDENTITY_DEPENDENCY_SET(candidate_act)
comparison = protected_continuity_controller
.COMPARE_REQUIRED_IDENTITY_PROPERTIES({ previous: previous_identity,
current: current_identity, requirements: requirements }) IF
comparison == QUALIFIED_EQUIVALENT: RETURN CONTINUITY_VALID IF
comparison == MATERIAL_CHANGE:
ACTIVATE_SUBSTITUTION_FENCE(candidate_act) RETURN
REVALIDATION_REQUIRED IF comparison == UNKNOWN:
HOLD_CANDIDATE_NON_EFFECTIVE(candidate_act) RETURN
IDENTITY_UNRESOLVED RETURN DENY
Only qualified continuity—not mere shared naming—is sufficient for
permitted substitution.
34.47 — REFERENCE ALGORITHM: TOOL CONTRACT CONTINUITY
FUNCTION QUALIFY_TOOL_CONTRACT_CONTINUITY( candidate_act,
actual_tool, protected_tool_controller ): intended =
LOAD_AUTHORIZED_TOOL_EFFECT_DESCRIPTOR( candidate_act ) current =
protected_tool_controller .LOAD_CURRENT_QUALIFIED_TOOL_CONTRACT(
actual_tool ) REQUIRE VERIFY_TOOL_PROVIDER_IDENTITY(current)
5.7.3.50. Source page 2963 of the original specification
REQUIRE VERIFY_CURRENT_TOOL_CONTRACT_GENERATION() REQUIRE
VERIFY_ACTUAL_OPERATION_CLASS( candidate_act, current ) REQUIRE
VERIFY_MATERIAL_EFFECT_PARAMETERS() IF
HAS_MATERIAL_NEW_SIDE_EFFECT(current, intended):
ACTIVATE_SUBSTITUTION_FENCE(candidate_act) RETURN
REVALIDATION_REQUIRED IF NOT
VERIFY_CURRENT_SOURCE_SCOPE_FOR_TOOL_EFFECT(): RETURN DENY RETURN
QUALIFIED_TOOL_CONTINUITY
Das Expires 29 April 2027 [Page 536]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Schema compatibility is insufficient when the actual effect has
materially changed.
34.48 — REFERENCE ALGORITHM: REDIRECT AND BACKEND VALIDATION
FUNCTION FOLLOW_QUALIFIED_DESTINATION_CHAIN( initial_destination,
candidate_act, protected_gateway ): destination = initial_destination
hops = 0 WHILE DESTINATION_TRANSITION_REQUIRED(destination): REQUIRE
hops < PROTECTED_MAXIMUM_HOPS next_destination =
RESOLVE_ACTUAL_NEXT_DESTINATION(destination) REQUIRE
VERIFY_DESTINATION_POLICY(next_destination) REQUIRE
VERIFY_CURRENT_TARGET_EQUIVALENCE( candidate_act, next_destination )
REQUIRE VERIFY_CREDENTIAL_FORWARDING_ELIGIBILITY( destination,
next_destination )
5.7.3.51. Source page 2964 of the original specification
destination = next_destination hops = hops + 1 REQUIRE
AUTHENTICATE_FINAL_RECEIVING_SERVICE( destination ) REQUIRE
VERIFY_ACTUAL_TARGET_RESOURCE( candidate_act, destination ) RETURN
QUALIFIED_FINAL_DESTINATION(destination)
All material destination changes remain subject to protected
qualification.
34.49 — REFERENCE ALGORITHM: CROSS-COMMITTED TARGET FINALITY
FUNCTION PREPARE_TARGET_BOUND_FINALITY( candidate_act,
protected_finality_controller ): REQUIRE
VERIFY_CANDIDATE_NON_EFFECTIVE() REQUIRE
VERIFY_CURRENT_ORIGINATING_SOURCE_GRANT() target =
INDEPENDENTLY_QUALIFY_ACTUAL_TARGET() REQUIRE
VERIFY_AUTHORIZED_TARGET_CORRESPONDENCE( candidate_act, target )
REQUIRE VERIFY_CURRENT_TOOL_EFFECT_SEMANTICS() REQUIRE
VERIFY_CURRENT_RESOURCE_AUTHORITY() REQUIRE
VERIFY_CURRENT_REVOCATION() validation =
COMMIT_CURRENT_TARGET_AND_EFFECT_VALIDATION({ candidate:
candidate_act, target: target, actual_effect:
CURRENT_QUALIFIED_OPERATION() })
5.7.3.52. Source page 2965 of the original specification
RETURN protected_finality_controller
.PREPARE_SCOPED_NON_BEARER_ENABLEMENT({ candidate:
HASH(candidate_act), target: HASH(target), operation:
HASH(CURRENT_QUALIFIED_OPERATION()), validation: HASH(validation),
designated_sink: RESOLVE_ACTUAL_FINALITY_SINK() })
Das Expires 29 April 2027 [Page 537]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The enablement remains subject to independent sink-local
verification.
34.50 — REFERENCE ALGORITHM: ACTUAL RESOURCE-SINK FINALITY
FUNCTION EFFECTUATE_WITH_TARGET_IDENTITY_CONTINUITY( candidate_act,
finality_reference, protected_resource_sink ): actual =
protected_resource_sink .RECONSTRUCT_ACTUAL_PENDING_OPERATION()
actual_target = protected_resource_sink
.QUALIFY_ACTUAL_RECEIVING_RESOURCE(actual) REQUIRE
VERIFY_CURRENT_ORIGINATING_AUTHORITY() REQUIRE
VERIFY_AUTHORIZED_TARGET_DESCRIPTOR( candidate_act, actual_target )
REQUIRE VERIFY_CURRENT_SERVICE_OR_DEVICE_IDENTITY() REQUIRE
VERIFY_CURRENT_TENANT_AND_RESOURCE_OWNER() REQUIRE
VERIFY_ACTUAL_TOOL_OPERATION_SEMANTICS() REQUIRE
VERIFY_MATERIAL_EFFECT_PARAMETERS( candidate_act, actual ) REQUIRE
VERIFY_CURRENT_REVOCATION_AND_POLICY()
5.7.3.53. Source page 2966 of the original specification
REQUIRE VERIFY_SCOPED_NON_BEARER_FINALITY( finality_reference,
actual_target, actual ) REQUIRE VERIFY_SINK_LOCAL_CONSUMPTION()
committed = protected_resource_sink
.COMMIT_PROTECTED_FINALITY_CONSUMPTION( finality_reference, actual )
IF committed != COMMITTED: RETURN DENY RETURN protected_resource_sink
.RELEASE_QUALIFIED_RESOURCE_EFFECT(actual)
Where the effect is transactional, relevant identity comparison,
consumption, and mutation may be serialized within the same protected
resource transaction.
For a remote or physical effect, the guarantee depends upon the
actual receiving enforcement and qualified outcome model.
34.51 — REFERENCE ALGORITHM: QUALIFIED SERVICE MIGRATION
FUNCTION REVALIDATE_AFTER_SERVICE_MIGRATION( candidate_act,
predecessor_service, successor_service,
protected_migration_controller ): REQUIRE
VERIFY_PREDECESSOR_SERVICE_IDENTITY() REQUIRE
VERIFY_SUCCESSOR_SERVICE_IDENTITY() REQUIRE
VERIFY_COMPETENT_MIGRATION_AUTHORITY() REQUIRE
VERIFY_ACTUAL_RESOURCE_CONTINUITY() REQUIRE
VERIFY_CURRENT_TENANT_AND_ACCOUNT_SCOPE() REQUIRE
VERIFY_TOOL_EFFECT_CONTINUITY()
Das Expires 29 April 2027 [Page 538]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.7.3.54. Source page 2967 of the original specification
REQUIRE VERIFY_CURRENT_SOURCE_AUTHORITY() REQUIRE
VERIFY_CURRENT_REVOCATION() REQUIRE
VERIFY_PREVIOUS_EFFECT_CONSUMPTION_STATE() migration =
protected_migration_controller
.COMMIT_QUALIFIED_IDENTITY_CONTINUITY({ candidate: candidate_act,
predecessor: predecessor_service, successor: successor_service,
current_resource: CURRENT_ACTUAL_RESOURCE_IDENTITY() }) RETURN
RECONSTITUTE_ELIGIBLE_TARGET_BOUND_FINALITY( candidate_act, migration
)
A valid service migration does not independently grant permission for
a different resource or a duplicate real effect.
34.52 — REFERENCE ALGORITHM: FAILOVER EFFECT RECONCILIATION
FUNCTION RECOVER_AFTER_ENDPOINT_FAILOVER( logical_operation,
previous_endpoint, successor_endpoint, protected_effect_journal ):
record = protected_effect_journal
.LOAD_CURRENT_LOGICAL_OPERATION_STATE( logical_operation ) REQUIRE
VERIFY_CURRENT_OPERATION_IDENTITY(record) REQUIRE
VERIFY_SUCCESSOR_ENDPOINT_ELIGIBILITY( successor_endpoint ) IF
QUALIFIED_EFFECT_ALREADY_COMPLETED(record): RETURN
PRESERVE_COMPLETED_EFFECT IF
PREVIOUS_EFFECT_OUTCOME_INDETERMINATE(record):
5.7.3.55. Source page 2968 of the original specification
observed = QUERY_QUALIFIED_RESOURCE_OUTCOME( logical_operation ) IF
VERIFY_QUALIFIED_COMPLETION(observed): RETURN
PRESERVE_COMPLETED_EFFECT IF VERIFY_QUALIFIED_NON_EFFECT(observed):
RETURN REQUIRE_CURRENT_REVALIDATION RETURN
PRESERVE_INDETERMINATE_EFFECT RETURN
REQUIRE_CURRENT_TARGET_AND_AUTHORITY_CHECK
An endpoint change does not create an independent fresh allowance to
repeat an uncertain effect.
34.53 — WORKED EXAMPLE A: DNS REBINDING TO INTERNAL SERVICE
An agent is authorized to retrieve information from a qualified
external service.
The service hostname initially resolves to an external address.
Before the actual request, the hostname resolves to a restricted
internal address.
Das Expires 29 April 2027 [Page 539]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The protected gateway evaluates the actual connection destination and
service identity.
The new destination is outside the authorized target envelope.
The request is refused.
Expected demonstrable result: Earlier hostname approval cannot
independently authorize a materially changed actual receiving
destination.
34.54 — WORKED EXAMPLE B: LEGITIMATE LOAD BALANCING
An API service is implemented by multiple authenticated instances.
An agent receives authority to modify one specified resource through
the logical service.
The selected network instance changes before effectuation.
The replacement is qualified as an eligible service instance.
5.7.3.56. Source page 2969 of the original specification
The actual resource identity, tenant, operation, and source authority
remain valid.
The operation may proceed through protected finality.
Expected demonstrable result: The architecture preserves legitimate
service-instance mobility without using a fixed IP address as the
sole identity guarantee.
34.55 — WORKED EXAMPLE C: TOOL NAME REUSE
An agent is authorized to invoke a tool named store_draft.
A tool registry update changes the implementation so it publishes the
draft externally.
The protected tool-contract controller identifies the changed
consequential effect.
The prior approval for local draft storage is insufficient.
The publication remains withheld.
Das Expires 29 April 2027 [Page 540]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Expected demonstrable result: A stable tool name does not allow an
unauthorized new side effect to inherit earlier authority.
34.56 — WORKED EXAMPLE D: SAME TOOL SCHEMA, DIFFERENT EFFECT
Two tool implementations accept identical parameters.
One modifies a test database.
The other modifies a production database.
An agent is authorized for testing only.
The actual resource sink verifies the database identity and
deployment environment.
The production mutation is refused.
Expected demonstrable result: Schema equality cannot replace actual
protected target identity.
34.57 — WORKED EXAMPLE E: VALID TLS, WRONG TENANT
An agent connects to an authentic service endpoint.
The certificate is valid for that service.
5.7.3.57. Source page 2970 of the original specification
The request identifies a resource belonging to another tenant.
The receiving sink checks the actual tenant and resource
authorization.
The unauthorized operation is refused.
Expected demonstrable result: Valid service authentication does not
independently establish permission for every tenant resource hosted
by that service.
34.58 — WORKED EXAMPLE F: HTTP REDIRECT
An agent is authorized to send a resource operation to one service.
The service redirects the request to a different hostname.
The protected controller qualifies the new destination and credential
audience.
Das Expires 29 April 2027 [Page 541]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The redirect is refused where the actual target lies outside the
authorized envelope.
Expected demonstrable result: Redirect instructions cannot
independently broaden the source-authorized destination set.
34.59 — WORKED EXAMPLE G: FILE SYMBOLIC-LINK SUBSTITUTION
An agent is authorized to update a specified file.
An attacker replaces the target path with a symbolic link to another
protected file.
The actual filesystem sink verifies the opened object's identity.
The substituted target does not match the authorized resource.
The write is refused.
Expected demonstrable result: Textual pathname approval cannot
automatically authorize mutation of a different actual filesystem
object.
34.60 — WORKED EXAMPLE H: FILE MIGRATION WITHOUT IDENTITY LOSS
A qualified storage service moves an authorized file to another
storage volume while maintaining the intended resource identity and
applicable permissions.
The protected controller establishes current continuity.
5.7.3.58. Source page 2971 of the original specification
The authorized modification may continue.
Expected demonstrable result: Legitimate storage migration need not
cause false denial when actual resource and effect continuity are
qualified.
34.61 — WORKED EXAMPLE I: DATABASE QUERY REBINDING
An agent is authorized to modify one specific customer record.
A database query is regenerated and now resolves to another
customer's record.
The protected database sink reconstructs the actual selected row and
tenant.
Das Expires 29 April 2027 [Page 542]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The changed target is outside the Candidate Act.
The mutation is refused.
Expected demonstrable result: Authorization of a logical record
reference does not automatically authorize a different row returned
by later query evaluation.
34.62 — WORKED EXAMPLE J: OBJECT STORAGE KEY REUSE
An agent is authorized to overwrite a particular object version.
The object is replaced with a new generation before the write.
The object-storage sink checks the version and current resource
identity.
A mutation based on the obsolete generation is refused or
revalidated.
Expected demonstrable result: An unchanged object key cannot
automatically substitute for a materially changed object version.
34.63 — WORKED EXAMPLE K: CLOUD ACCOUNT ALIAS REBINDING
A resource alias initially refers to an account controlled by Tenant
A.
The alias is reassigned to Tenant B.
An autonomous agent retains a previously approved operation.
The protected sink checks the actual account and owner state.
The old approval is insufficient.
5.7.3.59. Source page 2972 of the original specification
Expected demonstrable result: Resource alias reassignment cannot
silently transfer consequential permission across account boundaries.
34.64 — WORKED EXAMPLE L: TOOL CONTRACT UPGRADE
A tool implementation is upgraded.
The new implementation preserves the authorized operation semantics
and actual resource scope.
Das Expires 29 April 2027 [Page 543]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The protected controller qualifies the replacement.
An affected pending Candidate Act is revalidated where necessary.
The operation may continue.
Expected demonstrable result: Legitimate tool upgrades are supported
without treating implementation hash equality as the only permitted
continuity condition.
34.65 — WORKED EXAMPLE M: TOOL CONTRACT EXPANSION
A database tool's new contract introduces a bulk deletion operation.
An agent's original source grant permits only record inspection.
The agent attempts the deletion through the upgraded tool.
The actual database sink checks source authorization and the
operation class.
The deletion is refused.
Expected demonstrable result: Tool capability expansion cannot
independently expand the originating task.
34.66 — WORKED EXAMPLE N: CREDENTIAL AUDIENCE MISMATCH
An agent obtains a credential intended for Resource Service A.
It attempts to present the credential to Resource Service B.
The protected credential gateway checks the qualified actual
recipient and permitted audience.
The unauthorized substitution is refused.
5.7.3.60. Source page 2973 of the original specification
Expected demonstrable result: A credential technically available to
an agent does not authorize another receiving resource.
34.67 — WORKED EXAMPLE O: SAME IP, DIFFERENT VIRTUAL HOST
Two protected services share a network address.
An agent is authorized for Service A.
Das Expires 29 April 2027 [Page 544]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A request changes its effective application authority or routing to
Service B.
The protected controller checks the authenticated intended service
and actual receiving resource.
A changed consequential target is refused.
Expected demonstrable result: IP-address equality is not equivalent
to actual service or resource identity.
34.68 — WORKED EXAMPLE P: SERVICE MESH BACKEND CHANGE
A request enters an authenticated service proxy.
The proxy dynamically selects a backend.
The original operation was authorized for a specific tenant resource.
The selected backend is checked against the protected logical service
and resource envelope.
A backend associated with an unauthorized tenant is refused.
Expected demonstrable result: Trusted ingress into a service mesh
does not automatically authorize every backend destination.
34.69 — WORKED EXAMPLE Q: PROXY CREDENTIAL INJECTION
An agent submits an operation through a credential broker.
The broker holds a reusable service credential.
The selected backend changes after the initial request is
constructed.
The protected broker or downstream sink verifies the current actual
audience, resource, and operation before credential use or
effectuation.
5.7.3.61. Source page 2974 of the original specification
Expected demonstrable result: Credential substitution cannot
independently redirect the authorized effect to another resource.
34.70 — WORKED EXAMPLE R: DEVICE ADDRESS REASSIGNMENT
An industrial controller is authorized to send a command to Device A.
Das Expires 29 April 2027 [Page 545]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The device bus is reconfigured.
The same logical address now refers to Device B.
The protected device sink checks the actual receiving device
identity.
The command is refused unless B is separately qualified under the
authorized target conditions.
Expected demonstrable result: Device-address reuse does not
automatically transfer physical actuation authority.
34.71 — WORKED EXAMPLE S: QUALIFIED HARDWARE REPLACEMENT
A failed device is replaced with a competent successor unit.
The replacement is authenticated and qualified for the same bounded
physical function.
The source-authorized command remains within the current control
envelope.
The protected sink revalidates the actual command against the
replacement device and current operating state.
Expected demonstrable result: Authorized physical replacement may be
supported without allowing arbitrary device substitution.
34.72 — WORKED EXAMPLE T: SERVICE FAILOVER AFTER UNKNOWN EFFECT
A financial operation is dispatched to Service Instance A.
The connection fails before acknowledgement.
The system selects Instance B.
The earlier operation may already have completed.
5.7.3.62. Source page 2975 of the original specification
The protected outcome journal preserves the same logical operation
identity.
The system requires qualified reconciliation before any additional
effectuation.
Das Expires 29 April 2027 [Page 546]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Expected demonstrable result: Failover does not automatically permit
duplicate external effects.
34.73 — WORKED EXAMPLE U: API METHOD SUBSTITUTION
An agent is authorized to retrieve a resource through a read-only
request.
A tool upgrade or interceptor changes the operation into a state-
changing method.
The actual Finality Sink reconstructs the received method and target.
The mutation is outside the authorized Candidate Act.
Expected demonstrable result: A valid destination does not authorize
a materially different actual operation.
34.74 — WORKED EXAMPLE V: URI CANONICALIZATION DIFFERENCE
An authorization layer and resource server use different decoding or
path interpretation rules.
A crafted resource reference appears to target a permitted path
during validation but reaches a protected path at the receiver.
The actual sink uses qualified effective-resource interpretation.
The unauthorized path is refused.
Expected demonstrable result: A protected actual-resource descriptor
prevents authorization solely against a misleading textual
interpretation.
34.75 — WORKED EXAMPLE W: AUTHENTIC REPLACEMENT SERVICE, WRONG
RESOURCE
A service migrates to a qualified successor workload.
The successor is authentically identified.
However, its backend resource mapping points to another customer's
database.
The protected Finality Sink identifies the current actual database.
Das Expires 29 April 2027 [Page 547]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.7.3.63. Source page 2976 of the original specification
The changed target is refused.
Expected demonstrable result: Qualified workload migration does not
eliminate the need for actual resource-object correspondence.
34.76 — WORKED EXAMPLE X: TOOL DESCRIPTION INJECTION
A tool provider publishes a description claiming that a particular
operation is always approved.
The agent retrieves that description.
The protected controller stores the claim as tool metadata rather
than as an original source grant.
The actual operation requires current source authorization.
Expected demonstrable result: A tool cannot independently create
authorization merely through its own description.
34.77 — WORKED EXAMPLE Y: INDEPENDENT RESOURCE SINK
An agent obtains approval for a file update through a tool broker.
The tool attempts the write through an alternative filesystem access
route.
The actual protected filesystem sink reconstructs the target object
and operation.
Where the route bypasses mandatory enforcement, the system refuses or
blocks the effect.
Expected demonstrable result: Tool-level approval cannot substitute
for a mandatory actual resource enforcement point.
34.78 — WORKED EXAMPLE Z: ACTUAL TARGET EVIDENCE RECEIPT
A protected gateway commits a qualified operation against a resource.
The actual-effect receipt identifies the committed target and
operation.
A later workflow stage depends upon that completed effect.
Das Expires 29 April 2027 [Page 548]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The later operation checks the receipt and current source authority
separately.
5.7.3.64. Source page 2977 of the original specification
Expected demonstrable result: Evidence of prior actual resource
identity and effectuation can support causally dependent workflows
without creating unrestricted successor authority.
34.79 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
1. DNS rebinding. 2. DNS response substitution. 3. Stale DNS
cache. 4. Service-discovery poisoning. 5. Discovery authority
confusion. 6. Unauthorized alternative endpoint. 7. HTTP redirect
to unauthorized host. 8. Redirect into internal network. 9.
Redirect into link-local address space. 10. Redirect loop. 11.
Credential forwarding to redirected destination. 12. Reverse proxy
backend substitution. 13. Service mesh backend rebinding. 14. Same
IP, different service. 15. Same hostname, different tenant. 16.
Different IP, legitimate same service. 17. Unqualified workload
migration. 18. Compromised workload instance. 19. Replaced service
identity. 20. Revoked service credential. 21. Stale workload
identity. 22. Credential audience mismatch. 23. Resource owner
change. 24. Tenant account substitution. 25. Logical alias
reassignment. 26. Resource-name collision. 27. URI encoding
ambiguity. 28. Double decoding. 29. Reserved-character
interpretation mismatch. 30. Dot-segment normalization mismatch. 31.
Case sensitivity mismatch. 32. Unicode path ambiguity. 33.
Filesystem symbolic-link substitution. 34. Filesystem race between
path check and open. 35. File descriptor replacement assumption. 36.
Object key reused for another version. 37. Database query selecting
wrong row. 38. Cross-tenant record selection. 39. Device bus
address reassignment. 40. Wrong physical actuator. 41. Tool
registry replacement. 42. Tool name reuse. 43. Tool schema
unchanged with altered effects.
5.7.3.65. Source page 2978 of the original specification
44. Tool version label reuse. 45. Tool implementation substitution.
46. Tool description injection. 47. Tool provider identity
confusion. 48. Tool-to-tool delegation overreach. 49. New hidden
side effect. 50. Changed API parameter semantics. 51. Read-to-write
method substitution. 52. Unqualified tool capability expansion. 53.
Tool contract downgrade. 54. Malicious tool output claiming
permission. 55. Stale tool registry cache. 56. Uncontrolled
redirect through proxy. 57. Network connection reuse after relevant
revocation. 58. Proxy authority confused with resource authority.
59. Signed request to wrong actual recipient. 60. Valid TLS
Das Expires 29 April 2027 [Page 549]
Internet-Draft Execution-Finality Part 7: Tools October 2026
identity for wrong resource. 61. Unqualified backend identity
equivalence. 62. Overly broad endpoint equivalence class. 63.
Incomplete target dependency set. 64. Missed identity transition.
65. Excessive global fencing. 66. Stale Candidate Act target
descriptor. 67. Stale credential-release approval. 68. Old resource
alias restored from snapshot. 69. Consumed finality restored after
failover. 70. Resource operation replay after migration. 71. Lost
external acknowledgement. 72. Duplicate operation across instances.
73. False actual-resource receipt. 74. Compromised identity
registry. 75. Compromised discovery controller. 76. Compromised
credential broker. 77. Compromised tool registry. 78. Compromised
actual Finality Sink. 79. Monitoring-only enforcement substitution.
80. Uncontrolled alternate resource access path. 81. Unsupported
claim of global atomicity. 82. Endpoint qualification denial-of-
service. 83. Excessive redirect chain verification. 84. Service
partition during migration. 85. Resource operation after source
revocation. 86. Wrong Finality Sink used. 87. Finality reference
copied to another tenant. 88. Tool invocation receipt mistaken for
resource effect. 89. Service authentication mistaken for full target
permission. 90. Actual resource effect against a substituted target
despite valid earlier authorization.
5.7.3.66. Source page 2979 of the original specification
34.80 — PROPOSED FEASIBILITY AND ADVERSARIAL EXPERIMENTS
The following proposed experiments are illustrative, non-limiting,
and are not represented as previously completed tests.
Test 1 — Source Authority: Create a bounded authorization for one
consequential resource operation.
Test 2 — Candidate Act: Construct the proposed operation.
Test 3 — Non-Effective Hold: Ensure the actual resource is not
mutated before finality.
Test 4 — Authorized Target Descriptor: Commit permitted logical and
actual target conditions.
Test 5 — Qualified Service Discovery: Resolve the logical service.
Test 6 — Endpoint Authentication: Verify the receiving service
identity.
Test 7 — Actual Resource Identity: Verify the target resource or
tenant.
Das Expires 29 April 2027 [Page 550]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Test 8 — Initial Resolution Generation: Record qualified collection-
time mapping evidence.
Test 9 — Dynamic Address Change: Change the resolved network address.
Test 10 — Qualified Load Balancing: Permit a different authorized
service instance.
Test 11 — Unauthorized Service Instance: Substitute another
authenticated but unauthorized service.
Test 12 — DNS Rebinding: Change a domain resolution after
preparation.
Test 13 — Internal Destination: Redirect a request toward a
prohibited internal address.
Test 14 — Same IP, Different Service: Change the actual virtual host
while preserving the address.
Test 15 — Same Service, Different IP: Preserve the actual resource
under qualified migration.
Test 16 — HTTP Redirect: Change the request destination.
Test 17 — Multi-Hop Redirect: Traverse several qualified
destinations.
Test 18 — Redirect Limit: Exceed the permitted redirect count.
Test 19 — Credential Redirect: Attempt forwarding a credential to
another audience.
Test 20 — Proxy Backend Change: Alter the selected backend service.
5.7.3.67. Source page 2980 of the original specification
Test 21 — Wrong Tenant Backend: Route to an unauthorized tenant.
Test 22 — Workload Instance Replacement: Replace one permitted
service instance.
Test 23 — Revoked Workload Identity: Attempt execution through a
revoked instance.
Test 24 — Alias Rebinding: Redirect a logical resource name to
another object.
Das Expires 29 April 2027 [Page 551]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Test 25 — Resource Version Change: Replace an object while retaining
its logical key.
Test 26 — File Symbolic Link: Substitute the actual filesystem
target.
Test 27 — Filesystem Race: Race object replacement between
verification and write.
Test 28 — Object-Store Version: Require correct actual object
generation.
Test 29 — Database Row Rebinding: Change the record selected by a
query.
Test 30 — Cross-Tenant Database Record: Attempt mutation of a record
belonging to another tenant.
Test 31 — Tool Registry Lookup: Resolve a logical tool name.
Test 32 — Tool Provider Identity: Authenticate the tool provider.
Test 33 — Tool Contract Generation: Record the qualified interface
and effect descriptor.
Test 34 — Tool Upgrade: Replace the implementation with an equivalent
version.
Test 35 — Tool Side-Effect Expansion: Add an unauthorized
consequential operation.
Test 36 — Same Schema, New Effect: Retain the schema while changing
the actual target or action.
Test 37 — Tool Description Injection: Include a false authorization
claim in metadata.
Test 38 — Tool-to-Tool Handoff: Delegate a request to another tool.
Test 39 — Changed Resource Audience: Attempt operation using a
credential for a different service.
Test 40 — URI Percent-Encoding: Test relevant canonicalization rules.
Test 41 — Reserved Characters: Test effective resource
interpretation.
Das Expires 29 April 2027 [Page 552]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Test 42 — Parser Disagreement: Supply a request interpreted
differently by authorization and resource layers.
Test 43 — Actual Operation Reconstruction: Verify the resource and
effect at the receiving sink.
5.7.3.68. Source page 2981 of the original specification
Test 44 — Identity Dependency Set: Commit mandatory resource and tool
identity properties.
Test 45 — Material Substitution: Trigger selective fencing.
Test 46 — Nonmaterial Migration: Preserve eligibility after qualified
continuity.
Test 47 — Unknown Identity: Withhold an operation when mandatory
target evidence is unavailable.
Test 48 — Current Source Grant: Revalidate after material identity
change.
Test 49 — Current Resource Ownership: Revalidate current resource-
control state.
Test 50 — Current Revocation: Reject invalid source or resource
authority.
Test 51 — Cross-Committed Evidence: Bind original and current target
observations.
Test 52 — Target-Bound Non-Bearer Finality: Constitute operation-
specific enablement.
Test 53 — Wrong Target: Present valid-looking finality at another
resource.
Test 54 — Wrong Tool: Attempt substitution of the tool
implementation.
Test 55 — Wrong Effect: Change the material operation.
Test 56 — Wrong Tenant: Use the same service but another tenant's
target.
Test 57 — Wrong Sink: Present the reference to an unauthorized
resource gateway.
Das Expires 29 April 2027 [Page 553]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Test 58 — Protected Consumption: Consume valid finality.
Test 59 — Replay: Attempt the same effect again.
Test 60 — Multi-Agent Shared Tool: Race several agents invoking one
logical tool.
Test 61 — Service Failover: Switch to an authorized successor
endpoint.
Test 62 — Lost Acknowledgement: Suppress the original endpoint's
response.
Test 63 — Duplicate Failover Effect: Attempt the operation again
through the successor.
Test 64 — Actual-Effect Reconciliation: Query qualified resource
outcome.
Test 65 — Indeterminate Outcome: Preserve unresolved effect state.
Test 66 — Service Registry Rollback: Restore an earlier alias
mapping.
Test 67 — Identity Nonresurrection: Refuse restored obsolete
authority.
5.7.3.69. Source page 2982 of the original specification
Test 68 — Device Reassignment: Change the physical device behind a
stable address.
Test 69 — Qualified Device Replacement: Permit an eligible
replacement under current source authority.
Test 70 — Hardware Command Effect: Verify actual device and command
at the sink.
Test 71 — Removal of Source Authority: Attempt a valid resource
operation without original permission.
Test 72 — Removal of Actual Identity Check: Attempt target
substitution.
Test 73 — Removal of Tool Effect Correspondence: Attempt a hidden new
side effect.
Das Expires 29 April 2027 [Page 554]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Test 74 — Removal of Substitution Fencing: Attempt stale finality
after rebinding.
Test 75 — Removal of Sink Reconstruction: Attempt different actual
operation parameters.
Test 76 — Removal of Sink-Local Consumption: Attempt duplicate
effects.
Test 77 — Qualified Service Availability: Compare fixed-address
pinning with protected identity-equivalent routing.
Test 78 — Discovery Performance: Measure protected resolution and
authentication overhead.
Test 79 — Large Tool Registry: Measure operation-specific contract
and dependency checks.
Test 80 — Complete Integrated Workflow: Combine original source
authority, target identity, dynamic discovery, workload
authentication, actual resource qualification, tool-contract
continuity, material substitution fencing, independent validation,
target-bound non-bearer finality, actual sink reconstruction,
protected consumption, and recovery.
34.80.1 — Proposed Measurements
The experiments may measure:
Unauthorized real resource effects;
Wrong-target acceptance;
Cross-tenant effects;
Alias substitution detection;
Tool side-effect mismatch detection;
DNS rebinding outcomes;
5.7.3.70. Source page 2983 of the original specification
Redirect policy violations;
Actual endpoint and service identity mismatch;
False denial during legitimate migrations;
Das Expires 29 April 2027 [Page 555]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Credential audience mismatch;
Resource version and object identity errors;
Replay and duplication;
Recovery correctness;
And verification latency.
34.80.2 — Comparative Ablation
A useful four-configuration comparison comprises:
Configuration A — Name-Based Authorization: The system approves the
logical hostname, resource alias, or tool name.
Configuration B — Authenticated Endpoint Authorization: The system
adds current TLS or workload-identity verification and basic
destination policy.
Configuration C — Protected Target Continuity: The system checks
authenticated actual target, qualified alias mappings, tool-contract
generation, and material substitution fencing.
Configuration D — End-to-End Identity-to-Effect Finality: The system
additionally requires original source authority, current independent
operation validation, scoped non-bearer finality, actual resource-
sink reconstruction, and protected consumption.
34.80.3 — Proposed Decisive Experiment
An agent obtains approval for an operation against a specified
logical resource.
Before effectuation, an attacker rebinds the alias or changes the
selected tool implementation.
The original operation name and superficial invocation parameters
remain unchanged.
The experiment measures whether the actual receiving resource or
effect differs from what was authorized.
The strongest evidence concerns whether the unauthorized real
consequence occurred, not merely whether a gateway logged a mismatch.
Das Expires 29 April 2027 [Page 556]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A second experiment replaces the service with a qualified legitimate
successor while preserving the intended resource and effect.
5.7.3.71. Source page 2984 of the original specification
That test can demonstrate whether the system prevents unauthorized
substitution without indiscriminately blocking dynamic service
migration.
34.81 — NON-LIMITING PHOSITA REFERENCE PROTOTYPE
34.81.1 — Minimum Components
A PHOSITA may implement:
An autonomous agent;
A protected task-authority registry;
A versioned service-discovery table;
Two test API services;
An authenticated service-identity mechanism;
A protected tool registry;
An independent operation gateway;
A test-resource database;
And a protected finality and outcome journal.
34.81.2 — Initial Task
Authorize an agent to update one specific test record belonging to
Tenant A.
34.81.3 — Logical Resource
Provide a logical service alias.
34.81.4 — Protected Target Descriptor
Bind the Candidate Act to the authorized record, tenant, operation,
and service identity class.
34.81.5 — Non-Effective Hold
Das Expires 29 April 2027 [Page 557]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Prevent direct modification until protected checks pass.
34.81.6 — Initial Discovery
Resolve the logical service to Service Instance 1.
34.81.7 — Initial Identity Validation
5.7.3.72. Source page 2985 of the original specification
Verify the actual service identity and resource mapping.
34.81.8 — Identity Rebinding
Change discovery to Service Instance 2.
34.81.9 — Unauthorized Substitution Variant
Configure Instance 2 to target another tenant or record.
34.81.10 — Expected Result
The protected resource sink rejects the unauthorized mutation.
34.81.11 — Qualified Migration Variant
Configure Instance 2 as an eligible successor serving the same
authorized record.
34.81.12 — Expected Result
The operation may proceed after current independent target and effect
validation.
34.81.13 — Tool Contract Variant
Replace a read-only tool with a state-changing implementation while
preserving its name.
34.81.14 — Expected Result
The changed effect triggers current validation or denial.
34.81.15 — Redirect Variant
Redirect an otherwise permitted request to another resource audience.
34.81.16 — Expected Result
Das Expires 29 April 2027 [Page 558]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The protected gateway refuses the unauthorized destination.
34.81.17 — Finality Variant
Prepare valid target-bound non-bearer enablement.
34.81.18 — Expected Result
The actual sink verifies the current resource and commits only the
qualified operation.
34.81.19 — Failover Variant
Suppress an acknowledgement after the effect commits.
5.7.3.73. Source page 2986 of the original specification
34.81.20 — Expected Result
The successor endpoint does not automatically repeat the already
completed effect.
34.82 — OPTIONAL ADVANCED VARIATIONS
34.82.1 — Domain-Based Service Identity
The protected system uses qualified DNS and TLS service identity.
34.82.2 — Workload Identity
Services authenticate through short-lived workload credentials.
34.82.3 — Service-Mesh Identity
A protected proxy verifies eligible backend principals.
34.82.4 — Dynamic Discovery
The system permits qualified selection among multiple service
instances.
34.82.5 — Resource Alias Registry
The actual target is qualified against a protected alias mapping.
34.82.6 — Redirect Qualification
Material changes in destination or effect are independently verified.
Das Expires 29 April 2027 [Page 559]
Internet-Draft Execution-Finality Part 7: Tools October 2026
34.82.7 — Tool Schema Qualification
Typed tool input and output schemas contribute to the protected
contract.
34.82.8 — Tool Implementation Qualification
A protected registry identifies selected implementation versions.
34.82.9 — Tool Effect Contract
The tool's material consequential effects are separately
characterized.
34.82.10 — Filesystem Identity
An actual opened resource is verified against the authorized file.
34.82.11 — Object Storage Identity
5.7.3.74. Source page 2987 of the original specification
Current bucket, object, and generation information are checked.
34.82.12 — Database Identity
The actual selected record and tenant are qualified.
34.82.13 — Device Identity
The real connected actuator or controller is verified.
34.82.14 — Credential Audience
The actual receiving resource is checked against current credential
restrictions.
34.82.15 — Qualified Service Migration
An authenticated successor service may continue eligible operations.
34.82.16 — Failover Reconciliation
Unknown predecessor effects are reconciled before additional
effectuation.
34.82.17 — Protected Canonicalization
Das Expires 29 April 2027 [Page 560]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An actual protocol parser's effective resource interpretation is used
for correspondence checks.
34.82.18 — Hardware-Assisted Sink
A hardware controller may independently verify actual destination and
command identity.
34.82.19 — Cross-Domain Resource Handoff
A target may move between qualified administrative domains under
current source and resource authority.
34.82.20 — Causal Actual-Effect Receipt
A later operation may require qualified evidence identifying the
actual resource affected by an earlier completed operation.
34.83 — PROPOSED INVENTIVE-STEP CHARACTERIZATION
34.83.1 — Established Foundations
Existing systems provide:
Service discovery;
5.7.3.75. Source page 2988 of the original specification
DNS and TLS identity;
Authenticated workload identities;
Credential audience restrictions;
API tool schemas;
Resource identifiers;
Redirect validation;
Endpoint filtering;
Policy evaluation;
And version-controlled service configuration.
These technologies should be treated as established components.
Das Expires 29 April 2027 [Page 561]
Internet-Draft Execution-Finality Part 7: Tools October 2026
34.83.2 — Candidate Objective Technical Problem
How to preserve the identity and actual consequential semantics of a
source-authorized autonomous operation despite dynamic service
discovery, resource alias rebinding, tool replacement, proxy routing,
and legitimate service migration, without relying exclusively upon
static endpoint pinning or accepting previously valid tool names and
authentication results as sufficient authority to produce real
resource effects.
34.83.3 — Proposed Technical Solution
A protected controller constructs an Authorized Target Descriptor for
a non-effective Candidate Act.
The descriptor identifies the permitted actual resource and material
tool effect conditions.
Qualified discovery and current service authentication establish
candidate targets.
A protected identity-continuity controller determines whether
endpoint, object, or tool changes remain within the authorized
equivalence envelope.
Material changes trigger operation-specific finality fencing.
An independent validator reconstructs current actual target and tool
semantics.
Scoped non-bearer finality is constituted for the qualified
operation.
The receiving Finality Sink independently verifies the actual
resource and effect before protected consumption.
34.83.4 — Not Merely DNS Validation
5.7.3.76. Source page 2989 of the original specification
A DNS response may identify a service endpoint.
The proposed combination separately verifies current actual resource
identity and consequent source authority.
34.83.5 — Not Merely TLS Authentication
TLS can authenticate selected endpoint identities.
Das Expires 29 April 2027 [Page 562]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The proposed combination also verifies the actual tenant, resource
object, tool effect, and operation-specific finality.
34.83.6 — Not Merely Static Endpoint Pinning
Static endpoint pinning can restrict connections.
The proposed system may allow qualified resource-preserving migration
while rejecting materially different actual targets.
34.83.7 — Not Merely Tool Schema Validation
A schema can validate selected argument structures.
The proposed combination additionally binds actual effects and actual
resource identity to protected authorization.
34.83.8 — Not Merely Credential Audience Restriction
An audience restriction limits where a credential may be used.
The proposed system separately verifies the exact consequential
operation and receiving resource object.
34.83.9 — Not Merely a Service Registry
A service registry resolves logical services to endpoints.
The proposed combination converts material identity transitions into
operation-specific finality invalidation and sink-side verification.
34.83.10 — Candidate Narrow Inventive Kernel
A protected autonomous target-continuity execution-finality system in
which a consequential Candidate Act held non-effective is bound to a
protected descriptor of permitted actual resource identity and tool-
effect semantics; a qualified discovery controller establishes
current endpoint and workload identity; a protected continuity
controller classifies endpoint, alias, or tool changes as qualified
equivalents or material substitutions and fences affected pending
finality; an independent execution-time validator establishes current
actual resource and effect correspondence; and an actual Finality
Sink reconstructs the pending consequential operation and permits
effectuation
Das Expires 29 April 2027 [Page 563]
Internet-Draft Execution-Finality Part 7: Tools October 2026
5.7.3.77. Source page 2990 of the original specification
only following verification of current target identity, originating
source authority, scoped non-bearer enablement, and protected sink-
local consumption.
34.83.11 — Alias Rebinding Kernel
A narrower candidate may require protected current resolution-
generation checks and actual sink verification of resource-object
identity despite stable logical aliases.
34.83.12 — Tool Contract Kernel
Another candidate may require a protected association between tool-
contract generations and actual consequence descriptors, so that
material behavior changes invalidate pending tool finality.
34.83.13 — Qualified Migration Kernel
Another candidate may permit replacement service instances under
protected resource-identity equivalence while preserving operation
scope and consumption.
34.83.14 — Canonicalization Kernel
Another candidate may require actual receiving-resource
interpretation to control authorization correspondence rather than
relying solely upon upstream textual parsing.
34.83.15 — Multi-Hop Resource Kernel
Another candidate may require material redirect and proxy-backend
changes to remain within a protected authorized destination envelope
and be verified against the actual final recipient.
34.83.16 — Failover Nonduplication Kernel
Another candidate may require protected logical-operation continuity
and qualified actual-outcome reconciliation across a change of
receiving endpoint.
34.83.17 — Hindsight and Functional-Combination Analysis
A later inventive-step argument should identify the closest existing
service-discovery security, workload identity, tool authorization,
and resource-effectuation gateway systems.
Das Expires 29 April 2027 [Page 564]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The argument should not treat DNS rebinding prevention, TLS
authentication, token audience restrictions, endpoint pinning, or
resource-ID checks as individually novel.
The pertinent comparison should examine whether earlier systems
already teach the claimed combined relationship among:
1. An original source-authorized Candidate Act held in a Non-
Effective State; 2. A protected authorized actual-target and
material tool-effect descriptor; 3. Current authenticated endpoint
and workload identity; 4. Qualified identity equivalence for
legitimate migration; 5. Operation-specific material substitution
classification;
5.7.3.78. Source page 2991 of the original specification
6. Protected fencing of pending authority when actual target or tool
semantics change; 7. Current independent reconstruction of resource
identity and operation parameters; 8. Cross-committed identity-
continuity evidence; 9. Scoped non-bearer finality bound to actual
target and effect; 10. Independently enforcing resource-sink
identity and operation correspondence; 11. Protected sink-local
consumption and failover outcome preservation.
34.83.18 — Technical Interaction Rather Than Aggregation
The candidate technical interaction comprises several causally
distinct controls.
First, the target descriptor establishes what was actually
authorized.
Second, the discovery and continuity controller determines whether a
new endpoint still represents that authorized target.
Third, material substitution fencing prevents an obsolete approval
from being used against the new target.
Fourth, the independent sink reconstructs the actual resource
operation rather than trusting an upstream assertion of identity.
Fifth, the consumption controller prevents identity migration or
failover from duplicating the authorized effect.
The combination should be compared against prior systems providing
similar controls, rather than assuming its inventive character from
the number of components.
Das Expires 29 April 2027 [Page 565]
Internet-Draft Execution-Finality Part 7: Tools October 2026
34.83.19 — Proposed Causal Technical Effects
A qualified implementation may demonstrate:
Prevention of real operations against rebound unauthorized resources;
Prevention of unauthorized cross-tenant mutations despite valid
service authentication;
Prevention of changed tool behavior from inheriting earlier
approvals;
Prevention of unauthorized redirect and backend substitution;
Preservation of legitimate load balancing and service migration;
And preservation of protected single-use or bounded operation
authority across failover.
34.83.20 — Strong Comparative Test
A controlled prototype may compare:
A system authorizing only a hostname or tool name;
5.7.3.79. Source page 2992 of the original specification
A system authenticating the endpoint and checking the tool schema;
And a system additionally binding Candidate Acts to actual resource
identity, qualifying dynamic substitutions, and enforcing operation-
specific sink finality.
A useful test changes the actual receiving target or tool behavior
after initial approval while preserving the original logical name.
The decisive observation is whether an unauthorized real resource
mutation occurs.
A second test performs a legitimate service migration with an
unchanged authorized resource and effect.
The result can demonstrate whether the claimed mechanisms avoid
unnecessary fixed-endpoint restrictions.
34.83.21 — Patentability Qualification
Das Expires 29 April 2027 [Page 566]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The technical combinations above are candidate claim-support
disclosures.
They do not establish novelty, inventive step, sufficiency, priority,
or enforceable scope merely by being described.
Any later claim must be supported by the originally filed
specification and assessed against the actual relevant prior art
under the applicable legal standard.
34.84 — INDUSTRIAL APPLICABILITY
34.84.1 — Enterprise AI Agents
Dynamic tools and services may be qualified against exact current
resource authority.
34.84.2 — Cloud Infrastructure
Resource aliases and service endpoints may change without silently
redirecting authorized effects.
34.84.3 — Service Meshes
Backend workload identity and actual resource mapping may be
verified.
34.84.4 — API Gateways
Requests may remain bound to qualified actual receiving resources and
operation semantics.
34.84.5 — Tool-Using AI Systems
5.7.3.80. Source page 2993 of the original specification
Named tools may be upgraded without automatically inheriting
authority for additional effects.
34.84.6 — Software Development
Agent operations may distinguish test and production resources
despite identical interfaces.
34.84.7 — Database Administration
Actual row and tenant identity may be checked before mutations.
Das Expires 29 April 2027 [Page 567]
Internet-Draft Execution-Finality Part 7: Tools October 2026
34.84.8 — Object Storage
Object versions and account ownership may be bound to actual writes.
34.84.9 — Filesystem Security
Protected operations may verify actual opened objects against
authorized resources.
34.84.10 — Financial Processing
Payment destinations and account identities may remain distinct from
service hostnames.
34.84.11 — Electronic Commerce
Dynamic purchasing integrations may be qualified against actual
merchant, account, recipient, and transaction targets.
34.84.12 — Credential Management
Actual service audiences and resource identities may remain protected
during credential exercise.
34.84.13 — Telecommunications
Network service identities and configuration targets may be verified
despite dynamic infrastructure.
34.84.14 — Industrial Automation
Device replacement and address reassignment may be governed through
actual command-target identity.
34.84.15 — Robotics
Current actuator identity may be distinguished from a reused logical
command address.
34.84.16 — Autonomous Transportation
Dynamic service and device control identities may remain bound to
authorized consequences.
5.7.3.81. Source page 2994 of the original specification
34.84.17 — Satellite Systems
Das Expires 29 April 2027 [Page 568]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Delayed commands may be qualified against actual current receiving
devices and control authority.
34.84.18 — Multi-Agent Systems
Agent-to-tool and tool-to-tool delegation may remain bounded by
source-authorized actual effects.
34.84.19 — Confidential Computing
Protected environments may enforce service, resource, and operation
identity continuity.
34.84.20 — Future Autonomous Critical Systems
Dynamic computing resources may be replaced without transferring
unlimited consequential authority to unrelated endpoints or tool
implementations.
34.85 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
34.85.1 — Candidate Independent System Claim
A system comprising:
A protected originating source-authority controller configured to
identify a permitted consequential operation;
A Candidate Act controller configured to maintain the proposed
operation in a Non-Effective State;
An Authorized Target Descriptor controller configured to associate
the Candidate Act with a protected permitted actual resource identity
or identity predicate and a material operation-effect descriptor;
A qualified service-discovery controller configured to resolve
current candidate endpoints or tool implementations;
An identity-continuity controller configured to compare current
actual endpoint, service, resource, and tool semantics with the
authorized descriptor;
A protected substitution controller configured to fence pending
finality after a material identity or effect change;
An independent execution-time validator configured to establish
current source, actual resource, and operation correspondence;
Das Expires 29 April 2027 [Page 569]
Internet-Draft Execution-Finality Part 7: Tools October 2026
A scoped non-bearer finality controller;
5.7.3.82. Source page 2995 of the original specification
And an independent actual Finality Sink configured to reconstruct the
pending consequential operation and conditionally release the effect
only upon verification of current actual target identity, operation
semantics, source authority, and protected sink-local consumption.
34.85.2 — Candidate Independent Method Claim
A method comprising:
Establishing original source permission;
Constructing a Candidate Act;
Maintaining the operation non-effective;
Constructing an Authorized Target Descriptor;
Obtaining qualified dynamic discovery evidence;
Authenticating a current receiving principal;
Identifying the actual resource and tool-effect semantics;
Classifying any changed endpoint, alias, or implementation as a
qualified equivalent or material substitution;
Fencing affected pending finality;
Independently revalidating the actual operation;
Preparing scoped non-bearer enablement;
And effecting the operation only through an actual Finality Sink that
reconstructs and verifies the current receiving resource and
permitted consequential effect.
34.85.3 — Candidate Independent Tool-Continuity Claim
A protected autonomous tool-execution system configured to bind a
proposed tool operation to a qualified tool-effect contract, detect a
material change in tool implementation or semantics after initial
authorization, invalidate affected pending finality, and require
independent actual-resource verification before the changed tool can
produce a real effect.
Das Expires 29 April 2027 [Page 570]
Internet-Draft Execution-Finality Part 7: Tools October 2026
34.85.4 — Candidate Independent Dynamic-Migration Claim
A protected execution system configured to permit qualified changes
in network or workload instance locations while maintaining a
protected operation-specific actual resource identity, source-
authorized effect scope, and sink-local finality consumption.
34.85.5 — Candidate Independent Alias-Rebinding Claim
5.7.3.83. Source page 2996 of the original specification
A system configured to detect a material change between a source-
authorized logical resource reference and the actual resource
obtained at effectuation, withhold or revalidate the pending
Candidate Act, and require independent actual resource-sink
correspondence before protected consequential release.
34.86 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
1. The workload comprises an autonomous AI agent. 2. The workload
invokes a named tool. 3. The workload invokes a network API. 4. The
workload accesses a filesystem resource. 5. The workload accesses a
database resource. 6. The workload accesses an object-storage
resource. 7. The workload controls a physical device. 8. The
Candidate Act identifies an originating source grant. 9. The
Candidate Act identifies an intended consequential operation. 10.
The Candidate Act is held non-effective. 11. An Authorized Target
Descriptor identifies a logical resource. 12. The descriptor
identifies a permitted actual resource. 13. The descriptor
identifies a permitted resource identity predicate. 14. The
descriptor identifies a tenant or account scope. 15. The descriptor
identifies an authenticated service principal. 16. The descriptor
identifies a tool operation class. 17. The descriptor identifies
material effect parameters. 18. The descriptor identifies a
designated actual Finality Sink. 19. A protected controller obtains
current DNS resolution evidence. 20. A protected controller obtains
current service-discovery evidence. 21. The controller verifies the
endpoint actually contacted. 22. The controller verifies a qualified
TLS service identity. 23. The controller verifies a qualified
workload identity. 24. A service identity is distinguished from an
actual resource identity. 25. A network address is distinguished
from a logical service identity. 26. A resource alias is
distinguished from the actual protected object. 27. A protected
registry maintains a logical-to-actual identity mapping. 28. The
mapping includes a resolution generation. 29. The Candidate Act is
associated with a protected identity dependency set. 30. A material
alias change activates a finality fence. 31. A nonmaterial endpoint
change may be permitted after qualified identity continuity. 32. A
Das Expires 29 April 2027 [Page 571]
Internet-Draft Execution-Finality Part 7: Tools October 2026
protected equivalence class may identify permitted service instances.
33. An unqualified discovery endpoint is not automatically a member
of the class. 34. A revoked service instance is excluded from
current eligibility. 35. A qualified service migration may preserve
actual resource authorization. 36. Migration does not restore
consumed finality. 37. A service failover may require reconciliation
of earlier actual effect outcomes. 38. A lost acknowledgement does
not independently authorize a duplicate effect. 39. A redirect
changes the candidate effective destination. 40. A redirected
destination is verified against the authorized target envelope. 41.
Credentials are not automatically forwarded to an unauthorized
redirect target.
5.7.3.84. Source page 2997 of the original specification
42. A protected controller restricts redirect or proxy-chain length.
43. A protected proxy may verify the actual selected backend. 44. A
trusted front-end identity is distinguished from backend resource
authority. 45. A credential audience is checked against the actual
receiving service. 46. A resource-specific scope is checked
separately from credential audience validity. 47. A protected tool
registry identifies the tool's qualified provider. 48. The registry
identifies the current tool-contract generation. 49. The registry
identifies declared material side effects. 50. The registry
identifies applicable resource scopes. 51. A tool schema is
distinguished from actual implementation behavior. 52. A material
tool semantic change triggers pending finality revalidation. 53. A
newly introduced tool side effect requires applicable source
authority. 54. A stable tool name does not automatically establish
unchanged semantics. 55. Tool implementation replacement may be
permitted upon qualified actual-effect
continuity. 56. Tool descriptions do not independently establish
original task authority. 57. A protected controller verifies actual
tool operation parameters. 58. A protected controller verifies
actual method semantics. 59. A canonicalization profile is
associated with the effective protocol. 60. A resource URI is parsed
under qualified effective rules. 61. Reserved characters are
interpreted according to the actual protocol semantics. 62. A
material authorization/resource parser mismatch may cause denial. 63.
A filesystem sink verifies the actual opened object. 64. A path or
symbolic-link substitution may trigger target rejection. 65. A
storage sink verifies current object identity or version. 66. A
database sink verifies the actual selected record. 67. A database
sink verifies current tenant identity. 68. A hardware sink verifies
the actual device identity. 69. A device address may change without
changing the authorized physical resource. 70. A device address may
be reused for an unauthorized resource. 71. A protected controller
Das Expires 29 April 2027 [Page 572]
Internet-Draft Execution-Finality Part 7: Tools October 2026
maintains a current tool or resource resolution generation. 72. A
protected substitution classifier distinguishes equivalent migration
from material
replacement. 73. An unresolved mandatory identity condition causes
the effect to remain withheld. 74. Collection-time identity evidence
may be protected. 75. Execution-time identity evidence may be
independently obtained. 76. Collection and execution identity
evidence may be cross-committed. 77. The finality enablement is
bound to an actual target descriptor. 78. The finality enablement is
bound to material operation parameters. 79. The finality enablement
identifies a designated receiving sink. 80. The actual sink
independently reconstructs the pending operation. 81. The sink
independently verifies actual resource identity. 82. The sink
verifies current originating source authority. 83. The sink verifies
current resource owner or tenant scope. 84. The sink verifies
current applicable policy or revocation state. 85. The sink verifies
current tool-effect correspondence. 86. The sink verifies protected
non-bearer finality. 87. The sink verifies protected consumption.
88. A replay of the same finality reference cannot independently
cause a second effect.
5.7.3.85. Source page 2998 of the original specification
89. A logical alias restored from a snapshot does not automatically
restore revoked
authority. 90. A qualified actual-effect receipt may identify the
actual receiving resource and
completed operation. 91. The receipt may support a separate causally
dependent successor operation. 92. The successor still requires
current original source authority. 93. A dynamic service location
may be allowed without fixed-address pinning. 94. Protected resource
identity may be enforced through software, network, hardware, or
database mechanisms. 95. Existing URI, DNS, TLS, workload-identity,
audience-restriction, transactional, and
resource-gateway technologies may be employed as optional
implementation substrates.
34.87 — UNIVERSAL COMBINATION, SUBCOMBINATION, AND NON-LIMITING
PHOSITA CLAUSE
The technical features disclosed in the present embodiment may be
implemented individually where technically sufficient or in any
technically compatible combination.
Das Expires 29 April 2027 [Page 573]
Internet-Draft Execution-Finality Part 7: Tools October 2026
An implementation may use authenticated DNS resolution.
Another may use TLS service identity.
Another may use mutual TLS.
Another may use workload-identity credentials.
Another may use service-discovery registries.
Another may use an authenticated service mesh.
Another may use protected network proxies.
Another may use URI normalization.
Another may use resource-specific identity descriptors.
Another may use object-storage versioning.
Another may use file-object identity controls.
Another may use database record identifiers.
Another may use protected device identities.
Another may use tool-contract registries.
Another may use executable tool-effect validation.
5.7.3.86. Source page 2999 of the original specification
Another may use cryptographic commitments.
Another may use credential audience restrictions.
Another may use independently enforcing Finality Sinks.
Another may use protected failover reconciliation.
The invention does not require that every permitted resource be bound
to one fixed IP address.
The invention does not require that every legitimate service
migration invalidate the operation.
The invention does not require a particular workload identity
protocol.
Das Expires 29 April 2027 [Page 574]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The invention does not require a particular cloud resource naming
convention.
The invention does not assume that DNSSEC or TLS alone establishes
actual resource-operation authorization.
The invention does not assume that a valid service certificate
authorizes every tenant hosted by the service.
The invention does not assume that a tool's syntactic schema
establishes its full runtime effects.
The invention does not treat an authenticated but materially changed
endpoint as automatically source-authorized.
The invention does not treat a changed physical endpoint as
automatically unauthorized where qualified actual resource and effect
continuity remain valid.
The invention does not assume that a URI string has identical
semantics under every parser or backend.
The invention does not assume that an upstream proxy controls the
actual receiving resource unless the deployed enforcement
architecture establishes that property.
The invention does not require a universal global service-discovery
version.
The invention does not assume atomic effectuation across
independently controlled remote services.
The invention does not permit a qualified service failover to create
fresh authority for an already consumed or indeterminate operation.
The invention does not permit a tool registry entry to independently
expand original task permission.
5.7.3.87. Source page 3000 of the original specification
The invention does not require every tool to be executed in a
particular sandbox, operating system, virtual machine, or hardware
device.
The drawings, diagrams, algorithms, pseudocode, equations, examples,
proposed experiments, data structures, and implementation references
are illustrative and non-limiting technical aids for a person having
ordinary skill in the art.
Das Expires 29 April 2027 [Page 575]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Compatible technical limitations disclosed across multiple
embodiments may be combined where supported without requiring every
optional feature in every implementation.
34.88 — FINAL TECHNICAL CHARACTERIZATION
The present Embodiment 34 discloses a protected autonomous execution-
finality architecture for consequential operations whose logical
resource names, discovered endpoints, service instances, tool
implementations, or actual resource mappings may change between
initial authorization and effectuation.
An originating principal authorizes a bounded operation against a
specified resource or resource class.
The computational workload constructs a Candidate Act.
The Candidate Act remains in a Non-Effective State.
A protected controller establishes an Authorized Target Descriptor
identifying the qualified receiving resource and permitted actual
effect.
The system obtains current service-discovery, workload-identity, and
tool-contract information.
A protected continuity controller determines whether a changed
endpoint, alias, service implementation, or tool contract preserves
the required target and operation conditions.
A material substitution causes affected pending finality to be
withheld or revalidated.
A qualified legitimate migration may proceed under protected resource
and effect continuity.
Independent execution-time validation establishes the current actual
target, authenticated receiving principal, tool effect, resource
authority, and operation parameters.
Scoped non-bearer finality is constituted for the qualified
operation.
The actual Finality Sink reconstructs the pending resource effect and
verifies that the real target and operation correspond to the
protected source authorization.
Das Expires 29 April 2027 [Page 576]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The sink additionally verifies current applicable resource and
revocation state and protected sink-local consumption.
5.7.3.88. Source page 3001 of the original specification
A stale or rebound resource alias cannot independently redirect the
consequence.
A stable tool name cannot independently authorize changed tool
behavior.
Valid service authentication does not automatically authorize another
tenant's resource.
Legitimate service migration does not require unconditional rejection
where protected identity continuity is established.
Failover cannot automatically duplicate an already completed or
indeterminate operation.
The principal candidate inventive technical concept of Embodiment 34
is a protected autonomous resource-identity-to-execution-finality
system in which a held Candidate Act is associated with authorized
actual resource and tool-effect conditions, dynamic discovery and
tool substitution are qualified under protected identity-continuity
rules, material changes fence pending finality, and an independently
enforcing actual Finality Sink reconstructs the real receiving
resource and consequential operation before current source-authorized
scoped non-bearer finality is consumed.
34.89 — SHORT PHOSITA IMPLEMENTATION USING EXISTING TECHNOLOGIES
A PHOSITA may use established technologies as non-limiting
implementation substrates.
Existing technology Optional implementation role RFC 3986 — URI
Generic Syntax
Parse and normalize relevant URI components under qualified rules RFC
9525 — Service Identity in TLS
Verify appropriate reference identifiers against authenticated
service identities RFC 9460 — DNS Service Binding
Discover alternative service endpoints and connection parameters
SPIFFE workload identity Authenticate eligible workloads or service
principals RFC 8707 — OAuth Resource Indicators Request selected
resource-audience-restricted access tokens
Das Expires 29 April 2027 [Page 577]
Internet-Draft Execution-Finality Part 7: Tools October 2026
RFC 9421 — HTTP Message Signatures
Protect specified HTTP message components under an applicable signing
profile RFC 9530 — HTTP Digest Fields
Bind selected HTTP content or representation data to integrity
digests Protected service-discovery registries Maintain qualified
logical-service-to-endpoint mappings
Typed tool-contract registries Identify current tool schema, version,
and expected effect classes
Transactional databases Maintain authoritative actual resource
identities, generations, and consumption state
5.7.3.89. Source page 3002 of the original specification
Filesystem object and descriptor APIs Verify selected actual opened
file objects
Object-storage conditional operations Check relevant current object
version or generation
Mutual TLS and protected API proxies
Authenticate service connections and mediate consequential requests
Hardware command gateways Verify actual physical device and command
identity
Durable operation journals Preserve actual target, attempt,
completion, and failover outcome evidence
34.89.1 — Practical Common Implementation Workflow
A PHOSITA may implement the architecture as follows.
First, establish an original source grant describing which actual
resources and consequential effects an autonomous agent may perform.
Second, represent each proposed operation as a Candidate Act.
Third, construct an Authorized Target Descriptor containing the
permitted actual resource identity, tenant or account, tool
operation, and material effect parameters.
Fourth, maintain a protected service registry associating logical
names with eligible authenticated service principals and qualified
actual resource scopes.
Das Expires 29 April 2027 [Page 578]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Fifth, maintain a protected tool registry containing operation
schemas, semantic effect classes, implementation references, and
contract generations.
Sixth, keep the Candidate Act non-effective until current destination
and tool conditions are independently qualified.
Seventh, use ordinary service-discovery and connection-establishment
technologies to identify candidate endpoints.
Eighth, authenticate the actual receiving service or workload.
Ninth, resolve the actual receiving object, account, database row,
file, or device under the relevant protected resource authority.
Tenth, compare the current target and tool effect with the protected
Authorized Target Descriptor.
Eleventh, treat a qualified service migration as potentially
permissible while fencing changes that materially alter the actual
resource or operation.
Twelfth, independently validate current source authorization, actual
resource permission, and operation semantics.
Thirteenth, prepare scoped non-bearer finality bound to the qualified
target and effect.
5.7.3.90. Source page 3003 of the original specification
Fourteenth, require the actual resource sink to reconstruct or
observe the real receiving resource and operation.
Fifteenth, verify current source authority, target identity, tool
semantics, revocation, enablement, and sink-local consumption before
the actual effect.
Sixteenth, record qualified actual outcomes and preserve the logical
operation identity through retries, migration, and failover.
34.89.2 — Minimal Reference Data Structures
AUTHORIZED_TARGET ( candidate_id, source_grant_reference,
logical_resource, permitted_actual_resource,
permitted_service_principal, permitted_tenant, operation_class,
tool_contract_generation, actual_operation_digest )
SERVICE_RESOLUTION ( logical_resource, endpoint_identity,
authenticated_service_principal, actual_resource_mapping,
Das Expires 29 April 2027 [Page 579]
Internet-Draft Execution-Finality Part 7: Tools October 2026
resolution_generation, current_revocation_generation ) TOOL_CONTRACT
( tool_id, provider_id, contract_generation, schema_digest,
effect_class, permitted_resource_class,
current_implementation_reference ) TARGET_FINALITY ( candidate_id,
actual_resource_identity, effective_operation_digest,
required_identity_generation, required_contract_generation, sink_id,
consumption_state )
5.7.3.91. Source page 3004 of the original specification
These structures are illustrative.
The claimed security properties arise from protected identity
qualification, independent actual operation verification, and
enforcing resource-sink behavior rather than the mere existence of
database fields.
34.89.3 — Specific Hindsight-Defense Prototype
A particularly useful reference implementation employs:
Two authenticated service instances;
One logical service name;
A resource database containing separate records for Tenant A and
Tenant B;
A tool registry with two tool implementations using the same callable
name;
A protected operation gateway;
And a transactional resource Finality Sink.
A legitimate source grant permits one update to a specific record
belonging to Tenant A.
The operation is prepared while Service Instance 1 is selected.
The system then changes the service-discovery mapping to Instance 2.
In one experiment, Instance 2 accesses the same authorized resource.
The protected controller may permit continuation after verifying
actual target and effect equivalence.
Das Expires 29 April 2027 [Page 580]
Internet-Draft Execution-Finality Part 7: Tools October 2026
In another experiment, Instance 2 accesses the resource belonging to
Tenant B.
The actual resource sink must refuse the operation.
A further experiment replaces the tool with an implementation that
produces an additional external side effect.
The old Candidate Act cannot authorize the new side effect without
applicable current source and finality conditions.
Finally, the system suppresses acknowledgement of a completed update
and performs service failover.
The successor cannot independently repeat the already consumed
operation.
The experiments should inspect the actual resource database and
protected consumption journal rather than relying solely upon agent
or gateway logs.
5.7.3.92. Source page 3005 of the original specification
34.89.4 — Critical Implementation Cautions
A hostname is not necessarily an immutable resource identity.
An IP address is not necessarily a unique service principal.
A TLS certificate may authenticate a service without determining the
specific tenant or protected object.
A service registry can provide discovery without conferring
originating task authority.
A tool schema can constrain parameter syntax without proving all
implementation side effects.
A resource audience can constrain token use without establishing
exact operation permission.
A valid HTTP message signature protects its defined covered
components, not automatically every omitted field.
A local validation cannot guarantee that an independent remote effect
is atomic with the validator's state.
Das Expires 29 April 2027 [Page 581]
Internet-Draft Execution-Finality Part 7: Tools October 2026
The actual protected sink and its supported resource consistency
model determine the scope of the effectuation guarantee.
34.89.5 — Non-Limiting Common Reference Combination
Original source grant → Candidate Act → non-effective hold →
Authorized Target Descriptor → qualified service and tool discovery →
authenticated actual receiving principal → resource and operation
identity qualification → material substitution classification →
selective finality fence or authorized migration → independent
execution-time validation → cross-committed identity and effect
evidence → scoped non-bearer finality → actual Finality Sink →
resource, tool, and operation reconstruction → current source and
target correspondence → protected sink-local consumption → controlled
real effect.
The proposed distinguishing technical relationship is the mandatory
protection of the identity and consequential semantics of the actual
receiving resource throughout dynamic discovery, tool replacement,
alias rebinding, and service migration, enforced through operation-
specific finality rather than relying exclusively upon stable names,
authenticated connections, or previously approved tool invocations.
END OF EMBODIMENT 34 — COMPLETE TECHNICAL DISCLOSURE.
EMBODIMENT 35
PROTECTED AUTONOMOUS EXECUTION-FINALITY UNDER DEGRADED CONNECTIVITY,
NETWORK PARTITIONS, OFFLINE OPERATION, AND DELAYED CROSS-DOMAIN
REVOCATION
6. PHOSITA Implementation Using Existing Industry Technologies and
Platform Security Interfaces
The following procedures are newly authored illustrative realizations
and are not claimed as a complete deployed prototype, successful lab
experiment or the only way to implement the original patent
disclosure. An engineer should substitute equivalent technologies
only where they demonstrably preserve the source-authorized effect,
qualified observation, current target and actual sink enforcement
requirements. Distinguish an ordinary cooperating application from a
privileged OS-wide enforcement controller.
Das Expires 29 April 2027 [Page 582]
Internet-Draft Execution-Finality Part 7: Tools October 2026
6.1. Minimal cooperating resource reference build
Use two application clients (simulated iOS and Android or desktop
agents), a policy/binding service, independently authorized operation
validator, resource registry, transactional finality database, and a
receiving API/gateway that alone holds resource-write credentials.
The user-facing assistant proposes a Candidate Act but cannot
directly invoke the real effect-capable resource.
6.2. Application operation and identity normalization
Convert source-authorized task scope, actual method, resolved
resource ID, recipient, payload digest, tool contract generation and
designated FS into a stable typed object; reject ambiguous, null,
inconsistent or unsupported fields rather than accepting arbitrary
agent strings.
6.3. Qualified UI reference evidence
For a cooperating application, capture user selection via app-owned
stable identifiers and current resource view versions, not
screenshots alone. Authenticate presentation context, selection
provenance, observed object identity and expiry; avoid claiming that
every third-party app can access OS-level display or another app’s
private data.
6.4. Apple iOS, iPadOS and macOS application integration
Integrate with documented app-owned App Intents, Shortcuts, app
extensions and cooperating network endpoints. Use supported Keychain
and hardware-backed signing for relevant protected app identities;
build the decisive actual-effect gate at a cooperating receiver or
controlled app/resource. Ordinary third-party iOS apps cannot
install universal kernel hooks or intercept all other apps.
6.5. Android intents, Binder identity and credential support
Authenticate clients at Binder/application-service boundaries where
accessible, use Android permission APIs and Keystore-backed keys for
protected actors, and verify resource identity server-side.
Permissions to send an Intent or authenticate Binder do not establish
authorization for every actual downstream object mutation.
Das Expires 29 April 2027 [Page 583]
Internet-Draft Execution-Finality Part 7: Tools October 2026
6.6. Tool contract registry and effect version
Store signed or appropriately authenticated contract descriptors
including API schema, effect capabilities, destination classes,
transitive effects, privilege requirements, contract generation and
permitted compatibility policies. A human-readable tool name alone
is not stable effect identity.
6.7. Independent tool-change qualification
On tool upgrade or route change, compare the effect semantics under
competent policy. Differences may be compatible, explicitly
reauthorized, partially eligible under restricted scope, or
incompatible. Do not treat version string equality or a software
publisher signature as sufficient functional equivalence.
6.8. Model and runtime baseline control
Where authorized operations depend on approved model/algorithm/
runtime state, record a protected baseline, qualifying current
configuration evidence and the constraints under which behavioral
equivalence is accepted. A successful model hash check may prove
byte identity only, not the correctness of the eventual effect.
6.9. Instruction provenance and influence input
Record provenance for selected external content, tool outputs,
repository files, documents, browser state and agent instructions
with trust classes. A system should be able to identify where
externally controlled content attempted to change tool invocation
parameters and reject unauthorized source-grant expansion.
6.10. Resource alias and receiving-tenant identity
Separate logical URL, hostname, object name, alias and actual
receiving tenant/resource. Verify signed/authoritative current
mappings, destination certificate identity when meaningful,
application-layer resource ID, redirect chain and resource-binding
generation; do not infer unique identity solely from IP address or
TLS establishment.
6.11. Network redirects and re-resolution
Resolve authorization to the actual target under current policy and
re-evaluate material changes at the effectuation boundary. If a
redirect changes hostname, tenant, resource, audience or operation
semantics, old protected finality does not independently authorize
the redirected consequence.
Das Expires 29 April 2027 [Page 584]
Internet-Draft Execution-Finality Part 7: Tools October 2026
6.12. Protected storage and linearizable consumption
A serializable database or guarded compare-and-swap state store can
prototype finality consumption, resource-generation counters and
revocation epochs. Protect database mutation from the untrusted
agent and persist consumption before any state transition could allow
duplicate covered effects.
6.13. Tool package/update lifecycle
Verify installation authority and artifact provenance, record
dependencies and runtime load identity, freeze or fence pending acts
on material updates, invalidate old enablements, and require
revalidation under the current lifecycle generation before actual
effect release.
6.14. Container/sandbox deployment options
Use restricted runtimes, file/network policy controls, explicit
egress brokers or remote resource proxies where those controls
actually mediate all covered effect paths. A sandbox is helpful
confinement, not a substitute for protected source authorization,
target reconstruction or authoritative sink consumption.
6.15. Authenticated evidence and message formats
Use signed JSON/CBOR, COSE structures, transport mutual
authentication or OAuth-based proofs as appropriate to deployment.
Canonical byte representation, namespace rules, audience binding,
replay identifiers and trust-root rotation must be specified for each
actual implementation.
6.16. Threat and audit instrumentation
Record refusal reasons, qualified object identity, tool generation,
actual resource descriptor, protected grant/consumption transitions
and test receiver before/after state. Minimize personal content in
logs and avoid publishing real user tokens, private keys, unique
account identities or sensitive documents.
6.17. Fallback and privileged platform limits
When the effect boundary is outside any cooperating app/service or
cannot be controlled, characterize enforcement as partial, not
universal. A local OS integration, privileged broker, device-owner
app or hardware command gate requires actual system-level access;
unsupported paths are excluded from the defined guarantee or must be
made non-effective.
Das Expires 29 April 2027 [Page 585]
Internet-Draft Execution-Finality Part 7: Tools October 2026
6.18. Recovery and replay after crashes
On timeout or crash, inspect protected sink state and qualified
receiver outcome before retry; avoid treating a missing
acknowledgement as proof no operation happened. A retry with changed
actual object, redirected service, altered contract or consumed
authority requires fresh applicable validation.
6.19. Independent verification and developer review
Include separate unit and integration tests for semantics,
provenance, redirect, lifecycle transitions and sink equality;
publish exact software revisions and test fixtures on GitHub when
available. Document all assumed trusted services and untested
platform guarantees.
7. Reference Interfaces, Data Structures, State Machines and
Illustrative Algorithms
The following schemas and pseudocode are newly authored, non-
normative reference material showing one possible implementation.
They were not extracted verbatim from prior patent application
filings and are not experimental results or IETF-standard data
formats. Precise canonical encodings, algorithms and versioning need
an interoperable profile before multi-vendor deployment.
7.1. Typed Candidate Act and Semantic Context
Illustrative reference: protected state and actual receiving-
operation verification remain mandatory when required by the source-
specific implementation.
CandidateAct = {id, principal, source_grant, origin_agent,
ui_selection_ref, presentation_evidence_id,
authorized_target_id, target_version, recipient_id,
tool_id, contract_digest, runtime_generation,
operation_method, body_digest, data_classification,
destination_tenant, designated_sink, source_epoch,
expiry, single_use_nonce}; status = NON_EFFECTIVE
Figure 15: Typed Candidate Act and Semantic Context — data
structure or pseudocode
7.2. Qualified Presentation and Semantic Target Binding
Illustrative reference: protected state and actual receiving-
operation verification remain mandatory when required by the source-
specific implementation.
Das Expires 29 April 2027 [Page 586]
Internet-Draft Execution-Finality Part 7: Tools October 2026
qualify_user_reference(selection, protected_ui_context):
require source_selection_authentic(selection)
require view_generation_current(protected_ui_context)
resolved = resolve_stable_object(selection)
require stable_identity_or_refuse(resolved)
commit = bind(selection, resolved.id, resolved.version,
authorized_effect, presentation_context)
return protected_commit(commit)
Figure 16: Qualified Presentation and Semantic Target Binding —
data structure or pseudocode
7.3. Tool Contract Compatibility Predicate
Illustrative reference: protected state and actual receiving-
operation verification remain mandatory when required by the source-
specific implementation.
check_tool_contract(approved, current, authorized):
require valid_trust_root(current.publisher, current.manifest)
delta = compare_material_effect_semantics(approved,current)
if delta == NONE: return CONTINUE_WITH_CURRENT_CHECKS
if delta == PROVED_RESTRICTED_COMPATIBLE:
return LIMIT_TO_AUTHORIZED_INTERSECTION
if valid_separate_scope_change(authorized,delta):
return REVALIDATE_ALL_DEPENDENCIES
return FENCE_OLD_ENABLEMENT
Figure 17: Tool Contract Compatibility Predicate — data structure
or pseudocode
7.4. Runtime and Algorithm Baseline Qualification
Illustrative reference: protected state and actual receiving-
operation verification remain mandatory when required by the source-
specific implementation.
verify_execution_baseline(pending, current_runtime):
if baseline_not_mandatory_for(pending): return NOT_APPLICABLE
require valid_measurement_source(current_runtime)
require approved_or_qualified_configuration(current_runtime)
require compatible_tool_and_model_generation(pending)
require valid_revocation_and_current_policy()
return QUALIFIED_OR_WITHHOLD
Figure 18: Runtime and Algorithm Baseline Qualification — data
structure or pseudocode
Das Expires 29 April 2027 [Page 587]
Internet-Draft Execution-Finality Part 7: Tools October 2026
7.5. Instruction Provenance and Scope Isolation
Illustrative reference: protected state and actual receiving-
operation verification remain mandatory when required by the source-
specific implementation.
qualify_instruction_sources(task, inputs, pending):
for x in inputs:
record(provenance(x), trust_class(x), relevant_transforms(x))
if any_untrusted_input_attempts_new_grant(inputs): return DENY
if effect_scope(pending) not_subset_of source_scope(task):
return SCOPE_REAUTHORIZATION_REQUIRED
return EVIDENCE_READY_FOR_INDEPENDENT_SINK_CHECK
Figure 19: Instruction Provenance and Scope Isolation — data
structure or pseudocode
7.6. Alias and Resource-Binding Generation Check
Illustrative reference: protected state and actual receiving-
operation verification remain mandatory when required by the source-
specific implementation.
verify_resource_binding(alias, actual, authority):
resolved = trusted_resolver(alias)
require authenticated_resolution(resolved)
require resolved.epoch >= authority.binding_epoch
require same_resource_identity(resolved, actual)
require same_tenant_and_audience(resolved, actual)
require authorized_effect(actual, authority)
return CURRENT_BINDING_OR_REFUSE
Figure 20: Alias and Resource-Binding Generation Check — data
structure or pseudocode
7.7. Tool Install/Upgrade Generation Fence
Illustrative reference: protected state and actual receiving-
operation verification remain mandatory when required by the source-
specific implementation.
Das Expires 29 April 2027 [Page 588]
Internet-Draft Execution-Finality Part 7: Tools October 2026
transition_tool(old,new,install_grant):
require install_grant.valid_and_current
require validate_artifact_provenance(new)
require validate_contract_and_dependencies(new)
atomically:
fence_pendings_bound_to_old_generation(old)
advance_monotonic_generation(new)
activate_qualified_runtime(new)
require any_future_finality_is_reconstituted_under(new)
return CURRENT_GENERATION
Figure 21: Tool Install/Upgrade Generation Fence — data structure
or pseudocode
7.8. Finality Sink Reconstruction and Consumption
Illustrative reference: protected state and actual receiving-
operation verification remain mandatory when required by the source-
specific implementation.
execute_at_finality_sink(finality_ref):
actual = reconstruct_from_controlled_effect_interface()
candidate = protected_lookup(finality_ref)
require candidate.status == NON_EFFECTIVE
require current_source_and_delegation(candidate)
require current_tool_contract_and_runtime(candidate)
require qualified_presentation_and_target_mapping(candidate,actual)
require provenance_policy(candidate) and fresh_alias_binding(actual)
require actual_effect_is_within_source_scope(candidate,actual)
require sink_id_matches(actual) and protected_usage_available()
atomically_consume_authority(candidate,actual)
perform_only_verified_consequential_effect(actual)
Figure 22: Finality Sink Reconstruction and Consumption — data
structure or pseudocode
7.9. Redirect, Rebind or Capability-Substitution Handling
Illustrative reference: protected state and actual receiving-
operation verification remain mandatory when required by the source-
specific implementation.
Das Expires 29 April 2027 [Page 589]
Internet-Draft Execution-Finality Part 7: Tools October 2026
on_material_target_change(old,new,pending):
mark_pending_non_effective(pending)
if !authenticated(new.identity, new.tenant): return REFUSE
if !permitted_by_original_source_scope(new): return REAUTHORIZE
if !qualified_current_semantics(new): return REFUSE
revoke_or_fence(old.reference)
require_new_cross_bound_evidence_and_sink_validation()
return READY_FOR_FRESH_CURRENT_FINALITY
Figure 23: Redirect, Rebind or Capability-Substitution Handling —
data structure or pseudocode
7.10. Protected Failure and Recovery Classification
Illustrative reference: protected state and actual receiving-
operation verification remain mandatory when required by the source-
specific implementation.
on_ambiguous_tool_effect(attempt):
preserve_consumption_and_attempt_journal(attempt)
outcome = qualified_resource_side_reconcile(attempt)
if outcome == UNKNOWN: return INDETERMINATE_WITHHOLD
if outcome == COMPLETED: return DO_NOT_REPEAT
if outcome == PROVED_UNEFFECTED:
return REQUIRE_CURRENT_SOURCE_AUTHORITY_FOR_RETRY
return SEPARATELY_AUTHORIZED_RECOVERY_CANDIDATE_ACT
Figure 24: Protected Failure and Recovery Classification — data
structure or pseudocode
7.11. Source Authority and Tool Delta Machine
Illustrative reference: protected state and actual receiving-
operation verification remain mandatory when required by the source-
specific implementation.
States: PROPOSED, HELD_NES, EVIDENCE_QUALIFIED,
TOOL_FENCED, FINALITY_ELIGIBLE, CONSUMED,
EFFECT_COMMITTED, REFUSED, INDETERMINATE.
Allowed transitions depend on trusted policy and actual sink.
Tool identity generation advance cannot automatically map
TOOL_FENCED back to FINALITY_ELIGIBLE without fresh checks.
CONSUMED cannot reset to unused merely by agent restart.
Figure 25: Source Authority and Tool Delta Machine — data
structure or pseudocode
Das Expires 29 April 2027 [Page 590]
Internet-Draft Execution-Finality Part 7: Tools October 2026
8. Detailed Threat Models: Prompt Injection, Semantics Drift, Alias
Rebinding and Bypass
These attacker scenarios and mitigations are editorial threat-model
constructions, not findings about vulnerabilities in any particular
named product. They deliberately state residual risk if protected
interface observation, trustworthy inputs or enforcing resource
control are missing.
8.1. Threat 1 — Prompt injection from retrieved webpages
Attacker objective or failure mode: Untrusted retrieved content
claims to override the task and instructs agent to export secrets.
Required or illustrative mitigation: Source authority, content-origin
classification, actual egress/body binding and FS refusal.
Residual risk and boundary of claimed control: A compromised resource
with direct unmediated credential access may evade gateway-level
protections.
8.2. Threat 2 — Tool output laundering and authority confusion
Attacker objective or failure mode: A tool returns text resembling a
trusted system or user instruction.
Required or illustrative mitigation: Protected provenance
classification and no source-grant enlargement from lower-trust data.
Residual risk and boundary of claimed control: Influence inference
may be incomplete; decision must not rely on perfect
interpretability.
8.3. Threat 3 — User-interface semantic target substitution
Attacker objective or failure mode: Screen overlay or navigation
moves selection to another document after approval.
Required or illustrative mitigation: Qualified selection evidence,
stable object identity, version/freshness checks and sink-side actual
resource equality.
Residual risk and boundary of claimed control: A noncooperating UI/
application may not provide sufficient trustworthy presentation
evidence.
Das Expires 29 April 2027 [Page 591]
Internet-Draft Execution-Finality Part 7: Tools October 2026
8.4. Threat 4 — Tool update changes effect contract
Attacker objective or failure mode: Signed package updates an API to
upload extra data while retaining the same function name.
Required or illustrative mitigation: Versioned effect contract, post-
update semantic qualification, new source permission when needed,
finality fencing.
Residual risk and boundary of claimed control: Signatures prove
provenance, not functional safety or complete semantic equivalence.
8.5. Threat 5 — Algorithm/model swap or altered configuration
Attacker objective or failure mode: Inference provider or local agent
switches model/configuration after protected approval.
Required or illustrative mitigation: Current approved baseline where
required and actual sink effect validation.
Residual risk and boundary of claimed control: Not every deployment
has trusted runtime measurement; model equivalence can be
undecidable.
8.6. Threat 6 — DNS/URL redirect to wrong tenant
Attacker objective or failure mode: Same logical name resolves to
another service, tenant or object, or redirects after authorization.
Required or illustrative mitigation: Protected mapping generation,
actual receiver/resource identity, tenant/audience and method/body
checks.
Residual risk and boundary of claimed control: TLS alone may not
uniquely identify application-level tenant or business resource.
8.7. Threat 7 — Stale resource alias after rename
Attacker objective or failure mode: Authorized alias points to
another object following migration or relinking.
Required or illustrative mitigation: Current authoritative resource-
generation verification and actual object comparison.
Residual risk and boundary of claimed control: Some external
providers offer only eventual-consistency observations.
Das Expires 29 April 2027 [Page 592]
Internet-Draft Execution-Finality Part 7: Tools October 2026
8.8. Threat 8 — Malicious tool registry or dependency substitution
Attacker objective or failure mode: Attacker replaces registry
entries, plugin files or transitive dependency.
Required or illustrative mitigation: Authenticated provenance,
install authorization, loaded-runtime measurement where available and
lifecycle generation fencing.
Residual risk and boundary of claimed control: Publisher compromise,
compromised roots of trust or unobserved dependencies remain residual
risks.
8.9. Threat 9 — Concurrent race on single-use finality
Attacker objective or failure mode: Two tools invoke an effect
through competing aliases using the same enablement.
Required or illustrative mitigation: Sink-local authoritative atomic
consumption and alias-equivalent actual resource identity.
Residual risk and boundary of claimed control: Nonparticipating
effect paths can violate at-most-once claims outside stated coverage.
8.10. Threat 10 — Bypass through direct network or privileged broker
Attacker objective or failure mode: Agent bypasses intended gateway
to invoke same resource through an alternative path.
Required or illustrative mitigation: Identify covered effectuation
interfaces, block alternate credential paths, require enforcement at
actual receiving sink.
Residual risk and boundary of claimed control: No universal OS or
network mediation exists for arbitrary independent remote services.
8.11. Threat 11 — Forged presentation or identity evidence
Attacker objective or failure mode: Malicious component signs
misleading evidence or replays previously valid identity assertions.
Required or illustrative mitigation: Role separation, current trust
anchors, monotonic generations, independent observation and
freshness.
Residual risk and boundary of claimed control: A fully compromised
protected root can invalidate system assumptions.
Das Expires 29 April 2027 [Page 593]
Internet-Draft Execution-Finality Part 7: Tools October 2026
8.12. Threat 12 — Crash and rollback restore stale tool authority
Attacker objective or failure mode: Snapshot rollback revives older
runtime or an already-consumed approval.
Required or illustrative mitigation: Protected monotonic epoch,
journal continuity, source revocation and sink consumption.
Residual risk and boundary of claimed control: Local rollback safety
may require hardware monotonic mechanisms or an independent state
service.
9. Proposed Reproducible Security and Interoperability Validation Suite
All test cases are PROPOSED and NOT EXECUTED by this document.
Expected pass/deny behavior is an engineering hypothesis under a
specified protected reference architecture. Each future run must
publish setup, trust assumptions, software versions, deterministic
fixtures, actual sink state and protected before/after resource
observations. A refusal log without proof that the governed effect
did not occur is insufficient evidence of enforcement.
9.1. TI01 — Authorized displayed document
Test setup/stimulus: User selects stable object A and actual target
remains A. Use simulated protected agent, independently administered
policy/binding service, non-production receiving effect sink,
authenticated test keys and frozen source/task fixtures.
Expected result: PERMIT once after current validation. Capture
actual method, resource identity, material payload, source grant,
tool epoch, reason code, authoritative consumption state and target
resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.2. TI02 — Changed UI selection
Test setup/stimulus: UI view changes from document A to B after
authorization. Use simulated protected agent, independently
administered policy/binding service, non-production receiving effect
sink, authenticated test keys and frozen source/task fixtures.
Das Expires 29 April 2027 [Page 594]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Expected result: WITHHOLD or revalidate; do not mutate B under A
grant. Capture actual method, resource identity, material payload,
source grant, tool epoch, reason code, authoritative consumption
state and target resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.3. TI03 — Ambiguous natural-language referent
Test setup/stimulus: Two objects satisfy “that file” without a
qualified selection. Use simulated protected agent, independently
administered policy/binding service, non-production receiving effect
sink, authenticated test keys and frozen source/task fixtures.
Expected result: WITHHOLD until reference is resolved under permitted
context. Capture actual method, resource identity, material payload,
source grant, tool epoch, reason code, authoritative consumption
state and target resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.4. TI04 — Stale resource version
Test setup/stimulus: The selected file changes version before actual
write. Use simulated protected agent, independently administered
policy/binding service, non-production receiving effect sink,
authenticated test keys and frozen source/task fixtures.
Expected result: REFUSE or use separately qualified policy and
version. Capture actual method, resource identity, material payload,
source grant, tool epoch, reason code, authoritative consumption
state and target resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.5. TI05 — Unauthorized recipient substitution
Test setup/stimulus: Actual send recipient differs from protected
authorized recipient. Use simulated protected agent, independently
administered policy/binding service, non-production receiving effect
sink, authenticated test keys and frozen source/task fixtures.
Das Expires 29 April 2027 [Page 595]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Expected result: REFUSE at receiving sink. Capture actual method,
resource identity, material payload, source grant, tool epoch, reason
code, authoritative consumption state and target resource before/
after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.6. TI06 — Tool contract compatible upgrade
Test setup/stimulus: Current signed contract is materially equivalent
under approved compatibility rule. Use simulated protected agent,
independently administered policy/binding service, non-production
receiving effect sink, authenticated test keys and frozen source/task
fixtures.
Expected result: MAY PERMIT after actual-operation check. Capture
actual method, resource identity, material payload, source grant,
tool epoch, reason code, authoritative consumption state and target
resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.7. TI07 — Tool contract expanded disclosure
Test setup/stimulus: New version silently adds recipient or data
export. Use simulated protected agent, independently administered
policy/binding service, non-production receiving effect sink,
authenticated test keys and frozen source/task fixtures.
Expected result: FENCE stale scope; REAUTHORIZE separately if
allowed. Capture actual method, resource identity, material payload,
source grant, tool epoch, reason code, authoritative consumption
state and target resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.8. TI08 — Tool description tampering
Test setup/stimulus: Tool registry metadata altered without trusted
authenticator. Use simulated protected agent, independently
administered policy/binding service, non-production receiving effect
sink, authenticated test keys and frozen source/task fixtures.
Das Expires 29 April 2027 [Page 596]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Expected result: DENY contract validation. Capture actual method,
resource identity, material payload, source grant, tool epoch, reason
code, authoritative consumption state and target resource before/
after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.9. TI09 — Model identity swap
Test setup/stimulus: Mandatory model baseline replaced mid-workflow.
Use simulated protected agent, independently administered policy/
binding service, non-production receiving effect sink, authenticated
test keys and frozen source/task fixtures.
Expected result: WITHHOLD until qualified current baseline. Capture
actual method, resource identity, material payload, source grant,
tool epoch, reason code, authoritative consumption state and target
resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.10. TI10 — Optional baseline correctly omitted
Test setup/stimulus: Task has no mandatory model identity requirement
and current effect stays within source scope. Use simulated
protected agent, independently administered policy/binding service,
non-production receiving effect sink, authenticated test keys and
frozen source/task fixtures.
Expected result: Do not impose unconditional model-hash gate; apply
all required other gates. Capture actual method, resource identity,
material payload, source grant, tool epoch, reason code,
authoritative consumption state and target resource before/after
state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
Das Expires 29 April 2027 [Page 597]
Internet-Draft Execution-Finality Part 7: Tools October 2026
9.11. TI11 — Prompt injection in webpage
Test setup/stimulus: Web page instructs agent to ignore task and send
private file. Use simulated protected agent, independently
administered policy/binding service, non-production receiving effect
sink, authenticated test keys and frozen source/task fixtures.
Expected result: REFUSE unauthorized final resource effect. Capture
actual method, resource identity, material payload, source grant,
tool epoch, reason code, authoritative consumption state and target
resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.12. TI12 — Prompt injection in repository
Test setup/stimulus: Malicious README requests production credential
exfiltration. Use simulated protected agent, independently
administered policy/binding service, non-production receiving effect
sink, authenticated test keys and frozen source/task fixtures.
Expected result: Reject untrusted instruction authority and withhold
egress. Capture actual method, resource identity, material payload,
source grant, tool epoch, reason code, authoritative consumption
state and target resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.13. TI13 — Forged tool reply
Test setup/stimulus: Tool returns false role or admin message. Use
simulated protected agent, independently administered policy/binding
service, non-production receiving effect sink, authenticated test
keys and frozen source/task fixtures.
Expected result: Do not treat tool text as competent source grant.
Capture actual method, resource identity, material payload, source
grant, tool epoch, reason code, authoritative consumption state and
target resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
Das Expires 29 April 2027 [Page 598]
Internet-Draft Execution-Finality Part 7: Tools October 2026
9.14. TI14 — Valid source grant with altered payload
Test setup/stimulus: Requested endpoint and identity match but
outgoing body changed. Use simulated protected agent, independently
administered policy/binding service, non-production receiving effect
sink, authenticated test keys and frozen source/task fixtures.
Expected result: REFUSE because actual effect descriptor mismatches.
Capture actual method, resource identity, material payload, source
grant, tool epoch, reason code, authoritative consumption state and
target resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.15. TI15 — DNS rebinding
Test setup/stimulus: Approved hostname resolves to a new unauthorized
service instance. Use simulated protected agent, independently
administered policy/binding service, non-production receiving effect
sink, authenticated test keys and frozen source/task fixtures.
Expected result: REFUSE absent renewed current identity
qualification. Capture actual method, resource identity, material
payload, source grant, tool epoch, reason code, authoritative
consumption state and target resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.16. TI16 — HTTP cross-tenant redirect
Test setup/stimulus: 302 redirects authorized request to an unrelated
tenant. Use simulated protected agent, independently administered
policy/binding service, non-production receiving effect sink,
authenticated test keys and frozen source/task fixtures.
Expected result: WITHHOLD absent source-permitted target
correspondence. Capture actual method, resource identity, material
payload, source grant, tool epoch, reason code, authoritative
consumption state and target resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
Das Expires 29 April 2027 [Page 599]
Internet-Draft Execution-Finality Part 7: Tools October 2026
9.17. TI17 — Object alias rebound
Test setup/stimulus: Document alias now resolves to a different
canonical object. Use simulated protected agent, independently
administered policy/binding service, non-production receiving effect
sink, authenticated test keys and frozen source/task fixtures.
Expected result: REFUSE or require fresh protected binding. Capture
actual method, resource identity, material payload, source grant,
tool epoch, reason code, authoritative consumption state and target
resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.18. TI18 — Service capability substitution
Test setup/stimulus: Replacement tool advertises broader privileges
with same tool name. Use simulated protected agent, independently
administered policy/binding service, non-production receiving effect
sink, authenticated test keys and frozen source/task fixtures.
Expected result: Reject unauthorized capability expansion. Capture
actual method, resource identity, material payload, source grant,
tool epoch, reason code, authoritative consumption state and target
resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.19. TI19 — Attested but unauthorized tool
Test setup/stimulus: Signed tool is authentic but actual effect
exceeds grant. Use simulated protected agent, independently
administered policy/binding service, non-production receiving effect
sink, authenticated test keys and frozen source/task fixtures.
Expected result: REFUSE despite successful provenance verification.
Capture actual method, resource identity, material payload, source
grant, tool epoch, reason code, authoritative consumption state and
target resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
Das Expires 29 April 2027 [Page 600]
Internet-Draft Execution-Finality Part 7: Tools October 2026
9.20. TI20 — Tool update with old queued request
Test setup/stimulus: Upgrade causes previously prepared command to
execute under new behavior. Use simulated protected agent,
independently administered policy/binding service, non-production
receiving effect sink, authenticated test keys and frozen source/task
fixtures.
Expected result: FENCE old Candidate Act and require current
finality. Capture actual method, resource identity, material
payload, source grant, tool epoch, reason code, authoritative
consumption state and target resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.21. TI21 — Tool rollback
Test setup/stimulus: Old runtime restored after protected update
generation. Use simulated protected agent, independently
administered policy/binding service, non-production receiving effect
sink, authenticated test keys and frozen source/task fixtures.
Expected result: REFUSE stale generation unless distinct qualified
transition. Capture actual method, resource identity, material
payload, source grant, tool epoch, reason code, authoritative
consumption state and target resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.22. TI22 — Unapproved dependency injection
Test setup/stimulus: Transient plugin dependency replaced after
install. Use simulated protected agent, independently administered
policy/binding service, non-production receiving effect sink,
authenticated test keys and frozen source/task fixtures.
Expected result: REFUSE where integrity predicate mandatory. Capture
actual method, resource identity, material payload, source grant,
tool epoch, reason code, authoritative consumption state and target
resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
Das Expires 29 April 2027 [Page 601]
Internet-Draft Execution-Finality Part 7: Tools October 2026
9.23. TI23 — Parallel double-use authority
Test setup/stimulus: Two processes invoke equivalent effect under
same scoped finality. Use simulated protected agent, independently
administered policy/binding service, non-production receiving effect
sink, authenticated test keys and frozen source/task fixtures.
Expected result: No more than the explicitly authorized effect count.
Capture actual method, resource identity, material payload, source
grant, tool epoch, reason code, authoritative consumption state and
target resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.24. TI24 — Agent process crash after consumption
Test setup/stimulus: Kill process after sink consumption, before
response. Use simulated protected agent, independently administered
policy/binding service, non-production receiving effect sink,
authenticated test keys and frozen source/task fixtures.
Expected result: No unsafe replay or authority reset. Capture actual
method, resource identity, material payload, source grant, tool
epoch, reason code, authoritative consumption state and target
resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.25. TI25 — Network timeout after effect
Test setup/stimulus: Receiver commits but acknowledgement is lost.
Use simulated protected agent, independently administered policy/
binding service, non-production receiving effect sink, authenticated
test keys and frozen source/task fixtures.
Expected result: Mark outcome uncertain, reconcile; do not duplicate.
Capture actual method, resource identity, material payload, source
grant, tool epoch, reason code, authoritative consumption state and
target resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
Das Expires 29 April 2027 [Page 602]
Internet-Draft Execution-Finality Part 7: Tools October 2026
9.26. TI26 — Android cooperating app integration
Test setup/stimulus: App-origin Intent requests effect and
cooperating resource enforces source scope. Use simulated protected
agent, independently administered policy/binding service, non-
production receiving effect sink, authenticated test keys and frozen
source/task fixtures.
Expected result: Permit bound act, deny target or payload
substitutions. Capture actual method, resource identity, material
payload, source grant, tool epoch, reason code, authoritative
consumption state and target resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.27. TI27 — iOS cooperating App Intents integration
Test setup/stimulus: Supported app-owned intent invokes cooperative
remote service. Use simulated protected agent, independently
administered policy/binding service, non-production receiving effect
sink, authenticated test keys and frozen source/task fixtures.
Expected result: Permit only verified in-scope effect; do not claim
system-wide interception. Capture actual method, resource identity,
material payload, source grant, tool epoch, reason code,
authoritative consumption state and target resource before/after
state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.28. TI28 — Noncooperating platform alternate path
Test setup/stimulus: External uncontrolled endpoint is directly
reachable by agent. Use simulated protected agent, independently
administered policy/binding service, non-production receiving effect
sink, authenticated test keys and frozen source/task fixtures.
Expected result: Report coverage failure; no unsupported non-
bypassability claim. Capture actual method, resource identity,
material payload, source grant, tool epoch, reason code,
authoritative consumption state and target resource before/after
state.
Das Expires 29 April 2027 [Page 603]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.29. TI29 — Evidence replay with stale generation
Test setup/stimulus: Attacker replays valid signed mapping from
earlier epoch. Use simulated protected agent, independently
administered policy/binding service, non-production receiving effect
sink, authenticated test keys and frozen source/task fixtures.
Expected result: REFUSE under current generation/freshness rules.
Capture actual method, resource identity, material payload, source
grant, tool epoch, reason code, authoritative consumption state and
target resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
9.30. TI30 — Verification exhaustion or cyclic references
Test setup/stimulus: Deep nested tool/alias graph exceeds configured
validation budget. Use simulated protected agent, independently
administered policy/binding service, non-production receiving effect
sink, authenticated test keys and frozen source/task fixtures.
Expected result: Bound effort and WITHHOLD rather than allow on
timeout. Capture actual method, resource identity, material payload,
source grant, tool epoch, reason code, authoritative consumption
state and target resource before/after state.
Status: PROPOSED/NOT EXECUTED. No outcome is represented as
experimentally validated, patented at a historical date or present in
any external company product.
10. Detailed Industry and Product Alignment: Operating Systems, Agent
Frameworks, API Services and Hardware Platforms
Product names identify engineer-relevant contexts and deployment
constraints, not claimed vendor adoption, endorsement, invention
derivation or patent infringement. Public platform APIs alone do not
authorize interception of arbitrary other-app or hardware effects.
The following specific technical mappings are editorial
interpretations; check current vendor documentation for deployed
features and access restrictions. Apple, Siri, iOS, iPadOS, macOS,
Android, Gemini, Bixby, Copilot, Alexa, Matter, and other names used
in this document are trademarks of their respective owners.
Das Expires 29 April 2027 [Page 604]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10.1. Apple iOS, iPadOS, Siri, Shortcuts and App Intents
Product-relevant security problem: Users can refer to currently
displayed messages/files/photos while an assistant or extension
proposes a cross-application operation. UI context, available
resource handles and receiving app API operations may diverge.
Technical alignment, potential deployment and limitations: Use
cooperating App Intents and resource-owner services with stable
selection identifiers; bind user-reference context to authorized
object/recipient and have the receiving effectful interface enforce
actual resource equality. Do not claim generic iOS third-party hooks
into other apps or kernel.
10.2. Apple macOS automation, Keychain and desktop developer tools
Product-relevant security problem: Desktop agents can interact
through shells, document pickers and privileged apps while apparent
selection and destination can change.
Technical alignment, potential deployment and limitations: An app-
owned protected service or cooperating privileged gateway can verify
actual file descriptor/path identity and current tool-effect
semantics before publication, deletion or upload.
10.3. Google Android, Gemini, Intents, Binder and Keystore
Product-relevant security problem: An Intent may reach the wrong
exported component or a legitimate assistant may act on a changed
selected document.
Technical alignment, potential deployment and limitations: Use
documented exported-component permission enforcement and Binder
caller checks, authentic resource handles, protected current binding
and receiver-side checks. Keystore secures keys but does not alone
bind all actual effect parameters.
10.4. Microsoft Windows, Azure, Agent Framework and enterprise
governance
Product-relevant security problem: Automation and administrator
agents use changing plugins, API versions, cloud subscriptions and
tenant aliases.
Technical alignment, potential deployment and limitations: Apply
tool-effect contract version controls, qualified workload identities
and resource-owner actual tenant/target checks at privileged Windows
service or Azure resource gateway where supported.
Das Expires 29 April 2027 [Page 605]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10.5. OpenAI Codex, Responses API, Agents SDK and computer use
Product-relevant security problem: Autonomous coding and computer-use
tools can ingest malicious repository instructions, browser content
or tool replies, then request credentialed writes.
Technical alignment, potential deployment and limitations: Treat tool
calls as Candidate Acts; isolate untrusted text from authority,
retain per-act effect binding, and require an independent receiving
action gate rather than relying solely on model obedience.
10.6. Anthropic Claude Code, Managed Agents and tool sandboxing
Product-relevant security problem: Changes in tool permissions,
runtime components and untrusted document inputs can alter the
intended consequence.
Technical alignment, potential deployment and limitations: Combine
supported sandbox restrictions with independent tool-contract
generation checks, provenance-sensitive effect qualification and
actual resource-side verification.
10.7. Google Cloud, Gemini Agent, Kubernetes and service discovery
Product-relevant security problem: Aliases, services, mesh routing
and project IDs may change even when a logical API hostname remains
the same.
Technical alignment, potential deployment and limitations: Bind
current service/tenant/resource identity and source-allowed effect
parameters; reconcile workload identity from a qualified issuer with
the actual receiving application-level object.
10.8. Meta Muse, Sentinel and AI-agent isolation
Product-relevant security problem: Protected network egress and
credential brokerage restrict call paths, but endpoint identity,
effect contract and actual downstream resource identity are separate
questions.
Technical alignment, potential deployment and limitations: Compare
capability and real-target enforcement mechanisms technically without
asserting a published Meta implementation of the complete
receipt/capability/sink protocol disclosed here.
Das Expires 29 April 2027 [Page 606]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10.9. NVIDIA OpenShell, Sentry, BlueField and GPU/accelerator control
Product-relevant security problem: Protected sandboxes or DPU-
mediated networking can constrain paths, while model tool behavior,
loaded plugins and actual hardware command effects may still change.
Technical alignment, potential deployment and limitations: Use
protected effect descriptors and current command-capability checks at
an appropriate governed egress or device interface, subject to what
that hardware actually mediates.
10.10. Qualcomm Snapdragon, Arm-based hardware and device controllers
Product-relevant security problem: Mobile SoC protected key use,
hardware command buffers and multiple processor partitions create
separate identities and effectuation paths.
Technical alignment, potential deployment and limitations: Use
available protected key/measurement primitives with resource-side
verification, ensuring app-level authority and actual device
consequences remain independently bounded.
10.11. Huawei and heterogeneous mobile/embedded ecosystems
Product-relevant security problem: Cross-vendor apps, device
services, mobile hardware and endpoint migrations use different
privilege and resource identity models.
Technical alignment, potential deployment and limitations: Platform-
neutral effect descriptors, authenticated adapter evidence and actual
receiving controller enforcement can preserve approved consequence
semantics without requiring a particular vendor implementation.
10.12. Banking, payments and merchant APIs
Product-relevant security problem: An agent may resolve an alias to a
different bank account, recipient or payment endpoint after consent.
Technical alignment, potential deployment and limitations: Bind
current payee/account/transaction identity and amounts to receiving
payment sink checks, and distinguish authentication and request
acceptance from actual settlement or downstream causal proof.
10.13. Telecommunications, 5G/6G and edge control planes
Product-relevant security problem: Logical network functions and
service instances migrate under changing discovery/configuration
while privileged routing or policy operations remain sensitive.
Das Expires 29 April 2027 [Page 607]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Technical alignment, potential deployment and limitations: Require
authenticated resource/tenant identity, current effect contract,
version and protected telecom-controller finality before committing
covered network changes.
10.14. Enterprise SaaS, collaboration, CRM and email
Product-relevant security problem: An agent may confuse similarly
named documents, tenants, calendars, folders or people and send data
to the wrong workspace.
Technical alignment, potential deployment and limitations: Use
resource-provider canonical IDs, current tenant authorization,
confirmed user context and outbound content checks; reject stale
aliases and untrusted message instructions.
10.15. Industrial IoT, robotics and autonomous control
Product-relevant security problem: A previously valid tool name may
map to another actuator or changed command meaning after updates.
Technical alignment, potential deployment and limitations: Constrain
safety-relevant actual command to qualified current hardware mapping
and enforce control at a device interface where a physical effect can
really be withheld.
10.16. Software development, package supply chain and CI/CD
Product-relevant security problem: Updated plugins, repository
instructions, signed artifacts and changed deployment targets can
redirect autonomous coding assistants.
Technical alignment, potential deployment and limitations: Use
artifact provenance and update-state information as inputs;
independently constrain production deployment target, credential
audience and actual operation at an enforcing deployment boundary.
10.17. Voice and System Assistants: Apple Siri, Google Gemini, Samsung
Bixby, Microsoft Copilot and Amazon Alexa
Product-relevant security problem: Assistant requests are full of
references that must be resolved: "send this to her", "pay the usual
amount", "turn off the bedroom light". The assistant resolves
"this", "her" and "the bedroom light" from screen context, history or
contact data, and the receiving app acts on whatever identifier it is
given. A wrong resolution, a contact with a similar name, or
injected text on screen can redirect the action while every API call
remains properly authenticated.
Das Expires 29 April 2027 [Page 608]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Technical alignment, potential deployment and limitations: Bind the
presented context and the resolved identifiers (contact record, file
version, device identifier) into protected presentation evidence when
the user confirms; have the receiving app or backend, acting as
Finality Sink, compare the actual recipient or object against that
evidence. Third-party implementers can enforce only at their own
action handlers and servers; private assistant internals are not
assumed to be available.
Technical effect: The consequential action is applied only to the
object the user actually saw and confirmed; an ambiguous or
substituted referent causes a refusal or re-confirmation instead of a
misdirected message, payment or device command (tests TI01 to TI05).
10.18. Model Context Protocol Servers, Agent-to-Agent Protocols and
Tool or Plugin Registries
Product-relevant security problem: Agents increasingly discover and
call tools exposed by Model Context Protocol (MCP) servers, other
agents and plugin marketplaces. Tool descriptions are read by the
model and can carry injected instructions; a server can change a
tool's behaviour or description after the user approved it; a look-
alike server or registry entry can impersonate a trusted one; and a
tool's output can be crafted to steer the next call.
Technical alignment, potential deployment and limitations: Record
each approved tool as a canonical tool-effect contract bound to the
server identity, tool version and declared effect class; treat any
change in description, schema or declared effects as a new contract
requiring re-qualification; mark tool outputs as lower-trust input
whose influence on later consequential calls is evaluated; and
enforce the approved contract at the resource-side Finality Sink
rather than in the agent.
Technical effect: A silently changed, impersonated or poisoned tool
cannot produce a consequential effect under an earlier approval, and
instructions carried in tool descriptions or outputs cannot by
themselves authorize a new effect (tests TI06 to TI08, TI13, TI18,
TI22).
10.19. Browser Agents, Web Automation and Computer Use
Product-relevant security problem: Browser and computer-use agents
read pages that may contain hidden instructions, click on elements
whose position or meaning can change between screenshot and click,
and submit forms to endpoints that can redirect.
Das Expires 29 April 2027 [Page 609]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Technical alignment, potential deployment and limitations: Bind the
intended element, form target origin and material fields to protected
evidence at approval; re-resolve the actual submission origin and
fields at a cooperating gateway or receiving service; treat page
content as lower-trust instruction input.
Technical effect: Form submissions, purchases and account changes
occur only on the origin and fields that were approved, defeating
layout swaps, overlay attacks and cross-origin redirects driven by
page content (tests TI11, TI16).
10.20. Banking, Payments, Agentic Commerce and Payee Identity
Product-relevant security problem: Payment agents may be told to "pay
the plumber" or "reorder from the same shop". Payee aliases, saved
beneficiaries and merchant identifiers can be rebound or
impersonated, and an invoice read by the agent can contain altered
bank details.
Technical alignment, potential deployment and limitations: Resolve
payee and merchant identity through authenticated directories or the
bank's own beneficiary records; bind the resolved identity, account
and amount at approval; and have the payment sink verify the actual
beneficiary account, not the display name.
Technical effect: Funds go only to the beneficiary that was verified
and approved; altered invoice details or rebound aliases produce a
refusal rather than a misdirected payment (tests TI05, TI17).
10.21. Email, Messaging and Collaboration Agents
Product-relevant security problem: Agents that draft and send email
or chat messages rely on autocomplete, distribution lists and shared-
channel names. A recipient suggestion, a renamed channel or a list
whose membership changed can send confidential content to the wrong
audience.
Technical alignment, potential deployment and limitations: Bind the
resolved recipient set, channel identifier and attachment versions to
the approval; re-resolve membership and identifiers at the sending
service immediately before delivery; refuse or re-confirm on any
expansion.
Technical effect: Messages and attachments reach only the audience
that was approved, preventing data disclosure through recipient
substitution or silent list growth (tests TI02, TI05, TI17).
Das Expires 29 April 2027 [Page 610]
Internet-Draft Execution-Finality Part 7: Tools October 2026
10.22. Healthcare Record and Clinical Documentation Agents
Product-relevant security problem: Clinical documentation and
ordering assistants must act on the correct patient record and the
correct version of a document. Similar names, merged records and
stale record views can cause an update or order to land on the wrong
patient.
Technical alignment, potential deployment and limitations: Bind
actions to the authoritative patient identifier and record version
presented at confirmation, and have the clinical system verify
identity and version at write time; ambiguous matches require
explicit human confirmation. This is an engineering pattern, not a
medical-device or clinical-safety certification.
Technical effect: Updates and orders are applied only to the patient
and record version that were actually confirmed, and stale or
ambiguous identity produces a refusal (tests TI03, TI04, TI17).
10.23. Document Signing, Legal and Back-Office Approval
Product-relevant security problem: Agents that route documents for
signature or approval can attach a different version of a contract
than the one reviewed, or route it to a different signatory.
Technical alignment, potential deployment and limitations: Bind the
exact document digest, version and signatory identity to the
approval; have the signing service verify the digest and signer
immediately before applying a signature.
Technical effect: A signature or approval is applied only to the
exact document version and signer that were reviewed (tests TI04,
TI14).
10.24. Cloud Infrastructure-as-Code, Accounts, Tenants and Regions
Product-relevant security problem: Infrastructure agents apply
changes using account aliases, profile names, Kubernetes contexts and
region defaults. A changed default, a renamed context or a DNS or
endpoint redirect can apply a destructive change to production
instead of a test environment, or to another tenant.
Technical alignment, potential deployment and limitations: Resolve
account, tenant, cluster and region to authenticated identifiers at
approval; bind the plan digest to those identifiers; re-verify at the
control-plane boundary before apply; reject redirects and rebinding
to different tenants.
Das Expires 29 April 2027 [Page 611]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Technical effect: Infrastructure changes are applied only in the
account, tenant and region that were approved, preventing cross-
environment and cross-tenant damage (tests TI15, TI16, TI17, TI18).
10.25. Model Hosting, Inference Providers and Model Routers
Product-relevant security problem: Applications increasingly route
requests across models, versions and providers for cost or
availability. A routing change, an updated system configuration or a
substituted model can change behaviour after an approval was given
for a specific model and configuration.
Technical alignment, potential deployment and limitations: Record the
model identity, version and material configuration as part of the
approved baseline where the deployment declares them material; have
consequential actions carry that baseline and refuse or re-qualify
when it differs.
Technical effect: Consequential actions are attributed to, and only
executed under, the model and configuration baseline that was
approved, supporting accountability when providers change models
(tests TI09, TI10).
10.26. Smart Home, Matter Devices and Device Aliases
Product-relevant security problem: Home assistants address devices by
user-assigned names. Re-pairing, renaming or adding a device can
make "living room" refer to a different device class, including a
lock or garage door.
Technical alignment, potential deployment and limitations: Bind the
resolved device identifier and device type to the command approval;
have the hub or device verify identifier and type before actuation;
require re-confirmation when a name now maps to a different device or
a higher-risk device class.
Technical effect: A command is executed only on the specific device
and device class that were intended, preventing alias rebinding from
turning a lighting command into a lock or door command (test TI17).
10.27. Automotive Assistants, Apple CarPlay, Android Auto and Over-the-
Air Tool Updates
Product-relevant security problem: Vehicle software and in-vehicle
assistant integrations are updated over the air. A queued remote
command or assistant action may execute after an update changed the
meaning or effect of the underlying function, or after a rollback to
a vulnerable version.
Das Expires 29 April 2027 [Page 612]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Technical alignment, potential deployment and limitations: Fence
queued commands by tool and software generation; reject commands
authorized under an earlier generation when the effect contract
changed; treat rollbacks as generation changes requiring re-
qualification.
Technical effect: Remote commands and assistant actions execute only
under the software generation for which they were authorized,
preventing stale-command execution after updates and rollback-based
downgrades (tests TI20, TI21).
10.28. Government Digital Identity and the EU Digital Identity Wallet
Product-relevant security problem: Wallet-based identity
presentations and signatures depend on correctly identifying the
relying party and the attributes requested. An agent assisting the
user could present credentials to a look-alike relying party or
approve a request whose attribute set changed.
Technical alignment, potential deployment and limitations: Bind the
authenticated relying-party identity and exact attribute request to
the user's approval; verify both at the presentation boundary; refuse
if either differs.
Technical effect: Credentials are disclosed only to the relying party
and attribute set that the user approved (tests TI05, TI18).
10.29. Summary of Technical Effects Across Industries
The following technical effects are the design objectives of the
tool-integrity mechanisms in this Part. They are stated as testable
properties linked to the proposed TI01 to TI30 tests; no measured
results are claimed in this revision.
1. Referent correspondence: the object actually acted on matches
the object the user saw and confirmed, and ambiguity leads to
refusal or re-confirmation (TI01 to TI05).
2. Tool-contract integrity: a tool whose description, schema or
declared effects changed cannot act under an earlier approval,
while declared-compatible upgrades continue to work (TI06 to
TI08).
3. Model and configuration continuity: consequential actions run
only under the approved model and configuration baseline where
that baseline is declared material, and optional baselines are
not wrongly enforced (TI09, TI10).
Das Expires 29 April 2027 [Page 613]
Internet-Draft Execution-Finality Part 7: Tools October 2026
4. Instruction-provenance containment: instructions from web pages,
repositories and tool outputs cannot by themselves authorize a
new consequential effect (TI11 to TI13).
5. Payload binding: a valid source grant does not authorize an
altered payload (TI14).
6. Resource, host and tenant identity: redirects, DNS rebinding,
alias rebinding and service substitution cannot move an effect
to a different resource or tenant (TI15 to TI18).
7. Attestation is not authority: an attested but unauthorized tool
still cannot produce the effect (TI19).
8. Update and rollback fencing: queued requests do not execute
across tool generations, rollbacks require re-qualification, and
unapproved dependencies are rejected (TI20 to TI22).
9. Single use and recovery: authority is consumed once under
concurrency, crashes do not resurrect it, and timeouts lead to
reconciliation rather than duplicate effects (TI23 to TI25,
TI29).
10. Cross-platform operation with honest limits: the controls work
through cooperating Android and iOS receivers, and alternate
paths on non-cooperating platforms are reported as coverage gaps
(TI26 to TI28).
11. Bounded verification: verification cost is bounded and cyclic
references are rejected, limiting denial of service (TI30).
11. Detailed Relevance to IETF Working Groups, RFCs and Related
Security-Engineering Work
Charters and RFC numbers below are included to help patent examiners
and engineers find accurate prior related work. Relevance is
technical, not a claim of charter adoption, IETF consensus or a new
protocol requirement. An IETF WG generally specifies narrow existing
protocol surfaces; effectuation policy, actual business-object
semantics and OS privilege enforcement often remain outside its
charter. If this individual submission later enters standards
discussion, each newly proposed wire-level object requires exact
syntax, interop behavior and security analysis.
Das Expires 29 April 2027 [Page 614]
Internet-Draft Execution-Finality Part 7: Tools October 2026
11.1. OAuth WG: structured authorization versus actual agent tool
consequence
Primary references: [RFC6749], [RFC9396], [RFC8707], [RFC8693],
[RFC9449].
Existing RFCs or current WG charter: OAuth Rich Authorization
Requests (RFC 9396), Resource Indicators (RFC 8707), Token Exchange
(RFC 8693) and DPoP (RFC 9449) support structured grants, audiences
and proof of token possession.
Specific interoperable relationship and limits: An agent can hold a
correct authorization token and still invoke the wrong method,
changed tool contract, resource version, recipient or tenant. This
draft proposes independent matching of the actual operation to source
grant and protected effect descriptor; reuse OAuth structures when
applicable rather than implying OAuth alone supplies sink-local
finality.
Working-group/document index: https://datatracker.ietf.org/wg/oauth/
about/
11.2. WIMSE WG: workload identity and execution context
Primary references: [WIMSE].
Existing RFCs or current WG charter: WIMSE develops workload
identity, cross-system propagation, authentication and token
exchange, including work on AI identity management.
Specific interoperable relationship and limits: Qualified workload
identity or signed service-to-service calls may authenticate the tool
caller. Part 7 additionally binds current tool capabilities,
instruction authority and actual targeted resource effect, which
workload identity alone does not necessarily establish.
Working-group/document index: https://datatracker.ietf.org/wg/wimse/
about/
11.3. RATS WG: verifier, attestation evidence and runtime state
Primary references: [RFC9334].
Existing RFCs or current WG charter: RATS Architecture RFC 9334
defines attestations, verifiers, relying parties and results.
Relevant active RATS work includes reference integrity and epoch
markers.
Das Expires 29 April 2027 [Page 615]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Specific interoperable relationship and limits: Attestation may
support current runtime/tool measurements or platform confidence; it
does not prove the correctness or authorization of each subsequent
consequential resource operation. State the exact attested property
and bind it to current tool generation and actual sink operation when
necessary.
Working-group/document index: https://datatracker.ietf.org/wg/rats/
about/
11.4. COSE and CBOR: authenticated action/contract descriptors
Primary references: [RFC9052], [RFC8949].
Existing RFCs or current WG charter: RFC 8949 defines CBOR
representation; RFC 9052 describes COSE structures usable to sign or
authenticate protected evidence.
Specific interoperable relationship and limits: Stable encoded
identity and contract evidence could be carried in COSE/CBOR with
explicit canonical serialization and protected audience/expiry; these
formats do not by themselves ensure a user-selected object equals the
resource ultimately modified.
Working-group/document index: https://datatracker.ietf.org/wg/cose/
about/
11.5. SCITT WG: signed statement transparency and software claims
Primary references: [SCITT].
Existing RFCs or current WG charter: SCITT addresses interoperable
signed statements and transparency receipts for software supply
chains and related trustworthy publication ecosystems.
Specific interoperable relationship and limits: Authenticated tool
releases, contract versions and provenance statements can inform
lifecycle qualification. A SCITT receipt indicates properties of a
registered statement, not an automatic grant to execute a particular
changed tool effect at a private resource.
Working-group/document index: https://datatracker.ietf.org/wg/scitt/
about/
11.6. SUIT WG: authenticated software update manifests
Primary references: [RFC9019].
Das Expires 29 April 2027 [Page 616]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Existing RFCs or current WG charter: SUIT specifies update manifest
formats and IoT software-update security mechanisms; artifact
provenance and update sequencing are directly relevant to tool
lifecycle transitions.
Specific interoperable relationship and limits: A valid update
manifest can support installation and provenance checks. Part 7 adds
fencing of previously prepared consequential Candidate Acts, current
loaded-runtime identity, and reconstitution of finality for current
tool-effect semantics.
Working-group/document index: https://datatracker.ietf.org/wg/suit/
about/
11.7. HTTPBIS: redirects, conditional requests and actual resource
selection
Primary references: [RFC9110].
Existing RFCs or current WG charter: RFC 9110 defines HTTP methods,
status, redirection and conditional request semantics; HTTP 202 and
many 2xx responses do not establish all downstream business effects.
Specific interoperable relationship and limits: Source-authorized
URL, recipient, resource version, redirects and actual receiving
tenant should be verified against operation-specific policy. Where
appropriate, If-Match and stable resource IDs help but do not
substitute for verifying actual source authorization and protected
finality.
Working-group/document index:
https://datatracker.ietf.org/wg/httpbis/about/
11.8. ACE WG: constrained device authorization
Primary references: [RFC9200].
Existing RFCs or current WG charter: ACE uses OAuth 2.0 in
constrained environments, RFC 9200, where resource servers and
transport have distinct identity/capability limits.
Specific interoperable relationship and limits: A protected device-
command or actuator gateway can combine ACE access control with exact
actual-command and receiving-device identity binding, subject to
resource limitations and trust assumptions.
Working-group/document index: https://datatracker.ietf.org/wg/ace/
about/
Das Expires 29 April 2027 [Page 617]
Internet-Draft Execution-Finality Part 7: Tools October 2026
11.9. TEEP and trusted execution interfaces
Primary references: [RFC9397].
Existing RFCs or current WG charter: Trusted Execution Environment
Provisioning is related to installing and managing trustworthy
components in selected protected execution substrates.
Specific interoperable relationship and limits: Protected deployment/
provisioning contributes evidence of the loaded component where
available. Part 7 distinguishes protected software lifecycle and
execution identity from separate act-bound effectuation authority;
non-TEE implementations remain possible.
Working-group/document index: https://datatracker.ietf.org/wg/teep/
about/
11.10. SEC-DISPATCH and Security Area review
Existing RFCs or current WG charter: Security-area dispatch supports
finding venues for security problems that span multiple protocols; no
working group should be described as sponsoring these individual
drafts absent adoption.
Specific interoperable relationship and limits: Part 7 frames cross-
cutting security questions around resource identity, tool-contract
semantics, action descriptors, provenance, machine-readable refusal
and non-bypassable resource-side enforcement. These topics may merit
coordination across OAuth, WIMSE, RATS, SCITT, SUIT and HTTP rather
than forcing all protocol changes into one WG.
Working-group/document index:
https://datatracker.ietf.org/wg/secdispatch/about/
12. Relevance to the EU Artificial Intelligence Act
Regulation (EU) 2024/1689 [EU-AI-ACT] sets obligations for providers
and deployers of certain AI systems and general-purpose AI models.
Whether an obligation applies to a given deployment depends first on
whether the system meets the definition of an AI system in Article 3
and then on its classification, for example as high-risk under
Article 6 and Annex III. A purely cryptographic or rule-based
enforcement component that performs no inference may itself fall
outside that definition while still operating inside a system that is
in scope. This section is a non-normative technical mapping. It is
not legal advice and makes no claim of conformity, certification, or
presumption of conformity.
Das Expires 29 April 2027 [Page 618]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Risk management (Article 9): the protected-execution workflows,
threat model, and falsifiable test plan in this series give a
documented and testable control for the risk that an AI agent or
assistant produces an unauthorized consequential effect, including
through reasonably foreseeable misuse such as prompt injection.
Record-keeping and traceability (Article 12): protected validation
evidence, sink-local decisions, consumption state, and qualified
actual-effect receipts yield operation-level records of what was
proposed, what was authorized, what was withheld, and what actually
took effect. Such records can support automatic logging and post-
incident traceability, subject to data-minimization requirements.
Human oversight (Article 14): the Non-Effective State and the scope-
deviation re-authorization latch provide defined points at which a
consequential action can be withheld, interrupted, or escalated to a
competent natural person. The Act does not require human approval of
every individual decision, and this architecture does not assume it;
oversight can be exercised through bounded source authority and
explicit scope-delta approvals.
Accuracy, robustness, and cybersecurity (Article 15): fail-closed
withholding, single-use consumption, anti-replay state, and
independent reconstruction of the actual pending operation at the
Finality Sink contribute to resilience against attempts by
unauthorized third parties to alter a system's use or outputs by
exploiting vulnerabilities, and they bound the consequences of
erroneous model output.
Deployer obligations (Article 26) and obligations for general-purpose
AI models with systemic risk (Article 55), including an adequate
level of cybersecurity protection, may also be relevant where
deployers integrate third-party agents into mobile or enterprise
workflows. Harmonised standards under Article 40 and the application
dates of individual obligations have been subject to change and must
be checked at the time of use. Related EU instruments, such as the
Cyber Resilience Act, the NIS2 Directive, the General Data Protection
Regulation, and the Digital Markets Act, may interact with
deployments on mobile platforms but are outside the scope of this
document.
13. Security and Privacy Considerations and Truthfulness of Enforcement
Claims
Das Expires 29 April 2027 [Page 619]
Internet-Draft Execution-Finality Part 7: Tools October 2026
13.1. Actual operation versus simulated or textual intent
Under the selected threat model, an untrusted agent may misdescribe
its pending act. Inspect material method, target, content and
resource identity from the protected receiving interface, not solely
the untrusted JSON argument.
13.2. Semantic inference and visual ambiguity
Do not assume every natural-language, multimodal or screen-state
reference can be uniquely or reliably resolved. A required uncertain
binding must preserve non-effectuation pending requalification.
13.3. Identity, provenance and authorization separation
Cryptographic signer identity, key possession, tool registry
signature, app permissions and protected attestation are useful input
properties, not a substitute for current competent grant and exact
effect matching.
13.4. Current policy, revocation and time
Verify current validity of tool contract, source authority, target
ownership and resource binding generations; offline or partitioned
situations may require bounded leases or withholding rather than
universal immediate revocation.
13.5. Atomic consumption and rollback
Prevent accepted-but-consumed finality references and outdated tool
generations from becoming reusable after concurrency races, snapshot
rollback, process restart or network timeout.
13.6. Confidentiality, privacy and retention
Captured UI context, document IDs, tool-output provenance, developer
repository paths and audit traces may expose protected data.
Minimize storage, encrypt relevant evidence, apply role-based audit
access and redact export fixtures.
13.7. Enforcement path coverage
External services and arbitrary mobile apps may lack a cooperative
protected gate. Avoid claiming non-bypassability when an
independently reachable alternate effect path remains active.
Das Expires 29 April 2027 [Page 620]
Internet-Draft Execution-Finality Part 7: Tools October 2026
13.8. Denial-of-service and verification exhaustion
Bound recursion in tool/alias graphs, redirects, provenance chains,
resource resolution, signature checks and policy cost. A watchdog
timeout must not release a prohibited consequence.
13.9. Third-party platform limits
Application-visible OS APIs may be insufficient to mediate device-
wide process execution. Privileged Android services, iOS
entitlements, hardware key/command gates and cloud resource controls
require actual permission and provider cooperation.
13.10. Source priority and added implementation material
The original page-indexed source and newly authored explanations/test
proposals have different possible public dates. Later text or
diagrams cannot establish that those exact features were included in
an earlier filed PCT merely because both appear together in a new
Internet-Draft.
14. Patent-Examiner and Industry Search Index: Embodiment-to-Page and
Figure Mapping
Embodiment 3 — User-Referenced Object, Presentation Evidence and
Actual Consequential Target: original global source pages 435–492,
PDF segment "TECHNICAL SPECIFICATION -1-554.pdf", exact section
anchors emb3-page-<global-page>; architecture fig-emb3-architecture
and operational flowchart fig-emb3-flowchart. Original PDF remains
the authoritative technical and filing source.
Embodiment 6 — Tool-Effect Contract Integrity and Semantic
Compatibility Across Updates: original global source pages 666–722,
PDF segment "TECHNICAL SPECIFICATION -555-1062.pdf", exact section
anchors emb6-page-<global-page>; architecture fig-emb6-architecture
and operational flowchart fig-emb6-flowchart. Original PDF remains
the authoritative technical and filing source.
Embodiment 10 — Algorithm, Model and Configuration Baseline
Continuity: original global source pages 926–994, PDF segment
"TECHNICAL SPECIFICATION -555-1062.pdf", exact section anchors
emb10-page-<global-page>; architecture fig-emb10-architecture and
operational flowchart fig-emb10-flowchart. Original PDF remains the
authoritative technical and filing source.
Embodiment 21 — Authenticated Resource Alias and Actual Resource
Identity Resolution: original global source pages 1758–1829, PDF
segment "TECHNICAL SPECIFICATION -1542-2011.pdf", exact section
Das Expires 29 April 2027 [Page 621]
Internet-Draft Execution-Finality Part 7: Tools October 2026
anchors emb21-page-<global-page>; architecture fig-emb21-architecture
and operational flowchart fig-emb21-flowchart. Original PDF remains
the authoritative technical and filing source.
Embodiment 24 — Instruction Provenance, Lower-Trust Influence and
Protected Downstream Tool Authorization: original global source pages
2019–2091, PDF segment "TECHNICAL SPECIFICATION -2012-2566.pdf",
exact section anchors emb24-page-<global-page>; architecture fig-
emb24-architecture and operational flowchart fig-emb24-flowchart.
Original PDF remains the authoritative technical and filing source.
Embodiment 26 — Tool Installation, Activation, Runtime Upgrade and
Rollback Fencing: original global source pages 2169–2245, PDF segment
"TECHNICAL SPECIFICATION -2012-2566.pdf", exact section anchors
emb26-page-<global-page>; architecture fig-emb26-architecture and
operational flowchart fig-emb26-flowchart. Original PDF remains the
authoritative technical and filing source.
Embodiment 34 — Dynamic Tool/Service Identity, Capability
Substitution and Alias-Rebinding Resistance: original global source
pages 2914–3005, PDF segment "TECHNICAL SPECIFICATION
-2567-3101.pdf", exact section anchors emb34-page-<global-page>;
architecture fig-emb34-architecture and operational flowchart fig-
emb34-flowchart. Original PDF remains the authoritative technical
and filing source.
Main searchable security-problem pairs: wrong document/resource after
user selection (Embodiment 3), API/tool semantic drift after update
(Embodiment 6), model/runtime baseline change (Embodiment 10), DNS/
object redirect alias rebinding (Embodiment 21), indirect prompt
injection and instruction provenance (Embodiment 24), malicious/
obsolete tool installation (Embodiment 26), and tenant, service-
instance or capability substitution (Embodiment 34).
The accompanying JSON source map records original global pages and
XML anchors. The set of source units does not purport to reproduce
every page of the complete 3,567-page specification; the remaining
embodiments are allocated to other parts. Cross-referencing one
mechanism does not make every optional implementation in the entire
series mandatory.
15. Foundational and Companion Internet-Draft Cross-References
Part 1 of 12 — Foundational Protected Consequence Authority, Shared
Definitions and Common Workflows CW-1/CW-2/CW-3: [DAS-FOUNDATION]
Part 2 of 12 — Secure iOS, Android and Cross-Platform AI-Tool
Interoperability: [DAS-INTEROP]
Das Expires 29 April 2027 [Page 622]
Internet-Draft Execution-Finality Part 7: Tools October 2026
Part 3 of 12 — Protected Authorization, Validation Evidence and
Scoped Finality Capabilities: [DAS-EVIDENCE]
Part 4 of 12 — Finality Sink Reconstruction, Protected Consumption
and Anti-Bypass Security: [DAS-SINK]
Part 5 of 12 — Multi-Agent Authority, Delegation, Conflicts and
Quorum Enforcement: [DAS-MULTIAGENT]
Part 6 of 12 — Authenticated Actual-Effect Receipts and Causal Phase
Continuation: [DAS-RECEIPTS]
Part 8 of 12 — Remote Effect Evidence, Distributed Transactions and
Recovery: [DAS-RECOVERY]
Part 9 of 12 — Credential Custody, Protected Disclosure and API
Security: [DAS-CREDENTIALS]
Part 10 of 12 — Cross-Device Migration, Source Revocation and Offline
Fencing: [DAS-REVOCATION]
Part 11 of 12 — Kernel, Sandbox and Hardware Execution-Finality
Enforcement: [DAS-HARDWARE]
Part 12 of 12 — Resource Governance, Cloud, Telecom and Critical
Infrastructure Security: [DAS-INFRA]
16. Informative References
[DAS-FOUNDATION]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 1: Foundational
Consequential Authority and Common Workflows", Work in
Progress, Internet-Draft, draft-das-interoperable-
consequence-authority-00,
<https://datatracker.ietf.org/doc/draft-das-interoperable-
consequence-authority/>.
[DAS-INTEROP]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 2: Secure iOS and
Android AI Tool Interoperability", Work in Progress,
Internet-Draft, draft-das-cross-platform-ai-
interoperability-00, <https://datatracker.ietf.org/doc/
draft-das-cross-platform-ai-interoperability/>.
Das Expires 29 April 2027 [Page 623]
Internet-Draft Execution-Finality Part 7: Tools October 2026
[DAS-EVIDENCE]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 3: Protected Source
Authority, Cross-Committed Evidence, and Scoped Non-Bearer
Finality", Work in Progress, Internet-Draft, draft-das-
protected-authority-evidence-00,
<https://datatracker.ietf.org/doc/draft-das-protected-
authority-evidence/>.
[DAS-SINK] Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 4: Finality Sink
Enforcement, Actual-Operation Reconstruction, and Anti-
Bypass Security", Work in Progress, Internet-Draft, draft-
das-finality-sink-enforcement-00,
<https://datatracker.ietf.org/doc/draft-das-finality-sink-
enforcement/>.
[DAS-MULTIAGENT]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 5: Multi-Agent
Delegation, Conflict Arbitration, and Quorum Authority",
Work in Progress, Internet-Draft, draft-das-multi-agent-
authority-control-00, <https://datatracker.ietf.org/doc/
draft-das-multi-agent-authority-control/>.
[DAS-RECEIPTS]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 6: Verified Actual-
Effect Receipts and Protected Causal Continuation", Work
in Progress, Internet-Draft, draft-das-causal-effect-
receipts-00, <https://datatracker.ietf.org/doc/draft-das-
causal-effect-receipts/>.
[DAS-RECOVERY]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 8 of 12 — Remote
Effect Evidence, Distributed Transactions and Recovery",
Work in Progress, Internet-Draft, draft-das-distributed-
effect-recovery-00, <https://datatracker.ietf.org/doc/
draft-das-distributed-effect-recovery/>.
Das Expires 29 April 2027 [Page 624]
Internet-Draft Execution-Finality Part 7: Tools October 2026
[DAS-CREDENTIALS]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 9 of 12 — Credential
Custody, Protected Disclosure and API Security", Work in
Progress, Internet-Draft, draft-das-agent-credential-
privacy-00, <https://datatracker.ietf.org/doc/draft-das-
agent-credential-privacy/>.
[DAS-REVOCATION]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 10 of 12 — Cross-
Device Migration, Source Revocation and Offline Fencing",
Work in Progress, Internet-Draft, draft-das-cross-device-
authority-revocation-00,
<https://datatracker.ietf.org/doc/draft-das-cross-device-
authority-revocation/>.
[DAS-HARDWARE]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 11 of 12 — Kernel,
Sandbox and Hardware Execution-Finality Enforcement", Work
in Progress, Internet-Draft, draft-das-hardware-execution-
finality-00, <https://datatracker.ietf.org/doc/draft-das-
hardware-execution-finality/>.
[DAS-INFRA]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 12 of 12 — Resource
Governance, Cloud, Telecom and Critical Infrastructure
Security", Work in Progress, Internet-Draft, draft-das-
autonomous-infrastructure-finality-00,
<https://datatracker.ietf.org/doc/draft-das-autonomous-
infrastructure-finality/>.
[ZENODO] Das, S., "iOS and Android Interoperability for Secure
Third Party AI Tools - Cross-Platform Execution Finality,
Hardware Security, and Interoperability (3,567-Page
Specification)", DOI 10.5281/zenodo.23657985, October
2026, <https://zenodo.org/records/23657985>.
[PCT-055615]
Das, S., "Published international application WO
2026/150382 (PCT/IB2026/055615)", 2026,
<https://patentscope.wipo.int/search/en/WO2026150382>.
Das Expires 29 April 2027 [Page 625]
Internet-Draft Execution-Finality Part 7: Tools October 2026
[RFC8179] Bradner, S. and J. Contreras, "Intellectual Property
Rights in IETF Technology", RFC 8179, BCP 79,
DOI 10.17487/RFC8179, May 2017,
<https://www.rfc-editor.org/info/rfc8179>.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/info/rfc9396>.
[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
February 2020, <https://www.rfc-editor.org/info/rfc8707>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.
Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/info/rfc8693>.
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/info/rfc9449>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 8949, STD 94,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", RFC 9052, DOI 10.17487/RFC9052,
August 2022, <https://www.rfc-editor.org/info/rfc9052>.
[RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP
Semantics", RFC 9110, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
Das Expires 29 April 2027 [Page 626]
Internet-Draft Execution-Finality Part 7: Tools October 2026
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/info/rfc9200>.
[RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A
Firmware Update Architecture for Internet of Things",
RFC 9019, DOI 10.17487/RFC9019, April 2021,
<https://www.rfc-editor.org/info/rfc9019>.
[RFC9397] Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
"Trusted Execution Environment Provisioning (TEEP)
Architecture", RFC 9397, DOI 10.17487/RFC9397, July 2023,
<https://www.rfc-editor.org/info/rfc9397>.
[WIMSE] Internet Engineering Task Force, "Workload Identity in
Multi System Environments (wimse) Working Group",
<https://datatracker.ietf.org/wg/wimse/about/>.
[SCITT] Internet Engineering Task Force, "Supply Chain Integrity,
Transparency, and Trust (scitt) Working Group",
<https://datatracker.ietf.org/wg/scitt/about/>.
[EU-AI-ACT]
European Parliament and Council of the European Union,
"Regulation (EU) 2024/1689 of the European Parliament and
of the Council laying down harmonised rules on artificial
intelligence (Artificial Intelligence Act)", 13 June 2024,
<https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.
Author's Address
Sangam Kumar Das
Independent Researcher
Balasore
Odisha
India
Email: info@sangamdas.com
Das Expires 29 April 2027 [Page 627]